While the last posts were about the business dimension of digitalization, there obviously is a technology side to it as well. Digitalization requires the company to build new technical capabilities, specifically around the use of data and artificial intelligence, but the primary challenge is, in my experience, concerned with system and software architecture.
The system and software architectures embed the key decisions about the business of the organization and how we deliver value to customers. And although the architecture isn’t immutable, it’s often more expensive to change the architecture than other aspects of a system, such as features and interfaces. Also, as few of us ever have the opportunity to start from a greenfield situation, we’ll need to evolve the current architecture to facilitate the digital transformation. Architecture transformation tends to be slow and time consuming as many architecture design decisions have implications throughout the system and removing these is very demanding.
Especially in embedded or cyber-physical systems, the traditional approach was to force the software to follow the mechanical and electronics lifecycle. Similar to leaving mechanics and electronics unchanged after the start of production, the software is typically updated as little as possible too. This allows architects to build all kinds of dependencies in the architecture as these will incur a quality assurance cost only once.
With digitalization, we seek to improve the delivered value continuously through digital means, including updating the software and AI models as well as using data analytics to optimize the performance of the system. This has implications on the system architecture as it requires the mechanical and electronics parts to be designed to optimally support continuously improving value delivery. Suddenly, the atoms are in service of the bits instead of the other way around.
The implications on the architecture are, at least, threefold: platformization, modularization and instrumentation. First, the transition from delivering software for products once or infrequently during their lifetime to continuous updates easily becomes prohibitively expensive in case each product or each customer-specific instantiation of a product is treated as a separate, unique entity. Instead, we need to adopt a “superset platform” approach where all products and all product variants are configurations of the platform. All functionality delivered to customers lives in this one platform and all additions are made to the platform. This allows for a much higher degree of automation of quality assurance and deployment, but it has significant architectural implications. The architecture needs to support the superset of functional and quality requirements as well as a mature approach to managing variability.
Second, as most systems, especially in embedded contexts, are large and complex, we need to shift away from the traditional approach of shutting down the system, updating the entire software and restarting the system. In the case of DevOps, this causes too much system downtime and will lead to customers resisting upgrading their systems regularly. Instead, we need to support the independent deployment of components. This requires a modularization of the architecture to allow the system to function properly even if the components that make up the system are of different generations and versions. This in turn requires defensive approaches for component interfaces as well as maintaining multiple interfaces for the component to support different system configurations.
Finally, one of the key elements of digitalization is the use of data from the field for analytics and machine learning, both centrally and in the deployed systems. This requires the architecture to support easy instrumentation of components, features and interfaces. As it’s impossible to predict what the company might want to collect in terms of data, it’s critical to be able to easily add various types of instrumentation to the system as part of the DevOps cycle. In addition, as the amount of data generated in various parts of the system might be quite significant, some of the processing of this data needs to be done locally to decrease dependency on a centralized system.
Digitalization also has implications for the system and software architectures. The transition to continuous value delivery requires, especially for embedded systems, a kind of Copernican revolution in the system architecture where the atoms need to support the bits, rather than the other way around. This requires three main architecture changes: adopting a superset platform approach, significantly strengthened modularization of the system and mechanisms for easy incorporation of instrumentation as well as data processing functionality. To paraphrase Winston Churchill, we shape our architectures, but then our architectures shape us. So, design the architecture supporting your digital transformation carefully.
Like what you read? Sign up for my newsletter at jan@janbosch.com or follow me on janbosch.com/blog, LinkedIn (linkedin.com/in/janbosch), Medium or Twitter (@JanBosch).
