Architecting transient solutions

When I teach architecture classes, I increasingly run into architects who never architect a “system”. They do all the things architects do: analyse stakeholder needs, identify ways to address these needs, (help) decide on the best way by making trade-offs, communicate these decisions and oversee the solution’s implementation. However, after all the work is done, the stakeholder needs are fulfilled, but there is nothing in the real world that they can point to and say: “that is the thing I architected”. At the end of the road, the implementation of their solution to the stakeholder needs consisted of a series of changes to existing systems, but did not require the creation of a new system. Their job is to architect transient solutions: changes to a domain or product they are responsible for.

One example was brought to me by the architect responsible for a transportation ticket vending machine. There was a stakeholder need to reduce the time and cost required to deploy new products and user interaction schemes, and the solution was to move most of the logic and data from the vending machine to a central place. Projects like this require significant (and careful) design effort, and substantial implementation time. A documented solution architecture is a must. However, at the end of the road, no new systems have been created (with the possible exception of minor components like hubs between previously unconnected systems).

Depending on the prevailing flavor of delivery governance, such transient solutions are defined in architecture epics, project documents or change requests. The architects designing them call themselves “domain architect”, “project architect”, “tech lead” or “master builder”.

What’s in a name

Is this really architecture? The ISO 42010 definitions of architecting and architecture both refer to a “system” of interest, e.g. “fundamental concepts or properties of a system in its environment embodied in its elements, relationships, and in the principles of its design and evolution”. All the other words seem to apply, so can we ignore the fact that there is no one “system” to point to after implementation of the architecture? Is this question really relevant, as long as the person designing these solutions knows how to apply architecting principles and practices?

If this is architecture, what type of architecture is it? Of all the different genres of architecture (software, infrastructure, system, enterprise architecture, etc.) the term solution architecture seems to best cover these transient solutions. This phenomenon actually helps us to create an appropriate definition for the term solution in solution architecture. Where previously we had to make do with something like “a solution is a way to solve a problem”, I would suggest the following:

Solution: a coherent set of changes delivered to address a defined set of stakeholder needs.

The changes referred to in this definition pertain to elements which can be newly created, modified or removed as part of the solution. The term coherent implies that the (changes to the) elements cooperate to achieve the fulfillment of the stakeholder needs (using Fred Brooks’ term, the solution has conceptual integrity). Coordination of a solution’s delivery depends on the governance model applied, this can be using agile or traditional delivery models, in a value stream, in a program or project, governed by a contract or otherwise. How and where the stakeholder needs are defined also depends on the governance model applied, this can be in an epic or set of (user) stories, but also in a program or project definition, contract or change request. From the perspective of this definition of solution, architecting a new system or service is just a special case where the “set of changes” consist of the creation of one new system or service.

Applying architecture practices

How does this way of looking at solution architecture affect the way we apply architecture practices? To explore this question, let’s take Risk- and Cost-Driven Architecture (RCDA) as our reference practices. As stated in the introduction, most core practices apply to both transient solutions and to system (or system of systems) solutions:

Architectural Requirements Prioritization No change.
Architectural Decision Making No change.
Applying Architectural Strategies System solutions: focus on decomposition.

Transient solutions: also focus on transformation of

Architecture Documentation System solutions: architecture documentation maintained
with system.Transient solutions: documentation dissipates into the
documentation of the systems affected by the solution.
Solution Costing System solutions: solution breakdown structure decomposes
into new elements to be created .Transient solutions: solution breakdown structure
decomposes into transformation of affected elements.
Architecture Evaluation No change.
Architecture Implementation System solutions: focus on build and integration.

Transient solutions: focus on dependencies between changes
to affected elements (and integration).

Technical Debt Control System solutions: technical debt controlled at system level
(and higher).Transient solutions: technical debt controlled at level of
changed systems and higher.
Architecture Evolution Not applicable to transient solutions after completion,
because the solution has then dissipated into the affected

As you can see from this brief analysis, the main differences when applying architecture practices occur after the solution has been delivered. The most visible difference is what happens to the architecture documentation, for which it makes no sense to remain “as a unit” after implementation of a transient solution, except for historic reference. Extra care must be taken that the relevant information (such as rationale of architectural decisions) remains available afterwards, either in the documentation of the systems affected, or at a higher level (e.g. in domain or enterprise architecture documentation).


As less and less green field systems are created, an increasing number of architects find themselves mainly designing transient solutions – solutions that dissipate into the landscape and cannot afterwards be identified as a product or system. Good architecture practices are still applicable in this situation. This realization leads to the idea for a defininition of Solution Architecture as the “architecture of a coherent set of changes delivered to address a defined set of stakeholder needs”.

One thought on “Architecting transient solutions

  1. Erik de Ruijter

    Well nothing really new under the sun 😉 Greenfields have always been rare in our practice, quite often it’s step by step getting closer to the Target Architecture.
    Agree with your analysis but would like to stress that it’s also very helpful for a Solution architecture to contain some kind of long-term Target Architecture and Baseline Architecture for the ‘touched’ elements. After all there will very likely be some choices being made compromising on the ideal Target Architecture, e.g. due to timelines or simply lack of budget. And though the Solution Architecture ‘dissolves’ into the documentation of the changed systems, that Target Architecture probably still is kept with Enterprise (and Domain) architects and re-evaluated every 1-2 years or so. Having both, Solution architecture and high-level Target Architecture, then is helpful.
    This is the standard way recommended in e.g. Togaf, and worked well with me and fellow architects for 10+ years.


Leave a Reply

Your email address will not be published. Required fields are marked *