Since Continuous Architecture was first introduced some ten years ago, it has been encouraging to see so many people starting to recognise that the point is the architecture work, not the architects. Many architects have also transitioned to be technical leaders and guides rather than trying to make and govern every technical decision themselves. And just as architecture is best performed as a continual process, the way we do architecture has also evolved. Ten years on, it’s a good time to remind ourselves where Continuous Architecture began, the principles it set out, and how well they’ve stood the test of time.

Sustainable, continuous delivery of value

Right from the beginning of the story, when Pierre and Murat wrote the first book on Continuous Architecture, it has always been about driving a sustainable and continuous flow of business value. However, the pace of technological change in the last two decades placed new demands on the discipline. End users expected seamless, always-available digital experiences, while enterprises expected their technology organisations to deliver at the speed of the Internet. This meant that more traditional ‘up front’ approaches to architecture were too slow to respond to these demands and so architecture work had to evolve to stay valuable – to change pace without losing purpose.

This resulted in a new way of looking at architecture, as a continuous flow of decisions, rather than as primarily a comprehensive software modelling exercise, which it often had been in previous eras. While there is value in forward planning and looking ahead, the reality of today’s complex systems, their demanding quality attribute (non-functional) requirements, and conflicting, overlapping, continually evolving stakeholder needs meant that a new way of working was called for.

Architecture’s role today

In the software architecture field, we’ve always been preoccupied with the challenges of stakeholder needs, quality attributes, and cross-cutting concerns; however, the rate of change driven by agility and DevOps practices fundamentally altered the way that software delivery is performed. I believe this makes software architecture now more important than ever.

In response to these challenges, software architecture has evolved to deal with systems developed as a set of parallel and largely independent components (such as microservices). This means that the traditional single-architect approach, where one architect or a small group of technical leads make all the key decisions, simply ends up overloading the architects and this causes development to stall (or for the architecture to be simply ignored). This has meant that architectural work must be performed by more people, in smaller increments, with more focus on early delivery of value than had ever been the case before.

The Six Principles of Continuous Architecture

Continuous Architecture is an approach (or perhaps a philosophy) for doing software architecture that is intended to be adapted to different contexts, so it’s important to have some shared principles to help us remember what is important about the approach. Let’s remind ourselves of the six simple principles of Continuous Architecture that Murat and Pierre first described ten years ago in their original book, but with a little advantage of hindsight too.

Principle 1: Architect products; evolve from projects to products. Architecting products is more efficient than just designing point solutions to projects and focuses the team on its customers. Over the past decade, this principle has become standard practice in many digital-native companies. The rise of product-centric operating models in enterprises has validated this shift, though some traditional organisations still struggle to fully embrace a project-driven mindset.

Principle 2: Focus on quality attributes, not on functional requirements. Quality attribute requirements drive the architecture. This principle has only grown in importance, as resilience, security, and scalability have become critical characteristics of successful digital services. The challenge is that quality attributes are still often neglected under delivery pressure and it is still difficult to make the right trade-offs between them.

Principle 3: Delay design decisions until they are necessary. Design architectures based on facts, not on guesses. There is no point in designing and implementing capabilities that may never be used; it is a waste of time and resources. In practice, teams have become more comfortable with deferring decisions, as they have become more familiar with agile practices and have embraced the flexibility of cloud and infrastructure-as-code. The risk, however, is deferring too long and ending up past the point at which a critical decision was needed. Intentional effort and good judgement can avoid this.

**Principle 4: Architect for change—leverage the ‘power of small.’ **Big, monolithic, tightly coupled components are hard to change. Instead, leverage small, loosely coupled software elements. Microservices and modular design have brought this principle to the fore for many organisations, though many now face the challenge of managing complexity and operational overhead when ‘small’ becomes ‘too many.’

Principle 5: Architect for build, test, deploy, and operate. Traditional architecture work tends to focus exclusively on software building activities, but architects should be concerned about build, testing, deployment, and operation, as well, to support continuous delivery. Thus, helping us to create flexible, adaptable and nimble architectures for quick implementation into executable code that can be rapidly tested and deployed. Users can then provide feedback, the ultimate validation of architecture. This principle has been realised by the wide adoption of continuous integration and continuous delivery, along with DevOps ways-of-working, all of which force attention onto these crucial topics. Architects today must understand not only system design but also CI/CD, observability, and operations to ensure that their architectures can be considered truly ‘continuous.’

Principle 6: Model the organisation of your teams after the design of the system you are working on. The way teams are organised drives the architecture and design of the systems they are working on. Conway’s Law has become a widely accepted truth in the past decade and we have seen the emergence of sophisticated approaches to optimising organisations to deliver a flow of value, such as Team Topologies. Many organisations now harness approaches like this to design team structures that encourage desired architectural outcomes — though getting this right in practice remains a real challenge in many cases.

As we can see, none of the principles have been invalidated. If anything, they have become more relevant with time. Their durability is what still makes them a practical foundation for a modern approach to software architecture today.

You can refer to the six principles in detail in Murat and Pierre’s 2015 book Continuous Architecture (link), and the second book, *Continuous Architecture in Practice *(link), which the three of us published in 2021.

Continuous application of the architectural discipline

Continuous Architecture is an approach to software architecture that includes a set of principles, tools, techniques and ideas that together provide an architecture toolset to effectively deal with the demands of modern software delivery. In the last ten years, I have found them effective on a range of projects and products that I have worked on, their key strength being that they are dynamic and adaptable in nature. The approach continues to mature with experience and in response to new challenges, but the goal of Continuous Architecture remains to speed up software development and delivery by systematically applying a proven set of architecture practices throughout the software delivery lifecycle, to deliver value over the whole life of the product.

Looking back, the six principles have stood the test of time. Far from being outpaced by new methods or technologies, they have provided a resilient foundation for adapting to the challenges that have emerged over that period, including cloud, DevOps, and microservices. The challenge today is not whether the principles are valid, but how consistently organisations can live them in practice. That will be the true measure of success in the next decade of Continuous Architecture.

In future posts, I’ll explore why quality attributes and design decisions have become first class citizens in modern software architecture and why it is critical to consider how the architecture supports build, test, deploy, and operate, as well as the classical concerns of system design.