Month: July 2012

As I found in our Enterprise Architecture team in Microsoft, each time an Enterprise Architect is assigned to a specific area of the business, each one has a unique “engagement” with their stakeholders.  In very large organizations (like mine), there may be many different IT units as well as many different business units, all involved in a particular strategy.   Each situation is different.   This leads to a common problem that can framed with two questions:

1. So how do you know if your Enterprise Architect is doing a good job?
2. How do you set the right expectations to position that Enterprise Architect for success?

A Model for Positioning an Architect

We developed a simple grid that helps to position the EA with respect to a specific area of the business.  The two axes of the grid are: Architectural Maturity of the “segment” and Maturity of the Architectural Engagement itself.  Within each cell, we put a description of “what we want the EA to do” if they find themselves in that position.

Note that maturity of the engagement is a measurement of a relationship: specifically the relationship between the “business customer” and the Enterprise Architect.  Architectural maturity of the segment is measured against both the business area and the IT groups that they use (see below).  You need to measure the maturity of BOTH variables in order to understand what an Enterprise Architect will need to do to be effective.

Note that the Architectural Maturity axis has four levels, cryptically described as “Level I” through “Level IV”.  This is a reference to our internal maturity model, which I’m not at liberty to share in detail. 

The broad strokes are:

• Level  I – architecture is not a trusted and well-understood role in business change or IT programs.  (This includes business, information, solution, and technology architecture).
   
• Level II – architecture is used and their processes are defined, but not consistently and not well. 
   
• Level III – architecture is performed consistently and is part of governance as well as some portfolio planning activities.  The business stakeholder does not take ownership of driving the funding and execution of the roadmaps developed by the Enterprise Architect.
   
• Level IV – architecture is performed consistently and is involved in planning and governance.  The business stakeholders involved in funding and overseeing the business changes themselves are engaged with enterprise architecture, have been key in developing the roadmaps, and follow through with regular updates to the future state models and the roadmaps.  In addition, they decide on which initiatives to use BASED ON the content of the roadmaps. 

 

Using this model

I’ll provide two scenarios to illustrate how this simple grid is used. 

In Fabrikam, we are Enterprise Architects.  Fabrikam manufactures and distributes consumer electronics.  There are six divisions that manufacture different kinds of products (kitchen appliances, television and radio, automotive, etc). Let’s say that we have 18 Enterprise Architects in our EA team.  Fabrikam’s EA has divided into three working groups, each with six architects.  Maria manages one of these teams, and has six enterprise architects working for her.  Her team focuses on addressing business issues related to supply chain management. 

Maria is performing an annual review for two of her architects.  They are Tomas and Jai. 

Case 1: Tomas

Tomas is working with the kitchen appliance team.  This is the oldest division in Fabrikam, and they have their own IT group that has been stable for many years.  That team has established processes for IT architecture but no business architecture.  Their architectural maturity is Level III.   Tomas just moved over to the kitchen appliance division from the television and radio division.  He is a well established architect with years of experience, but the kitchen appliance team is just beginning to get to know him.  As a result, the maturity of the engagement is “Useful.”  

The intersection of these axes has the following text:

• Engage in existing review and governance processes
• Engage stakeholders in cross business decisions
• Collect current state data

Maria can set expectations with Tomas and with the Kitchen Appliance division.  Tomas will be expected to engage in existing governance and review processes.  He will be expected to work with business stakeholders in the kitchen appliance team as well as other divisions to address shared opportunities, capability overlaps, and strategic prioritization.  He will be expected to collect current state information models, system models, technology models, and business strategies for the EA repository.  He will be measured on his ability to deliver on these expectations.

Case 2: Jai

Jai is working with the automotive division.  This is the newest division in Fabrikam, and they are just beginning to roll out their first set of after-market automotive radios and CD players in the North American market.  Their IT division is small and rather chaotic.  Their architectural maturity is Level I.  Jai has been working with the automotive division for about two years, and has repeatedly earned recognition from their business leaders for his skill and depth of knowledge.  The maturity of the engagement is “Influential”.

The intersection of these axes has the following text:

• Demonstrate EA specific methods and deliverables
• Drive the scoping, approval, and oversight of an enterprise-relevant project

Maria can set expectations with Jai and with the automotive division.  Jai is expected to demonstrate EA specific methods and deliverables.  The teams know him and trust him.  He can demonstrate how EA can be valuable by simply doing the work and showing how valuable the results are.  Due to his level of influence, he can work with the business to invest in an area of improvement that will benefit the entire enterprise (for example, a project to improve the distribution of finished goods to retailers), and then work with the IT teams and business stakeholders involved to get the project launched and oversee its development.  Jai can be measured on his ability to deliver on these expectations.

Conclusion

In small organizations, Enterprise Architects can be “heros” and just “do what works,” but if you are trying to develop a mature EA program, each architect needs to have specific goals and specific deliverables that they will be expected to deliver.  This kind of model, we found, is useful for helping each architect to position themselves and their role in the organization.