Feedback may be discussed regularly, as an important aspect of much of our work in Agile, DevOps, digital product development, Continuous Architecture and in conversations about optimising learning, but how we actually implement effective feedback loops to obtain that feedback is explored far less often.
It is worth starting with why feedback matters in Continuous Architecture specifically. At its core, feedback acts as an architectural reality check. It forces us to confront a simple but critical question: Are we improving or getting worse at meeting our architectural requirements and stakeholder concerns? Without that check, progress becomes assumed rather than genuine, and decisions risk being driven by our instincts, assumptions and biases, rather than real understanding.
Continuous Architecture places particular emphasis on incremental work, allowing architecture to evolve within the delivery process, rather than being a set of fixed decisions made early in delivery. This shift enables adaptation, but adaptation alone is not enough. To adapt effectively, we need to know how the system is behaving, how it is changing over time and whether those changes are taking us closer to or further away from our intended outcomes. Feedback is what makes that possible.
From linear to circular: how feedback changes everything
In practice, iteration and feedback loops sit at the centre of the Continuous Architecture approach. Work flows through an iterative cycle of architecture, design, construction, testing and delivery, but crucially, it is not a one-way flow. Insights from both the development environment and from the system in operation feed back into architectural decisions, influencing what happens next. Feedback allows not only the path to evolve, but also the goal itself, as new information emerges and priorities shift.
The Agile community often use a diagram like the one below to illustrate the importance of feedback but it is just as relevant when thinking about architecture work.
When we start on any complex endeavour we usually have a vision and an assumed goal, which is based on what we know at that point. But as we progress, if we have effective feedback loops, we regularly learn more and each time this happens we realise that we need to alter our course a little, so we end up at a different, and better, end goal.
A feedback loop like this, in its simplest form, consists of measuring, interpreting, acting and then measuring again. Measurement provides the signal, interpretation turns that signal into insight, action changes the system and further measurement reveals whether that action had the intended effect. When this loop is working well, architecture becomes a process of continuous learning. When it is not, teams may still be delivering, but they are not necessarily improving.
Measuring what matters, not what’s easy
A key challenge is deciding what to measure. It is easy to simply measure what is readily available, such as code metrics, or information pulled from system logs or infrastructure data, but this often leads to measuring what is convenient rather than what is going to provide the most useful insight. To avoid this, it is important to begin with intent: what do we need to understand, why is this important, and what decisions will it inform?
The Goal, Question, Metric (GQM) approach [1] provides a useful structure here. By defining a clear goal, framing the questions that reveal progress and then identifying the metrics that answer those questions, measurement becomes purposeful rather than incidental.
This example shows how the GQM approach can be applied to a performance target, in this case, sustaining 10k TPS under defined load conditions. The goal is broken down into a set of practical questions that help determine whether the architecture is meeting the required quality attribute or whether further architectural work may be needed.
Each question then leads to specific metrics, allowing performance to be measured in a structured and actionable way. In practice, this also requires consideration of how those measurements will be collected, including the data source, collection mechanism and characteristics of the metric itself, such as accuracy, frequency, time period and retention.
Looking inward, outward and upward
It is always important to remember that feedback in architecture is not limited to internal software design concerns. While measurements such as code clarity or the complexity of dependencies provide valuable insight into maintainability and extensibility, external measures such as response time, failure rates or user behaviour reflect how the system is experienced in practice. Business metrics, including transaction volumes or customer engagement, add another dimension, helping to validate whether architectural decisions are supporting broader organisational objectives. A balanced set of measurements in our feedback loops will typically span all three, internal, operational and business perspectives.
Automate for value, not for its own sake
Another common misconception is that feedback loops must be fully automated to be valuable. In reality, feedback can be manual or semi-automated as well as the ideal state of being fully automated, and each has its place.
Manual approaches, such as querying logs or analysing data periodically, are often the best way to start. They allow teams to explore what is useful without significant investment. Semi-automated approaches introduce regular data collection with some level of analysis. While fully automated feedback loops provide continuous, real-time insight and are most effective when the measurement is both important and frequently needed. The progression between these stages should be the result of the value we are gaining from each one.
Fitness functions: making feedback actionable at speed
A widely discussed mechanism for implementing feedback loops is the idea of fitness functions. These provide an automated check against defined architectural expectations, offering immediate feedback when those expectations are not met. For example, a set of fitness functions might enforce limits on response times, complexity levels or security vulnerabilities, raising alerts or halting CI pipelines when they fall outside defined ranges. Fitness functions augment measurements to make them rapidly visible and actionable, highlighting issues as they arise rather than allowing them to be passive artefacts and potentially accumulate unnoticed.
Where feedback loops break down
Despite their importance, feedback loops are often undermined by several recurring pitfalls. Teams may focus on the mechanisms of measurement rather than the value it provides, invest heavily in tooling without a clear purpose, or collect large volumes of data that are never used to inform decisions.
There is also a tendency to prioritise technical metrics at the expense of business measurements, or to seek perfect accuracy when a timely, approximate insight would be much quicker as just as useful. Perhaps most critically, feedback is sometimes gathered but not acted upon, breaking the loop entirely.
Start small, but with intent
For this reason, the most effective approach is to start small but with intent. Identify a limited number of meaningful measures that address key risks or uncertainties, implement them in the simplest possible way and use the results to drive visible decisions. This not only demonstrates the value of feedback early but also builds the habit of using evidence to guide architectural work. Over time, additional loops can be introduced and existing ones refined.
Without feedback, architecture is just a set of assumptions
Feedback loops are not simply a supporting practice. They are the mechanism that connects intent with results, ensuring that architecture work is delivering value for both technical and business needs as systems evolve.
Often not given enough attention or gaining enough traction in conversations, they are a critical step in Continuous Architecture, as it is practising what it fundamentally preaches. As James Clear says, “Success is the product of daily habits, not once-in-a-lifetime transformations.”
I find that many teams find them difficult to create and maintain. How do you do it?
References
- As well as the Wikipedia page, which will lead you to the original references, consult Michael Keeling‘s chapter, “Measure the Unknown with the GQM Approach” from the book Software Architecture Metrics (O’Reilly, 2022).
Continuous Architecture in Practice 