For more info please see Chapter 23
Introduction
Pr inciples are general rules and guidelines, intended to be enduring and seldom amended, that
infor m and support the way in which an organization sets about fulfilling its mission.
In their turn, principles may be just one element in a structured set of ideas that collectively
define and guide the organization, from values through to actions and results.
Depending on the organization, principles may be established within different domains and at
different levels. Two key domains infor m the development and utilization of architecture:
n Enterprise pr inciples provide a basis for decision-making throughout an enterpr ise, and
infor m how the organization sets about fulfilling its mission. Such principles are commonly
found as a means of harmonizing decision-making across an organization. In particular,
they are a key element in a successful architecture governance strategy (see Chapter 50).
Within the broad domain of enterpr ise pr inciples, it is common to have subsidiar y pr inciples
within a business or organizational unit. Examples include IT, HR, domestic operations, or
overseas operations. These principles provide a basis for decision-making within the
subsidiar y domain and will infor m architecture development within the domain. Care must
be taken to ensure that the principles used to infor m architecture development align to the
organizational context of the Architecture Capability.
n Architecture pr inciples are a set of principles that relate to architecture wor k. They reflect
a level of consensus across the enterpr ise, and embody the spirit and thinking of existing
enter prise principles. Architecture principles govern the architecture process, affecting the
development, maintenance, and use of the enterpr ise architecture.
It is common to have sets of principles for m a hierarchy, in that segment principles will be
infor med by, and elaborate on, the principles at the enterpr ise level. Architecture principles will
be infor med and constrained by enter prise principles.
Architecture principles may restate other enterpr ise guidance in terms and for m that effectively
guide architecture development.
The remainder of this section deals exclusively with architecture principles.
23.2 Characteristics of Architecture Principles
Architecture principles define the underlying general rules and guidelines for the use and
deployment of all IT resources and assets across the enterpr ise. They reflect a level of
consensus among the var ious elements of the enterpr ise, and for m the basis for making future
IT decisions.
Each architecture principle should be clearly related back to the business objectives and key
architecture drivers.
23.4 Developing Architecture Principles
Architecture principles are typically developed by the enterpr ise architects, in conjunction with
the key stakeholders, and are approved by the Architecture Board.
Architecture principles will be infor med by principles at the enterpr ise level, if they exist.
Architecture principles must be clearly traceable and clearly articulated to guide decisionmaking.
They are chosen so as to ensure alignment of the architecture and implementation of
the Target Architecture with business strategies and visions.
Specifically, the development of architecture principles is typically influenced by the following:
n Enterprise mission and plans: the mission, plans, and organizational infrastr ucture of the
enter prise.
n Enterprise strategic initiatives: the character istics of the enterpr ise — its strengths,
weaknesses, oppor tunities, and threats — and its current enterpr ise-wide initiatives (such
as process improvement and quality management).
n External constraints: mar ket factors (time-to-market imperatives, customer expectations,
etc.); existing and potential legislation.
n Current systems and technology: the set of infor mation resources deployed within the
enter prise, including systems documentation, equipment inventor ies, networ k configuration
diagrams, policies, and procedures.
n Emerging industry trends: predictions about economic, political, technical, and market
factors that influence the enterpr ise environment.
Physical Application Component
An application, application module, application service, or other deployable component of functionality. For example, a configured and deployed instance of a Commercial Off-The-Shelf (COTS) Enterprise Resource Planning (ERP) supply chain management application.
Physical Data Component
A boundary zone that encapsulates related data entities to form a physical location to be held. For example, a purchase order business object, comprising purchase order header and item business object nodes.
Physical Technology Component
A specific technology infrastructure product or technology infrastructure product instance. For example, a particular product version of a Commercial Off-The-Shelf (COTS) solution, or a specific brand and version of server.
Logical Application Component
An encapsulation of application functionality that is independent of a particular implementation. For example, the classification of all purchase request processing applications implemented in an enterprise.
Logical Data Component
A boundary zone that encapsulates related data entities to form a logical location to be held. For example, external procurement information.
Logical Technology Component
An encapsulation of technology infrastructure that is independent of a particular product. A class of technology product. For example, supply chain management software as part of an Enterprise Resource Planning (ERP) suite or a Commercial Off-The-Shelf (COTS) purchase request processing enterprise service.