Today we kicked off a new series: "Stories on Facilitating Software Architecture & design." You might be wondering, "Why this now? Haven't we been building systems?" And you'd be right. But what we've seen, and what we're experiencing, is that the traditional approaches to software architecture create more friction as systems grow.
We consistently observe the same patterns across different architectural approaches. Whether teams follow traditional enterprise architecture practices or take more hands-on, emergent approaches, they encounter similar obstacles when delivering effective software architecture. The challenge remains: how do we build systems that truly work and enable flow of software delivery? That's precisely what drives our exploration of alternative approaches that deliver real results.
The Problem: Blockers, Bottlenecks, and the Status Quo
When you look at how organisations scale their software, you see a many teams – different kinds of teams – all needing to make architectural decisions. And these aren't just small decisions; they often impact other teams significantly. The big question is: how transparent are these decisions? How do teams coordinate? And how does the very structure of the organisation help, or hurt, this process? Also how do they validate the decision after the fact, and get feedback so that teams and the organisation can benefit from learning this
When it comes to system creation, there are two main modes:
The Solution/Enterprise Architect: This is a more traditional approach to architecture, sometimes rebranded as an "enablement" team. When we’ve been in that position, did it truly enable the organisation? Often, we become the bottleneck. Teams are waiting for our input, our expertise. We've all seen it – if you're working inside a team, you're dependent, and that means waiting. And a team cannot wait. They'll either build something themselves, work around you, or just do "some" architecture without really knowing if it’s going to solve the problem at hand. And let me tell you, there's no such thing as "no architecture." It's either good, bad, or somewhere in between, but it's always there.
The "Hands-On" Architect: This mode is about working within the teams. Better, right? You're there, helping, guiding. But even here, you can be the blocker too. The architect (or person with that role) is still often the single point of knowledge, and that knowledge isn't truly being passed to the team. And even if you imagine an ideal most capable architect in the world, they simply can't have all the context that the team that works on the problem day in and day out. So in this case too, we are lacking in feedback both ways.
Both of these approaches, despite good intentions, often lead to teams waiting for architectural input, which hinders flow and can result in bad decisions within and across teams.
Team Boundaries and The Learning Gap
Think about John Cutler's model of team boundaries (we talked about this in the recording, and you might see it in some visuals we share later https://amplitude.com/blog/journey-to-product-teams-infographic also https://indiyoung.com/explanations-problem-space/ ). It illustrates the different phases of software development: opportunity selection, requirements, planning, design, build, test, release, run.
What we often see is that many development teams are completely removed from the "learning" phases on the left side – the opportunity selection, requirements, and planning. If a team isn't part of that, they can never truly grasp the full aspects of architecture, because they're denied the ability to learn the craft themselves. Architects, Product and even Managers often sit on the left, and teams are on the right, leading to a huge gap.
This is why Evelyn van Kelle, Gien Verschatse and Kenny Baas-Schwegler wrote there book Collaborative Software Design, and been pushing for a shift towards more collaborative and decentralized approaches. The status quo, with its ivory towers and hands-on blockers, keeps this alive.
The Fifth Revolution and Empowering Teams
Andrew talks about the "fifth revolution" – continuously designing organizations for flow and ownership. This is about enabling swift and continuous delivery of customer value. Product thinking was essential, DevOps was a game-changer, and the Agile Manifesto set the stage. Now, with Team Topologies and stream-aligned teams, it's really about letting teams design themselves for flow. The goal isn't for managers to dictate team structures, but for teams to take ownership of their flow.
Now, you might be thinking, "This sounds great, but my organization isn't there yet. Can I still do something?" Absolutely! You don't need to meet all the preconditions for full decentralization to start making changes.
We even shared an example in our recording: a team struggling because their Product Owner wasn't available for Example Mapping sessions (a Collaborative Modelling tool). The team decided to do the example mapping for themselves, based on a Backlog Item ticket they received. This brought up a lot of questions and uncovered assumptions. By pushing these questions and assumptions back to the Product Owner, they started "bringing the pain forward." This ultimately showed the Product Owner the value of earlier involvement, shifting the boundary of their work.
Start by Assessing Current State
So, where do you start? Begin by assessing the current flow of change in your context. Identify the blockers to getting things done.
Susan Kaiser's "Architecture for Flow" and Paul Rayner’s Team Flow Event Storming are great resources for this. Alternatively, You can start with informal discussions within your team: "How do we actually get something done around here?"
These stories are about practical ways to tackle these challenges. In our next session, we'll dive deeper into more contextual matters – what you can actually start doing now in your own context. We'll hopefully have Andrew join us, and discuss the power of transparency through Architectural Decision Records (ADRs).
So, stay tuned for more "Stories on Facilitating Software Architecture." We're just getting started, and we're excited to explore this journey with you.
Resources
- Facilitating Software Architecture: Empowering Teams to Make Architectural Decisions by Andrew Harmel-Law
- Collaborative Software Design: How to facilitate domain modeling decisions by Evelyn van Kelle, Gien Verschatse & Kenny Baas-Schwegler
- Learning Systems Thinking by Diana Montalion
- Architecting for Flow: Adaptive Systems with Domain-Driven Design, Wardley Mapping, and Team Topologies by Susanne Kaiser
- EventStorming Team Flow – Paul Rayner
