How Policy Integration Works in Enterprise Architecture

We covered policy integration in the post Unstoppable Enterprise Architecture. That part of our discussion was about how to structurally insert Enterprise Architecture into an organization’s policy machinery and drive value through that intervention.

But we still need to address policies specifically, and we will do that now.

Again, let’s have a look at how a few of the major Enterprise Architecture approaches define and address policies:

How Traditional Enterprise Architecture Approaches Define Policies

TOGAF Perspective on Policies

Policies are a part of the governance structure. They are rules, guidelines, or constraints that guide how architectures are developed and how systems behave within the enterprise. The purpose is to ensure compliance with enterprise architecture and standards.

Gartner Perspective on Policies

Policies are executive-level directives that shape IT governance and architecture. They are principle-based guardrails that enforce alignment between IT and business strategy.

Policy Integration Across the Enterprise

I agree, at least conceptually, with the descriptions of policies by TOGAF and Gartner, except that they are approached with Enterprise Architecture as the focal point.

If we accept that worldview, Enterprise Architecture—metaphorically—is the center of the solar system, and all the other functions of the organization are just shitty little planets that rotate around us…²

No.

Policies originate from across the enterprise—including IT and Enterprise Architecture. It should be the role of Enterprise Architecture to integrate those policies so that, where appropriate, they are translated into architecture requirements, which I like to implement with rules and measures (the subjects of our next three posts).

But, in order to get there, let’s start by working through a few different types and examples of policies, their origins, and how they can lead to architecture requirements.

Sources of Enterprise Policies That Influence Architecture

Board of Directors Policies

The Board of Directors likely provides corporate charters, codes of conduct, governance, and other strategic directives. Some may lead to architecture requirements to ensure these high-level directives are built into and operationalized in our technology solutions.

For example:

• Technology systems must be designed, implemented, and operated in a manner that supports the organization’s Environmental, Social, and Governance (ESG) objectives by optimizing energy efficiency and minimizing environmental impact.

This type of policy could lead to architecture requirements for measuring and controlling the power consumption used to train LLMs, for instance.

Risk and Legal Policies

A Risk organization will provide policies that address requirements for regulatory compliance, contracts, intellectual property, privacy, insurance, third-party risk management, and business continuity.

Some examples:

• The organization must ensure that all third-party integrations adhere to security, privacy, and contractual compliance requirements, including protection of sensitive data.
• The organization must ensure continuity of critical business services through resilient, tested solutions that meet recovery objectives and geographic redundancy requirements.

Interestingly, architecture requirements are often in place that loosely tie these types of directives together, just without the explicit traceability that Enterprise Architecture is materially contributing to ensuring the effectuation of these risk-based policies.

The same thing can likely be said about controls defined by cybersecurity, which we will cover next. . .

Cybersecurity Policies

Cybersecurity organizations define policies for identity and access management, privileged access, encryption, and threat response, to name a few functions. Much of this is represented as controls (people-, process-, and technology-based), which often necessitate architecture requirements for their implementation.

Examples:

• All users and systems must be granted only the minimum access necessary, and authentication to sensitive systems must require multiple factors of verification.
• The organization must maintain security monitoring and incident response capabilities that support proactive detection, standardized response, and evidentiary integrity.

Internal Audit Policies

An Internal Audit function in an organization likely defines and/or implements audit standards, remediation mandates, and “friendly fire” methods and processes. Much of what is being audited is focused on ensuring that systems and processes can be independently tested and validated.

Examples:

• Applications must maintain complete, tamper-resistant records of activity in accordance with audit and compliance requirements.
• Audit processes must produce accessible and verifiable evidence that supports testing, oversight, and timely remediation of findings.

Finance and Accounting Policies

Finance and Accounting policies address budgeting, financial reporting controls (e.g., SOX), procurement, and vendor management concerns, including supply chain standards for sourcing. Some of these policies should be used, where directly applicable, to incorporate those needs into architecture requirements.

Examples:

• Financial data must be classified and managed in alignment with lifecycle and retention requirements appropriate to its type and sensitivity.
• Financial systems must implement separation of duties and access controls to prevent fraud and ensure the integrity of transactions.
• Financial reporting systems must comply with Sarbanes-Oxley (SOX) requirements by maintaining reliable, complete, and verifiable transaction records and controls.

Translating Policies Into Architecture Requirements

These are just a few examples for where policies may come from, but there are many others, including Operations, Facilities, Sales, Marketing, and, of course, Information Technology.

Policy Classification Across Architecture Domains

Another part of policy integration, which we covered in the post Key Steps for Effective Enterprise Architecture Programs, is classifying policies into domains. There are five: system, application, data, infrastructure, and security.

But it’s important to note that policies will not neatly fit into just one of those domains. There will be redundancies, crossovers, and inconsistencies. Dealing with this is why I use terms like integration and reconciliation. It is also not at all easy to do.

Why Policy Integration Is Core to Enterprise Architecture

Policies are inflection points in most organizations. They can be overlapping, contradictory—even incomprehensible—but they have to be addressed.

Where properly situated, they should be used to define clear architectural direction and oversight.

From Policy to Runtime Behavior

If we reconcile policies and turn them into architecture requirements that specify how a computer will do something, the organization has a much better likelihood of realizing those policies at runtime, which, again, is where the effectiveness of Enterprise Architecture is determined.

Again, Enterprise Architecture is uniquely positioned to accomplish this extremely important policy integration work, and it’s an incredibly valuable contribution to the business.

What Comes Next: Rules and Measures

We will return to these policy examples in the next three posts to illustrate how they can be turned into architecture requirements through rules and measures.

Notes:
1. Image created with OpenAI’s ChatGPT (GPT-5).
2. My good friend Shawn Ellis dropped this line in a meeting with an outsourcing vendor years ago when he was done arguing with them about something. In that version, Shawn was the Sun. The message also came across epically that they needed to do what he was telling them to do.