Enterprise Architecture Measurement: A No-Nonsense Approach to Metrics and Governance

In addition to rules—which we covered in the article How Rules Translate Architectural Intent into Action—I use measures to make architecture requirements concrete. While rules state the specification, measures are used to determine effectiveness. 

By approaching architecture requirements this way, we gain structure with less rigidity. It gives us multiple ways to define and discuss what matters, and the linguistic flexibility to move between statements and questions to better articulate our intent.

How to Define Objective Measures in Enterprise Architecture

There are a few ways to structure measures, but, in my experience, the most effective is through one or more questions per rule that are answered deterministically (e.g., yes or no, true or false).

By framing the assessment as a simple dichotomy, you create the potential for a more objective view of adherence to the specification. This approach also requires us—when crafting the rules and measures—to break the specification down into its essential components, which is often the most logical and revealing way to think about these problems.

But, you can also expand the approach if it makes sense for your organization.

For example, introducing an evaluation scale (e.g., 0–3) could provide a more fine-grained assessment. But approach this with caution, as that granularity could come at the expense of objectivity.

Let’s cover three types of measures, with examples, to illustrate the approach.

Basic Measurement Techniques in Enterprise Architecture

Just asking, “Did you do the thing?” may not sound all that insightful, but sometimes it can be all you actually need for measuring many important things. 

Here’s an example:

Each Tier-1 and Tier-2 workload must undergo an annual disaster recovery test that confirms recovery objectives are met and procedures perform as designed.

The measure may simply be a yes or no question asking if that has been done, typically completed during scheduled asset reviews (e.g., annually), ideally defined in an asset management policy. (We’re potentially checking off a lot of boxes here with just a simple question.) 

But, at this level of granularity, you don’t have the ability to drill down into the results to evaluate complexity, which may be important and is also why I picked this rule as the example (e.g., a “yes” might just mean, My thing worked, but it doesn’t matter because yours didn’t and that’s not part of the assessment).

Adaptive Measurement for Evolving Enterprise Architecture Standards

Another option is to craft rules so that they will remain true over time (i.e., without modification) and then use measures for the things that will change over time. 

For example, you might create a basic rule for data encryption:

Encrypt all sensitive data in transit and at rest using approved methods.

Then, you expand the measures over time as the specific implementation standards evolve, which generates granularity in the assessment criteria: 

1. Is AES-128 encryption used for data at rest?
2. Is TLS 1.1 used for data in transit?
3. Is AES-256 used for data at rest?
4. Is TLS 1.3 used for data in transit?

In this way, by breaking out measures individually, you are able to objectively determine whether the rule is being met, and with specificity. 

But also, as technology evolves, you have the ability to track which assets may be behind on compliance with a new technology standard, which can be good from a planning, technical debt, and compliance standpoint. 

Advanced Enterprise Architecture Measurement for Complex Scenarios

If you need to be more sophisticated, where, again, there may be nuance in assessing a rule, your measures can be a series of questions with the aim of understanding the extent to which the rule is being met.

Let’s go through an observability example where there is likely nuance to the rule, and adherence to it, which, also, is absolutely what you are trying to determine:

All production workloads must maintain sufficient observability to detect, diagnose, and verify the health and performance of the system in real-time.

Measures:

1. Traceability: Does the workload emit structured logs that include trace and correlation IDs?
2. Centralization: Are logs, metrics, and traces centralized in a common observability platform?
3. Alerting: Are alerting thresholds defined for key business transactions or error conditions?
4. Verification: Are synthetic or canary checks in place to verify system availability from the user’s perspective?
5. Feedback & Improvement: Are incidents and postmortems traced back to observable gaps and used to improve telemetry design?
6. Automation & Integration: Is observability integrated with CI/CD pipelines to validate instrumentation before release?

Building an Enterprise Architecture Measurement Framework

With these examples, we’ve shown how to specify architecture requirements through rules and measures—and how they tie together in a policy- and principle-based approach to this part of Enterprise Architecture.

I had originally planned to stop here—with one article on requirements, one on rules, and one on measures. But after using all of these assertive words—requirements, rules, specifications, measures, assessments, oversight, governance (plus that mean-looking guy with the green visor)—it seems reasonable to pause and talk about perspective. 

Somewhere between defining, measuring, and enforcing policies and requirements, it’s easy to lose sight of why we’re doing any of this in the first place. So we’ll wrap up our architecture requirements segment in the next article, Calm Down and See the Bigger Picture—It’s Just Architecture. I hope you’ll join me.

Notes:
1. Featured Image created with OpenAI’s ChatGPT (GPT-5).