Home > Research > Prove the Value of Enterprise Architecture With SMART KPIs

Prove the Value of Enterprise Architecture With SMART KPIs

This note outlines some of the fundamental key performance indicators (KPIs) that you should measure to show the success of the enterprise architecture (EA) team. It also discusses how you measure them and visualize the result.

There are four types of metrics covered here:

EA Value Index covers the metrics that are directly attributed to the architecture team alone. These are great metrics to track not only to show the value of enterprise architecture, but to use over time as a great motivator for the architecture team.

Business Alignment Index covers how well enterprise architecture is satisfying the need of the business. When these metrics increase, it is usually accompanied by architecture job satisfaction and increased effectiveness of relationships between the business and architecture.

“Everyone needs to know that their job matters to someone – anyone. Without seeing a connection between their work and the satisfaction of other people, an employee will not find lasting fulfillment.” – Patrick Lencioni

Standards are an effective way to work smarter and reduce required effort on business change. Measuring how much the organization is standards based is a good way to motivate architecture and development to work as efficiently as possible.

Technical debt is generally incurred when tactical decisions are made for a good reason but do not align to the strategic objective. It has always been difficult to reduce technical debt over time because fixing something that is perceived to be working is inefficient. The metrics we cover in this section will show how much technical debt is being incurred against that which is being resolved over time.

Recommendations

This section covers some key metrics split into the four types that can accelerate and gain efficiencies across enterprise architecture.

EA Value

Metric Title: Plateau alignment

SMART Measure: How many plateaus have development iterations been aligned to?

How: In your enterprise continuum, there should be several artifacts that describe your enterprise architecture. Best practice dictates that you create an implementation and migration viewpoint that defines the architecture plateaus (or interim architectures). These plateaus represent base camps on the way to the summit of your development program. If you trace these plateaus to the work packages that represent your sprints or work iterations, you will be able to track how many development iterations relied on enterprise architecture as part of the planning process. This can be achieved in any good enterprise architecture tool.

Metric Title: Business capability satisfaction

SMART Measure: Satisfaction of business capabilities that have been realized by EA oversight

How: During show and tells or with a survey, you can easily establish which capabilities were useful to the business. If the architectures are traced to the business capability model, it is possible to establish a direct relationship between enterprise architecture effectiveness and business satisfaction. This can all be modeled in an architecture tool.

Metric Title: Regulation compliance

SMART Measure: Number of compliant regulation components based on reusable architecture

How: When you break down compliance and regulation into its constituent parts, each clause or section of the regulation may have implications or requirements for the architecture. It is important as architecture is created to trace it back to those constituent parts to establish that enterprise architecture is helping risk and compliance. This is an important metric because regulation is not normally optional but mandatory and the consequences of non-compliance can be severe. The traceability can be modeled in an architecture tool.

Metric Title: Reduction in development/integration effort

SMART Measure: Reusable ABB, SBB, architecture patterns by effort

How: When you create reusable enterprise architecture artifacts in the enterprise continuum, each one should have an effort measure associated with them. This can be used to determine how much effort is saved when those artifacts are reused in a project. These could be architecture building blocks (ABB), solution building blocks (SBB), reference architectures, or standard patterns. Using an architecture tool here will greatly reduce the effort in tracking reusability. When you can tell the story of cost savings on reusability, if done well this can almost pay for the enterprise architecture practice with a single metric.

Business Alignment

Metric Title: Number of level-three business capabilities implemented

SMART Measure: Count of business capabilities associated to plateau architectures

How: As with the business satisfaction of capabilities, this metric relies on the traceability from business capabilities to architectures. If you measure the capabilities that have been implemented during the sprint with supporting architecture, you can equate architecture’s contribution to the business goals. This modeling is possible in most enterprise architecture tools.

Metric Title: Number of high-value level-three capabilities implemented

SMART Measure: Count (or sum if capabilities are weighted) of high-value capabilities implemented

