How Rules Translate Architectural Intent into Action

In the article When Architecture Requirements Meet Organizational Politics, we discussed the need for architecture requirements and how they fit into the broader machinery of Enterprise Architecture. Now it’s time to work through what these requirements actually are and how to approach creating them. 

I recommend reading the article Effective Enterprise Architecture Principles, if you haven’t already, where we introduced the following structure:

From Principles to Requirements: Rules and Measures

I prefer establishing architecture requirements in two parts: first, with rules; second, with measures. The rules tell us what to do. The measures tell us if we’re doing that and to what extent.

As we’ve covered before, these rules and measures—together, the architecture requirements—are drawn from policies and principles, with a heavier lean toward the former.

Why Architecture Rules Exist: Learning from Failure

We like to think that architecture rules come from best practices—and sometimes they do.

But in reality, we usually know what to do—or to avoid—as a result of accumulated experience where bad things have happened.

That is to say that, over time, we’ve made a computer do something and we’ve learned what works and what doesn’t.

Translating Policy into Actionable Architecture Rules

So, if policies are where everyone agrees in principle (I’m being overly assumptive here, of course), rules are where those policies take an operational shape, turning intent into something specific, testable, and enforceable.

Each part of the organization sees the world differently: Risk worries about exposure, Cybersecurity about integrity. A good rule connects those perspectives, resolves the friction, and translates collective intent into something the organization can act upon in a measurable way.

The Structure of Effective Architecture Rules

To ground the discussion, we will build on a few examples from the article The Role of Asset Management in Enterprise Architecture.

In that article, we covered Level 1 reviews, with some initial ideas for areas to focus on at this level of assessment.

We’ll pick up from there by using Trusted Sources and Licensing, illustratively, to build rules from that policy-based foundation.

Example: Trusted Sources Rule

Here are a few examples of policies from across an organization that address Trusted Sources:

Risk: Engage only vendors or projects with verified identity, established reputation, and traceable ownership. Anonymous or unverifiable sources are prohibited.

Cybersecurity: Use only systems and services from authenticated, trusted sources. Block any vendor or project with unknown or suspicious origin.

Finance: Conduct business only with identifiable, verifiable entities. Do not engage or fund vendors lacking traceable ownership or audit transparency.

Here’s an example of a rule that integrates and reconciles these policies: 

Software must be obtained only from sources that can be independently verified as legitimate and reputable. Verification must include:

1. Confirmed Business Identity (registered legal entity and traceable ownership)
2. Authenticated Download or Delivery Channel (official vendor site, verified marketplace, or authorized distributor)
3. Auditable Financial and Licensing Records (invoice, payment trace, or contract)

Software from anonymous developers, unverified websites, peer-to-peer networks, or other untraceable origins is strictly prohibited.

Example: Licensing Rule

Here are a few examples of policies from across an organization that address licensing: 

Risk: Software and vendors must be verified, reputable, and traceable to minimize organizational exposure. Unverified or anonymous sources present unacceptable risk and must not be used.

Cybersecurity: Software and systems must originate from authenticated, trusted sources with validated integrity. Any code or service from unknown or suspicious origin must be blocked to prevent compromise.

Finance: Software and technology purchases must be made only through identifiable, verifiable vendors with transparent ownership and compliant licensing. Entities lacking traceable credentials or valid terms are ineligible for procurement or payment.

Here’s an example of a rule that integrates and reconciles these policies: 

Software must only use licenses that are formally approved and listed in the Enterprise Architecture licensing standard. The license must be:

1. Current: not expired, deprecated, or revoked by the licensor.
2. Compatible: does not conflict with organizational, vendor, or integration requirements.
3. Compliant: reviewed and cleared by Legal, Risk, and Architecture for intended use.

Licenses that impose restrictive obligations, uncertain ownership rights, or unapproved usage terms are prohibited.

These are just a few examples of where Enterprise Architecture is well-positioned to figure things out through policy reconciliation and integration. It’s a lot of work, but it’s extremely valuable and doable.

From Rules to Measures: Evaluating Effectiveness

In the next article, we’ll cover measures—the evaluative criteria for each rule. Then, once we’ve done that, we’ll bring the two together and talk about how to make architecture requirements work over time.

Notes:
1. Featured Image created with OpenAI’s ChatGPT (GPT-5).
2. To introduce rules in this article, I used a few examples from the “Level 1 Review” section of the article The role of Asset Management in Enterprise Architecture. Level 1 reviews are for the purpose of assessing Untrusted assets for adherence to a minimal set of evaluative criteria. In these cases, the measures should be unambiguous. But as we expand to a broader scope for rules, that won’t necessarily be the case. We’ll address that in the measures article.