We've recently undergone a significant reorganization as a result of hiring a new CxO into the organization to lead our technology and operations functions. With new leadership came a new decisioning matrix, a.k.a. committees structure.
I've been actively engaged in architecture governance for over ten years in my company, and have had the opportunity to see how a number of other profit-centric corporations handle this question. There needs to be at least two levels of governance, but the actual number of committees can vary greatly depending on size, velocity, geographic distribution, disparity of business function, and diversity of technologies.
Well run committees are great places to bring visibility to a topic, to remove personal preference and bias, and to inject predictability into an organization's decision-making process. As such, there are two fundamental questions that architecture committees should be asking and answering:
- What should we do?
- How should we do it?
The first question is sometimes changed to "Should we do this?", but the key operative is still, "Should." This question is about business aspirations, policy, principle, and sometimes cost and timing. The members of this committee must be leaders of the technology and business teams and have accountability for directing resources such that once the "Should we" question is answered with a "Yes" there is no debate among the worker-bees as to the direction.
The second question, "How.." assumes that we are going to do the thing in question, and the task is to accomplish it within (or as close to) the enterprise standards. Exceptions are always possible, with proper vetting and visibility.
Some have asked, doesn't the "how" sometimes affect the "should?" No! It.Should.Never.
I cannot think of a business need or requirement that would garner a "Yes" vote on the question of "Should we" and then be cancelled or rejected because it's just too hard. The obvious exception to this rule occurs when the business community says "We want product X" rather than "We need function X." Businesses should never dictate the "How" of a solution, only the "What." If you avoid that conundrum, you'll never find a "Should we" that contradicts with a "How do we."
So how many committees do you need to effectively manage your architecture decisions. Without a doubt, larger organizations might require more simply as a workload management vehicle, but that aside, you'll need the two functions mentioned above - which may be spread across a small number of committees.
We ended up with an Executive Standards Committee, two subcommittees (one for applications, one for infrastructure) and a series of architecture working groups. There is some overlap in memberships to ensure consistency, but not so much that it would inhibit challenges. The executive and subcommittees address the "Should we", while the working groups focus on the "How."
What do you have?