As you begin to develop an Architecture Review Board (ARB) the question of the bigger picture comes up real quick. There are several ways of looking at the ARB’s function in the enterprise.
One way to look at an ARB is to consider the ARB the policy setting group and the architecture validation group. I do not share that opinion. Blending the decision making authority with the rules and policy authority introduces a great deal of conflict of interest. When combining these functions the group loses focus and mixes standards setting with the validation of IT architectures.
Below I think there is a better way. I have outlined a model that shows how to execute an architecture governance structure that I have used in my past EA organizations and plan to continue to use on a going forward basis with my EA organization.
As shown above there are three main governance functions. Each one has a very specific purpose.
Architecture Review Board – Validates and approves solutions based on their alignment to the strategic imperatives of the organization.
Architecture Guidance Team (AGT) – This team defines the principles, policies, standards, frameworks and solution guidance that is published to a repository and portal for consumption by the architecture community and ARB.
The Office of Enterprise Architecture or Architecture Engagement Services – The enterprise architecture organization facilitates and drives many of the governance functions. While Enterprise, Domain and Solution Architects are not the sole decision makers, given the distributed domain model, they are the thought leaders in the organization to be the agents of change.
To further explain this concept I use an analogy that I have used for the past 5 years that really resonates with folks is using the US government as a parallel to this governance model. See below:
You can see a ton of similarities here. I break these three forms of government into the following activities of the EA function:
Judge It - This area goes into the governance activates of an Architecture Review Board (ARB). Ideally ARB's should have limited power and only have the ability to review architectures not to create the laws (i.e., standards).
Standardize It - When we talk about standardization this is the activity that forms virtual teams of domain stakeholders to build what is commonly referred to as Principles, Policies and Standards.
Execute On It - The executive branch in reality is the "commander chief" that is the official spokesman and stimulates action in time of need. Likewise with EA's on strategic projects and management of future strategies. Like with all analogies it's not 100% accurate but it can be a power tool to convey a message.
OR Architecture Review Board = Judicial BranchArchitecture Guidance Team (AGT) = Legislative Branch The Office of Enterprise Architecture or Architecture Engagement Services = Executive Branch
The point of the analogy is not for communicating with people whom already understand EA but rather others such as developers, business representing or senior IT decision makers.
So what's the point here for EA's? Being able to articulate your function and purpose to your audience in terms they understand will greatly help you in your endeavors. This allows your audience to understand what you do and how you can help them. On the flip side, if they do not fully understand your role there is a good possibility that they will not engage. This isn't because they want to, but because they do not know that they should.
What this model provides us with is a clear separation of duties but also ensures that the right people are in the right governance function. When we look at the ARB, we want to have senior IT decision makers in the room evaluating and validating designs to ensure alignment. If we had subject matter experts in the ARB, the room could be filled with a lot of people and a lot more opinions. The ARB should be a tight group of leaders of no more than 10 –12 voting members.
The AGT on the other hand, should be filled with SME’s as they best know the technology sets and most likely will be accountable for them as well. The reverse is true for the ARB members. We wouldn’t want senior decision makers driving a platform or protocol standard.
In a future post I will detail out these members, how it all fits together and their roles and responsibilities.
Keeping in Sync
As you can see from the first model of how all of these functions interact there is somewhat of a lifecycle we are defining with regards to the technology life cycle of the technology portfolio and the architecture repository of knowledge. Since the AGT and the ARB are tightly connected and have integrated processes and transparency the knowledge gathered by both bodies is integrated as well. This in turn keeps this information base always up to date without a separate function in charge to constantly chase people down for information.
You will need a librarian, an ownership model and stewardship thought through but these activities should be light since we are updating this base as an output and/or input to our enterprise processes.
An added benefit to this model as well is the traceability aspects. When using the Architecture Metadata Repository as your main way to validate projects tracing back to business capabilities, goals and objectives is very achievable. Additionally, this can be linked to Business Reference Models (BRM) or Performance Reference Models (PRM) as shown in FEA.
Comments