Open Agile Architecture™

Sometimes, and depending on the approach used, Enterprise Architecture frameworks distinguish Enterprise Architecture from solution architecture. Enterprise Architecture is at the entity level and has a medium to long time horizon. In contrast, the scope of solution architecture is sometimes limited to a project. For example, the TOGAF Standard, Version 9.2 describes solution architecture as typically applying to “a single project or project release, assisting in the translation of requirements into a solution vision, high-level business and/or IT system specifications, and a portfolio of implementation tasks”. The time horizon of solution architecture is therefore contingent to the time horizon of projects. This does not imply, however, that the approach could not be adapted to cover a solution that does not depend on, or is not tied to, a specific project.

To echo this, Murat Erder and Pierre Pureur observe that “solution architects focus on providing project-level architectures, but Enterprise Architects attempt to create strategies, architecture plans, architecture standards, and architecture frameworks for the whole enterprise” [Erder 2016].

When the definition of solution architecture refers to a project or an application, the points of attention below need to be addressed:

As Murat Erder and Pierre Pureur recommend, “architecting products, not just solutions for projects because architecting products is more efficient than just designing point solutions to projects and focuses the team on its customers”.

Architecturally significant decisions fall into the categories below. They define or modify:

They are classified according to:

Think about decisions as one-way or two-way doors [Rossman 2019]. When you walk through a one-way door, if you do not like what you see on the other side, you cannot get back to the initial state. This type of decision, also referred to as a Type 1 decision, is difficult to reverse. For example, once you have settled for the asynchronous architecture style, it is difficult to revert to a synchronous architecture style.

When you walk through a two-way door, if you do not like what you see on the other side, you can walk right back through the door and return to the previous state. This type of decision, also referred to as a Type 2 decision, is easy to reverse. Type 2 decisions should be delegated to the lowest reasonable organizational level.

The scope of a decision is the surface of its impacts along the Level and Perspective axes of Figure 7.

Table 1 formulates recommendations depending on the type and scope of decisions.

When combining intentional and emergent architecture, decisions that come from intentional architecture may change. New ones are added and past decisions can be reversed. Therefore, it is important to document the motivations behind past decisions. An Architecture Decision Record (ADR) provides an Agile and lightweight way of doing this.

Michael Nygard [Nygard 2011] wrote a blog that explains why and how to document architecture decisions. When someone does not understand the rationale of a decision the choice must be made to either accept it, though it should be changed because the context has changed, or change it without understanding the consequences.

Michael Nygard has developed an ADR template that is accessible on GitHub [Nygard] and outlined below:

ADR Title

Intentional architecture is illustrated here using a Car Sharing Platform (CSP) example that began as a startup to connect drivers to passengers, where drivers publish their available seats and passengers reserve them online.

At the beginning, the connection between users was free-of-charge. The CSP needed to add a profit formula to its business model and has experimented with several economic models:

The transactional model is now the most frequent; the driver sets a price per passenger based on a recommendation from the platform of around €0.065 per kilometer. The price must not exceed the cost of the journey so that the driver cannot make a profit from it. The CSP adds a commission that changes depending on the country of operation. In France, it is around 18% to 21%.

In order to fund its international development, the CSP conducted a few massive fundraising events. Because the economic situation and culture of each country is different, the economic model was customized by each country. For example, in some countries, the CSP does not charge a commission. In Poland, the CSP has switched to subscription. The net is that few countries are profitable.

The rather unprofitable international development combined with increased competition forced the CSP to change. The number of employees was significantly reduced and platform algorithms were improved; for example:

On the organizational side, the CSP was initially divided into large teams. Then, little by little, the CSP broke down its organization into smaller teams aligned with outcomes. It effectively created small startups of 6 to 12 people, regrouped into tribes.

On the software side, the CSP adopted DevOps. This enabled the enterprise to make more than ten updates of its services a day.

Figure 8 is a simplified representation of the CSP development stages; and see the corresponding points (1) to (6) in the text that follows. Architecturally significant decisions must be made at some development stages. Not all “Continuous Product Improvement” iterations require “Product Architecture Refactoring”.

“User Research” (1) helps to clarify driver and passenger needs. It provides inputs to segment the market. Passengers need to travel cheaply from Point A to Point B at some date and time. Drivers who have seats available can offer them. Passengers may work for enterprises that need to facilitate employee commuting.

The first architecturally important decision is about segmenting the market. Passengers and drivers are two obvious segments with complementary needs. Enterprises are a potential market segment, though less obvious to define.

