Revisiting Continuous Architecture

Back in 2016, we published a book called “Continuous Architecture” introducing a new architectural approach that enables Continuous Delivery and can be leveraged in practice to deliver software-intensive systems rapidly, in a sustainable way and with high quality. While it is accepted that there is less value in defining up-front architecture today, systems still must meet their challenging quality attributes; stakeholders still have complex, conflicting, and overlapping needs; there are still many design tradeoffs to understand and make; and perhaps more than ever, there are crosscutting concerns, such as security, scalability, performance and resilience, that need to be addressed to allow a system to meet the needs of its stakeholders.

The pace of innovation – especially software driven innovation – is relentlessly accelerating. The Internet has become part of our daily lives and cloud computing, Internet-connected services and the API-economy all mean that the Internet is part of our systems rather than being something that they are connected to.  In turn, this has driven the need for rapid change and stringent quality-attributes, leading to trends like the use of cloud computing, microservices and Continuous Delivery.

While the goal of architecture remains to deliver business value in a sustainable manner, the increasing speed of delivery expected from IT practitioners within enterprises presents new challenges. At the same time, the ease of use and 24/7 expectations of end users is being driven by the overwhelming expansion of technology in our daily lives – we have moved from PCs to tablets to smartphones to wearable technology. Computers have crawled out of the labs and are now nestled in our pockets. They are almost always connected to each other and their capabilities are surpassing our wildest expectations. Today’s software delivery teams are now expected to operate at Internet and cloud time and scale. This has significantly increased the demand, and resulted in the widening adoption of Agile, Continuous Delivery and DevOps practices. 

While software architecture is still an important contributor to product delivery success, it needs to evolve to deal with an environment where systems are typically developed as a set of parallel and largely independent components (e.g. microservices). With this style of software development, the traditional “single architect” approach, where a single architect or small group of technical leads make all the key decisions, simply ends up overloading the architects and causes development to stall. Today’s software delivery needs architecture work to be performed by more people, in smaller increments, with more focus on early delivery of value, than has often been the case historically.

So what is Continuous Architecture and how does it address this challenge? We think of it as an architectural approach that follows six simple principles:

Principle 1: Architect products; evolve from projects to products.

Principle 2: Focus on quality attributes, not on functional requirements.

Principle 3: Delay design decisions until they are absolutely necessary.

Principle 4: Architect for change—leverage the “power of small.”

Principle 5: Architect for build, test, deploy, and operate.

Principle 6: Model the organization of your teams after the design of the system you are working on.

The six principles are complemented by a number of well-known architectural tools such as utility trees, decision logs and design tactics to name a few, as well as by a set of essential activities for architecture – see diagram below.  

The six principles, essential activities and tools[1] assist the people conducting architectural activities in defining the key components of software architecture, such as:

  • Context of the system
  • Key functional requirements which will impact the architecture
  • Quality Attributes that drive the architecture
  • Architecture and design decisions

This article is the first one in a series (authored by Murat Erder, Eoin Woods and me) that will provide practical advice and guidance on how to leverage the Continuous Architecture approach. Our goal in this series of articles is to explain how this approach may help with the day-to-day challenges that development teams face in today’s complex environment of rapidly changing technologies, growing masses of data, and stringent quality attribute requirements associated with modern systems, such as security, scalability, performance, and resilience.

It seems likely that current trends will continue and our systems will be ever more connected and will need to exhibit the sort of pseudo-intelligence that Google, Amazon, Apple and Facebook are building into their consumer-facing applications today, leading to yet more demands on our software architectures – so we hope you will keep on reading our articles for advice on how to deal with these challenges!


[1] See Erder, Murat, and Pierre Pureur. Continuous architecture: Sustainable architecture in an agile and cloud-centric world. Morgan Kaufmann, 2015 for an in-depth discussion of the Continuous Architecture principles and tools

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

%d bloggers like this: