Mike Walker's Blog

Setting Architecture Review Board Member Expectations

In my previous post Defining the Anatomy of a Architecture Review Board we talked about getting the right people together to assemble your ARB. In this post we will talk about the expectations of those members. 

What you will find with ARB’s is that “the devil is in the details…”. This is especially true for the details of an ARB’s membership. I have found that if you don’t properly set expectation on the membership it can cause some major disruptions in the operations of the ARB.

There are four major expectations every board should define to ensure success. Those expectations are:

• Time – Must allocate [x] to [x] hours to the ARB on a weekly basis for architecture design reviews, exception management and ARB tasks. [x] hour should be dedicated for the meeting itself. This is a minimal of [x] hours a week with the potential of [x] hours a week.
• Meeting Attendance – Meetings will be held bi-weekly. The expectation is that a primary representative is at the meeting and if that individual cannot make it, then the designated secondary individual should attend the ARB.
• Accountability – Members are accountable for their reviews, decisions and deliverables to bring to the ARB. The Chief Architect evaluates the performance on the members on a monthly basis and reports status to the executive sponsors.
• Subject Matter Expertise – The ARB team members are to bring their subject matter expertise to the ARB. Specifically to provide the following:
  • Gather and analyze materials as applicable to their domain of expertise
  • Identify impacts of emerging technologies with current portfolio of assets
  • Provide qualitative and quantitative feedback
  • Ensure discussions are fact based and practical
  • Provide solution recommendations and/or methods for exploration of problem
  • Focus on problems holistically across the enterprise that includes the business, operations and IT aspects.

 

While there can definitely be more expectations that can be set, these general purpose expectations can be leveraged as a base for your ARB.

Defining the Anatomy of a Architecture Review Board

Continuing my series on describing Architecture Review Boards I will discuss the people that will participate in an ARB. We will take a step back to provide context of the membership with a domain based model.

We should first start off with understanding that the ARB is comprised of leaders across an organization with decision making authority. This federated model will allow for cross organizational visibility and coverage of solution reviews. The federated model is based on architecture domains.

Architecture domains are logical representations of areas of concern or sometimes called cross cutting concerns. There are a set of base domains that can be used but each organization has it’s own vocabulary and ways of describing these domains so it is best to use them as a reference rather as authoritative.

Below is a sample of a set of domains:

You can quickly see that these domains are broad. They should span IT, Operations and Business lines. Another observation you may have is you see “Data” listed as a domain. As a general practice I stay away from using data as a domain as it should be a sub domain, “Information” should be the domain here but in this case it was politically more accepted to use Data rather than Information.

With the domains there will need to be some flexibility and keep in mind that nothing is set in stone. Refinement happens naturally as you start to leverage the model.

With these domains there are sub-domains that allow for deeper separation of logical areas. As shown above, the reference below is an example of a set of sub-domains that can be used to describe in further detail your environment.

The above set of sub domains should not snap to an organizational model. These domains and sub-domains need to have subject matter experts aligned rather than an organizational hierarchy. If you have a matrix style organization than there would most definitely be alignment however.

Now that we are talking about people, how do we snap people to our domains and sub domains? What I show below is the separation of the domain and sub-domain.

We have a one to one mapping to the domain and to a role. The two roles are:

• Architecture Domain Owners – Provides leadership to drive excellence inside a domain group. There will be one individual per domain that will be ultimately accountable for the domain. The Domain Owners will also be the final approver of the standards that are developed out of the domain.
• Architecture Domain Experts – These individuals are the implementers and researchers that develop the standards for the organization. They will have responsibilities to manage the portfolio of standards that they have direct ownership over in their sub-domain.

This model provides us with a community driven approach to developing the organizations standards.

Now lets overlay our domains over our governance bodies, namely the ARB and AGT. You will see a nice alignment to these governance bodies.

Additionally, there is a healthy balance of membership of these functions. Based on our definition we have the right people in the right function. See below for the definitions from Relating Architecture Review Boards to Other Architecture Governance Bodies:

