Continuous Architecture Principles and Goals

Creating and maintaining software architecture that remains sustainable over time is a challenge for software architects and developers. Software Architects used to meet every requirement, provide every feature, and plan every system component at once with big software architecture upfront, which involves completing and perfecting architectural designs before implementations are started. Alternatively, teams might produce emergent architectures, where development teams start delivering functionality and let architectural designs emerge with little upfront planning. Unfortunately, none of those methods is consistently successful in delivering sustainable architecture. 

Continuous Architecture Principles

As for “Continuous Architecture,” this is about using the appropriate tools to make the right decisions and support Continuous Delivery, Continuous Integration, and Continuous Testing. “Continuous Architecture” is an approach based on a toolbox — not a formal process. 

It is based on the following principles that describe how software architects can continuously elaborate software architectures in today’s world of Agile, DevOps, and cloud:

• Focus on quality attributes, not on functional requirements. Quality attribute requirements drive the architecture.
• Architect for change — leverage the “power of small.” Big, monolithic, tightly coupled components are hard to change. Instead, leverage small, loosely coupled software elements.
• Architect products; evolve from projects to products. Architecting products are more efficient than just designing point solutions to projects and focusing the team on its customers.
• Delay design decisions until they are absolutely necessary — design architectures based on facts, not on guesses. There is no point in designing and implementing capabilities that may never be used—it wastes time and resources.
• Architect for build, test, deploy, and operate. Most architecture methodologies focus exclusively on software building activities, but architects and engineers should also be concerned about testing, deployment, and operation in order to support continuous delivery.
• Model the organization of your teams after the design of the system you are working on. The way teams are organized drives the architecture and design of the systems they are working on.

These principles provide a useful model but are not prescriptive. The following four essential activities complement them:

1. “Focus on quality attributes, the key cross-cutting requirements that good architecture should address. 
2. Drive architectural decisions, which are the primary unit of work of architectural activities. 
3. Know your technical debt, the understanding and management of which is key for sustainable architecture. 
4. Implement feedback loops, which enable us to iterate through the software development lifecycle and understand the impact of architectural decisions. Automation is a key aspect of effective feedback loops.

Also, the continuous architecture includes an architectural “toolbox” that incorporates a set of proven tools, such as decision logs, utility trees, and architectural tactics. Software architects and engineers can extend this toolbox by adding tools relevant to their contexts.

Continuous Architecture starts from your problems instead of promoting generic organizational or architecture models. It operationalizes the shift from project to product and leverages the power of modern software engineering practices. It is truly open. 

The goal of Continuous Architecture in the Continuous Delivery context is to speed up the software development and delivery process by systematically applying an architecture perspective and discipline continuously throughout the process. 

How to bring an architecture perspective to the overall process, following five key components of that process:

• Continuous feedback and monitoring
• Continuous Integration (CI)
• Continuous release and deployment
• Continuous testing
• Hybrid cloud deployment

Continuous Architecture also operates in two dimensions, time and scale. The time dimension addresses how software architects enable architectural practices in a world of increasingly rapid delivery cycles. Although the scale dimension looks at the level software architects are operating at. Continuous Architectural principles apply consistently at all scales, but the level of focus and the tools used might vary.

A key advantage of Continuous Architecture is that it is driven by feedback; in fact, the team actively solicits feedback from the development teams, the testing teams, the DevOps teams, and their business partners. They use this feedback to continuously test the architecture and govern the evolution of the architecture based on data. This data is collected through a number of channels, for example, “prototyping,” A/B testing, feedback loops from continuous testing, manual reviews, automated code inspection, or any number of approaches that provide substantive feedback on architectural qualities.

Continuous Architecture Goals

• To create an architecture that can evolve with applications, that is testable, that can respond to feedback, and in fact, is driven by feedback
• To make Enterprise Architecture real
• To make solution architecture sustainable
• To create real-world, actionable, useful strategies

Software architects create long-term products, not just project solutions. Software Architects have to consider architecture activities as a runway following the life of a product (as it goes through different stages: from cradle to grave). 

Software Architects have to make decisions, design new features, and reconsider/rework what they have done given the new context they are in. The design needs to be robust to future change. 

Software Architects build products with a holistic view. Behind this, there are two different but complementary ideas. First, software architects look at the architecture from a full-stack perspective considering all the different layers products are built on: infrastructure, network, middleware, application, and urbanism. In the meantime, software architects also need to make sure the product fits well into the system. Here software architects focus on the integration strategy with other systems products have to communicate.

Software architects prove and validate the architecture by implementing it, not by validating documents. Powerpoint slides and ArchiMate diagrams don’t go to production. The code developed by their squad does. And the sooner, the better. 

Teams that apply Continuous Architecture at the individual application level can notice that it enables a more sustainable delivery model and platform that is more resilient against future change. Companies leveraging continuous architecture at the enterprise level can observe an increased efficiency in delivering solutions, a healthier ecosystem of common platforms, and increased knowledge sharing.