A. Framework and Principles

[¤1] A. Framework and Principles

[¤2] Preliminary Phase: Framework and Principles

[¤3] Objectives Approach Inputs Steps Outputs

(w_stahlecker) To ensure that everyone who will be involved in, or benefit from this approach, is committed to the success of the architectural process. To define the architecture principles that will inform the constraints on any architecture work. To define the 'architecture footprint' for the organization - the people reponsible for performing architecture work, where they are located, and their responsibilities. To define the scope and assumptions (particularly in a federated architecture environment) To set up and monitor a process (normally including a pilot project) to confirm the fitness for purpose of the defined framework. If necessary, to define a set of criteria for evaluating architecture tools (an example set of criteria is given in Part IV), repositories and repository management processes to be used to capture, publish, and maintain architecture artifacts. To define the framework and detailed methodologies that are going to be used to develop enterprise architectures in the organization concerned.
[¤4] Objectives

(c_greenslade) To ensure that everyone who will be involved in, or benefit from this approach, is committed to the success of the architectural process.
[¤5] To define the framework and detailed methodologies that are going to be used to develop enterprise architectures in the organization concerned.
[¤6] To set up and monitor a process (normally including a pilot project) to confirm the fitness for purpose of the defined framework.
[¤7] To define the architecture principles that will inform the constraints on any architecture work.
[¤8] To define the scope and assumptions (particularly in a federated architecture environment)
[¤9] If necessary, to define a set of criteria for evaluating architecture tools (an example set of criteria is given in Part IV), repositories and repository management processes to be used to capture, publish, and maintain architecture artifacts.
[¤10] To define the "architecture footprint" for the organization - the people reponsible for performing architecture work, where they are located, and their responsibilities.

[¤11] Approach

[¤12] This preliminary phase is about defining "How we do Architecture" in the enterprise concerned. There are two main aspects: defining the framework to be used; and defining the architecture principles that will inform any architecture work.

[¤13] The enterprise's approach to reuse of architecture assets is a key part of both the framework definition and architecture principles. (Typically the principles will state the policy on reuse; and the framework will explain how reuse is effected.)

[¤14] In federated architectures (see Enterprise Scope / Focus in the Introduction to the Architecture Development Method), requirements from a higher level architecture are often manifested as "principles" in lower level ones.

(w_stahlecker) move 18/19/20 before current 15/16/17
[¤15] Framework

[¤16] The TOGAF Architecture Development Method is a generic method, intended to be used by enterprises in a wide variety of industry types and geographies. It is also designed for use with a wide variety of other enterprise architecture frameworks, if required (although it can be used perfectly well in its own right, without adaptation).

[¤17] This phase therefore involves doing any necessary work to adapt the ADM to define an organization-specific framework, using either the TOGAF deliverables or the deliverables of another framework. The issues involved in this are discussed under Adapting the ADM in the Introduction to the ADM.

[¤18] Principles

[¤19] This phase also defines the architecture principles that will form part of the constraints on any architecture work undertaken in the enterprise. The issues involved in this are explained in Part IV, Architectural Principles.

(m_iacob) Put 'Architecture work complies with business principles...' instead of 'Architecture work is informed by business principles...'.
[¤20] Architecture work is informed by business principles as well as architecture principles. The architecture principles themsleves are also normally based in part on business principles. Defining business principles normally lies outside the scope of the Architecture function. However, depending on how such principles are defined and promulgated within the enterprise concerned, it may be possible for the set of architecture principles to also restate, or cross-refer to, a set of business principles, business goals, and strategic business drivers defined elsewhere within the enterprise. (Within an architecture project, the architect will normally need to ensure that the definitions of these business principles, goals, and strategic drivers are current, and to clarify any areas of ambiguity.)

(m_iacob) Replace paramountcy with supremacy, or dominance , or with something semantically equivalent.
(a_bodor) Replace 'paramountcy with leadership.
[¤21] The issue of architecture governance is closely linked to that of architecture principles. The body responsible for governance will also normally be responsible for approving the architecture principles; and the paramountcy of this body in resolving architecture issues will normally be one of the principles cited. The issues involved in governance are explained in Part IV, IT Governance.

[¤22] Inputs

[¤23] The inputs to this phase are:

[¤24] TOGAF Architecture Development Method
[¤25] Other architecture framework(s), if required
[¤26] Business Strategy, Business Principles, Business Goals and Business Drivers (when pre-existing)
[¤27] IT Governance Strategy (when pre-existing)
[¤28] Architecture Principles (when pre-existing)
[¤29] Principles that are being subscribed to, arising from other, federated architectures

[¤30] Steps

[¤31] The TOGAF Architecture Development Method is a generic method, intended to be used by a wide variety of different enterprises, and in conjunction with a wide variety of other architecture frameworks, if required. It is not practical to define specific steps for adapting the ADM to such a wide variety of potential contexts. The issues involved are discussed in detail under Adapting the ADM in the Introduction to the ADM.

[¤32] Outputs

[¤33] The outputs of this phase are:

[¤34] Framework Definition
[¤35] Architecture Principles
[¤36] Restatement of, or reference to, Business Principles, Business Goals and Business Drivers