Facilitating Software Architecture

by Andrew Harmel-Law

The software architect role is evolving. As systems and distributed teams become more complex, it's often impossible for architects to be everywhere they need to be. To be effective, consultants and in-house architects alike have to move constantly from client to client or team to team to collaborate and work with code. And the situation is reaching a breaking point.

There's a better way. Andrew Harmel-Law, tech principal at Thoughtworks, shows you how architects and development teams can collaborate effectively and efficiently on the architectures of their systems. Techniques in this book help you ensure that everyone and everything is working toward the same goal. You'll learn how to create a collaborative, decentralized mindset that allows everyone to do architecture and build the best systems they've ever experienced.

With this book, you will:

Understand the new dynamics that affect modern software delivery and how to take advantage of them to optimize for fast flow and continuous feedback
Learn a methodology that brings software architecture and development together in partnership
Nurture the fundamental interplay of decisions, advice, autonomy, and architecture
Initiate practices and constraints that maximize benefits and mitigate risks
Create an approach tuned to your skill sets, architecture, and your organization's engineering culture
Identify and work to prevent failure modes when they threaten to arise

Genres: Technology, Architecture, Management, Programming, Software, Leadership

Paperback

First published January 1, 2025

About the author

A Tech Principal at Thoughtworks, Andrew specializes in domain-driven design, org design, software and systems architecture, agile delivery, build tools and automation.

Andrew is also an author and trainer for O’Reilly. They’ve written one book about facilitating software architecture and one chapter about implementing the Accelerate/DORA four key metrics. They also run regular online training sessions in Domain-Driven Design (First Steps) and Architecture Decision Making by Example.

Experienced across the software development lifecycle and in many sectors, what motivates them is the humane delivery and sustainable evolution of large-scale software solutions that fulfill complex user needs. They understand that people, architecture, process and tooling all have key roles to play in achieving this.

Andrew has been involved with OSS to a greater or lesser extent since their career began; as a user, contributor, expert group member, or paid advocate—most notably as one of the Jenkins JobDSL originators.

Andrew enjoys sharing their experience as much as possible. This sharing is not only seen in their formal consulting engagements and writing, but also informally through mentoring, blog posts, conferences (keynoting, speaking and organising), and open-sourcing their code.

Reviews

[Andrew · Rating 5 out of 5]

I'm the author, so I'm biased.

[Vanessa · Rating 5 out of 5]

I had the privilege to participate in the first Architectural Advisory Forum (AAF), to see the magic in the making. A group of people who had never spoken or understood each other before, quickly and seamlessly falling into the flow of the AAF. I saw technical decisions being made democratically and responsibly, arguments being solved with disagreement and commitments, and more than anything, I saw people converging naturally towards a common strategy and getting comfortable with responsibility towards themselves and others. This book is a groundbreaking contribution to our industry, and I wish it was on the desk of every technical leader. 

[Ahmad hosseini · Rating 2 out of 5]

In nutshell, book is about Architecture Advice Process method. This is a new way to making architecture decision. The main difference between this way and old way is that you as architect, seek help from all team members to make decision and involve them in this work.
This book offers a practical and insightful guide for software architects navigating decentralized teams, building trust, innovation, and scalable architecture practices. It also includes a lot of information about team management and decision making.
Author also talks about how to implement Architecture Advice Process and prepare advices for how deal with challenges you may deal with them in this path.
Book includes a lot of theory and maybe be boring for some persons.

[Vanessa · Rating 5 out of 5]

I had the privilege to participate in the first Architectural Advisory Forum(AAF), to see the magic in the making. A group of people who had never spoken or understood each other before, quickly and seamlessly falling into the flow of the AAF. I saw technical decisions being made democratically and responsibly, arguments being solved with disagreement and commitments, and more than anything, I saw people converging naturally towards a common strategy and getting comfortable with responsibility towards themselves and others. This book is a groundbreaking contribution to our industry, and I wish it was on the desk of every technical leader.

[Jacqui Read · Rating 5 out of 5]

Software architecture is not all about the technical aspects, but that is where most books focus. This book looks at the whole socio-technical domain of software architecture.

Recommended reading for any architect, tech lead, or anyone looking to step into an architecture role. This book builds out from the main premise in software architecture of making decisions. Software architecture is making decisions. The technical aspects are secondary.

[Illia · Rating 3 out of 5]

Only the first 2 or 3 chapters are worth attention; the rest is completely pointless.

[Joshua R. Taylor · Rating 4 out of 5]

