Where did architecture go?
Agile emerged at a time when companies built and commonly released software in lengthy cycles of 6+ months. Each cycle had an explicit architecture or design phase involving more experienced developers, frequently named "Architects." Architects, responsible for architecture, made decisions that constrained development teams. Today's world of agile software development looks very different with software continuously being released - often on a weekly, daily or even hourly basis. But where did architecture go?
Agile approaches do not mention architecture
As more and more organisations adopted an agile approach, they threw out the proverbial "baby with the bathwater." Popular agile methods like XP, Scrum or Kanban don't explicitly include an architecture practice or process. Teams interpreted this absence as an excuse to ignore or deprioritise architectural thinking. Avoiding "Big Design Up Front" (BDUF) turned into skipping any architectural thinking, even though a small amount would have added tremendous value.
Thinking about architecture is even more essential in today's world of rapid, agile software development. Gone are the days that a single person makes architecturally significant decisions; leaving the implementation to others. Software is too complicated and evolves too rapidly.
Technical decision-making accelerated
The reach of decisions expanded over the last two decades with richer libraries, frameworks, and APIs provided by SAAS platforms. The pace of technical decisions accelerated with on-demand cloud infrastructure, automation tooling and continuous delivery patterns. Today, developers can rapidly create rich applications with powerful building blocks. These building blocks inadvertently shape and constrain architecture. Without an explicit focus on architectural thinking, developers produce accidental architecture - a software system built through a series of small decisions without any forward-looking guidance.
No single role owns architecture
Organisations who transitioned to agile ways of working often still have an Architect role. Although teams may have changed their practices, the person playing the architect role rarely changed their mindset. An architect, now working in an agile team, still views their role as the “owner” of software architecture, or the person who makes the architectural decisions. You might observe this when an architect moves across teams either defining architectural blueprints, or mandating a standard, tool or approach. Teams will often nod along, find out the decisions are not fit for purpose, or bothersome and pragmatically find a lightweight solution or workaround. I’m sure you’ve seen this dysfunctional behaviour before.
Architecture is often described as the decisions that are hard to change. Making a good decision is much harder in a world where everything is much more dynamic - user needs evolve, product strategy pivots, dependencies like libraries, APIs or frameworks change and naturally the speed and amount of code developers write. A single person cannot maintain an up-to-date picture of context to make a well-fitting decision.
The solution? Everyone needs to own architecture.
Everyone owns architecture
Good decisions always account for context. A design choice that helps a service scale to thousands of concurrent users may add unnecessary complexity for a service that will never need to scale. Adding numerous metrics and observability to a service makes sense for a critical business service but is wasted effort for a one-time use. The people who are most familiar with the context for a decision are those who are working in that context every day. Developers! In successful agile teams, architects no longer try to be the single person making good decisions. Instead, they help developers make better architectural decisions.
What successful architects focus on in agile organisations
Successful architects in agile organisations no longer see their role as exclusively making architectural decisions. They see their role as ensuring good architectural decisions get made. Mostly by team members, sometimes with support from the architect and rarely by the architect themself.
To ensure teams make better architectural decisions, an architect looks at what they can do to improve everyone’s ability to make architecture decisions. If architecture is about making good decisions that are hard to reverse, then an architect focuses on two levers:
- Make decisions easier to undo
- Help people make better decisions that are harder to undo
Making decisions easier to undo
Developers make decisions constantly. In almost every business, Product Managers pressure developers to deliver software faster. In response, developers look to see what they can reuse or build on. Developers might search for a library or framework, or find code on StackOverflow that meets their current need. If developers find a solution, they will often copy-and-paste, or follow a step-by-step tutorial to build what they need.
In the haste to deliver value quickly, developers are not focused on designing for reversibility. Others may not know how to do so because they are not as experienced. From a business perspective, the developer may have delivered a useful feature but from a technical perspective, they may have added in accidental complexity, or unnecessary coupling. A developer building a new service in a framework might deliver something quickly but not recognise the way the framework constrains future choices.
Architects improve this by reminding developers to focus on good design; to focus on building well-refactored code and teaching developers techniques, what to look for and how to improve this. An architect amplifies their team’s ability to transform code that might look like an architectural decision (harder to change) into a design decision (easier to change). For some developers it might be enough to add a check for unnecessary coupling to a code review, or to a definition of done list. For other developers, an architect might need to teach developers coding approaches that increase the reversibility of change like the Adapter Pattern, Inversion of Control and Separation of Concerns. A single architect won’t scale to review every decision, but a team can.
Making better decisions that are harder to undo
Not all decisions that a team makes can be simplified to design decisions. Some decisions will be hard to change and therefore architecturally significant. What can architects do to help teams make better decisions? Two things. Provide context and guidance about what good looks like.
An architect typically has more context than a developer on a team. The architect interacts with more teams. They have a broader but less deep awareness of how systems evolve. A developer has the opposite - a much deeper awareness of the current state of a system and how they are changing it but less awareness of what other teams are working on.
A developer, with a narrower focus, might make a decision that seems suitable for their context, but may make less sense in the broader organisation. If only they had more context! Fortunately, architects can provide this. Better yet, architects can create channels for developers to discover and pull for more relevant context. A common mechanism for this is to work with teams to write down and publish Architecture Decisions Records. These might be as simple as on a wiki, or as a MarkDown file in source code repository for a service. Once decisions are written down, they are more discoverable and with a little encouragement from an architect, developers build a broader context that influences their decision.
How can architects provide guidance to developers about what a good decision looks like? Through architectural principles. Unlike rules, principles provide a guiding framework, describing what to optimise decisions for and why. Principles are not a substitute for thinking, but a tool to improve decisions.
Architectural principles look different across organisations. Each organisation is building a different product, with a different engineering culture and optimising for different needs. Therefore it makes sense each organisation defines a set of architectural principles about what good decisions look like for their context. An example of some principles if you’re building cloud-native software is “The Twelve-Factor App” (https://12factor.net/). If you’re not building cloud-native software, many of the guidelines will feel out of place.
Architecture is there, but it looks different in an agile world
Agile methods may not have explicit practices for architecture but that should not be interpreted that architecture is no longer important. If anything, architecture is even more important today with teams making more decisions quicker. The increased velocity of decision-making means it is impossible for a single person to own or manage them. The traditional gatekeeper of architecture, the architect, must adapt to this faster world or become irrelevant.
To stay relevant in today’s fast-moving world, architects must focus less on making the most important architectural decisions, and instead focus on building an environment where everyone makes better decisions. To do so, architects might need to play the role of a teacher, showing how developers can transform architectural decisions into a design decision. Sometimes an architect must act like a guide, connecting teams, providing context and guidance about what good decisions look like in that organisation.