logo

Build your agile operating model to develop and operate outstanding digital products

Continuous Architecture offers guiding ideas, practices, rituals and methods. Unlike most existing enterprise architecture or agile at scale frameworks, Continuous Architecture:

Starts from your problems instead of promoting generic organizational or architecture models
Operationalizes the shift from project to product
Leverages the power of modern software engineering practices
Is truly open
icon

Problem Discovery

Learn more →

What are the major issues facing your enterprise? Engineers and architects are proficient at solving problems, they are often less skilled at challenging the way problems are stated. Spending time solving the wrong problem wastes the enterprise’s time and resources. Therefore, Continuous Architecture recommends to pay attention to the way problems are framed because it largely influences solutions. Reframing a problem can sometimes help you find radically different and more effective solutions. The discovery of a problem begins with an acute sense of observation that leads you to ask the right questions. Reframing also requires the open minded attitude that can help you think out of the box.

icon

Framework

Learn more →

The tools and kits we have created can be used in isolation or they can work together to help the enterprise change to be more successful. In a Volatile, Uncertain, Complex or Ambiguous world, it is important to bring structure while enabling business and operational agility. The Continuous Architecture Framework (CAF) combines intentional architecture and emergent design to help autonomous teams align around a common purpose and a set of shared Objectives and Key Results (OKRs) while preserving agile teams’ autonomy. Team autonomy is a pre-requisite to speed because it reduces coordination activities that slow down teams. On the other hand, when autonomous teams are mis-aligned it increases the risk of delivering poor client and employee experience due to ineffective coordination. The CAF helps maintain a healthy balance between autonomy and alignment along the enterprise journey toward an agile @scale operating model. The equation we’re proposing is ALIGNMENT + AUTONOMY > CONTROL.

What are the roles we propose in the Continuous Architecture operating model.

icon

Practices

Learn more →

Here is the toolbox we have created to help teams realizing their architecture activities. A set of tools and kits that can be used.

icon

Rituals

Learn more →

Architecting is not only about tools, kits and practices. Equally important is the time we spend together working on the architecture around some key rituals. The objective is to foster collaboration in teams on architecture activities.

References

ref
Continuous Architecture

When we decided to start this Continuous Architecture journey, we discovered that the term have been already coined by Murat Erder and Pierre Pureur. Back in 2015, they published their fist book Continuous Architecture: Sustainable Architecture in an Agile and Cloud-Centric World and they are working on a second one Continuous Architecture in Practice. We can say that Murat and Pierre through their work were a source of inspiration for us. We got in touch with them to make sure it was ok to reuse the Continuous Architecture term and they agreed. We’re very grateful to them and the least we could do is to reference their work. If you have a chance to have a look at it, you’ll see that we share many things: spirit, ideas, philosophy & experiences.

When we decided to start this Continuous Architecture journey, we discovered that the term have been already coined by Murat Erder and Pierre Pureur. Back in 2015, they published their fist book Continuous Architecture: Sustainable Architecture in an Agile and Cloud-Centric World and they are working on a second one Continuous Architecture in Practice. We can say that Murat and Pierre through their work were a source of inspiration for us. We got in touch with them to make sure it was ok to reuse the Continuous Architecture term and they agreed. We’re very grateful to them and the least we could do is to reference their work. If you have a chance to have a look at it, you’ll see that we share many things: spirit, ideas, philosophy & experiences.

ref
Open Agile ArchitectureTM

Several Continuous Architecture’s maintainers contributed to the development of the Open Agile ArchitectureTM Standard. Though the Continuous Architecture Toolkit and Framework was developed independently, we believe the two bodies of knowledge share many common principles and are therefore consistent and complementary.

Several Continuous Architecture’s maintainers contributed to the development of the Open Agile ArchitectureTM Standard. Though the Continuous Architecture Toolkit and Framework was developed independently, we believe the two bodies of knowledge share many common principles and are therefore consistent and complementary.

ref
SAFe and Scaled Agile Framework

Continuous Architecture toolkit leverages the architectural runway, a practice coming from the SAFe and Scaled Agile Framework ® SAFe and Scaled Agile Framework are registered trademarks of Scaled Agile, Inc.

Continuous Architecture toolkit leverages the architectural runway, a practice coming from the SAFe and Scaled Agile Framework ® SAFe and Scaled Agile Framework are registered trademarks of Scaled Agile, Inc.

ref
DDD-crew

Domain-Design Design Crew is an open source project aiming to help adopt the famous Eric Evans’ DDD approach. DDD-crew is really an inspirational source for us and we hope we can contribute back.

Domain-Design Design Crew is an open source project aiming to help adopt the famous Eric Evans’ DDD approach. DDD-crew is really an inspirational source for us and we hope we can contribute back.

Case Studies

Michelin
Order to cash domain
Michelin
Re-architecting our curing solution
Retail Bank
Innovative lending product
Michelin
Order to cash domain
How we leverage Continuous Architecture and Domain Driven Design approaches to switch to an Event Driven Architecture

Several years ago, we revisited our information system supporting order to cash processes from order capture to transportation optimization up to logistic delivery. We used to have a legacy monolith hosted on a mainframe supporting most of these processes. We decided to adopt a best of breed approach: several solutions were implemented to support the different part of these end to end processes. As soon as you have several systems contributing, you need a central component to ensure the overall execution and in our case it was a central orchestrator through Business Process Management tool. After several years, we saw different issues rising with this approach especially around the orchestrator. So, we decided to re-think our architecture around the concept of events and their choregraphy as we wanted to get rid of this orchestrator. And we’ll explain how we did it. The approach we took, look at it as a recipe we tried but keep in mind we don’t pretend to be a three star restaurant ;)

Learn more →
Michelin
Re-architecting our curing solution
How Continuous Architecture helped us to re-architect monolith legacies on our plants with an Event driven micro-services solution

In the tyre industry, we do make tyres by cooking or curing a raw tyre, so-called green tyre which is an assembly of rubber and metallic layers. This process takes place in plants in the curing shop where press lines composed of press machines are steered in parallel by an Information System. Here we’ll share with you how we leverage the Continuous Architecture operating model in the creation of a new delivery team and how Domain Driven Design and Continuous Architecture are tightly related. You’ll see how to explore a domain with an Event Storming, how to decompose your domain into bounded contexts, how to define the coupling between bounded contexts with a context map, how to describe your contexts and the end to end dynamic.

Learn more →
Retail Bank
Innovative lending product
How Continuous Architecture leverages the Jobs-To-Be-Done approach to help innovate products and services

We used the Jobs-To-Be-Done approach to understand what treasurers seek to accomplish. A job is a goal or an objective independent of the products or services a bank offers. Bank clients, in this example treasurers, purchase your products or services as a mean to an end which is to help them better do their jobs. For example, treasurers forecast the cash flows that result from their operations to estimate working capital requirements. If a bank can predict small businesses’ minimum sales with high accuracy, it can invent a differentiated lending product. We illustrate this outside-in approach helped the bank innovate.

Learn more →