New acquaintances or old friends?

“Agile meets Architecture”? A conference designed just for me? That’s what first came to mind when I stumbled across the AmA conference on Twitter in 2022, and rapidly booked a place. The two key strands of my three decade professional career finally came together in a conference. I was delighted! Then I reflected – wasn’t this more like agile and architecture as old friends who had grown estranged meeting up again after years apart?

When I first got introduced to the ideas around what were then called lightweight methodologies, in the late 1990s and very early 2000s, it was through the online writing of Martin Fowler and Alistair Cockburn, and the first edition of Kent Beck’s Extreme Programming Explained. All three authors were writing about both architecture – in Fowler’s case the pattern library that would become Patterns of Enterprise Application Architecture – as well as software development methodologies.

The online discussions at the time – about how much architecture was enough, about emergent design and the early thoughts around evolutionary architecture; about how XP’s metaphor was its equivalent of architecture; Cockburn’s hexagonal architecture – all elements of architecture wrapped up in how much they supported the values and principles of the agile manifesto. And then further through the 2000s: Martin Fowler wrote about whether the role of the architect was needed (‘even by our industry’s standards, “architect” and “architecture” are terribly overloaded words’); Scott Ambler wrote about  Agile Modeling, Agile Data and even Agile Enterprise Architecture.

So agile and architecture didn’t even get estranged – at least if you were listening to and reading the right people. And in my career – I’ve had Chief Architect roles, and roles in large scale Agile Transformation -  wherever possible I combined the two.

But of course the AmA conference is highly valuable for our industry. And the 2022 conference was a superb and inspiring  2 day event! Because for many agilists and many architects, the connection between the two has been lost.

Scrum – for many, still unfortunately a synonym for ‘agile’ – famously is one of the few of the original Snowbird-era agile methodologies that doesn’t include software engineering practices, so some Scrum teams don’t push hard on ensuring that the software context they’re working in is architected and designed to support agility. And some architects, at all levels, working with agile teams still think that their job is to produce a fixed design, upfront, for someone else to implement in a predetermined set of ‘sprints’.

So the spirit of agile architecture – agile principles applied to software architecture, and architectural concerns supporting agility – does need careful nurturing.

If you’re working in a 2-pizza sized team, on a product that you wholly own, that is loosely coupled (if at all) with any other products or systems, then the recipe for agile plus architecture is reasonably simple, taking inspiration from Martin Fowler’s early 2000s articles Who Needs An Architect and Is Design Dead:

1. Architecture is “the things you wish you had got right early”
2. Minimise this: work in a context where reversibility is both possible and relatively low cost, because you rarely have enough information to get everything right early
3. Architecture design and implementation work should be performed collaboratively and cooperatively within the team and by the team members (not given to the team by someone from outside) – supported by a senior / ‘master’ / ‘coach’ developer (again, someone who works full time in the team)

The context of software delivery has changed even for this type of team since the early 2000s. I’ll talk a lot more about this at the conference, but the fact that Software Has Eaten The World, combined with the infinity feedback loop of agile development plus agile operations (otherwise known as DevOps) adds one more thing to that list:

4. Architecture is always contingent - ‘early’ doesn’t just mean early in a project timeframe, but early in a system lifecycle. Many software teams are not working on a blank sheet of paper but adding new features and qualities to an existing system. Many systems live for 10 or 20 years or (much) longer and need to adapt to both new valuable features and a changing technical landscape. So learn from both of those things, and from feedback, and prepare to be able to change your architecture slowly and deliberately to fit with the changing world.

For many teams – even back in the early 2000s, when we were talking about scrums-of-scrums just months after Snowbird – their context is not just working on a standalone system, but working as part of a system-of-systems or, for most larger enterprises, a system-of-systems-of-systems.

And to do that, they’re working as part of a team-of-teams, or a team-of-teams-of-teams. What does architecture mean in this context? What does it mean to design a system-of-systems or a system-of-systems-of-systems. 

Part of what it means to do that effectively – for those who have been paying attention to everything from Conway’s Law to Team Topologies – is designing both an organisation (ToT or ToToT) and an architecture (SoS or SoSoS) in combination, and aligning that to independent value delivery – ideally per individual 2 pizza team - a nested set of Value Streams. That’s a very different set of practices compared to both agile and architecture within the 2-pizza team – much more socio-technical than pure technical (though even team level architecture and design is a socio-technical practice). 

To add to the complication, as above, most ToToT/SoSoS/Value Stream design is not on a blank sheet of paper, but working with existing systems, organisations and valuable products and services! This software that has eaten the enterprise world has typically not been designed or organized for delivery and operation in such a way to continually deliver Better Value, Sooner, Safer and Happier, and there is (usually!) no magic wand to wave to rapidly rearchitect and reorganize.

Agile and architecture will continue to need each other to survive in a world of growing complexity and dependence on software. Long may they continue their close friendship!