For more than a year now, I’m working as a system designer, which roughly means being responsible not for a product or product line, but for a system to which different products are integrated. So I’d like to share my first reflections.

There are definitions of system architecture contrasting it to software architecture. They revolve around multiple disciplines (e.g. software, electronics, hydraulics and pneumatics of an electric train) and systems comprising multiple pieces of SW. These definitions are tricky to make, as everything including ourselves are systems and every system is part of a larger system. I give a new definition: If software architecture is the set of design decisions that are costly to change^[1]loosely paraphrased from Grady Booch, system architecture comprises the design decisions that are practically impossible to change.

This impossibility arises from the fact that the impact of these design decisions’ goes beyond one piece of software to other pieces of SW and components from other disciplines. Within a software, we could theoretically change the architecture of the SW after some difficult convincing of the higher management etc. In a system, we’d need to go out of our organization and convince the users, integrators, other SW teams and companies, electronics designers. You also need to change existing systems in the field^[2]For this discussion, it helps to make the distinction between the organization in which the software is developed and the field, where other organizations such as other suppliers, partners, users, … Continue reading. This makes the change practically impossible. Take for instance Japan’s electricity grid, of which one part operates with 50 Hz and the other with 60 Hz, so energy cannot be balanced easily among both, and no one can rectify this discrepancy, due to the design decisions in the 19th century.

Practically impossible means actually that some time in the future, theoretically, you can change the system-level design decisions. Products in the system will be phased out, some compatibility aspects will not have the value they once had, and most importantly the burden of the outdated design decisions will get much heavier. So, over decades, you may change those with careful planning and communication. But a decade is a long-time in the SW business.

In short, every introduced design decision will remain practically forever. Under these circumstances, the primary concern of system architecture becomes avoiding painting yourself into a corner. In other words, the absolute priority of keeping the system functional and compatible renders other concerns (e.g. other NFRs) less important. Furthermore the making of design decisions is also slowed down, where in contrast, it is increasingly the trend in SW architecture to go to market as quickly as possible first, and then adapt the architecture according to the feedback from the field.