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

Just Enough Anticipation: Architect Your Time Dimension

Eltjo Poort, IEEE Software, vol.33, no.6, pp. 11-15, Nov.-Dec. 2016

A bit of planning is indispensable to anticipate events that will affect your software’s risk profile. Traditional architectural planning emphasizes the spatial dimension (for example, components and connectors) but neglects the time dimension. Consulting IT architect Eltjo Poort makes the case for an explicit representation of architectural evolution along the time axis and reports on the experiences with architecture roadmapping where he works.

Official link

Pre-publication version

Architectuur krijgt nieuwe kans (Dutch)

Eltjo Poort, Computable, 20 September 2016

Official link

‘The best architectures, requirements and designs emerge from self-organizing teams’, is wellicht het meest misbruikte principe uit het Agile Manifesto. Door de jaren heen was de gangbare interpretatie van dit principe verworden tot: ‘Hoe minder je nadenkt over de toekomst, hoe beter je systeem wordt.” Het was de afgelopen tien jaar in de software-ontwikkeling niet bon-ton om het over architectuur te hebben. Maar het tij is langzaam aan het keren.

Modelleren wordt weer oogluikend toegestaan – zij het soms achter gesloten deuren, om het stigma ‘Big Up-front Design’ te vermijden. We durven het nog nauwelijks hardop architectuur te noemen, dus ontstaan er eufemismen als ‘Design thinking’ en ‘Master builder’. Maar het besef dat een beetje anticipatie in je systeemontwerp noodzakelijk is om risico’s beheersbaar te houden is nu wel doorgedrongen, getuige bijvoorbeeld het concept van de ‘Architectural Runway’ in het steeds populairder wordende Scaled Agile Framework.

Het is dus weer veilig voor ons, de anticiperende ontwerpers in de digitale wereld, om voorzichtig uit de kast te komen en ons bekend te maken als bijvoorbeeld enterprise-architect, solution-architect of software-architect. Daarmee is het ook tijd om de balans op te maken: wat staat ons te wachten, wat speelt er in het land van de digitale architectuur? In dit artikel een korte inventarisatie van de belangrijkste trends en ontwikkelingen.

SATURN 2016 – part 2

This is the second and last part of my SATURN 2016 conference report. Since I posted the first part, the organizers have posted video recordings of many of the best talks, and more will follow on the SATURN playlist on YouTube.

Ethical and social considerations in software architecture design featured in many talks, but most prominently in three short “DEV@SATURN” talks by Michael Keeling, João de Sousa and Bett Bollhoefer. DEV@SATURN was a new feature this year: 15 minute talks in the plenary sessions, which yielded some enjoyable and interesting food for thought; I would say a successful experiment. Michael presented a reasoning framework for ethical considerations in architectural decision making, including some reusable quality attribute scenarios for environmental sustainability and fairness to customers and developers. João reported on his work to develop an Internet of Things interaction framework (“Bezirk”) that shifts the power to control data exchanges from companies and application developers to end users – an architecture that gives app users more choices than just the two bad options we are generally given now: give access to everything the app demands or the app doesn’t work at all. João received the conference’s New Directions award for his talk. Bett gave us a glimpse of the insights into mindful software development she gathered in a “Zen of Software Development” booklet (and got the whole audience to do some yoga on the spot…).

Other highlights

For me, the most interesting keynote was Daniel Jackson’s “Rethinking Software Design”. It was mostly about user experience design, and the word “architecture” only appeared once – but Daniel presented some keen insights into the impact of bad user interaction design at the architectural level. Software and solution architects generally do not get very much involved in user interaction design, especially those schooled in the SEI architecture practices, which are mostly based on the notion that non-functional requirements and quality attributes drive architectural design. But isn’t usability also a quality attribute? Bad user interaction design has a substantial risk and cost impact, and can cause a project to fail – both strong indicators that user interaction design is architecturally significant, and thus should be addressed by architects.

Another highlight was Eoin Woods’ talk on Getting your system in production – and keeping it there. 90 minutes of great practical advice. Eoin is a star at systematically presenting solutions, and illustrates each and every point he makes with an amusing (or dramatic) real-life story. Like user interaction, production is another area architects sometimes underestimate, or at best have an ad-hoc approach to. If you have a few minutes, peruse Eoin’s slides, and if you have some more time, watch his presentation here.

