Systems Engineering in a Service-Driven World

In an earlier post, I have brought up some of my frustrations with traditional approaches to systems engineering. That led to quite a bit of discussion and emailing back and forth with various folks. For those that did not read the post, my problem with traditional system engineering include at least the following concerns: (1) meaningless mechanical and hardware variants without business value, (2) system architectures with high coupling, (3) a complete disregard of backward compatibility during system evolution, (4) lack of abstraction mechanisms and (5) a general tendency to blame software for everything that is wrong with the system.

During the last months, in my engagement with various companies, I have been testing and discussing an alternative perspective on systems engineering, intended for a world in which systems are deployed as services and monetized through subscription. One of the main differences between a traditional product business and a services business is that the products created by the company turn from revenue and profit drivers to cost factors. For instance, when a car company converts itself into a mobility services company, the cars that used to drive revenue and profit now are costs that the company will seek to minimize.

When a company offers its products as services, the expectation of customers is that the offering gets better over time. Similarly, the company will seek to decrease its cost by deploying new software into the product frequently and measuring how the product is used as this helps to align internal R&D investments with the key differentiators for customers. And, of course, the longer I can keep a physical product out in the field while it delivers acceptable service for customers, the lower my cost will be.

One approach to systems engineering is to separate the mechanics and electronics from the software and operate both as two independent, though related, release processes. So, everything atoms is engineered in the traditional product-centric, waterfall style and everything bits is built iteratively and deployed frequently. This requires architecting a stable interface between the atoms and the bits, but once in place, the two engineering processes can largely operate in isolation.

Although this works and some of the companies that I work with operate in this way, the challenge is that some features require both atoms and bits in order to deliver value to customers. In many of my posts I take the position that in this new world it’s the bits that are differentiating and the atoms are commodity. However, this is of course an oversimplification. The fact is that customers have “jobs” that they are looking for having realized by our product or service. As the saying goes: Nobody buys a drill for its own sake; The job is to get a hole in one’s wall and the drill is bought to get that job done. To deliver solutions to the “jobs” that our customers have, it’s not about bits versus atoms, but about the best combination of bits and atoms to optimally meet customer needs.

So, a second perspective on systems engineering is to think about a stream-based systems engineering approach where software, electronics and mechanics all are system elements that just happen to evolve and deploy on different timelines. In practice, software may deploy every day or every agile sprint. Electronics may evolve in a quarterly or half-yearly heartbeat, whereas mechanics may evolve yearly or every two years. In the figure below, I tried to graphically illustrate this.

Figure: Illustrating an alternative systems engineering perspective

Products are initially composed by picking from available versions of the mechanical, electronic and software components available. Once deployed in the field, the software in these products is deployed constantly. Whenever the electronics in the product runs out of computing power or storage space, the electronics is replaced. This perhaps happens every 6-12 months. Finally, mechanical parts of the system may be upgraded every couple of years.

Although the model that I describe here is highly conceptual and needs a lot more details for a company to implement, it addresses the concerns that I have experienced with traditional systems engineering: mechanical and electronics variants are only created when there is business value and need to adhere to the system architecture interfaces and, consequently, are freely exchangeable. This focus on interchangeability forces a high degree of architecture decoupling at the system level. Also, it forces a culture where only the highest priority cross component dependencies are allowed, which requires a significant increase in abstraction levels on interfaces. Finally, as mechanics, electronics and software evolve in parallel and largely independent from each other, the blame culture can be replaced with a collaborative one where new functionality can be realized by mechanics and electronics and then gradually and iteratively be exposed to customers as a mechanism to make the service better continuously.

Concluding, the old perspective on systems engineering suffers from significant problems, especially in a world where products are increasingly provided as services. An alternative, integrated perspective on systems engineering where each discipline operates in an iterative process, but with different heartbeats, provides a much better approach to align the different technologies in a system. Here, I only scratch the surface of this alternative approach, but shared at least some of the key characteristics. As always, let me know what you think? What are your experiences?

Follow me on  janbosch.com/blog, LinkedIn (linkedin.com/in/janbosch) or Twitter (@JanBosch)! And you might like www.software-center.se!