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:

• The Open Group's TOGAF 8.1.1. Architecture Principles chapter

• Mark Schulz, Architecture Principles white paper

• Craig Borysowich, Running a Architecture Principles Workshop blog post

• Architecture Principles: The Cornerstones of Enterprise Architecture, by Danny Greefhorst and Erik Proper, May 2011, book

• Principles in an Enterprise Architecture Context, Erik Proper and Danny Greefhorst, Journal of Enterprise Architecture, Feb 2011

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:

Industry

• Ebay's Architecture Principles with Randy Shoup (video) [and Shoup on InfoQ]

• Adaptive Security Architecture Principles, Sun

• W3C Principles (and Practices and Constraints) of the Architecture for the World Wide Web

• Mark Schulz, Architecture Principles white paper has a number of examples, as does the TOGAF Architecture Principles chapter

University

• IT Architecture Principles, AWG, Azusa Pacific University

• Duke TAG Architecture Principles

Federal and state agencies:

• NIH Enterprise Architecture Principles
  - Enterprise
  - Applications
  - Collaboration
  - Data
  - Integration
  - Network
  - Security
  - Systems Management

• State of Connecticut Conceptual Architecture Principles

• State of Wisconsin Enterprise Architecture principles
  - Enterprise
  - Management and Organization
  - Technology
  - Application Delivery
  - User Interface
  - Security
  - System Management
  - Data Management
  - Centers of Excellence

• North Dakota Conceptual Architecture Principles (with counterargument)

• State of Oregon Principles for Government Excellence

Other governments:

• New Zealand FEA Principles