getting production

IMG_0472At the close of the conference, I had the honor of receiving the first Linda Northrop Software Architecture Award, a few minutes after Linda herself gave a very nice overview keynote on the status of the software architecture practice. It felt great to get such international recognition for the hard work my CGI colleagues and I put into improving the way we do architecture, during a decade in which the whole idea of up-front design was widely discredited by the mainstream software development community. As noted above, the pendulum seems to be swinging back in the other direction now, and people are back modeling systems in order to build better software – hopefully, before long, with the door open again.

SATURN 2016 – part 1

This year’s SATURN (Software Engineering Institute (SEI) Architecture Technology User Network Conference) was held in San Diego from May 2-5. Compared to last year, the geographical context was much improved – Southern California felt a lot more relaxed than Baltimore under curfew. The conference organizers had once again prepared an excellent technical program, and as always it was sometimes difficult to choose between tracks – everything was interesting. Fortunately, all presentations were video-recorded, and should appear on the conference website soon.

The fantastic opening keynote was by community guru Grady Booch, who gave us a peek into the future of architecting. He talked about “abstracting the unknown”: architecting the kind of systems that stretch us both technically, socially and ethically. His talk set the stage for a number of central themes that pervaded the program: evolutionary architecture, ethical considerations, and the renewed recognition of the role of modeling (the real world) and intentional design in software engineering. Slides 43-45 in Grady’s presentation give an elegant summary of the modern view of why and how we architect. As for architecting the unknown, it is clear that there is much less opportunity for reuse, and that we need a method that allows our intuition to play a much more prominent role.

architecting the unknown

Grady Booch’s tips when you find yourself having to architect the unknown.

Evolutionary architecture and roadmapping was the topic of talks by Patrick Kua, David Adsit, Alejandro Bianchi, Pierre Pureur (continuous architecture) and myself, and of a keynote by IoT frontrunner Joseph Salvo. The common message here seems to be that the “dot on the horizon”, the architected future state, is becoming less meaningful in a world that changes faster than architectures can be realized. We therefore need architectures and architecting practices that are flexible and resilient enough to maintain their value in a rapidly changing business or technological context. We all reported on our experiences implementing such practices, in my own case introducing an evolution viewpoint to help achieve just enough anticipation in your architecture.

Adding time dimension

Modeling the real world seems to be a prerequisite for an architecture to have that flexibility and resilience. I remember teaching this in Object Oriented Analysis and Design classes in the 90s, but it seems that insight is resurfacing now after having been deprecated by overzealous agilistas for a while. This was the topic of talks by Amber Haley, Arila Barnes and George Fairbanks, and played an important role in Daniel Jackson’s excellent Wednesday morning keynote. George talked about the stigma clinging to modeling in some agile teams, and “modeling with the door shut” to avoid being seen practicing such a shameful activity. It was also funny to see that modern modelers are developing their own, new languages for domain modeling, where we successfully used UML in the past. It seems UML is now so much associated with technical design that people don’t recognize it as a domain modeling language anymore, and feel the need to reinvent the wheel… for similar reasons, much of what we used to call architecture now seems to be relabeled “design thinking”.


There is much more to report on SATURN 2016 – next installment coming up soon!


The Software Engineering Institute at Carnegie Mellon has selected me as the winner of this year’s Linda Northrop Software Architecture Award. I feel honored to receive this award from the most respected research institute in our profession. It is a great recognition of the work done by the RCDA team at CGI in the past six years. Thank you Philippe Kruchten for nominating me, and Eoin Woods and Tom Verhoeff for endorsing my nomination.

Architecting in a Solution Costing Context: Early Experiences with Solution-Based Estimating

Eltjo R. Poort, Eric van der Vliet, Software Architecture (WICSA), 2015 12th Working IEEE/IFIP Conference on , vol., no., pp.127-130, 4-8 May 2015

Organizations require cost estimates for delivering and operating software-intensive solutions. One of the factors impacting these costs is the solution’s architecture. Applying solution architecting practices helps improve the accuracy of early cost estimating. In CGI, we have started to emphasize the application of architecting practices in cost estimating, and this paper reports on the early experiences of this initiative, which we call Solution-Based Estimating. We present an architectural viewpoint designed to address the costing concern, and report some early feedback from projects that have applied the Solution-Based Estimating approach.

Official link

Pre-publication version