{"id":985,"date":"2019-11-02T15:42:35","date_gmt":"2019-11-02T15:42:35","guid":{"rendered":"http:\/\/janbosch.com\/blog\/?p=985"},"modified":"2019-11-02T15:42:41","modified_gmt":"2019-11-02T15:42:41","slug":"who-manages-your-system-architecture","status":"publish","type":"post","link":"https:\/\/janbosch.com\/blog\/index.php\/2019\/11\/02\/who-manages-your-system-architecture\/","title":{"rendered":"Who manages your system architecture?"},"content":{"rendered":"\n
\"\"
Photo by Markus Spiske on Unsplash\n<\/figcaption><\/figure>\n\n\n\n

This week, I spent two days in systems engineering workshops. Systems engineers are concerned with designing products and solutions including mechanical, electronic and software components. Systems engineers and architects address all requirements of a system, including regulatory constraints, such as functional safety, customer-facing functionality, such as the features that the customer uses on a daily basis, and evolvability and maintainability, decreasing the total cost of ownership over the lifetime of the system.<\/p>\n\n\n\n

The systems engineering \nworkshops were concerned with the implications of digitalization, which \nwe define as software + data + artificial intelligence. The consequence \nof digitalization on most of the systems is that changes are required to\n their architecture. The interesting finding was that in several \ncompanies, there was nobody in the organization who was responsible for \nthe overall systems architecture. Instead, the original architecture had\n become incarnated in the organizational structure. Each of the \ndepartments or units was responsible for one subsystem or component in \nthe traditional architecture.<\/p>\n\n\n\n

Of course, the strong relationship \nbetween architecture and R&D organization isn\u2019t new. Many are aware \nof Conway\u2019s law from 1967 and in earlier posts<\/a>,\n I\u2019ve presented the BAPO model. However, in both cases, the assumption \nis that there\u2019s some role or team that governs the overall system \narchitecture.<\/p>\n\n\n\n

How\n can so many organizations end up without such a role or team? One \nexplanation is that in many industries, there\u2019s a \u2018dominant design\u2019 that\n has been established as the standard everyone in the industry adheres \nto. It allows individual companies to provide specific components \nidentified in the dominant design. The same pattern occurs inside the \norganization, where each component in the dominant design is mapped to \nan organizational unit. The interfaces between the components are then \nused as coordination and integration points within the organization. \nOnce the dominant design has been established in an industry, there\u2019s \nactually no need within the company to govern or manage the system \narchitecture as the industry as a whole operates according to this \narchitecture.<\/p>\n\n\n\n

The\n consequence of digitalization is that, in many industries, the dominant\n design that has been in place for many years or even several decades \nceases to be the optimal solution. Instead, we need to return to \narchitecture design to explore alternative architectures that better \nsupport the incorporation of software, data and artificial intelligence.\n The realization I had this week was that many companies are not \nrealizing that the \u2018dominant design\u2019 architecture of their industry is \noutdated and needs to be replaced with a better alternative. This \nrequires large amounts of experimentation with various architecture \nalternatives across the industry. Each company needs to conduct its own \narchitecture experiments with the aim of identifying the new dominant \ndesign for the industry.<\/p>\n\n\n\n

The challenge I want to highlight is that\n although companies need to experiment with alternative architectures, \nmany have no system architecture function that actually is able to \nperform this experimentation. Either there\u2019s no system architecture \ngovernance in the company at all or the system architecture and \nengineering function has atrophied to the point that it only manages \nsmall decisions within the context of the conventional \u2018dominant design\u2019\n architecture such as selection of suppliers, interface management or \nsystem validation.<\/p>\n\n\n\n

Concluding, digitalization is causing the disruption of the \u2018dominant design\u2019 architecture in many industries. In industries where that architecture has been the norm for many years or even decades, companies have no or severely atrophied systems engineering functions that are unable to provide governance of nor experimentation with the system architecture. This lack of capability is extremely dangerous for incumbent companies from a disruption perspective in any industry as ecosystem-level disruption is typically driven by the introduction of a new architecture that\u2019s adopted as the new dominant design. So, the question I\u2019d like to leave you with is: who manages your system architecture?<\/p>\n\n\n\n

To get more insights earlier, sign up for my newsletter at<\/em>jan@janbosch.com<\/em><\/a> or follow me on<\/em> janbosch.com\/blog<\/em><\/a>, LinkedIn (<\/em>linkedin.com\/in\/janbosch<\/em><\/a>) or Twitter (<\/em>@JanBosch<\/em><\/a>).<\/em><\/p>\n","protected":false},"excerpt":{"rendered":"

This week, I spent two days in systems engineering workshops. Systems engineers are concerned with designing products and solutions including mechanical, electronic and software components. Systems engineers and architects address all requirements of a system, including regulatory constraints, such as functional safety, customer-facing functionality, such as the features that the customer uses on a daily … Read more<\/a><\/p>\n","protected":false},"author":2,"featured_media":0,"comment_status":"open","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\/985"}],"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=985"}],"version-history":[{"count":1,"href":"https:\/\/janbosch.com\/blog\/index.php\/wp-json\/wp\/v2\/posts\/985\/revisions"}],"predecessor-version":[{"id":987,"href":"https:\/\/janbosch.com\/blog\/index.php\/wp-json\/wp\/v2\/posts\/985\/revisions\/987"}],"wp:attachment":[{"href":"https:\/\/janbosch.com\/blog\/index.php\/wp-json\/wp\/v2\/media?parent=985"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/janbosch.com\/blog\/index.php\/wp-json\/wp\/v2\/categories?post=985"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/janbosch.com\/blog\/index.php\/wp-json\/wp\/v2\/tags?post=985"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}