One of the things architects can learn from the Agile mindset is the importance of short feedback loops. The quicker an architect receives feedback on their output, the faster they learn about its effect in their specific solution context – and better informed architects make better decisions. Architecture is a matter of reducing uncertainty by gathering knowledge and making decisions, and a shorter architecture feedback loop speeds up that uncertainty reduction, leading to better architectures. On top of this, shorter loops lead to shorter reaction times when things change, which increases agility. In this blog post, I will share some tips for shortening the architectural feedback loop.

Architectural decisions are your primary deliverable

What does your organization consider the primary architectural deliverable? Chances are it is a document with a name like Project (Start) Architecture or Software Architecture Description – let’s call it The Architecture Document. It takes weeks or even months to produce, after which time all architectural models and decisions are approved and distributed in one foul swoop – The Architecture Document version 1.0. If you are in this situation, the first step to shortening your feedback loop is to start viewing individual architectural decisions as your primary deliverable. The finer granularity of these decisions, compared to The Architecture Document, will make it much easier to speed up the feedback loop.

Continuously share concerns and decisions

Do not be afraid to share your unfinished architecture output. The sooner you share, the faster you learn. I like to let my stakeholders (both business and technical) know what I think are the most critical architectural concerns, and share decisions as soon as I am aware that they need to be taken. (One word of caution: always make sure the status of the decision-in-progress is absolutely clear to prevent people acting on them prematurely.) This gives stakeholders the opportunity to contribute to the architectural process from the start. Make this information as easy as possible to access: don’t put it in text documents, but find a low-threshold platform like a Wiki or issue tracking system.

Invite immediate feedback from stakeholders

We are often hesitant to ask for feedback on something that we ourselves do not consider to be perfect already. Architects, however, cannot afford to wait that long. Most architectures emerge from a dynamic process of frequently identifying new concerns, repeatedly finding out new facts and continuously adjusting partial decisions that interact with each other and our context. The perfect architecture is only known after the solution has been delivered (if then).

So tell your stakeholders to give you feedback when they have it, and not to wait for ‘official’ review moments like a ‘version 0.9’. Make it as easy as possible for them: enable the comments box on your Wiki, invite people to email you. If big print-outs of your architectural models adorn the team’s war-room, make sure to put a pencil on a string next to them. Make sure everyone knows you welcome feedback by asking for it at the water cooler, or on your team chat platform if you are not co-located.

Simplify your architecture documentation template

Template bloat is one of the causes of long architectural feedback loops. Organizations often lack a decent repository for architectural knowledge, and abuse their architecture documentation templates as a dumping place for all lessons learned. Diverse stakeholder concerns for all types of solutions end up getting their own sections in the template. On top of that, architects for whom The Architecture Document is the only place to store knowledge about a solution cause even more bloat. There are two things you can do to fight this document obesity:

• Create a template with sections for only the most common concerns at only the start of a solution’s lifecycle. Get rid of all ‘placeholder’ sections. Add views for other concerns only as they become significant later in the lifecycle, and only insofar as they are relevant to your context – in short, create living, minimal architecture documentation.
• Make sure you have another repository for knowledge that is not immediately relevant at the current point in the solution lifecycle. Create a wiki or library for the organization’s lessons learned and documentation plug-ins for views to be added later in the lifecycle, and find a place outside of The Architecture Document for solution-specific insights that you have gathered.

Get involved in delivery

The final tip for an effective, short feedback loop is to get involved in the delivery of your solution. If you are a software architect, coding key parts of the solution yourself is a great way to get involved. If you do not have that opportunity, get involved in integration, quality attribute testing or other architecturally significant delivery activities. You will not only become your own feedback channel, but also stimulate other delivery team members to tell you about their concerns and help improve your architecture.

In my work of coaching organizations to approach architecting in an agile way, shortening the architectural feedback loop has proven to be one of the most effective ways to improve architects’ effectivity and business value. Especially its positive effect on the scability of architecture work and the start-up time of smaller projects is quickly noticed and appreciated by business stakeholders. Let me know if the five tips in this post prove to be useful to you as well.

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:

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

Conclusion

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