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:
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:
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.
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:
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.
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".
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.
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.