The “Initial Product Architecture” (2) is simple. It is based on a two-sided market supported by a platform that connects passengers and drivers. The platform offers minimum community features to help better match passengers and drivers; for example, using social reputation. The key design objective is to balance the growth in demand for transportation with the growth of transportation offers. If the two are unbalanced, passengers or drivers will become frustrated.

The next stage is to develop a “Minimum Viable Product” (3), which consists of:

Because the MVP objective is to validate the product’s market viability, the CSP opts for a sacrificial architecture for its initial website.

Martin Fowler coined the term “sacrificial architecture” [Fowler 2014] to designate situations where a team deliberately chooses to throw away a codebase. He lists some examples of companies that have done this, such as eBay or Google^®.

When fewer resources are allocated to developing the website, more can be spent:

In this example, a sacrificial architecture is risky should rapid traffic growth exceed the capacity of the website. This is one example of the trade-offs that must be analyzed. The sacrificial architecture decision should be documented using an ADR.

Architecting the support function is important too. One of the goals is to minimize fixed costs until the CSP can prove that the economic model works. Support primarily relies on self-care, which is completed by a call center to handle cases that require human intervention.

The more sophisticated the self-care, the higher the software development costs. The more cases not solved by self-care, the higher the support costs. This is an example of an operating model decision that impacts architecture (4), (5). Architecturally important operating model decisions must be documented using ADRs.

Architecture evolution is also triggered by new ideas that emerge from the bottom up. For example, a new car rider’s localization feature was invented during a “coding night”. One hour before the scheduled departure time, the driver is asked to join Ride Map, and to indicate the exact starting point on that map. Passengers can then easily find their driver and are also invited to share their location, to facilitate the meeting.

This new feature requires updating the driver and passenger journeys and interfacing the platform with mapping software in real time. This impacts the existing platform architecture.

Two CSP business development strategies require intentional thinking:

The fast international expansion requires a well-thought out operating model and platform architecture. Examples of architecture questions include:

The shift toward a multi-modal transportation model requires a different approach. Instead of an iterative process, shifting to a concurrent development process is recommended. Though the CSP “as-is” architecture is modular, unavoidable dependencies remain. For example, a new “multi-modal reservation” sub-system needs to interface with the “car-pooling seats reservation” sub-system. A new “multi-modal pricing” module aggregates the prices quoted by car-pooling drivers with prices provided by third-party reservation systems.

Because seats offered by third-party reservation systems cannot be blocked by a distributed transaction monitor, an event-driven architecture that implements a Saga transactional model is mandated. Section 21.2.2 introduces this architecture style and the concept of Saga.

Waterfall and iterative processes often tend to identify the incompatibilities of architectural decisions too late, which is a major cause of rework. By contrast, SBCE delays architecture decisions until “the last responsible moment” [Atwood 2006]. It is counterintuitive that delaying decisions actually shortens development time while improving quality.

When the solution space is constrained too early, it leads to suboptimal architecture decisions. In contrast, SBCE works like this:

The set of design alternatives shrinks as they are eliminated, knowledge accumulates, and the remaining alternatives are developed to increasing levels of fidelity. Simultaneously, target ranges narrow in corresponding stages, converging on values that provide the best set of trade-offs.

The starting point is the creation of a context map to help decompose the CSP platform into sub-systems. Chapter 20 introduces context maps.

Figure 9 represents a context map for the multi-modal reservation domain.

Applying the Inverse Conway Maneuver, the CSP segments the organization into teams that:

Agile teams work in parallel and follow a responsibility-based management style. Figure 10 illustrates the big picture and describes how all the pieces fit together.

Each team of teams (tribe) and team (squad) mirrors some piece of the intentional architecture model. Integration events are scheduled on a regular basis; for example, for integrating the “Multi-Modal Reservation” sub-system with the “Third-Party Reservation” sub-system. The Third-Party Reservation sub-system encapsulates access to third-party reservation sites; for example, Ouibus.

Design and architecture conversations between teams happen continuously. An Obeya room can be set up to facilitate coordination and cooperation. This is a room that contains visually engaging charts and graphs where teams meet to engage in meaningful design and architecture conversations.

Integration events are experiments that aim to verify how the pieces of the larger system work together. The status is based on results, not on progress reports processed by a project manager who does not understand design and architecture issues.

This document does not impose adopting a “process-oriented” Agile framework such as the Scaled Agile Framework^® (SAFe^®) or Large-Scale Scrum (LeSS). Its purpose is to complement them. A word of caution though; the Agile community is increasingly criticizing these frameworks because they promote practices that are sometimes inconsistent with Lean and Agile tenets. In this chapter the concept of continuous architecture is introduced in the context of intentional architecture. Chapter 6 will drill down further into continuous architecture in a software context.