Blog Posts

Home /
Blog Posts

Continuous Architecture Manifesto - Edition 1.0 (2019)

This document is the first edition (1.0) of the Continuous Architecture Manifesto, originally published in 2019. It reflects the initial set of beliefs and principles that shaped the foundation of Continuous Architecture.

Architecture for flow case study

A case study from the industry to see how Domain Driven Design & Team topologies can be used to architect for fast flow

Using our Miro templates

Download the latest release of the miro board you want to use. As of now, we provide: Team Topologies Miro template Event storming Open Miro and click on Upload from backup. This will create a new board called Restored SOMETHING Then simply rename the board and start using it by copy and pasting the different shapes as required Making changes to the Miro templates and share it You are absolutely free to change our board to make it more useful in your context. If you want to share those templates, there are several ways to share templates in Miro

Problem discovery

In his book “Kaizen and the art of creative thinking” Shigeo Shingo1 states there are three essential steps to problem solving:

Why changing the way we architect our solutions?

Since a decade or so, lots of new software engineering practices were introduced mainly to deliver our products faster to our end users. One finds here lean management, agile, devops transformation, Continuous Integration and Continuous Delivery … Why such a trend? because the value is only produced when your product is deployed and used. Everything that is not deployed is just inventory in your souce code base. But one key area was still missing in this massive transformation of our engineering practices and if you end up browsing our Continuous Architecture web site, I guess you already know which area we’re talking about. As the old adage is saying, Rome was not built in a day. We can then perfectly understand that we can not transform all disciplines at the same time. But to complete the journey, we need to finish this off with Architecture. Our creed is “yesterday’s architecture methodologies and processes will not deliver future solutions”. If you take a step back, we can say we build software in a continuous manner today. So let’s adapt our architecture operating model to it !

Start your journey

Start your journey The deployment of the new ways of working (practices, rituals, framework) described in the Continuous Architecture Framework and Toolbox is a major change journey. There is no single pathway to move your enterprise (or part of it) from its current state to the ideal state (or north star) we recommend and which is embodied in the key tenets of the Continuous Architecture Manifesto - edition 1.

Banking Case Study

Introduction This banking Case Study is under development. Its purpose is to to illustrate Continuous Architecture practices. It will be mainly used to test the meta-model and provide an example to be used during training sessions.

Order to cash domain

Context and background Several years ago, we revisited our information system supporting order to cash processes. We used to have a legacy monolith (hosted on a mainframe) and 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: from order capture to transportation optimization up to logistic delivery … This move, helped us to

Re-architecture our curing solution

Domain Driven Design is set of concepts and practices aiming to align the structure and language of the software code with the business domain the code is supporting. It was popularized by Eric Evans and gets lots of traction in the last couple of years. One of the main difficuties when you’re trying to adopt DDD to model and design your solution is “Where the hell should I start from?”

Blog Posts

Categories