{"id":1950,"date":"2024-09-09T08:13:58","date_gmt":"2024-09-09T08:13:58","guid":{"rendered":"https:\/\/janbosch.com\/blog\/?p=1950"},"modified":"2024-09-09T08:13:59","modified_gmt":"2024-09-09T08:13:59","slug":"from-agile-to-radical-systems-engineering","status":"publish","type":"post","link":"https:\/\/janbosch.com\/blog\/index.php\/2024\/09\/09\/from-agile-to-radical-systems-engineering\/","title":{"rendered":"From Agile to Radical: systems engineering"},"content":{"rendered":"\n
\"\"
Image by Herbert Aust from Pixabay<\/figcaption><\/figure>\n\n\n\n

As someone who works with the bits, ie software, data and AI, I\u2019m often annoyed by the constraints that atoms enforce on products. Whereas it\u2019s 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.<\/p>\n\n\n\n

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 \u2018atoms\u2019 side and would prefer to ignore everything that\u2019s happening on the \u2018bits\u2019 side.<\/p>\n\n\n\n

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\u2019re 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.<\/p>\n\n\n\n

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\u2019s no need to keep paying unless there\u2019s significant value delivered in return for the continuous flow of funds they\u2019re asked to part with.<\/p>\n\n\n\n

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.<\/p>\n\n\n\n

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\u2019ve made the company a million euros. The logic is so straightforward that I\u2019m 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\u2019s 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.<\/p>\n\n\n\n

Second, although many system architects and systems engineers are becoming more enlightened, it\u2019s 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.<\/p>\n\n\n\n

Third, there\u2019s a principle in architecture that\u2019s 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\u2019s 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 \u2018atoms\u2019 unaffected.<\/p>\n\n\n\n

For example, in the automotive industry, it\u2019s 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.<\/p>\n\n\n\n

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, \u201ccontinuous improvement is better than delayed perfection.\u201d That\u2019s true for products as well as humans.<\/p>\n\n\n\n

Want to read more like this? Sign up for my newsletter at\u00a0jan@janbosch.com<\/a>\u00a0or follow me on\u00a0janbosch.com\/blog<\/a>, LinkedIn (linkedin.com\/in\/janbosch<\/a>) or Twitter (@JanBosch<\/a>).<\/em><\/p>\n","protected":false},"excerpt":{"rendered":"

As someone who works with the bits, ie software, data and AI, I\u2019m often annoyed by the constraints that atoms enforce on products. Whereas it\u2019s 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 … Read more<\/a><\/p>\n","protected":false},"author":2,"featured_media":0,"comment_status":"closed","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"generate_page_header":"","footnotes":""},"categories":[8,10],"tags":[],"_links":{"self":[{"href":"https:\/\/janbosch.com\/blog\/index.php\/wp-json\/wp\/v2\/posts\/1950"}],"collection":[{"href":"https:\/\/janbosch.com\/blog\/index.php\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/janbosch.com\/blog\/index.php\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/janbosch.com\/blog\/index.php\/wp-json\/wp\/v2\/users\/2"}],"replies":[{"embeddable":true,"href":"https:\/\/janbosch.com\/blog\/index.php\/wp-json\/wp\/v2\/comments?post=1950"}],"version-history":[{"count":1,"href":"https:\/\/janbosch.com\/blog\/index.php\/wp-json\/wp\/v2\/posts\/1950\/revisions"}],"predecessor-version":[{"id":1951,"href":"https:\/\/janbosch.com\/blog\/index.php\/wp-json\/wp\/v2\/posts\/1950\/revisions\/1951"}],"wp:attachment":[{"href":"https:\/\/janbosch.com\/blog\/index.php\/wp-json\/wp\/v2\/media?parent=1950"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/janbosch.com\/blog\/index.php\/wp-json\/wp\/v2\/categories?post=1950"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/janbosch.com\/blog\/index.php\/wp-json\/wp\/v2\/tags?post=1950"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}