Intentional Architecture

This document defines intentional architecture as a purposeful set of statements, models, and decisions that represent some future architectural state. This document recommends balancing intentionality and emergence. Though BUFD is incompatible with Agile ways of working, this document recognizes the need and value for intentional architecture. Agile Architecture is leaner and combines intentionality and emergence.

The scope of intentional architecture is defined by the three axes of Roadmap Space. It is equivalent to Figure 19-1, Summary Classification Model for Architecture Landscape, in the TOGAF Standard, Version 9.2 [TOGAF Standard 2018].

Figure 1. Roadmap Space

Enterprise Architecture versus Solution 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:

  • A project time horizon may not match the time horizon of other solutions or products, therefore they may impact other teams with different time horizons

  • When Agile organizations shift from project to product, the definition of solution architecture evolves to become the product architecture

  • The boundary between architecture work and project work is blurred; for example, it is not obvious that implementation tasks qualify as architecture work

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

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

  • The way the enterprise is segmented

  • The allocation of functions or activities to segments

  • The structural interfaces that link segments

  • The standards or guardrails that facilitate interoperability and composability

They are classified according to:

  • Their degree of reversibility

  • The breadth of their scope

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 Roadmap Space.

Decisioning Patterns formulates recommendations depending on the type and scope of decisions.

Table 1. Decisioning Patterns
Decision Type Decision Scope Decisioning Approach

Type 2

One team

Delegated to the team. Fast decision-making and experimentation.

Type 1

One team

Delegated to the team. Careful discussions. Delay the architecture decision until “the last responsible moment” [Atwood 2006].

Type 2

One team of teams

Delegated to the team of teams. Cross-team coordination. Fast decision-making and experimentation.

Type 1

One team of teams

Delegated to the team of teams. Careful discussions and cross-team coordination. SBCE. Delay the architecture decision until “the last responsible moment” [Atwood 2006].

Type 2

Several teams of teams

Cross-team coordination. Consensus or committee decision-making. Fast decision-making and experimentation.

Type 1

Several teams of teams

Cross-team coordination. Committee decision-making. SBCE. Delay the architecture decision until “the last responsible moment” [Atwood 2006].

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.

Architecture Decision Record

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

  • Status

    What is the status: proposed, accepted, rejected, deprecated, superseded, etc.?

  • Context

    What is the issue that is motivating this decision or change?

  • Decision

    What is the change that is being proposed and/or being executed?

  • Decision scope

    Which segments of the enterprise and its software systems are impacted?

  • Decision type

    Is the decision easily reversible or not, and why?

  • Consequences

    What becomes easier or more difficult to do because of this change?

Example: Car Sharing Platform (CSP)

This fictional example is presented here for illustrative purposes only, to support the text and to enable a clearer understanding for the reader.

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:

  • Sell the car-sharing service to other enterprises

  • Offer a “for a fee” phone bridge that participants can use to talk to each other

  • Offer a monthly subscription model

  • Charge passengers for each ride (transactional model)

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:

  • To automatically define new points of contact between drivers and passengers, closer to their homes

  • To enable a multi-modal platform that includes other modes of transportation than cars; for example, bus rides

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.

From Intentional to Continuous

Startup Stages 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”.

Figure 2. Startup Stages

“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:

  • The website

  • Client support

  • A communication plan to boost usage

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:

  • To improve quality, which directly impacts user experience

  • To boost communication, which is key to MVP success

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

  • The shift toward a multi-modal transportation model

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

  • Which activities should remain centralized, or be decentralized?

  • What should be the scope and setup of local country operations?

  • Should the original website be cloned in each country, or should the CSP develop a multi-tenant platform that could be customized to meet individual country needs?

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. Benefits of Event-Driven Architecture introduces this architecture style and the concept of Saga.

Set-Based Concurrent Engineering (SBCE)

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 product team breaks the system down recursively into sub-systems until the right level of granularity is reached

  • It identifies a broad target for the system and each sub-system

  • Multiple concepts for the system and each sub-system are created

  • The team filters these concepts by thorough evaluation, eliminating concepts that are weak or do not fit with each other

  • Failure information goes into a knowledge base that guides architecture design

  • As filtering occurs, there is a rapid convergence toward a solution that is often more elegant and innovative than the one conventional point-based development would produce

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.

SBCE of the CSP

The starting point is the creation of a context map to help decompose the CSP platform into sub-systems. Domain-Driven Design: Strategic Patterns introduces context maps.

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

Figure 3. Simplified Context Map

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

  • Deliver a product, a product feature, a journey, or a sub-journey

  • Mirror the candidate sub-systems identified by the context map (the Inverse Conway Maneuver)

  • Include business, software development, security, and IT profiles (cross-functional)

  • Are led by product owners

  • Measure success against Objectives and Key Results (OKRs)

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

Figure 4. Responsibility-Based Management

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.

A Few Concluding Words

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. Continuous Architectural Refactoring will drill down further into continuous architecture in a software context.