• 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.

Once you segment out the right people for the right governance functions we now need to organize the ARB with roles and responsibilities. There are four roles within the ARB:

• Executive Sponsors – While the executive sponsors do not attend the ARB meetings they do approve the ARB processes and extend executive support when needed. These individuals are usually SVP’s or CxO level individuals.
• Chairman – This role is responsible for running the meeting, acting as the mediator, vetoes when appropriate and has the accountability over the ARB’s overall role and effectiveness in the organization. This individual is usually the Chief Architect of the company.
• Voting Members – Domain owners are the voting members. The domain owners provide subject matter expertise for their domain and have voting rights when it is time to approve a solution.
• Non-Voting Members – These individuals are either the teams proposing solutions or supporting resources for a evaluation. These members are usually not the same and are transient.

To qualify for membership on the ARB, members should be knowledgeable and experienced in their respective areas, empowered to act as a spokesperson for their team, and available to attend the meetings and perform follow-on analysis work.

It is important to setup these roles and communicate them to the company. Once the definition and communication plan has been defined, as a good measure to ensure that every ARB is successful there should be a primary and secondary defined. See below for an example:

The primary will be the domain owner as we discussed earlier, and the secondary is usually one of the sub-domain members.

SharePoint 2010 Upgrade Resources

A big thanks to Dennis Bottjer for post this compile of SharePoint 2010 Upgrade Resources:

• Upgrade Approach Testing (Visio Diagram) –  It illustrates how to prepare and test the upgrade.
• SharePoint 2010 Upgrade Planning (PDF) - This is a plan for upgrading from WSS 3.0 or MOSS 2007 to SharePoint 2010.
• SharePoint 2010 Topologies (Visio Diagram) – Illustrates different Farm Configurations, SharePoint Services, and Server Roles.
• SharePoint 2010: Software Development Kit – Provides code examples for SharePoint 2010.

Relating Architecture Review Boards to Other Architecture Governance Bodies

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 Branch

Architecture 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.

Microsoft Steps Up Architecture Modeling

Sudhanshu Hate from Infosys posted a good overview article on the new architecture modeling capabilities in Visual Studio Team System - Architecture Edition.

However, even though Microsoft steps-up in the architecture modeling capability it still lacks the repository aspects that bring the most value. As an example, each one of the models is still file based stored in a project structure. This isn't conducive to enabling architecture management across an organization. Everything is built in a hierarchy within a project.

One other gap is alignment to architecture modeling standards such as Archimate. I think there is an opportunity for Microsoft to leverage this already developed standard in the same way as they did with UML. Rather what we see now is Microsoft's own definition of what a logical model is.

This is a great first step getting the modeling pieces and kudos to the VSTS Team Architecture folks but I would encourage my friends back in Redmond to align more with the architecture industry standards and build out the a repository to enable systematic reuse and to make application portfolio management a reality.

