Continuous Architecture Framework

By Frédéric Lé <> and Jean-Pierre Le Cam <>

We build software in a continuous manner, let’s adapt our architecture operating model to it. That would be the elevator pitch for our Continuous Architecture initiative.

Since a decade or so, lots of new software engineering practices were introduced mainly to deliver faster our products to end users. Speed is obviously key these days but it was not the only goal of those practices: their intend was also to deliver better products that fix end user problems. If you look at it, you’ll see a common pattern in many companies that deployed these different transformations like agile, lean, devops …​: architecture was a missing area. The Continuous Architecture Framework (or CAF) below is our proposal to adapt our operating model to this continuous world. It is organized into six related views as depicted in this figure.

Your browser does not support SVGs

To navigate the framework, click on the different rectangles that represent framework views.

The questions below drive the navigation between the views of the framework:

  • Defining your Experience Objectives is a way to assess how your product fit its market. Here, you’re asking yourselves what is the job to be done and how to fix end user problems.

  • It pushes you to define your product, its boundaries and characteristics and how you’ll manage it over time from ideation to is retirement.

  • What are the technologies you can leverage to enable and augment your products and capabilities?

  • Operations are crucial to operate your product at scale and integrated in your company

  • A true agile organization that will deliver your products accordingly the Information System architecture is also fundamental; otherwise you’ll probably end up with some frictions between teams.

  • And when you start to talk about organization, we often need to define how to decompose the enterprise

Though the CAF perspectives are related, the diagram and the above explanations should not be interpreted as a waterfall process model. The activities of this framework are executed in a continuous manner all along the product lifecycle. Depending on where you stand on this lifecycle, you’ll insist or focus on different aspects.


Let’s say you are in the exploration phase for a new product. You should probably be focusing your energy on the experience objectives and the product itself. It’s maybe not the right time to invest massively on technologies or operations at this point. But when you do move to the growth phase, then technologies and operations become critical if you don’t want to put your business at risk. Which means that technologies and operations can be addressed in parallel at the company or business unit levels to help products' teams achieving what they have to by giving them the right enablers at the right time and save precious time. And wether we like or not, the enterprise decomposition will impact what you’re doing with an intentional architecture that most of time reflect how the enterprise is decomposed ie organized. And it will happen any time. Up to us by using the Continuous Architecture Framework to help with that decomposition first and influence it with the inverse Conway manoeuver which helps to design an organization so it match the architecture and not vice and versa. One of the thing Continuous implies here is to keep a balance between intentional architecture and emergent design. It helps better manage the uncertainty and complexity that characterizes the digital journey of the enterprise.