Software Architecture

Development Process

By Kees Jan Koster

Kees Jan Koster

Published

22.05.2022

The development process for Architecture Zero is mostly what would be considered common in current software development teams and for open source projects. GIT, code reviews, transparency on code and implementation are central to the way we work.That said, the development process for Zero has to facilitate customs and processes that are common in marine and industrial settings. In such a setting, code typically gets written and maintained by a single person or a few people. The PLC development methodologies are slowly adopting the same practices that more general software teams use, but at the time of this writing there is still a gap.This chapter discusses how these concepts apply to Architecture Zero and how we balance the needs of the partners in the project. It proposes we adopt an open source style development methodology, with clear boundaries in ownership, so that everyone's intellectual property is respected, but does invite partners to consider adopting open source style development practices.

Code Changes and Code Review

As is common in the software industry, we rely on transparency to safeguard the quality of changes, rather than putting barriers to code changes. Conceptually, everyone is free to make changes to the code, but for each piece of code there is a review process. Contrast this to a typical system in an industrial setting, where only the supplier has the means to make changes. The same objective is achieved: well considered and safe code changes. However, this is done by bottlenecking on a supplier, rather than relying on transparency and code review. Big and small changes are requested of a supplier, who returns with a new version of the system.

In practice, we find that most if not all changes are still performed by the original supplier of the code. It is just that others have the option to contribute and even make change requests in the form of code patches. This speeds up the development process for the supplier. It also allows developers to communicate change requests in an unambiguous, formal language i.e. the programming language, instead of having to deal with the ambiguity that natural languages bring.

Code reviews are performed for all code by experts on the subsystem.

Safeguarding Integrator Responsibility

There is a good reason why system integrators keep close control over the source code and deployment: they have a contractual obligation to resolve problems and issues that arise from changes. This makes system integrators reluctant to allow other parties access to systems that they carry that responsibility for. Others may be unaware of the finer points of the systems and may inadvertently introduce errors. The integrator typically keeps the code closed to prevent this from happening.

A downside of the access restrictions is that the integrator may form a bottleneck for changes, which is not desirable. On top of that, this way of working fosters walled gardens in the systems, where one party cannot participate in the development of other party's systems. The development process for Architecture Zero safeguards the integrity of the system and the responsibility of the integrator in full transparency and without causing such bottlenecks.

Base Review Process

The base review process is shown below, showing the developer of the code to the left, the owner's team in the middle and the system integrator to the right. The "critical section" is where the system integrator fulfils their contractual responsibility. All changes are fed into that "review and accept" step, where the system integrator performs a final assessment of the changes, and may veto any changes that are not at the right level of quality.

Let's look at the same process from the perspective of the GIT repository. In this diagram, all parties may submit changes to the source code in GIT. This is shown on the left of the image. Note how changes in GIT do not reflect on the live systems until after a review and after acceptance and deployment by the system integrator.

Review Process for Integrator Changes

In case the integrator themselves are making changes, all changes are reviewed by the owner's team as well as by the integrator themselves. The integrator is expected to

Review Process for Owner's Team Changes

In case the owner's team want to make their own changes, the process looks a lot the same, except there there is no third party developer involved.

Review Process for Hotfixes

Finally, in case there is a calamity where the engineer absolutely needs to make changes to the live system without following the expected process.

Note that these steps are not an acceptable way to speed up the development process. It is only to be used in situations where the system integrator cannot support the engineer and follow the regular process quickly.

As shown in the diagram, code review and GIT operations are still performed, but retroactively instead of acting as a gatekeeper. In this exceptional case, the review process acts as a safety net. Hotfixes are typically drafted under pressure and it is good to perform a review once the dust has settled.

Source Code Organisation

Code is organised in a central GIT repository. We use the so-called mono-repository model, where all code from all subsystems is collected into a single, giant GIT repository.

The GIT repository is owned by the project, not the suppliers. This ensures continuity over the lifetime of the project.

UTF-8

Unless there is a good reason not to, all source code and supporting files are stored in UTF-8 format. This ensures that we have the ability to use text in all languages.