Scaling Architectural Processes with Guilds

by | May 21, 2019 | Strategy, Systems | 0 comments

People in Conversation, Alexis Brown

Reading Time: 2 minutes

Comcast published a detailed description of how they use Architecture ‘Guilds’ to scale investigation, review, and decision making:

https://www.infoq.com/articles/architecture-guild-800-friends

Scaling decision making is a hard problem because you want to:

  • gather input from interested and knowledgeable creators and users
  • focus on the most important parts of the problem and solution, avoiding bikeshedding and overly-strict ‘standards’
  • make a good decision at a responsible moment and then go do something, avoiding analysis paralysis

A friend who is “one of the 800” engineers at Comcast, confirmed a couple of things:

  1. The article is a good representation of what they do
  2. It works well! It’s a great way to crowdsource bigger decisions.

Highlights from the article:

  • they adapted the Internet Engineering Task Force (IETF)-style working group model to their organization by scaling the IETF process down and emphasizing ‘grass roots’ input
  • the central architecture team steers by identifying capabilities where more commonality is warranted
  • group chat facilitates communication on topics via a central #architecture channel and a channel for each working group, e.g. #arch-wg-source-control
  • working groups are staffed by 2-3 co-chairs sourced from teams that care about that capability
  • each working group maintains a source repository with a charter and records of their decisions

The ‘Novel’ Parts

There are a few ‘novel’ parts of Comcast’s approach that jump out at me.

First, they’ve solved the input gathering problem by officially extending the information gathering process to their 800 person organization. They extend reach using source control and group chat tools that are natural for a technical audience and improve access for ‘remote’ participants.

Second, they limit scope of each working group and potential decision. The charter defines what is in and out of scope for a given WG. Each decision must document users’ actual use cases.

Third, after the working group members research the topic, they vote on it. Only solutions that are currently implementable are permitted for evaluation (pull the Architecture Astronauts back to Earth!).

That covers each of the points I described as problems in scaling decision making.

Here’s a a bonus ‘novel’ point…

The investigation and decision record is owned and recorded in the working group’s source repository. This solves the practical problem of “where do we discuss and record this cross-cutting concern?” that teams often face around topics like source control, delivery process, API design, UI design patterns, etc. Whew.

Ok, maybe what’s ‘novel’ is that Comcast combined ‘obvious’ practices together in a way that works well (for them, at least).

I’m looking forward to trying these practices with some teams. I’d love to hear from you if you’ve tried to scale architectural decision making processes across your organization!

#NoDrama