{"id":1271,"date":"2021-06-23T08:11:19","date_gmt":"2021-06-23T08:11:19","guid":{"rendered":"http:\/\/janbosch.com\/blog\/?p=1271"},"modified":"2021-06-23T08:11:20","modified_gmt":"2021-06-23T08:11:20","slug":"outdated-belief-2-a-carefully-designed-architecture-is-critical","status":"publish","type":"post","link":"https:\/\/janbosch.com\/blog\/index.php\/2021\/06\/23\/outdated-belief-2-a-carefully-designed-architecture-is-critical\/","title":{"rendered":"Outdated belief #2: A carefully designed architecture is critical"},"content":{"rendered":"\n
\"\"
Image by PIRO4D from Pixabay<\/figcaption><\/figure>\n\n\n\n

In the early 2000s, I was one of those people preaching the importance of careful design and analysis of a system\u2019s architecture before starting development. The belief was that especially non-functional requirements, such as performance and robustness, are hard to \u2018bolt on\u2019 to the system once development is underway. So, the software architecture community, including me, developed all kinds of tools and techniques to structure and provide systematic means to take architecture design decisions, assess the architecture\u2019s ability to meet the non-functional requirements, such as performance and maintainability, and ensure the alignment between requirements and the architecture.<\/p>\n\n\n\n

Although these techniques were and are extremely valuable, even today, there are several challenges with this view of the world. The first is that the original viewpoint is one where we start from a stable and complete set of requirements for the system. As pointed out when we discussed the first outdated belief<\/a>, requirements are far from stable and tend to evolve at about 1 percent per month for most systems. That means that requirements form a moving target and can\u2019t be used as a stable fundament for the development of a system.<\/p>\n\n\n\n

The second challenge is the assumption that we have a greenfield \ncontext and are starting from scratch. Although new systems are built \nfrom scratch, the vast majority of the development effort is on systems \nthat have been around for a while. With the emergence of the minimal \nviable product (MVP) style thinking, we can see that the greenfield \nperiod for any new system is intentionally shortened to the minimally \npossible period.<\/p>\n\n\n\n

The third challenge with the original view is that it assumes that we only need architecture work at the beginning of the project. Once the architecture is \u2018done,\u2019 we can move on to development and testing and no further architecture work is required. Anyone who has ever worked on a real-world system realizes how wrong that assumption is.<\/p>\n\n\n\n

Finally, the traditional way of thinking is\n that it\u2019s all about the architecture and not about the architects. \nAlthough the architecture establishes the guidelines, structures and \nboundaries for the system, it\u2019s the architects that define these and \nthen evolve them over time. So, the architecture is only one of the \nrelevant artifacts that we benefit from during development. It\u2019s also \nabout the underlying principles, the design decisions that led to the \narchitecture, the connection to the business drivers, and so on.<\/p>\n\n\n\n

Today, it\u2019s clear that a system\u2019s architecture evolves continuously, \neg in response to new requirements, evolving technologies or changing \nuser behavior. The architecture isn\u2019t a static artifact, cast in stone, \nbut rather a continuously evolving, organic entity that responds to the \nneeds of the various stakeholders. It tends to evolve more slowly than \nthe system\u2019s features and functionality and as such provides structure, \nbut it does need to evolve.<\/p>\n\n\n\n

That brings us to the outdated belief that we\u2019re discussing here. The\n architecture of a new system starts small, largely undefined and not \nwell understood and covering only the needs of the MVP. If the MVP is \nsuccessful and we want to grow it, then the architecture needs to evolve\n to meet requirements like scalability, performance and the system\u2019s \nincreased functionality needs. And often it needs to build integrations \nwith other systems, demanding interfaces where we never expected to have\n these in the first place.<\/p>\n\n\n\n

There are three principles that I believe are critical for working \nsuccessfully with software architecture. First, it\u2019s about architects, \nnot architecture. The architecture is the constantly evolving artifact \nand any architecture documentation is like a milestone along the way: \naccurate when created but outdated when published. Much more important \nare the people driving this constant evolution, the architects. They \nneed to bridge the link between business and technology.<\/p>\n\n\n\n

Second, as I already alluded to several times in this post, \narchitecture is continuously evolving in response to a constantly \nevolving and changing world. Rather than trying to resist and slow down \nthe change, we should lean into the future and proactively evolve the \narchitecture based on the needs we can see appearing. Our research shows\n no correlation between the age of an architecture and the need for \ntechnical debt management. Hence, we need to start evolving the \narchitecture from the start.<\/p>\n\n\n\n

Third, most professionals don\u2019t realize this, but architecture is the\n incarnation of the future business strategy. In virtually all \nsituations, the pace at which the architecture can change and evolve is \nvery slow. That means that the architecture design decisions made today \nmake certain business strategies very easy to realize in one or a few \nyears, and others prohibitively expensive. Therefore, the architecture \nevolution initiated today defines the range of realistic business \nstrategies down the line. In practice, it\u2019s not the business leaders but\n rather the architects who determine business strategy.<\/p>\n\n\n\n

Software architecture isn\u2019t a one-time effort where we pour the concrete for the foundation of the system to never change it again. Instead, it\u2019s a constantly evolving artifact that happens to evolve more slowly than the features and functionality in the system. Consequently, it\u2019s about doing just enough architecture work at the start of a new system to get the MVP in place and then growing the architecture with the system in response to the needs of the business supported by the architecture. We need to welcome change and lean into the future as not doing so will cause the system to become outdated and irrelevant. And writing off many person-years of effort and losing vast amounts of codified domain knowledge is wasteful in ways that few things are. And who wants that?<\/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>), Medium<\/a> or Twitter (<\/em>@JanBosch<\/em><\/a>).<\/em><\/p>\n","protected":false},"excerpt":{"rendered":"

In the early 2000s, I was one of those people preaching the importance of careful design and analysis of a system\u2019s architecture before starting development. The belief was that especially non-functional requirements, such as performance and robustness, are hard to \u2018bolt on\u2019 to the system once development is underway. So, the software architecture community, including … 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\/1271"}],"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=1271"}],"version-history":[{"count":1,"href":"https:\/\/janbosch.com\/blog\/index.php\/wp-json\/wp\/v2\/posts\/1271\/revisions"}],"predecessor-version":[{"id":1273,"href":"https:\/\/janbosch.com\/blog\/index.php\/wp-json\/wp\/v2\/posts\/1271\/revisions\/1273"}],"wp:attachment":[{"href":"https:\/\/janbosch.com\/blog\/index.php\/wp-json\/wp\/v2\/media?parent=1271"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/janbosch.com\/blog\/index.php\/wp-json\/wp\/v2\/categories?post=1271"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/janbosch.com\/blog\/index.php\/wp-json\/wp\/v2\/tags?post=1271"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}