Because EA is a support function to IT and the business, developing meaningful metrics can be difficult. However, by capturing the appropriate metrics, progress can be measured, value can be calculated, and the group justified. The best way to develop metrics for a support function such as EA is to analyze inputs and outputs of work through the department. What work goes into the team and what deliverables come out? If the group is designed per the examples in this chapter, work will come into the group in the form of the following:

Metrics describing work products coming out from EA may include the following:

While these outputs can be measured, determining their value is difficult. One way to measure value of support services is to survey the customers. After each architecture service is completed, a survey can be sent out asking for input. Surveys can be written to measure if expectations were met on each engagement. A ranking system can be developed for survey results and the grades aggregated to generate a customer satisfaction score.

As EA documents systems within the EA repository, metrics about cost can be captured. How old are the applications? How many IT resources support them? How much infrastructure do they consume (CPU cycles and storage)? All of these metrics can be factored into a formula that determines the real savings of eliminating legacy applications. Enterprise Architecture can also lead efforts for server and data center consolidation. These projects normally yield large savings, clearly justifying the investment in the architecture function.

From a research support perspective, EA can measure research firm usage and identify services that overlap across research vendors. The number of research firms can be consolidated to a few that provide the most benefit and firms that are not used often, or provide similar services to those that are used frequently, can be eliminated.

Enterprise Architecture is responsible for causing changes to occur across the company. As the architecture function matures, a track record can be maintained of new technology and solutions introduced by Enterprise Architecture over time. The following figure provides an example of how EA affects the company over time:

This figure shows that new technology is introduced to the organization in three distinct stages. The introduction stage is led by the EA team. Emerging technology is evaluated and tested. Standards and best practice documents are prepared for solutions that are determined to be important to IT and the business. The architecture team is staffed with resources that are freed up of day-to-day issues, so they can work on evaluating and proving the viability of innovative solutions.

Applying new technology is not easy, as applications development and engineering groups are busy with company priorities. Therefore, it is the job of architecture to prove the new technology and become experts on it to assist with transition. During the transition stage, architecture provides expert assistance to project team members. The best way to move something new into the mainstream is by finding early adopters. These are people in need of innovative solutions to meet their goals. During the transition stage, EA works in an advisory role, as the new technology is adopted by others in the organization.

Sometimes, letting go of a new and exciting solution is difficult for members of the architecture team, but they must; otherwise, they will become a bottleneck to adoption at a later date. Once early adopters have experienced success they spread the word. Word-of-mouth about early success helps "sell" the new solutions to others. Soon, the new technology is being used by many groups and becomes mainstream to the organization in the adoption stage. Once the technology is completely transitioned, architecture need only track compliance to standards and recommended best practices. This adoption life cycle is perpetual and positive effects on the organization can be tracked and measured.