The Architect Is Accountable!

This post could be subtitled, "The Architect Makes Decisions... and is ultimately responsible"

We have previously identified this responsibility for decision-making as one of the most important roles of the Architect:

"The software Architect has overall responsibility for driving the major technical decisions, expressed as the software architecture. This typically includes identifying and documenting the architecturally significant aspects of the system, including requirements, design, implementation, and deployment "views" of the system."

In this capacity, the Software Architect has ultimate accountability for the results of the project. When things go south, people should turn to the Architect to recover... and explain. All too often, we see cases where an Architect goes along with a project until the "architecture is done" and then moves on. When the project gets into trouble, you hear "Those developers didn't follow instructions" or worse. It's the responsibility of the Architect to avoid even this potential, something that can simply be accomplished by remaining a fully engaged member of the team - operating as "we" and "our's" instead of "them" and "their's".

But the Architect's responsibility doesn't end there. The measure of success for the Architect is based on more than just the project results. He is also accountable for the Business and IT Strategy. It isn't enough to for the single project to successfully meet it's objectives, but the results must also contribute to these strategic considerations. Factors that are by definition more valuable and significant.

Being successful in this capacity will almost always require an ability to balance competing stakeholder needs. The Architect rarely finds himself facing simple black-and-white decisions, but rather the need to carefully select just the right shade of gray, and to do so under intense pressure and without enough time and not enough information. That's the life of the Architect. Philippe Kruchten summed it up like this: "The life of a Software Architect is a long and rapid succession of suboptimal design decisions taken partly in the dark."

But like most things in the endless balancing act of the Architect, we have to be careful not to fall into the deadly cycle of becoming the decision authority for every decision. While the Architect is accountable, he simply can't own every decision. Even if it made sense for some reason, it's simply not practical. The Architect is out-numbered by a factor of, perhaps, 10 or 20 to one on any given project, and those other 10 or 20 engineers aren't just drones - they're experienced professionals who's input is essential.

So where do you draw the line? There are many factors at play there, but we'll consider one important one. In "What is Architecture", we talked about the need to organize a team around the architecture. A key result of this practice is the establishment of a natural and effective demarcation of decision-making responsibility. In their article titled Guiding Principles for Enterprise Architects, Bredemeyer Consulting talk about the "Minimalist Architecture Principle" which essentially says “if a decision can reasonably be made by someone with a more narrow scope of responsibility, defer the decision to that person or group.”

This practice keeps the Architect focused on the most significant decisions - those of the greatest value (and consequence) and of the type that require the broadest perspective and authority. But we have to be careful. This is essentially a form of delegation. As is always the case with delegation, we can transfer the responsibility but not the accountability. The Architect remains accountable for the overall results, and he must put practices in place to effectively assess those results throughout every stage of the project.

A few of us were discussing this concept of accountability recently, and someone tossed out the idea that the Architect is responsible from "cradle to grave." That's a good way to look at it. The Architect is accountable from the first stages of ideation all the way through to the production release and beyond as this new capability helps to realize the overall Business and IT Strategy. We got to thinking, though, and decided maybe "grave" wasn't a good thought to associate with this accountability. How about if we just say the Architect is accountable "From Cradle to Glory."