discipline banner.gif (11841 bytes)

Visual Architecting Process Action Guides
- Init/Commit
- Meta-architecture
  - Requirements
  - Specification
- Conceptual Architecture
  - Requirements
  - Specification
- Logical Architecture
- Execution Architecture
- Architecture Deployment


Other Columns

i. Architecture Teams   (.pdf)

ii. Minimalist Architecture   (.pdf)

Related White Papers

i. Software Architecture (.pdf)

ii. Visual Architecting Process   (.pdf)

iii. Architecture as Business Competency (.pdf)

For more on Architecture Action Guides see

i. Downloads

ii. Software Architecture Workshop

For more on Architecting see

Architecting Process

Book List




Architecture Principles

Definition of principles:

Via Nova Architectura, Architecture Principles Arena:

"Even though there are several definitions of principles, we believe there are actually three classes of principles:

Principles as inherent laws. These are essentially properties of (classes of) a system that are inherent to a system (such as an enterprise, an information system, or a software system), and can as such be observed and validated.
Examples are the laws of nature, law of requisite variety, laws of social behavior, etc.

Principles as imposed laws. Like inherent laws, they are properties that can be validated. However, imposed laws also require mechanisms to enforce them. Imposed laws typically address concerns of stakeholders. Some of these concerns may be raised by inherent laws which may have a negative/undesirable effect with regard to the system being designed.
Examples are: societal laws, policies and regulations within organizations, etc.

Principles as guidelines. Desired properties that are so concrete that they offer guidelines to make operational behavior fit imposed laws.
For example: use your car's cruise control is an advisable property to abide by that provides guidance in obeying the law concerning maximum speeds on roads."

NIH Enterprise Architecture:

"Principles are high level statements of the fundamental values that guide Information Technology (IT) decision-making and activities at NIH and are the foundation for IT architecture, standards, and policy development."

W3C's Architecture for the World Wide Web Vol 1:

'An architectural principle is a fundamental rule that applies to a large number of situations and variables. Architectural principles include "separation of concerns", "generic interface", "self-descriptive syntax," "visible semantics," "network effect" (Metcalfe's Law), and Amdahl's Law: "The speed of a system is limited by its slowest component."'

Guide to creating architecture principles:

We advocate that principles included in the architecture decision set as Architecture Principles are statements of direction or practice that we will develop consensus and focus action around, to change the status quo (either to do something different with a shift in strategic direction, or to do something consistently that we have only being doing in isolated instances perhaps because it involves hard choices and tradeoffs). If we are going to take a minimalist approach to architecture, then we look to the minimum we need to do to ensure that the right things happen to achieve the strategic outcomes our business seeks. So we don't want to state general good principles that are already adhered to, or which are good practice but not something we should extend and encumber the architecture decision set with (everything we add to the architecture consumes attention of those who create and maintain it, those who need to understand and act in accordance with it, and those who govern it). Which begs the question--how long-lived are architecture principles? As business strategy and architecture drivers change, we want to revisit the set of principles, looking to cull principles that no longer apply and  adding principles that reflect the new direction. Once a principle is pretty well enculturated within the organization, we may continue to keep it in the architecture decision set if it is a point of uniqueness to our organization and we find that as we onboard new developers and architects (new hires or through acquisitions), the principle is important to helping bring them into our organization's (technical) culture (for technical principles) with its norms and principles guiding decisions and practice.  -- Ruth Malan, Architecture Principles

Architecture Principles Template

  • principle statement: clear statement that will guide and align decisions addressed by the principle, and ensure consistency across the scope of the principle

  • rationale: what benefits we get from following the principle (motivating why we have to change what we do); provides traceability to strategy or system/architecture objective the principle will help us meet

  • counter forces (aka counterarguments or alternatives considered): provides a place to say we recognize why the status quo is the way it is, what other factors weigh against the principle and what other approaches we might take (that other people in our environment would argue for) and why we shouldn't do that. One way to think about the counterargument/counter force, is that it illuminates implications/things that need to be done to ensure the principle is followed/viable in the social/business/technical context. It provides a place to say "we tend to do this, and this is how it hurts us" and "we could alternatively do this, and this is how that would hurt us."

  • implications: what we have to do to as a result of and to facilitate the change

  • scope (optional, as relevant): the intended scope of impact of the principle (explicitly denoting decision scopes to which the principle does not apply, so that these don't have to go through the exception request process, assuming the principle is tended under the governance process).

This guidance assumes that we are using "architecture principle" to mean a normative rule or code of conduct that orients and aligns decisions and actions. Well-stated principles cleave the decision space between decisions in line with the principle and decisions that run counter to the principle.

Which is not to say that architects shouldn't collect, organize, disseminate and teach guiding principles/approaches that leads to good designs. The point is only to separate general education of the development teams from principles that are formally used to shape the direction and decision space.

Examples of architecture principles:



Federal and state agencies:

Other governments:

Examples of Principles from Outside of Software and Enterprise Architecture

  • Definition of principle on wikipedia

  • principles definition from BusinessDictionary.com:
    "Fundamental norms, rules, or values that represent what is desirable and positive for a person, group, organization, or community, and help it in determining the rightfulness or wrongfulness of its actions. Principles are more basic than policy and objectives, and are meant to govern both."

Principles governing (professional) conduct:

Examples in Software

Examples in Enterprise Architecture

Guidance on Creating EA Principles

If you haven't watched Gandhi in a while, I heartily recommend it! It is about a great leader, and about great followers. And it is about principles with catchy names like "An eye for an eye makes the whole world blind." Deep, nation--and world--changing principles.

Principles used by CEOs

We are seeing more examples of the use of principles among business leadership, including the Patagonia Principles described by founder Yvon Chouinard, and the principles that Howard Behar used during his tenure as CEO of Starbucks.

Guiding Principles for Architects


Copyright 2009-2011 Bredemeyer Consulting
URL: http://www.bredemeyer.com
Created: March 24, 2009
Last Modified: July 27, 2011