How: Similar to the previous metric, however, this focuses on the critical capabilities to the business. Usually the business architecture includes a capability model that contains a heatmap view of the priority business capabilities against goals. This can be used to filter the critical capabilities implemented by architecture to achieve a more powerful metric.

Metric Title: Number of business issues resolved

SMART Measure: Count of business issues resolved between sprints

How: Show and tells for the business should not be passive meetings; the business should be encouraged to evaluate the product from the sprint and critique which parts of the product are effective and satisfy requirements and which need work. Each issue identified that needs work should be addressed by the next show and tell. This will give the business confidence that development is progressing for the exclusive benefit of the business. If these issues or tasks are recorded and attributed to the ceremony in a tracking tool, reporting on this metric can be achieved easily.

Metric Title: Number of business issues identified

SMART Measure: Number of business issues identified per show and tell

How: As per the previous metric, it is good practice to track how many issues are identified by the business daily. The stronger the relationship between architecture and the business becomes, and the more aligned they are to the goals, the fewer issues will be raised during the show and tells.

Standards

Metric Title: Number of deviations from technology standard approved

SMART Measure: Approved deviations from mainstream or emerging standards

How: Your standards landscape, including architecture building blocks, solution building blocks, patterns, and technology standards, should be centrally documented, ideally in a wiki or intranet. These standards should be classified as:

  • Emerging (something new that should become a mainstream standard in future)
  • Mainstream (the preferred standard that most initiatives should use)
  • Contained (standards that should not be used for new initiatives but may remain in the current state architecture from a legacy perspective)
  • Decommissioned (standards that were once mainstream in the organization but have since been retired deliberately due to expense, out of support, or obsolete in some way; standards in this category should never be used)

When initiatives come through architecture governance to request a waiver for misalignment to standards, they should be recorded and tracked so that deviations from standards are reduced over time.

Metric Title: Resolvable standard deviations

SMART Measure: Deviations from standards that have a resolution path

How: A subset of the waivers granted in governance will have a future initiative or program that will enable the waiver to be released. This subset of waivers should also be tracked to show the volume of misaligned initiatives that will be resolved in time.

Metric Title: Payloads and data stores modeled on standards

SMART Measure: Entity coverage that is traced to a standard data model

How: Best-practice data architecture states that data models are traced to standards such as EDI, HL7, or UBL. This decreases the ambiguity of the models, speeds up the modeling process, and reduces the transformation needed between payloads in services to the model of the data at rest. A good data model has traceability from all entities to the standards on which they are based. This can be used to generate the metric. This facility is available in most good enterprise architecture modeling tools.

Technical Debt

Metric Title: Story points

SMART Measure: Always have a pointed story that represents technical debt with story points

How: When you incur technical debt, if it is documented in a story or requirement in a catalog with an associated story point or effort estimation, you can measure the increase or decrease of technical debt over time. Project management tools, especially those used for Agile projects have this facility built in.

Metric Title: Resolvable

SMART Measure: Technical debt stories that are resolvable

How: Some technical debt stories that you create when the debt is incurred can immediately be associated with an epic story in the backlog for a future initiative that will resolve the technical debt when complete. This is worth documenting so that you can project how much technical debt you will have at a point in the future.

Metric Title: Average time to resolve

SMART Measure: Time between current date and expected completion date

How: Going back to the last metric, it’s possible to measure the time it takes to resolve each technical debt item if you have an epic story planned for the future that resolves the debt item. You can report on this in project management tools to ensure the time to resolve reduces over time.

Bottom Line

Many of the metrics mentioned here required an enterprise architecture tool. This is one great reason for modeling architecture rather than creating images of architecture. However, it is still possible to capture some of these KPIs without the tooling, but it may be a high effort and very manual process.

Once these metrics have been established and you can track progression over time, the result should be better business engagement, reduction in effort of development cycles, and a business case for more architecture resources!


Want to Know More?

Traditional Enterprise Architecture Is Dead. We Need to Move With the Times.

Design an Enterprise Architecture Strategy