See below for his post (http://www.infosysblogs.com/microsoft/2009/11/architecture_rules_enforcement.html):

For all these years if a .Net architect has to model the software system. He or she has to rely on modeling tools like Rational XDE, or Visio Enterprise Architect. Personally I was never impressed with Visio Enterprise architect’s modeling support, and code generation it has to offer. Though Visio has several stencils, templates, symbols available; UML modeling and associated code generation was always bit stiff. Integration with Visual studio to synch up models with code and vice a versa was another challenge.  3^rd party tools like RationalXDE has good support for .NET but one has to pay hefty license fees to use such tools.

Result of this, system modeling used to get constrained into Microsoft Word, Power Points, Visio’s. Keeping Word/Visio based models up to date w.r.to the architecture, design, code changes was always a catching game leading the code, designs and overall system documentation out of synch impacting traceability between these artifacts.

Increasingly this has caused the disharmony between architecture modeling and development teams.

After all these years, finally, Microsoft Visual Studio 2010(VS2010) seem to have helped overcome this obstacle by embracing Unified Modeling Language (UML) and making architecture, design, development, testing seamlessly possible through its Integrated development environment. If not all, VS2010 has support for most of the UML diagramming types like

1.    Use case diagram

2.    Activity diagram

3.    Sequence diagram

4.    Class diagram

5.    Component diagram

With VS2010 beta 2, while there are a few UML diagram types i found missing at this point of time like the ones of State life cycle, object, deployment etc. I was impressed with the inclusion of diagram type called as “Layered diagram”. Through this modeling diagram, one can not only depict various logical layers like Presentation (UI), Business logic, Data Access, Utility and Database but also define the dependencies/coupling between them in terms which layer can call which one. This helps in establishing and adhering the architecture rules set by an architect while architecting the system like Presentation layer components should not directly call the data access layer component and vice a versa.

To validate the architecture in code, one can map various project (UI, Service, Data access) files by dragging and dropping into this layer diagram in respective layers and then validate it by using VS2010 “Validate Architecture” option which tracks down any violations in the code.

So far while most of the architects used to write similar rules as part of MS word architecture document but it was left with the wisdom of developer to adhere or violate it, catching such architecture principle violations were difficult in the million Lines of code developed.

Through Layer diagramming architecture validation support, VS2010 will help in keeping the design and code in synch with the architecture and design principles established during the early stages of life cycle. However this is not all with VS2010 architecture modeling support, I have just scratched the surface of what VS2010 has on offer and intend to cover other aspects in coming blogs.

For all these years if a .Net architect has to model the software system. He or she has to rely on modeling tools like Rational XDE, or Visio Enterprise Architect. Personally I was never impressed with Visio Enterprise architect’s modeling support, and code generation it has to offer. Though Visio has several stencils, templates, symbols available; UML modeling and associated code generation was always bit stiff. Integration with Visual studio to synch up models with code and vice a versa was another challenge.  3^rd party tools like RationalXDE has good support for .NET but one has to pay hefty license fees to use such tools.

Result of this, system modeling used to get constrained into Microsoft Word, Power Points, Visio’s. Keeping Word/Visio based models up to date w.r.to the architecture, design, code changes was always a catching game leading the code, designs and overall system documentation out of synch impacting traceability between these artifacts.

Increasingly this has caused the disharmony between architecture modeling and development teams.

After all these years, finally, Microsoft Visual Studio 2010(VS2010) seem to have helped overcome this obstacle by embracing Unified Modeling Language (UML) and making architecture, design, development, testing seamlessly possible through its Integrated development environment. If not all, VS2010 has support for most of the UML diagramming types like

1.    Use case diagram

2.    Activity diagram

3.    Sequence diagram

4.    Class diagram

5.    Component diagram

With VS2010 beta 2, while there are a few UML diagram types i found missing at this point of time like the ones of State life cycle, object, deployment etc. I was impressed with the inclusion of diagram type called as “Layered diagram”. Through this modeling diagram, one can not only depict various logical layers like Presentation (UI), Business logic, Data Access, Utility and Database but also define the dependencies/coupling between them in terms which layer can call which one. This helps in establishing and adhering the architecture rules set by an architect while architecting the system like Presentation layer components should not directly call the data access layer component and vice a versa.

To validate the architecture in code, one can map various project (UI, Service, Data access) files by dragging and dropping into this layer diagram in respective layers and then validate it by using VS2010 “Validate Architecture” option which tracks down any violations in the code.

So far while most of the architects used to write similar rules as part of MS word architecture document but it was left with the wisdom of developer to adhere or violate it, catching such architecture principle violations were difficult in the million Lines of code developed.

Through Layer diagramming architecture validation support, VS2010 will help in keeping the design and code in synch with the architecture and design principles established during the early stages of life cycle. However this is not all with VS2010 architecture modeling support, I have just scratched the surface of what VS2010 has on offer and intend to cover other aspects in coming blogs.