EA has been getting more and more attention lately, but there's still considerable (and justifiable) discussion of its value for many organizations. EA has traditionally found more fertile ground in larger organizations, typically ones that are highly regulated or otherwise linked to governments. These organizations generally need and do more transition planning than, say, a smaller company in a high-growth environment.

Nonetheless, if you are considering launching or improving your EA function, here are a few things to consider:

What kinds of KPI will tell me whether EA is creating value for the organization?

• Activity oriented (e.g. number of artifacts created)
• Agility metrics (e.g. ability of systems to change in response to business needs)
• Maturity oriented (e.g. percentage of organization doing a given quality or governance practice)
• Perception oriented (e.g. stakeholder satisfaction)
• Process oriented (e.g. adherence to steps in a governance process, results of steps in governance processes)
• Value oriented (e.g. cost reduction)
• Other

In my experience, one of the fatal mistakes for new EA initiatives is sticking to a KPI scope that is too narrow. That is, picking one of the KPI areas mentioned above and using that as the only benchmark. EA inherently touches many branches of the organization and has many different perspectives, so it must therefore have many different methods for measuring value. Creating a culture that fosters this diversity will shepherd the EA conversation into upper management discussions where broad initiatives often have blurry lines for accountability and therefore shared risk for executive sponsors.

What is my IT's organizational model?

• Centralized (centralized app development, support and infrastructure reporting to a single CIO)
• Distributed (multiple app development and support areas with a single shared infrastructure organization, with separate CIOs for each area)
• Federated (multiple app development and support areas with a single shared infrastructure organization, all reporting to a single CIO)
• Hybrid (a combination of Federated and Distributed)
• Other

The IT organizational model speaks to the ability of the EA function to centralize control and to focus intensity during long-range the planning. Organizations with highly centralized models will be more implementation focused since resources are generally marshaled in a more focused manner. In contrast, logically, a distributed organization will require more communication and long-range planning to coordinate efforts across projects affecting distinct sets of resources. All of this combines to create insight into how the EA functions within that context: centralized, it will function as part of implementation teams, often with EAs serving in other roles as SME for a particular discipline, while distributed, EAs will have a broader scope and be more removed from implementation details.

How do architects do their jobs today?

• Centralized (all architects are in a single department.)
• Federated (a centralized architecture group and also architects in other IT areas reporting to managers in that area)
• Distributed (multiple architecture groups, each reporting to a different manager)
• Hybrid (a combination of Federated and Distributed)
• Other

This one is all about managing change at the human level. It takes a lot for architects to accept doing things differently without a clear value proposition. It's our nature to accept change only when the change improves the quality of the solution. (Incidentally, note I didn't mention anything about cost. That's for the PMO to figure out.) The bottom line is, changing someone's daily routine requires managing expectations relative to the status quo and providing them the requisite training to be effective.