As a fledgeling technical architect, Andrew Harmel-Law's Facilitating Software Architecture has been a trusty companion as I've dived into my first projects as a software architect. I've enjoyed its visions of decentalised architectural decision making, where teams are no longer waiting on overburdened architects or suffering under the tyranny of the worst architect stereotype (egotistic, obnoxious, borderline narcissistic). An ideal which for me recalls the decision making of the Apollo programme's mission control: decisions and power pushed to the grass roots -- to those closest to the problem. Dare I say, it has a faint whiff of anarchy about it?

The core idea from my read is the 'Architectural Advice Process' (AAP) -- a way of allowing many people in a software organisation to take architectural decisions, while regulating them to make it more likely that their decisions are aligned with all the right stakeholders. Anybody may make an architectural decision when following this process, but as part of making their decision they must seek advice from experts in their area and all parties the decision effects (to the greatest practical degree, it can be assumed).

The vessel for any architectural decision is the architectural decision record (ADR), and Harmel-Law clearly goes through how the authoring process of an ADR would look like while following the AAP. I really appreciate how the process of writing ADRs concretely illustrates what makes the advice process so effective -- how options can be collated and added to; where new consequences of options are collected and the balance between them checked. I think these sections especially, overlayed with the 'architectural decisions' section of Fundamentals of Software Architecture: An Engineering Approach, will stick with me through my architectural practice.

As the book progresses, Harmel-Law gradually increases the scope. He moves to a programme scope, explaining how to make the AAP efficient over many teams (advice), how to align architectural principles (shared context) and share ideas of new technologies or approaches (options). He then zooms out further to explain how an entire software organisation can be effectively led and effectively function alongside the more traditional organisations it needs to transact with. It was with this progression I unfortunately started to mentally check-out of the content, since the influence required to implement any of the ideas here was far from my position as a technical architect. It felt more aimed at 'Head of ...' or 'Chief X officer' type people, or an enterprise architect at a stretch.

Overall I'm sure my practice will be shaped well by Harmel-Law's ideas, reminding me that I don't need to be an authoritarian arse to get things done in architecture. In fact, letting go and fully integrating the great ideas that can be spread across a team may prove to be a key part of doing my job well.

[Sebastian Gebski · Rating 3 out of 5]

Massively overblown.

It's supposed to be a book about effective technical decision making, but TBH (if you don't want to do "babysitting"), it's a topic for a series of posts at-most. So the author has decided to become Cpt. Obvious and provide very literal recipes for truly trivial things. Honestly, if you need this level of detail (& can't figure it out yourself / make it happen), you have a very serious problem of a different sort ...

The 1st part is about architectural decisions and ADRs - it's fairly OK-ish. Then he moves towards giving arch. advice and decentralization of decision-making. I had an impression that one good article on RACI matrix covers this topic much better (with a higher clarity and actionability). Then he moves towards very enterprisey constructs (that TBH don't address the underlying issue, just walk it around) like - architecture advice forum or tech radars ... The next section is about arch. principles - and again - personally I think it's a very valuable & important topic, but somehow the true essence of its meaning is lost in the oververbose content ;(

In the final section the book surprisingly (?) redirects into leadership (!) and culture areas. Yes, they ARE related (culture should impact the decision making), but it feels mostly like a preaching fluff - one can write about leadership ad infinitum but it should truly correspond to the core topic of the book.

IMHO there's a massive amount of work put into this book. And I'm not questioning the knowledge and experience of the author. But writing a good book is something entirely different that just capturing one's knowledge - more deliberate work is needed to extract what's truly essential and build it into some focused "story". This part hasn't been covered here well.

It's a solid 3.2 (rounded down), but you can easily add 0.5-0.7 point if you don't read it end-to-end and just skim to the specific section you'd like to confront your knowledge against.

[Christoph Kappel · Rating 5 out of 5]

A really interesting, but quite lengthy book, which explains the whole architecture decision process from back to front. It sometimes felt a bit repetitive and the amount of footnotes made it sometimes a bit difficult to read for me, but overall a solid experience and informative.

My key takeaways are definitely to call it architecture advice process and also the general idea of ADR spikes - which is in my opinion a brilliant framing.

There are so many references of really good other books, it might be a real time saver just to start with this one though.

[Nick · Rating 5 out of 5]

After reading a summary of the advice process I debated whether to buy this book, wondering if it was worth the cost. But after checking it out I'm glad I did, this title will teach you so much more about architecture than just the advice process.

Context, I came into the title as a senior software developer who'd been studying software design for a few years, and who is occasionally treading into the world of design in his career. From that perspective the book completely re-framed the way I look at the role of software architect, and how design is done. It also taught me the everyday, practical realities of software design.

In short, if you're a developer (or architect) at any level you'll benefit from this book. Many thanks to Harmel-Law for getting this out there.

[Josu]

Recommended by Alex Comunian (TW)