Fixing the architecture as we go may work in pure software systems but fails in systems that include mechanics and electronics.
When I wrote my first book in the 1990s, it was on software architecture. The central tenet at that time was that we had to be careful and intentional about the initial design of the architecture as subsequent changes were considered to be impossibly difficult. So, as a community, we developed techniques to assess architectures, determine the impact of design decisions, predict maintenance costs and so forth.
With the advent of Agile, the focus on software architecture was intentionally removed by the proponents as the notion of upfront architecture design went against the Agile principles of working software every sprint and responding to change in a fast and agile fashion. And lo and behold, we realized that it’s entirely feasible to undo and replace architecture design decisions in systems that have lots of functionality implemented already. Out of this grew the architecture technical debt community and the focus on architecture refactoring as a continuous process for every software-intensive system.
One of my concerns with the Agile paradigm is that it ignores architectural questions, considering them out of scope. Of course, we’ve compensated for that and added architecture activities, but the challenge remains: the paradigm doesn’t provide a constructive way to deal with architecture beyond the principle of fixing it as you go. That principle works for systems that are purely software, but when there are mechanical and electronic components present, it breaks down.
The notion of system architecture is central to Radical as it puts boundaries between areas of functionality where we can be quick and nimble and areas where we need to predict future needs, commit to hard change decisions and work our way around the resulting limitations. In many of the companies I collaborate with, there’s a bit of an antagonistic relationship between the people working with atoms and those working with bits. However, any system incorporates both, so we need to ensure that we carefully design the interface between the atoms and the bits to maximize positive business outcomes and maintain as much future optionality as possible.
For some reason, many system architects have their roots in mechanical or electronics engineering. This often leads to a tendency to consider software, data and AI to be in service of the mechanics and electronics. In a rapidly digitalizing world, this is where I disagree: the atoms need to be architected to support the bits rather than the other way around. This means, among others, ensuring enough memory and computer ‘headroom’ so that we can offer software updates throughout the economic life of the system. In addition, if we want to get any data out and new software and AI models in, connectivity is a critical element. Finally, whenever there’s a choice to realize functionality in mechanics or electronics or in software or machine learning models, the latter should be prioritized as it provides more flexibility and the ability to provide post-deployment updates.
Similar to any architect role, the role of a system architect is to predict where the business will take itself and prepare the system architecture to optimally support the most likely business strategies. This has at least three main implications: platforms, upgradeability and the ecosystem.
First, as the mechanics and electronics need to be in service of the software and the machine learning models, we need to minimize the amount of unnecessary variability between different products the company puts on the market. Earlier, this was less of a concern as we had to do verification and certification only once, but with the adoption of DevOps, every point of variability is expensive as it needs to be considered for every release of new software. The best way to accomplish this is to organize the entire product portfolio as a superset platform where every product is a configuration of the platform components.
The benefit of a superset platform is that testing, verification and certification can be done for the platform rather than for each product derived from it. Done right, this requires less effort, time and resources and enables DevOps in contexts where it would be prohibitively expensive for individual products.
Second, the question of upgradability often goes along the atoms-versus-bits line. Many reason that it’s cheap to upgrade software, hence DevOps, and prohibitively expensive to upgrade anything atoms. In practice, it’s not as black and white. Virtually any system including atoms has some form of maintenance associated with it. Replacing some of the electronics with a higher-performance alternative during scheduled maintenance windows isn’t necessarily free but may well be worth the effort to extend the system’s economic life and increase the opportunities for continuous revenue.
Especially for systems with a long lifetime of one to three decades, the cost of putting bleeding-edge technology in at the time of initial deployment with the intent of providing headroom for a lifetime of updates is likely higher than a model where the electronics is replaced every couple of years and we use mainstream, low-cost solutions every time.
The third dimension to consider as part of the system and software architecture is the ecosystem. Many companies seek to open up some aspects of their offerings so that customers or third parties can build integrations and extensions beyond the base product functionality. This requires architects to define interfaces that can be used by these parties. The broader the access to an interface, however, the more stable it has to be as the cost of evolving it doesn’t just concern internal R&D activities but also forces customers and third parties to invest in evolving.
What aspects of the system to open up and how to open up is a business strategy decision that’s realized through architectural means. This is, once again, one of the areas where the interdependence between business strategy and architecture is very strong. Architects need to focus as much on the business implications of the interfaces that they design as they need to ensure functionality, safety and security.
The Agile paradigm largely ignores the notion of architecture and encourages us to fix things as we go. This may work to some extent in pure software systems but fails in systems that include mechanics and electronics. In these cases, we need to design the system architecture in such a way that (1) the atoms are in service of the bits, (2) we organize the system portfolio in a superset platform, (3) we support upgrades of software and machine learning models as well as electronics and, where necessary, mechanics throughout the economic life of systems and (4) we open up to the ecosystem of customers and third parties around us in line with the business strategy we’ve chosen. To end with a quote from Norman Fisher: “As an architect, you design for the present with an awareness of the past for a future that’s essentially unknown.”
