High Ceremony Software Architecture Kills Collaboration

I was a panelist on the "Architecture and Collaboration" panel at the SATURN 2012 conference in St. Petersburg, Florida this past May. For the panel I was asked to provide a single slide stating my position. This was my first time sitting on a panel and the first time I was ever required to have a clear "position" on a subject. It took a long time and a lot of thinking before I finally was able to A) understand what my own position was, B) have a position that would differentiate me from other panelists (we all by and large have the same opinions toward architecture and collaboration), and C) articulate it in such a way that I could fit it on one slide.

My position was simple, clocking in at 4 words: "High ceremony suffocates collaboration."

Assuming the "voice of the outsider" for the panel and representing an Agile perspective, I explained my position (out of nerves, somewhat poorly) at the start of the event. Staring at 150+ faces in the crowd, I could feel the shock, horror, and confusion from many in the audience at what I was proposing.

My fellow panelists and the audience immediately pounced. "What do you mean 'high ceremony suffocates'," they cried, "because the methods we use help us collaborate!"

We are surrounded by ceremony when it comes to software architecture. The vocabulary. The abstract concepts. The workshops and processes. The artifacts and documents. Some subset of these things is supposedly required for effective software architecture design. Formal checkpoints and documents are intended to improve a team's chances of building the right thing on time and on budget by promoting collaboration among teams and individuals. While some ceremony, like a common vocabulary and basic understanding of core concepts, is essential, sometimes the ceremony becomes the goal. As a result the things intended to help teams instead become blockers to effective communication.

The high ceremony I'm referring to are documentation, formal diagramming, multi-day workshops, "holier than though" arguments about vocabulary. These things can get in the way of effective communication and prevent true collaboration.

Collaboration is the act of working with others to achieve a shared objective. In software architecture, collaboration is all about creating a shared understanding. Documents do not create understanding. Reviews and checkpoints are an act in absolution ("blessing a design"). Workshops are a means to an end, not the goal itself. It is tempting to assume that because a design is formally articulated or because everyone participated in a workshop that this is enough, that the team is all on the same page.

From a collaboration perspective, the right methods are the ones that facilitate to most interactions per second among teammates. This might be a document. It might also just be a whiteboard. Workshops are certainly helpful, though the right workshop for your team and situation may not necessarily be the one with the most rigorous engineering process.

As architects we are the masters of ceremony. And this is a role of immense responsibility.

If collaboration is your goal, do not choose high ceremony methods. High ceremony is not about collaboration but rather pontification.

Overall the panel went extremely well. I successfully stirred up some controversy and started an excellent converstation. For that matter, the intelligent, lively discourse throughout the entire conference is a true reflection of the kinds of high quality software architects that attend SATURN. The SATURN 2013 conference will be held in Minneapolis, MN April 29 to May 3 and the conference program looks to reflect the same high quality as last year. Mary Poppendiek, Scott Berkun, Stephan Murer and Pilippe Krutchen are all giving keynotes

Popular posts from this blog

Dealing with Constraints in Software Architecture Design

Architectural Drivers: Building Blocks for Decision Making

Managing Multiple Ruby Versions with uru on Windows