Many people hate architecture reviews.
I can understand them. When it’s done as a boring and useless committee, full of guys that don’t understand what you are talking about, yet will make the decision.
But architecture reviews are an effective mechanism to ensure the alignment of decisions between stakeholders that have different perspectives, constraints, and time-horizon.
Being owner of such processes, I make a personal commitment to make architecture reviews that feel like peer reviews: a useful process that improves Quality and Speed.
Follow the QE Unit for more Quality Engineering from the community.
What is an Architecture Review as a Peer Review?
An architecture review is a process acting as a quality gate in the software lifecycle, performed between stakeholders impacted by upcoming changes.
Architecture reviews have the objectives to:
- Clarify and assess the need for a change
- Generate alternative scenarios that solves the problem
- Identify trade offs with pros and cons between scenarios
- Assess non-functional requirements and constraints
- Identify potential opportunities of reuse and risks
- Reduce the likelihood of late rework and issues due to poor design
- Capture the rationale for important design decisions
- Discover or reinforce the need of platform foundations
- Ensure decisions are taken favoring shared standards
- Align stakeholders among requests for changes in the landscape.
The practice is common in other domains like in construction, the architect reviews its plans with the builders, yourself, and peers in the office to align what’s going to be done.
The difference in software is that changes are continuous.
It’s relatively easy to plan your garden with the possible extension you would do in your house in the next 10 years. It’s another with a high degree of uncertainty.
Software has to constantly evolve being able to deliver value in the short-term as well as meeting long-term objectives supported by multiple layers of architecture.
That’s why architecture reviews can be done at various levels: enterprise, functional, application, technology, software, infrastructure, security.
The number of actors on complex themes have the tendency to create an inefficient process that gets worse when people play with power and politics.
Implementing an adaptive process of Architecture Reviews as Peer Reviews enable to align stakeholders with minimal effort, yet maximum Quality and Speed.
Why using architecture reviews in Quality Engineering?
Quality Engineering is the paradigm constraining the entire software lifecycle to continuously deliver Quality at Speed software.
The pressure of digitalization is pushing organizations to reinvent their offers through software to generate new value streams.
Companies can only succeed by meeting the expectations of successful user experience, through quality, and by being first in the place to capture value, with speed.
How does architecture reviews contribute to Quality?
Software quality depends on the involved stakeholders, their needs, objectives and perception; an alignment on quality requires aligning their interests.
The software lifecycle is by nature distributed among different activities and stakeholders, resulting in a reduction of formal interactions and sharing between them.
Architecture reviews are an effective way to share and validate upcoming changes for stakeholders concerned by the decision, aligning on the direction.
Architecture reviews contribute to Quality being:
- Result-driven focusing on concrete software deliverables to plan
- Systematic as applicable to all changes and linked to DoR or DoD.
- Scalable fostering asynchronous process and deployable among teams.
How does architecture reviews contribute to Speed?
Architecture reviews, or committees to be more precise, have the bad reputation of slowing down initiatives with useless templates and discussions.
While taking decisions in a silo with a high degree of autonomy is satisfying, it has a high probability of missing critical information that leads to costly reworks afterwards.
My grandfather always said that it’s much easier to change something on paper than once it’s done; I totally agree, and promote architecture reviews that enable speed.
Architecture reviews contribute to Speed with:
- Focus in the main stakeholders, questions and points to be addressed
- Rhythm by defining the topics to address, milestones and implementation timings
- Asynchronicity leveraging portals, notifications and collaboration tooling
- Visibility on the current pipeline of upcoming changes and rationale of decisions.
How to start using architecture reviews in QE?
Implementing architecture reviews is like any structuring initiative, it must start slowly on a limited scope to then expand once foundations are in place.
The goal is to take effective decisions with minimal effort. Hence, ensure that simple changes go fast with a light process, while larger initiatives are correctly decoupled.
It is important to stick to the following principles:
- Don’t use status name like “board” or “committee”
- Seek minimal effort to validate changes
- Involve early the different stakeholders
- Provide guidelines over strict rules
- Share visibility of pipeline and decisions
- Drive with rhythm to keep moving forward.
We can differentiate three main steps to getting started with architecture reviews:
- Pre-requisites
- Process
- Measurement
Prepare Architecture Review Pre-requisites
This first step consists in installing the foundations required to support your architecture review process and measurement.
You need to implement the following key elements:
- Architecture Review Space
- Architecture Review Process
- Architecture Review Template
- Architecture Decision Record
- Architecture Decision Pipeline.
The documentation space can be your company knowledge portal like Confluence, Notion, and similar alternatives. It’s important to structure it with the next elements.
First, write a page that formalizes the review process:
- Explicit the why, what, who, when, how
- Clarify who is owner of the process
- Define how stakeholders are involved and decisions are made
- Add past examples where it could have made the difference
- State when to perform architecture for the clarity of process
- Provide relevant pointers to the other areas.
The architecture review template can be quite simple, sticking to providing guidelines over rules. One effective way is to have one page per architecture review where context is given, topics and stakeholders identified, with the planning of subjects review.
Each topic or subtopic of an architecture review can rely on the One-Slide Problem Summary, followed by relevant slides that support your analysis and argumentation.
The last parts to formalize are the Architecture Decision Record (ADR) and the Architecture Reviews Pipeline.
The ADR is a record of decisions taken capturing the key elements of context, options evaluated and rationale for decisions.
ADR are useful at many stakes:
- Make sure everyone in the meeting is aligned
- Sharing asynchronously to many stakeholders
- Systematize changes in referential like cartography
- Identify patterns, standards and foundations improvements
- Avoid future questions like “Why was that decided that way?”.
To that effect, I recommend this page containing useful ADR templates.
The remaining element is the Architecture Review Pipeline that will contain all the upcoming, in progress and archived architecture reviews with relevant links to documents. It can be achieved with a sheet, a backlog management tool, just pick a simple solution to start with.
Initiate The Architecture Review Process
Starting your architecture review process will follow a gradual deployment among the organizations, focusing on topics that can act as early wins.
One temptation is to try to address all changes, but that’s not realistic ambitions.
Follow the architect’s advice of Gregor Hohpe: “Play or Pass”.
Then apply the architecture review process on selected topics added to your architecture review pipeline:
- Formalize the problem
- Identify the sub-topics to address
- Plan the minimal workshops needed
- Write the architecture decision record
- Share the decision among stakeholders
Write a master page containing all the reference information regarding the review, such as the problem statement, list of subtopics, stakeholders, and review planning.
After having performed the preparation workshops, plan each review meeting with:
- A prepared One-Slide Problem Summary
- Additional content to support the discussion
- Minimum of stakeholders required for sharing inputs and decisions.
Once the review is done, archive the page in a specific area, write the Architecture Decision Record following the template, and share it with participations for validation before sharing more broadly in the organization.
Use measurement to drive improvements
You will get better at “architecture reviews as peer review” process with practice, time, and most importantly, continuous improvement.
The objectives of reviews being to accelerate the delivery of valuable software in the short and long-term, various measurements are required.
The following metrics can help to measure the review process performance:
- Architecture reviews NPS (why not?)
- Architecture review cycle-time (from planning in quarter to decisions)
- Architecture review reworks (number of time taken decisions were reviewed).
You can complete your view with factual metrics on the number of views of the ADR space, visualization of architecture review page, and engagement.
But the most important outcomes matters, starting by the business ones:
- Are you delivering more Quality at Speed software? (you can complete this view with NPS, business measures and Accelerate metrics)
- Are you making better decisions for your trajectory? (i.e. reuse assets, identify new opportunities, generate scenarios with more value and less risks)
- Are you capturing mid-term benefits from architecture reviews? (i.e. able to accelerate with previously taken better decisions)
Subjective feedback from stakeholders is also useful, asking questions like:
- Does the team feel the process is useful and delivering value?
- Are stakeholders feeling involved and influencing the process?
This satisfaction measurement is not easy but essential to your initiative. It can be frustrating that a good part of the process value is not visible, due to time delays to see benefits.
That’s why it’s important to complete measurements with factual metrics and engage with stakeholders to adapt the process to maximize value creation.
Architecture Reviews as Peer Reviews within MAMOS
The effective implementation of architecture reviews is a game-changer for organizations looking to accelerate with Quality Engineering.
They have to align the different domains of MAMOS, ranging from Methods, Architecture, Management & culture, Organization and Skills to transform the entire system.
Even if Architecture reviews as Peer Reviews is part of the domain Methods, it enables to systematically assess the fit of changes across the different layers.
Methodologies are as boring as the people who organize them and the ones who accept to participate. If it’s not working, do something to make it better.
After all, you drive the change.
References
Software Architecture Review: The State of Practice by Muhammad Ali Babar, Lero—the Irish Software Engineering Research Centre and Ian Gorton, Pacific Northwest National Laboratory, IEEE Computer July 2009 © IEEE 2009
Samir Roshan (2012), IT Architecture Review: The Basics, The Approach, The Outcome. Thinking Loud on Cloud.
Georg Buchgeher, Rainer Weinreich (2013), Agile Software Architecture: Chapter 7. Continuous Software Architecture Analysis. Morgan Kaufmann.