Continuous Architecture Principles

The Principles of Continuous Architecture

The concept of Continuous Architecture arose as a response to the need for an architectural approach that is able to support very rapid delivery cycles as well as more traditional delivery models. Due to advances in Software Engineering as well as the availability of new enabling technologies , the approach used for architecting modern systems that require agility (our “systems of engagement”) is different from the approach we used to architect older systems (such as our “systems of record” and “systems of operation”). As a result, we can deliver modern applications rapidly, sustainably and with high quality using a Continuous Delivery (see Note 1) approach – which is enabled by using a Continuous Architecture approach. But what is Continuous Architecture? We believe that it can be defined as an architecture style that follows the following six simple principles:

  1. Architect Products – not Projects
  2. Focus on Quality Attributes – not on Functional Requirements
  3. Delay design decisions until they are absolutely necessary
  4. Architect for Change – Leverage “The Power of Small”
  5. Architect for Build, Test and Deploy
  6. Model the organization of your teams after the design of the system you are working on

We will be discussing these principles in detail starting with Principle 1 in this blog page. The other principles will be discussed in subsequent pages.

  1. Architect Products – not Projects

Architects generally tend to fall into two broad categories: those who concentrate on projects (“Solution Architecture” which is considered a tactical, shorter term approach) and those who work on company-wide strategies (“Enterprise Architecture” which is seen as a strategic, longer term approach). While a Project-only focus may lead to making short-term architecture decisions, an Enterprise-only focus may be perceived as theoretical and impractical, especially in the Application domain. After all, who can accurately predict which technologies our Systems of Engagement in Financial Services will leverage a few years years from now to interface with prospects and customers? Will they be using tablets, smart phones, intelligent watches, glasses or even some new device still waiting to be invented?

How can we solve this challenge? Projects are temporary in nature, and meant to deliver a well-defined result. In reality, projects rarely exist in isolation – they are often part of a larger endeavor (sometimes called a “Program”) that exists in order to enhance a product or service. Looking at the architecture required by a project in isolation can be misleading, and hides the need for a longer-term product-level architecture, which is more strategic in nature than the project level architecture.  

Practically speaking, creating and maintaining an architecture is an expensive task so it makes a lot of sense to leverage it across multiple projects. In that context, a product-level architecture can be reused many times, avoiding rework and promoting planned software reuse – as opposed to random reuse paradigms that seldom work (see Note 2) . Using this approach, individual projects are instantiated from common product architecture.

According to Forrester Research, “a distinctive, value-based approach to software development has emerged, identifiable by a high-performing class of “product-centric” development teams that characteristically support their company’s value chain, partner with both their customers and business stakeholders, and own the business results that their software delivers” (see Note 3). As IT organizations evolve from today’s project-centric focus to a product-centric focus, it is critical for Software Architecture to lead the way by focusing on products. Continuous Architecture’s focus on products and product lines blurs the distinction between Solution Architects and Enterprise Architects. As Continuous Architecture becomes a reality, architectures evolve into strategic assets that can be leveraged continuously and rapidly to deliver business value.


  1. See Martin Fowler’s Blog dated 30 May 2013 ( for a great overview of Continuous Delivery. See also Jez Humble’s and David Farley’s book “Continuous Delivery: Reliable Software Releases through Build, Test, and Deployment Automation (Addison-Wesley Signature Series) for more information on this topic
  2. For an in-depth discussion of this topic please refer to “Refactoring: Improving the Design of Existing Code by Martin Fowler, Kent Beck, John Brant and William Opdyke (Jul 8, 1999)”

  3. Forrester Research – “Product-Centric Development Is A Hot New Trend”, December 23, 2009.