The profession of Enterprise Architecture is beginning to emerge from its early stages of development. The number of people professing the title of Enterprise Architect has grown from a relative few in the 1990s to thousands today. On LinkedIn, a popular social networking site for professionals, the “Enterprise Architecture Network” discussion group boasts over 79,000 members.
There is a great deal of demand for Enterprise Architecture services. Large consulting firms like Accenture, Deloitte, PWC, and Wipro, large software vendors like Microsoft and IBM, large hardware vendors like Fujitsu and Hewlett Packard, and outsourcing firms like Computer Sciences Corporation, have all developed service offerings that revolve around providing Enterprise Architecture as a service to their clients.
While the field has grown, the proliferation of voices, methods, frameworks, and generally inconsistent advice in the field of EA has also grown. The number of “EA Frameworks” has grown to include a wide array of overlapping bodies of work. Included in this list are GERAM, TOGAF, FEAF, MODAF, DODAF, PEAF, E2AF, Zachman, and many others. Jaap Schekkerman has released three editions of his 250+ page book “How to Survive in the Jungle of Enterprise Architecture Frameworks” which attempts to compare only 15 of them!
Unfortunately this proliferation has created a problem that is common among emerging professions: a lack of maturity. As Geoffrey A. Moore pointed out in his landmark book, “Crossing the Chasm,” the market for a high-tech product will self-segment into Early Adopters (accounting for less than 20% of the market) and the more pragmatic customers in the Early Majority, Late Majority, and Laggards categories. Viewing Enterprise Architecture as a new high-tech product provides useful insight into why EA has failed to “cross the chasm” from early adoption to the pragmatic majority.
In order for Enterprise Architecture to cross the chasm, there has to be an intentional strategy to gain a foothold in one target market that is part of the Early Majority, and then to use the success of Enterprise Architecture in that space to build the credibility needed for other segments to adopt.
Unfortunately, while EA has been successful in some target markets in the Early Majority (like Telecom and Federal), the lack of consistency in the approach, terminology, and even value proposition of EA across industries poses an obstacle for increasing EA adoption. In other words, the success of EA in one or two areas is failing to help EA gain a foothold among other industries. Could it be because they don’t use the same words to describe success?
Unable to depend on a broader “EA movement,” each EA team is waging a lonely struggle for relevance and ongoing support within their own enterprise. To remain relevant, EA teams have often focused on “low hanging fruit,” immediately valuable initiatives that generate results quickly but often fail to address long-standing challenges. The mantra of modern Enterprise Architecture has become “provide immediate value immediately,” a position that relegates long-term thinking and investment to another day. Ironically, it is this long-term thinking and investment that EA is supposed to provide.
It should come as no surprise that a profession that is designed to provide value in the long term is struggling with demonstrating short-term results. Many EA programs fail as a result of this struggle. In a widely publicized study commissioned by EA tools vendor IDS Sheer, Jonathan Broer, then an undergraduate researcher from Rotterdam University, conducted a study of 191 organizations. The startling results of his survey suggest that up to 66% of all EA-sponsored efforts have failed to produce the expected results. Of the root causes cited: the lack of business awareness of Enterprise Architecture, lack of executive and stakeholder support, and the inability to provide a rapid return on investment.
There have been a few studies designed to examine the reason for the lack of EA to deliver rapid value. There have been no studies developed to examine the reason that EA success in some sectors have failed to translate to others.
In summary, EA stands at a crossroads. The profession of Enterprise Architecture is plagued by multiple problems.
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.