Updated: Updated: Transformation
This is the beginning of a mini-series of reflections on agile software development. I call it “SAFE” - Simple Agile for Enterprises.
As an architect, I am frequently asked about the role that architecture can play in environments that practice agile development methods. The core assumption behind this question is usually that agile teams don’t need architecture or at least don’t need architects.
The Three Architectures
When discussing architecture, my inclination is to start with making sure that we talk about the same thing when we say “architecture”. In my mind “architecture” can refer to 3 different aspects of system design:
- The System: each system we build has an architecture - it has some inherent structure.
- The Doing: we might want to consciously choose what architecture to give our system. That’s doing architecture.
- The People: architecture is done by people who are often called architects and may be part of an “architecture” team.
So, you cannot choose not to have an architecture - every system has one. You can choose to make a conscious decision about the architecture and you can choose to do so with an architecture team or without. Life is full of choices.
Doing Agile Architecture
With that clarification, we can refine our question to whether doing architecture is compatible with agile development. Sometimes, teams get hung up on whether there are people or teams with the title “architect” but for me that’s not the key point. People can call themselves whatever they like.
As usual, I like to reduce confusion by sharing simple models. Unsurprisingly, I have one for doing architecture as well:
The assumed model is often the one on the left where an architect resides on the top and tells developers what to do or how to do things. Sometimes, this model is necessary, e.g. when developers are unable to agree on anything and get bogged down by debates, complexity, and finger pointing. However, this model should be used with caution. Because the architect is lacking feedback from the actual implementation, this setup is prone to an Architect’s Dream, Developer’s Nightmare scenario (the Matrix references in this presentation from 2007 were surely a sign of things to come in my later books).
Alternatively, architects can be embedded in teams, either as a dedicated person (#2) or distributed across team members via a shared responsibility (#3). What doesn’t work is teams claiming that they are “doing architecture” but no one knows for sure how it’s done (#4). The other way this setup is sometimes described: “we don’t need architecture because we’re agile.” Those teams usually flounder and are reverted back into model #1 as a corrective action. They can then work their way to the right again.
So much for the organizational setup, but we still need to be clear why we want to be doing architecture in the first place.
Architecture Sells Options
My favorite description of what architecture does is based on the notion of options (elaborated in The Software Architect Elevator). Options give us the ability to defer decision into the future until more information is available. Being able to do so has value because with more information you can make better decisions. For example, instead of having to anticipate server sizing upfront, architecture can give us the option of scale-out applications and elastic platforms to defer this decision until we actually know how much capacity we need.
As I illustrated in my blog post, the higher the uncertainty we operate under, the more valuable having options becomes. This has been proven in the Nobel-prize worthy Black-Scholes Formula of options pricing but is also intuitive. If an application’s workload never changes, deferring the server sizing decision is less valuable than when we have absolutely no idea what load our application will face.
This leads us to our first major realization:
If options become more valuable with uncertainty and architecture sells options, architecture becomes more valuable with increasing uncertainty.
Agile Methods
Hardly any trend in IT has been as dramatically misunderstood, misinterpreted, and misused as agile methods. The spawning of various prescriptive frameworks and certification programs has only exacerbated that problem. It’s a shame, really, because agile development is fairly simple at the core.
At the center stands the idea to maximize business value by delivering software early and frequently. It’s assumed that priorities change, so late changes are welcomed even if it means deviating from the original plan. These values are cemented in the Agile Manifesto from 2001 (please also look at the 12 principles, not just the values).
In a static environment where everything is known, agile methods don’t add a whole lot - we can just follow the plan. However, in face of rapidly changing needs or an active discovery of business needs based on what we’ve built so far, agile methods shine because they allows us to react quickly and reprioritize.
This leads us to our second valuable insight:
Agile methods are most valuable when we’re dealing with high levels of uncertainty.
Agile ♥ Architecture
Ah, interesting! Both architecture and agile methods thrive under high levels of uncertainty! And isn’t that exactly the environment we mostly face today with rapid changes in technology and short-lived business models? So, agile and architecture are addressing the same problem from different angles: architecture gives you the options to sustain velocity when the unexpected happens. And agile gives you the attitude to always be learning and to quickly adapt to changing circumstances.
So, the folks looking to pitch agile against architecture seem to be missing the point and might just be vying for the ill-fated model #4 in the diagram above.
I’d happily conclude that architecture and agile live in perfect harmony and even have a little lovefest:
But what about… “Agile Architecture”?
Unsurprisingly, the internet is full of thoughts, or let’s say text, on agile architecture. There’s the Agile Architect whose principles (value people, communicate, less is more) are sensible, but drift into smart advice (“minimize complexity”) and truisms (“Choose the Right Solution”, “Deliver Quality”).
Lastly, it’s difficult to opine about agile without coming across SAFe, the cleverly named but otherwise much derided framework that allows you to earn more certification medals than an average soviet general, sufficiently deep pockets and stamina permitting. SAFe has indeed a whole page on Agile Architecture, letting us learn that “it supports Agile development practices through collaboration, emergent design, intentional architecture, and design simplicity”, which sounds reasonable but doesn’t leave us a lot smarter than before. Perhaps that’s why the site doesn’t want you to copy its content - go have a look for yourself if you’re keen
True Architecture Supports True Agile
So in my book (pun intended), if you see architecture as something that provides you options and helps you maintain velocity in face of uncertainty, then it’ll blend perfectly well with agile delivery. However, if your organization considers architecture a multi-year planning process anchored in PowerPoint rather than enabling software delivery, then re-labeling likely isn’t going to help much. In this case it’s unlikely, though, that true agile delivery happens in the the first place - perhaps it has also just been relabeled.
Next Up: Part 2: Agile is the Steering Wheel
More Articles on Transformation
- Are IT’s biggest decisions its worst?
- Looking for talent? Don’t hire a digital hitman!
- Looking to speed up? You’ll need a clutch to shift gears.
Make More Impact as an Architect
My book The Software Architect Elevator helps architects and IT professionals play at the intersection of technology, organization, and transformation by sharing the real-life journey of a chief architect. Buy it on Amazon US, Amazon UK, Amazon Europe
