Architecture Principles

Architecture principles express an organization's beliefs about how technology should be designed and used, in a form that can guide many decisions. Examples include "reuse before buy, buy before build," "data is owned by the business and managed as an asset" and "systems must be secure by design." Each principle is short, but it carries a rationale and implications that explain why it matters and what it requires in practice.

Principles help organizations make consistent decisions without reviewing every choice in detail. When a project team is choosing between options, the principles indicate which direction the organization prefers. They also make disagreements easier to resolve, since debates can refer to agreed principles rather than personal preferences. For enterprise architecture and IT finance, well-chosen principles steer the organization toward simpler, more reusable and more affordable technology over time.

Definition of Architecture Principles

Architecture principles are general rules that inform and support how an organization fulfills its mission through technology. They are intended to be stable, changing rarely, and to apply across projects and business units.

TOGAF describes a standard format for principles and recommends developing them early in an architecture practice. Principles form the foundation of enterprise architecture governance and are often used as criteria in architecture reviews.

Structure of a Principle

The name is a short, memorable statement of the principle, such as "cloud first" or "single source for master data."

The statement explains the principle in one or two sentences, removing ambiguity about what it means. Clear statements reduce arguments about interpretation later.

The rationale explains why the principle matters, usually in terms of business benefits such as lower cost, reduced risk or faster delivery.

The implications describe what the principle requires in practice, such as changes to processes, standards or skills, and what it means for projects.

Common Categories

Business principles address how technology supports the business, such as maximizing benefit to the organization as a whole rather than to individual units.

Data principles address how data is owned, shared, protected and defined, such as treating data as a shared asset with clear owners. These principles often support data governance policies.

Application principles address how applications are chosen and designed, such as preferring standard packaged software and reusable services. Technology principles address infrastructure choices, such as standardizing platforms and automating operations.

Importance of Architecture Principles in Enterprise Architecture

Principles enable consistent decisions at scale. Architects cannot review every choice, but teams that understand the principles can make aligned decisions themselves. This allows governance to focus on the decisions that truly need review.

They connect technology choices to business goals. A good principle explains how a technical preference serves the organization's strategy. This makes principles easier to defend when business leaders question a technology decision.

They also provide a basis for governance, giving review boards clear criteria for assessing designs and exceptions. Decisions become more predictable, and teams can anticipate what reviewers will ask.

Effect on Costs

Many principles directly influence long-term costs. Preferring reuse reduces duplicated applications, standardizing platforms reduces licensing and support costs, and designing for automation lowers operating effort.

Principles also guide trade-offs between upfront cost and lifetime cost. A principle favoring total cost of ownership over purchase price encourages teams to consider support, integration and exit costs.

Over time, consistent application of a few principles can reshape the application inventory, reducing the number of platforms and overlapping systems the organization must fund.

Principles that are ignored deliver no savings, so tracking how often exceptions are granted is an important measure.

Common Pitfalls

Too many principles dilute their impact. Most organizations work best with between 10 and 20. A short list is easier to remember and apply in everyday decisions.

Principles that are vague or obvious, such as "systems should be reliable," give no real guidance. Useful principles involve a choice that someone could reasonably disagree with. Testing each draft principle by asking whether its opposite would be a sensible position helps filter out statements that add nothing.

Principles that are written but never used in decisions lose credibility. They need to be referenced in design reviews, investment approvals and standards. Leaders also need to follow them, since exceptions granted at the top quickly weaken them everywhere else.