About the book “Facilitating Software Architecture”

The role of a software architect is evolving. As systems and distributed teams become more complex, it is becoming impossible for architects to be everywhere they need to be. Consultants have to move onto the next client and, for those who remain in-house, being a ‘hands-on’ architect, moving from team to team, getting into the code, collaborating as required, has reached its breaking point. There is too much to know and too many places to be.

“Facilitating Software Architecture” describes another way to do architecture driven by decentralized and empowering decision-making techniques. It explains how to be an effective architect and how to structure an architecture organization for success when you need to scale out with many, many development teams. Learn an alternative approach to architecting, documenting, and evolving complex systems that will remain coherent while responding to the unique circumstances in your organization. Using the techniques in the book, you can ensure that everyone and everything is working towards the same goal, that the correct understandings are reached with the correct people, that it’s clear where everyone is at any given moment, and that (most importantly) you’re doing this efficiently and effectively. This collaborative, decentralized mindset, propelled by a simple set of enabling constraints and arranged according to some core principles, allows us all to ‘do’ architecture and build the best systems we’ve ever experienced. Systems which we’re all proud of, and that are a joy to work with.

Book outline

Part I - First Principles

Chapter 1 - Centralized Architecture Practices in a Decentralized World
Chapter 2 - To Practice Architecture is to Decide
Chapter 3 - Decisions at Scale
Chapter 4 - The Architecture Advice Process
Chapter 5 - Rolling Out the Architecture Advice Process
Chapter 6 - Architectural Decision Records

Part II - Nurturing and Evolving Your Culture of Decentralized Trust

Chapter 7 - Replacing Hierarchy With Decentralized Trust
Chapter 8 - An Architecture Advice Forum
Chapter 9 - Testable CFRs and Actionable Tech Strategy
Chapter 10 - Collectively-Sourced Architectural Principles
Chapter 11 - Using a Technology Radar

Part III - Finding Your Way Through the Decision Landscape

Chapter 12 - The Art of Deciding
Chapter 13 - Tackling Architectural Variability
Chapter 14 - Variability and the Interconnectedness of Decisions

Part IV - Centering the “Social” in Your Practice of Architecture

Chapter 15 - The Transition of Power and Accountability
Chapter 16 - On Leadership
Chapter 17 - Fitting the Advice Process Within Your Organization

Why I wrote the book

Software architecture is getting harder and harder. In the past few years Neal Ford, Mark Richards, Pramod Sadalage and Zhamak Dehghani have provided 750+ pages on ‘the hard parts’ and Gregor Hohpe gave us 350 more pages on riding the ‘Software Architect Elevator’. We have a lot to learn, continuously, if we want to keep our systems working. Those with ‘traditional’ architecture roles – top-down, ivory tower, father-knows-best – feel this rising knowledge gap keenly. The responsibilities of designing and evolving complex systems can no longer be undertaken by a blessed few.

Until recently, the alternative approach was to become a ‘hands-on’ architect, moving from team to team, getting into the code, collaborating as required. That approach has also reached its breaking point. Not only is there too much to know, with the advent of independent, self-managing teams, there are also too many places to be. The expectation of teams to ‘flow’, continuously delivering their software to production, means they pay a steep price every single time they are blocked, waiting for architectural input.

There is another way - stop architecture being practiced solely by architects, and instead have them facilitate architecture everywhere and with anyone. In the book I share my experiences, and those of my colleagues and our clients, tackling these challenges head on. I open up about the ways I failed and our near-misses too. I elaborate on the pre-conceptions and prejudices which we unpicked, and which you, the reader, will need to unlearn too, as well as the signals to watch out for as you foster your very own culture of ‘anybody’ architecture.

I initially shared my ideas on this topic publicly as a blog on MartinFowler.com published on November 30th 2021. On the 9th of December 2021 it was in the top 8% of all articles on his site. On the 3rd of January 2022 it was the top article and at the end of January it was in the top 3%. It continues to be popular.

Interest elsewhere was also strong. I was interviewed by InfoQ for an article and podcast. Both were well received and conversations about the article and re-shares continue to this day on my social media. Ruth Malan (who inspired a great deal of the book) then kindly included it in her Technical Leadership Masterclass. In June 2022 DDD Europe allowed me to run a mass-participation keynote on the topic. 800+ attendees were presented with the core approach and asked to discuss it and share their thoughts. The results (released under a CC license) clearly indicated that there was great appetite for many more resources in this area. Subsequent to this, people are reaching out to me on platforms such as LinkedIn having tried it out and shared experience reports. Various European conferences also accepted my proposals to talk about it (OOP Berlin, LeadDev London, XConf Europe).

Since the Early Access drafts of the book were available I continued to have great interactions with many people trying out the techniques I outlined, and mixing in their own. Others approached me to tell me they’d ended up at a simmilar place having followed their own instincts. Everyone offered me a great deal of feedback that was gratefully received. Much of it ending up directly in the final book.

It is my hope that a community of practice will build around this approach and those like it. It is also my hope that this site will become one of multiple hubs for this community. Because thinking and building and learning together is incredibly powerful.