When is it time for a new architecture?
The architecture of a system represents its framework and should not actually change much over time. Nevertheless, there are good reasons to do so from time to time. One of the most impressive examples of the successful modification of an architecture is the SpaceX Raptor Engine. The cover picture shows the evolution of this rocket engine over three architectures.
The following article deals with the guiding principles that help to determine when a new architecture makes sense and when it does not.
Architecture and design
There are different definitions for system architecture. The NASA handbook, for example, defines architecture as the structural design of a system that describes how different elements interact to fulfill requirements. INCOSE sees architecture as an abstract representation that describes the structure, behavior and properties of a system. I often use the following definition:
System architecture is the structural framework that defines the organization and interactions of the design elements and enables their decoupling.
Michael Jastram
This means that the design can be developed and replaced quickly and easily, but the architecture cannot.
The following picture is from the article Systems Engineering at SpaceX. It shows very nicely the evolution of the design of a control unit. The old design can easily be replaced by the new one, the architecture of the overall system does not change. However, the control unit itself is a Black Boxwhich has its own (hidden) architecture. Without knowing the inner workings, I assume that the architecture of the control unit has changed considerably, if only because of the new form factor.
Why change at all?
In an ideal world, we would of course immediately take the perfect architecture and implement the perfect design, so that no changes would be necessary. However, handling changes with confidence is one of the most important aspects of systems engineering.
At the business level, competitiveness is the main reason for changing a system. With the changes, we improve quality by removing bugs and improving performance. We reduce costs and perhaps also implement new features. The decision-makers don't care whether we change the design or the architecture to achieve these goals.
Design changes are easily...
However, a design change can be made quickly and, with a good architecture, has little impact on other parts of the system. Innovative companies therefore make (more or less) continuous design changes. However, these typically do not appear immediately in the customer product (deployment), but initially remain in the development process, where they can be tested as part of an internal release.
Release and deployment are not the same thing.
However, companies that carry out frequent deployments are generally faster and more innovative. It is not uncommon for software companies to have dozens of deploys per day. These are usually design updates, or even just updated libraries. Especially with smartphone apps, we can observe that new versions are regularly released with meaningless descriptions such as:
This release includes stability and performance improvements
Typical release notes for a smartphone app
This often indicates that nothing has changed for the user, but that the libraries have been updated, often to close new security loopholes. Thanks to semantic versioning this is now also very robust.
Changing the design of physical systems is not so trivial, although here too we need to distinguish between software and non-software. More and more physical systems are now regularly updating their software design, and have been doing so for a long time. I remember the release of Wi-Fi 4 in 2009, and because standardization took longer, some manufacturers initially launched routers without Wi-Fi 4 support. However, these could later be retrofitted via a firmware update in order to use the new functions.
Design updates of physical systems during operation are also possible, but expensive. This is experienced BMW at the moment, which is currently conducting a recall for 150,000 vehiclesto replace the electronics in some of these vehicles for safety reasons.
... Architectural changes difficult
Architecture changes, on the other hand, are extremely complex and can almost be compared to a new development. This is why companies do not implement architecture changes lightly. There must be a business case for the decision-makers. In other words, the new architecture must bring significant benefits to make the investment worthwhile.
This certainly explains the German automotive industry's attitude towards electrification: the combustion engine is the central element in which manufacturers have amassed enormous intellectual property and which has made German cars unique on the global market. Until recently, the business case for a new all-electric architecture seemed weak to decision-makers. That's why manufacturers had made several (unsuccessful) attempts to build an electric car by changing the design rather than the architecture, like the BMW E1 or Opel Astra Impuls from the 1990s.
Electrification through design changes is possible: Gasoline engine out, electric motor in. But a saleable electric car needs a completely new architecture.
Architectural changes need a business case
And that brings us back to the question from the beginning: developing a new architecture is a strategic decision that requires a solid business case. In the case of electric cars, the pressure comes from outside: the competition shows that it works, customers show that they want it.
The pressure can also come from within. Apple's decision to start developing the M1 chips to use a new architecture for their devices. In doing so, the company decoupled itself from Intel and enabled energy efficiency with high performance that would not have been possible with Intel.
SpaceX Raptor Engine
At first glance, you can't tell what architecture is behind an Apple MacBook. The SpaceX Raptor Engine (cover image), on the other hand, does, which is why it is a good example of impressive architecture (no matter what you think of it). ElMo holds).
The Raptor Engine is special in that (1) it is still under development and (2) the engine is only used for exactly one type of rocket from the same company. But even this does not change the fact that there must be a clear business case for SpaceX to change the architecture for the second time.
And the business case is there, as the following X-post shows: an increase in thrust of over 50%, weight reduction of over 25%, or over 50% if you look at the overall propulsion system, as the heat shield is eliminated. This is very nicely summarized in this article. The business case is obvious in aerospace, where weight and thrust are essential metrics.
Conclusion
Companies today need to be agile in order to remain competitive. This includes regular changes to the design, but not the architecture.
Architecture changes, on the other hand, are risky and expensive. Companies should only take this step if the business case is clear and if they have the appropriate maturity in development.
Image source: SpaceX via X
