Since sustainable architecture was first introduced about ten years ago, it has been encouraging to see so many people beginning to recognize that the issue is the work of architecture, not architects. Many architects have also become technical leaders and guides rather than trying to make and control every technical decision themselves. And just as architecture is best executed as an ongoing process, the way we do architecture has also evolved. Ten years later, it’s a good time to remind ourselves where sustainable architecture began, what principles set it forth, and how well they have stood the test of time.
Continuous, ongoing delivery of value
From the very 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 over the past two decades has placed new demands on the discipline. End users expected seamless, always-available digital experiences, while enterprises expected their technology organizations to operate at the speed of the Internet. This meant that more traditional ‘upfront’ approaches to architecture were too slow to respond to these demands and so to remain valuable the architectural work had to evolve – to change pace without losing purpose.
This resulted in a new way of viewing architecture as a continuous flow of decisions, rather than primarily as a comprehensive software modeling exercise, as it often was in previous eras. While there is importance in planning ahead and looking ahead, the reality of today’s complex systems, their demanding quality attribute (non-functional) requirements, and conflicting, overlapping, constantly evolving stakeholder needs meant that a new way of working was called for.
role of architecture today
In the software architecture field, we have always been engaged with the challenges of stakeholder needs, quality specifications, and cross-cutting concerns; However, the rate of change driven by agility and DevOps practices has fundamentally changed the way software delivery is done. I believe this makes software architecture more important now than ever.
In response to these challenges, software architectures have 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 makes all the important decisions, ultimately overburdens architects and leads to development stalling (or the architecture simply being ignored). This means that architectural work must be done by more people, in smaller increments, with a greater focus than before on prompt delivery of value.
Six Principles of Sustainable Architecture
Sustainable architecture is an approach (or perhaps a philosophy) to software architecture that is intended to be adapted to different contexts, so it is 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 sustainable architecture that Murat and Pierre first described in their original book ten years ago, but also with a little foresight.
Principle 1: Architect Products; Evolving from projects to products. Architecting products is more efficient and focuses the team on their customers than designing point solutions for projects. 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, although some traditional organizations are still struggling to fully adopt a project-driven mindset.
Principle 2: Focus on quality characteristics, not functional requirements. Quality feature requirements drive the architecture. The importance of this principle has only increased, as flexibility, security and scalability have become important characteristics of successful digital services. The challenge is that under delivery pressure quality attributes are still often ignored and finding the right compromise between them is still difficult.
Principle 3: Delay design decisions until they are necessary. Design architectures should be based on facts, not assumptions. There is no point designing and implementing capabilities that may never be used; This 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 the cloud and infrastructure-as-code. However, the risk is procrastinating too long and getting past the point at which an important decision was needed. This can be avoided with deliberate effort and good judgment.
Principle 4: Architects of Change – Leverage the ‘Power of the Small’. Large, monolithic, tightly coupled components are difficult to replace. Instead, take advantage of small, loosely coupled software elements. Microservices and modular design have brought this principle to the forefront for many organizations, however many now face the challenge of managing complexity and operational overhead when ‘small’ becomes ‘too much’.
Principle 5: Architect to build, test, deploy, and operate. Traditional architecture work focuses exclusively on software construction activities, but architects must also be concerned about building, testing, deployment, and operations to support continuous delivery. Thus, helping us create flexible, adaptable and agile architectures for quick implementation in executable code that can be rapidly tested and deployed. Users can then provide feedback, which is the final validation of the architecture. This principle has been realized by the widespread adoption of continuous integration and continuous delivery along with DevOps ways of working, all of which draw attention to these important topics. Today architects must understand not only system design but also CI/CD, observability and operations to ensure that their architectures can truly be considered ‘continuous’.
Principle 6: Model the organization of your teams after the design of the system you’re working on. The way teams are organized drives the architecture and design of the systems they are working on. Conway’s Law has become a widely accepted truth over the last decade and we have seen the emergence of sophisticated approaches such as team topology to optimize organizations to deliver flow of value. Many organizations now use such an approach to design team structures that encourage the desired architectural outcomes – although getting this right in practice remains a real challenge in many cases.
As we can see, neither theory has been invalidated. If anything, they have become more relevant over time. Their durability is what makes them a practical foundation for modern approaches to software architecture even today.
You can refer to the six principles in detail in Murat and Pierre’s 2015 book sustainable architecture (link), and the second book, Sustainable Architecture in Practice (link), which the three of us published in 2021.
Continuous application of architectural discipline
Continuous Architecture is an approach to software architecture that encompasses a set of principles, tools, techniques, and ideas that together provide an architecture toolset to effectively deal with the demands of modern software delivery. Over the last ten years, I have found them effective on many projects and products I have worked on, their main strength is 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 sustainable architecture is to accelerate software development and delivery by systematically applying a proven set of architecture practices throughout the software delivery lifecycle, to deliver value over the entire life of the product.
Looking back, the six principles have stood the test of time. Rather than being overtaken by new methods or technologies, they have provided a flexible foundation to address the challenges that have emerged during that period, including cloud, DevOps, and microservices. The challenge today is not whether the principles are valid, but how consistently organizations can put them into practice. This will be the true measure of success in the next decade of sustainable architecture.
In future posts, I will explore why quality attributes and design decisions have become first-class citizens in modern software architectures and why it is important to consider how the architecture supports the classical concerns of system design along with construction, testing, deployment, and operations.