As someone who works with the bits, ie software, data and AI, I’m often annoyed by the constraints that atoms enforce on products. Whereas it’s easy, or at least doable, to adopt DevOps, DataOps and AIOps, achieving the same for the mechanical and electronics parts of our systems often proves to be impossible or prohibitively expensive.
Occasionally, I meet systems engineers and architects who basically shrug their shoulders and claim that this is simply how things are and that trying to change reality is simply a Don Quichotte style of fighting windmills. The response I sometimes get is that they would like to be left alone to do their thing on the ‘atoms’ side and would prefer to ignore everything that’s happening on the ‘bits’ side.
The fact of the matter is that digitalization is a fundamentally new way of delivering value to customers. Rather than buying a widget, using it for a while and then replacing it with the next widget, we’re looking to build a relationship with our customers where the monetization is continuous. And for customers to accept paying continuously for the offering, we need to continuously improve it.
This is especially the case when the business model includes both an upfront, transactional part and a continuous part. In those cases, customers often feel that since they already paid for the initial product, there’s no need to keep paying unless there’s significant value delivered in return for the continuous flow of funds they’re asked to part with.
For systems engineering, this has at least three major implications: focus on lifetime value rather than bill of materials, technology selection in favor of continuous evolution and the adoption of architectonics in the system architecture.
First, traditionally, systems engineering was often focused on minimizing the bill of materials. If you manufacture a million widgets and you can save one euro on the bill of materials, you’ve made the company a million euros. The logic is so straightforward that I’m almost embarrassed to write it down. However, this often leads to a situation that also the electronics in the product are squeezed to the point that there’s hardly any headroom from a computational and storage perspective. This results in a situation where even if there are new features that customers would be willing to pay for, the lack of headroom makes it impossible to deploy new software versions. The focus on minimizing the bill of materials simply eradicates any opportunities for post-deployment delivery of value to customers and, consequently, monetization.
Second, although many system architects and systems engineers are becoming more enlightened, it’s long been the case that these individuals started as mechanical or electronics engineers and consequently had little affinity with software. This often leads to a situation where functionality is mapped to the technologies the architect is familiar with, eg electronics, and consequently frozen at the start of production. Systems engineering needs to focus on always selecting the technology that provides the most post-deployment flexibility. This could be to assign many features to software, but it can also mean selecting FPGAs instead of ASICs as the firmware in FPGAs can be updated post-deployment whereas an ASIC is frozen at production.
Third, there’s a principle in architecture that’s often referred to as architectonics, meaning the structuring of a system in ways that put things that change at the same frequency together. For instance, for a house, the fundament is typically immovable, but the non-bearing walls can be moved without too much impact. It’s entirely feasible to architect systems in the same way. This would allow us to upgrade parts of the electronics and mechanics during the economic lifetime of the system while leaving the rest of the ‘atoms’ unaffected.
For example, in the automotive industry, it’s long been discussed to conduct an upgrade of the electronics in new vehicles after the first two or three years when cars come out of their leasing contracts and go on the private market. That would allow car companies to continue to sell updates and upgrades long after the car was manufactured. And, of course, it allows them to put less expensive electronics in the vehicle from the beginning as this will be replaced anyway a few years in.
We need to reframe how we reason about our offering. Traditionally, the offering was intended as a transaction where the customer bought the widget, used it up and bought a replacement some years later. Now, we want to create a continuous customer relationship that allows for continuous value delivery and monetization. This requires us to justify the continuous payments, especially if customers are asked to also pay an upfront transactional fee. This justification typically centers around providing additional functionality and features over time. Accomplishing this requires some fundamental changes to how we conduct systems engineering, specifically focusing on optimizing total lifetime value, maximizing the amount of functionality that can be updated post-deployment and applying the principles of architectonics. To quote Mark Twain, “continuous improvement is better than delayed perfection.” That’s true for products as well as humans.
Want to read more like this? Sign up for my newsletter at jan@janbosch.com or follow me on janbosch.com/blog, LinkedIn (linkedin.com/in/janbosch) or Twitter (@JanBosch).
