Architecture Principles

Principles are the guiding lights for any endeavor. So also for an enterprise architecture. TOGAF defines principles as:

"Principles are general rules and guidelines, intended to be enduring and seldom amended, that inform and support the way in which an organization sets about fulfilling its mission."

Essentially principles drive behavior of the enterprise. This is an initial output of the Preliminary Phase. Architecture Principles are developed by the Enterprise Architects - in conjunction with the key stakeholders. These principles are then approved by the Architecture Board.

Architecture Principles are influenced by:

  • Enterprise mission and plans
  • Enterprise strategic initiatives
  • External constraints
  • Current systems and technology
  • Emerging trends in the industry

Principles are defined on two levels: Enterprise and Architecture Principles

Enterprise Principles

As the name suggests enterprise principles relate to the enterprise as a whole - not just the architecture. It provides a basis for decision making throughout the enterprise. It is important to have defined and clearly stated enterprise principles. A good set of enterprise principles can form a basis for a lot of decisions about how the organization sets about fulfilling its mission. A consistent set of principles lead to harmonious decisions across the organization.

The enterprise principles are a key element in successful Architecture Governance Strategy. We can have subsidiary principles of enterprise principles - e.g. IT, HR, domestic operation, etc.

Architecture Principles

Architecture Principles on the other hand, are more specifically related to the (enterprise) architecture. They provide a set of principles that relate to architecture work. Architecture principles define an Enterprise wide spirit and thinking process. They govern the architecture process - the development, maintenance and use of Enterprise Architecture

Architecture Principles inherit from enterprise principles. They are developed by the Enterprise Architect, in conjunction with the key stakeholders - and approved by the Architecture Board. This inheritance should be clearly traceable. The principles should be clearly articulated to guide decision making. They should ensure alignment of the architecture and implementation of the target architecture with business strategies and vision

Architecture Components

The TOGAF standard recommends a standard template for describing principles. The template enforces a thorough exercise in developing these principles. In addition to the Principle Definition Statement, each principle should have associated rationale and implications statements. These promote understanding and acceptance of the principles themselves, and to support the use of the principles in explaining and justifying why specific decisions are made.


The name of an architectural principle is what we use to refer to it. The name has to be chosen with care.

  • Represent the essence of the rule
  • Should be easy to remember
  • Should not mention specific technology platforms
  • No ambiguous words like support,open,consider,"avoid","manage","management"
  • No unnecessary adjectives and adverbs


This is the essence of the principle. The statement of the principle is what we look for. The statement has to be carved rightly, to ensure the appropriate application of the principle

  • The statement should be unambiguous
  • It should communicate the fundamental rule
  • No ambiguous words like support,open,consider,"avoid","manage","management"
  • No unnecessary adjectives and adverbs

Often, the Principles statements are similar across organizations. It is important to clarify the exact spirit of this particular organization.


The rationale defines why we chose this principle - how is it relevant and useful on the journey of the enterprise.

  • Highlight the business benefits of adhering to the principle
  • Use business terminology
  • Point to the similarity between the IT principles and the principles governing business operations
  • Describe relationship with other principles
  • The intentions regarding a balanced interpretation
  • Situation where one principle would be given precedence over another


The implications demonstrate what the person defining the principles had thought about the impact of following the principle.

  • Should highlight the requirements - for business as well as IT - The Resources, costs, activities/tasks needed
  • Identify if current system/standard/practice is incongruent with the principle
  • Identify any impact to the business and the consequence of adopting
  • Clear answer to "How does this affect me?"
  • Do not oversimplify, trivialize or judge the merit of the impact.
  • Can also include "potential impacts"- speculative rather than fully analyzed

Quality of Principles

Having an agreed, written statement of principle does not mean that the principle is good. A good set of principles will be founded in the beliefs and values of the organization and expressed in language that the business understands and uses. Principles should be few in number. Too many principles lead to chaos. They should be future oriented. Principles should focus on a long path ahead. And just having a good set of principles is not enough. Principles are meaningless unless they are endorsed and championed by the senior management.

A good set of principles provide a firm foundation for making decisions. Often we have a scenario where there is no black and white answer to a choice we have to make. Principles are the guiding light here. They can help in many choices including architecture; policies, procedures, standards and any kind of contradictory situations.

On the other hand, a poor set of principles will quickly crumble under their own weight. The resultant architectures, policies and standards will be arbitrary and lack any credibility

There are five major criteria that distinguish a good set of principles


The principles should be understandable. That is, the underlying tenets can be quickly grasped and understood by everyone in the organization. The intention of the principle should be clear and unambiguous. Without understandability, all the effort on defining the principles is wasted


Each principle should be sufficiently definitive and precise. The principle should be fundamentally strong to an extent that it can lead to a correct decision in a variety of complex and (potentially) controversial scenarios. Such robust principles can lead the enterprise to a good quality decisions about architectures, plans, policies and standards.


The principles should not leave domains uncovered. The set of principles should be good enough to provide guidance in every possible situation.


A counterpart of completeness is consistency. We should not get into a situation where two principles we follow lead us to two different decisions. The set of decisions put together should be able to lead us to a decision without any confusion around it.


We should not need a new set of principles every day. The principles should have a good life - and should be able to endure changes in the environment around.

The principles should be enduring, yet they should be able to accommodate changes. An amendment process should be established for adding, removing, or altering principles after they are ratified initially.

Applying the Principles

Architecture Principles define the core guidelines about the deployment of IT resources and assets in the enterprise. They serve as a guide for establishing different evaluation criteria - for any decision that is made in the process.

They provide a framework for the enterprise to make conscious decisions about Enterprise Architecture

  • Choosing projects that implement the target Enterprise Architecture.
  • Defining the functional requirements of the architecture.
  • Existing implementations and the future strategic portfolio
  • Assessing compliance with the defined architectures

The Rationale statements highlight the value of the architecture to the enterprise, and therefore provide a basis for justifying architecture activities. The Implications statements provide an outline of the key tasks, resources, and potential costs to the enterprise of following the principle; they also provide valuable inputs to future transition initiatives and planning activities.

The architecture principles also support the Architecture Governance activities. They provide a direction to interpret the standard Architecture Compliance assessments; and potentially change them where required.

Principles are inter-related and need to be applied as a set. At times they will compete with each other. For example "availability" and "security" tend towards conflicting decisions. (Note this is not inconsistency. Rather it is completeness if it can highlight either aspect, and provide a way to choose). Each principle must be considered as "everything else being constant". Often, decision will involve choosing between principles. The rational for such decisions should always be documented.

A common reaction on first reading a principle is: "This is obvious and does not need to be documented". The fact that a principle is self-evident does not mean that the principle is always followed. Having principles that appear obvious helps ensure that decisions actually follow the desired outcome.