Introduction

URL de origem: http://pubs.opengroup.org/architecture/togaf9-doc/arch/chap01.html

TOGAF is a framework - a detailed method and a set of supporting tools - for developing an enterprise architecture. It may be used freely by any organization wishing to develop an enterprise architecture for use within that organization (see 4.5.1 Conditions of Use).

TOGAF is developed and maintained by members of The Open Group, working within the Architecture Forum (refer to www.opengroup.org/architecture). The original development of TOGAF Version 1 in 1995 was based on the Technical Architecture Framework for Information Management (TAFIM), developed by the US Department of Defense (DoD). The DoD gave The Open Group explicit permission and encouragement to create TOGAF by building on the TAFIM, which itself was the result of many years of development effort and many millions of dollars of US Government investment.

Starting from this sound foundation, the members of The Open Group Architecture Forum have developed successive versions of TOGAF and published each one on The Open Group public web site.

If you are new to the field of enterprise architecture and/or TOGAF, you are recommended to read the Executive Overview (refer to 1.2 Executive Overview), where you will find answers to questions such as:

  • What is an enterprise?
  • Why do I need an enterprise architecture?
  • Why do I need TOGAF as a framework for enterprise architecture?

 1.1 Structure of the TOGAF Document

The structure of the TOGAF documentation reflects the structure and content of an Architecture Capability within an enterprise, as shown in Figure 1-1.


  Figure 1-1: Structure of the TOGAF Document

There are seven parts to the TOGAF document:

PART I
(Introduction) This part provides a high-level introduction to the key concepts of enterprise architecture and in particular the TOGAF approach. It contains the definitions of terms used throughout TOGAF and release notes detailing the changes between this version and the previous version of TOGAF.
PART II
(Architecture Development Method) This part is the core of TOGAF. It describes the TOGAF Architecture Development Method (ADM) - a step-by-step approach to developing an enterprise architecture.
PART III
(ADM Guidelines and Techniques) This part contains a collection of guidelines and techniques available for use in applying TOGAF and the TOGAF ADM.
PART IV
(Architecture Content Framework) This part describes the TOGAF content framework, including a structured metamodel for architectural artifacts, the use of re-usable architecture building blocks, and an overview of typical architecture deliverables.
PART V
(Enterprise Continuum & Tools) This part discusses appropriate taxonomies and tools to categorize and store the outputs of architecture activity within an enterprise.
PART VI
(TOGAF Reference Models) This part provides a selection of architectural reference models, which includes the TOGAF Foundation Architecture, and the Integrated Information Infrastructure Reference Model (III-RM).
PART VII
(Architecture Capability Framework) This part discusses the organization, processes, skills, roles, and responsibilities required to establish and operate an architecture function within an enterprise.

The intention of dividing the TOGAF specification into these independent parts is to allow for different areas of specialization to be considered in detail and potentially addressed in isolation. Although all parts work together as a whole, it is also feasible to select particular parts for adoption while excluding others. For example, an organization may wish to adopt the ADM process, but elect not to use any of the materials relating to Architecture Capability.

As an open framework, such use is encouraged, particularly in the following situations:

  • Organizations that are new to TOGAF and wish to incrementally adopt TOGAF concepts are expected to focus on particular parts of the specification for initial adoption, with other areas tabled for later consideration.
  • Organizations that have already deployed architecture frameworks may choose to merge these frameworks with aspects of the TOGAF specification.

 1.2 Executive Overview

This section provides an executive overview of enterprise architecture, the basic concepts of what it is (not just another name for IT Architecture), and why it is needed. It provides a summary of the benefits of establishing an enterprise architecture and adopting TOGAF to achieve that.

 What is an enterprise?

TOGAF defines "enterprise" as any collection of organizations that has a common set of goals. For example, an enterprise could be a government agency, a whole corporation, a division of a corporation, a single department, or a chain of geographically distant organizations linked together by common ownership.

The term "enterprise" in the context of "enterprise architecture" can be used to denote both an entire enterprise - encompassing all of its information and technology services, processes, and infrastructure - and a specific domain within the enterprise. In both cases, the architecture crosses multiple systems, and multiple functional groups within the enterprise.

Confusion often arises from the evolving nature of the term "enterprise". An extended enterprise nowadays frequently includes partners, suppliers, and customers. If the goal is to integrate an extended enterprise, then the enterprise comprises the partners, suppliers, and customers, as well as internal business units.

The business operating model concept is useful to determine the nature and scope of the enterprise architecture within an organization. Large corporations and government agencies may comprise multiple enterprises, and may develop and maintain a number of independent enterprise architectures to address each one. However, there is often much in common about the information systems in each enterprise, and there is usually great potential for gain in the use of a common architecture framework. For example, a common framework can provide a basis for the development of an Architecture Repository for the integration and re-use of models, designs, and baseline data.

 Why do I need an enterprise architecture?

The purpose of enterprise architecture is to optimize across the enterprise the often fragmented legacy of processes (both manual and automated) into an integrated environment that is responsive to change and supportive of the delivery of the business strategy.

Today's CEOs know that the effective management and exploitation of information through IT is a key factor to business success, and an indispensable means to achieving competitive advantage. An enterprise architecture addresses this need, by providing a strategic context for the evolution of the IT system in response to the constantly changing needs of the business environment.

Furthermore, a good enterprise architecture enables you to achieve the right balance between IT efficiency and business innovation. It allows individual business units to innovate safely in their pursuit of competitive advantage. At the same time, it ensures the needs of the organization for an integrated IT strategy are met, permitting the closest possible synergy across the extended enterprise.

The advantages that result from a good enterprise architecture bring important business benefits, which are clearly visible in the net profit or loss of a company or organization:

  • A more efficient business operation:
    • Lower business operation costs
    • More agile organization
    • Business capabilities shared across the organization
    • Lower change management costs
    • More flexible workforce
    • Improved business productivity
  • A more efficient IT operation:
    • Lower software development, support, and maintenance costs
    • Increased portability of applications
    • Improved interoperability and easier system and network management
    • Improved ability to address critical enterprise-wide issues like security
    • Easier upgrade and exchange of system components
  • Better return on existing investment, reduced risk for future investment:
    • Reduced complexity in the business and IT
    • Maximum return on investment in existing business and IT infrastructure
    • The flexibility to make, buy, or out-source business and IT solutions
    • Reduced risk overall in new investments and their cost of ownership
  • Faster, simpler, and cheaper procurement:
    • Buying decisions are simpler, because the information governing procurement is readily available in a coherent plan
    • The procurement process is faster - maximizing procurement speed and flexibility without sacrificing architectural coherence
    • The ability to procure heterogeneous, multi-vendor open systems
    • The ability to secure more economic capabilities
 What specifically would prompt me to develop an enterprise architecture?

Typically, preparation for business transformation needs or for radical infrastructure changes initiates an enterprise architecture review or development. Often key people identify areas of change required in order for new business goals to be met. Such people are commonly referred to as the "stakeholders" in the change. The role of the architect is to address their concerns by:

  • Identifying and refining the requirements that the stakeholders have
  • Developing views of the architecture that show how the concerns and requirements are going to be addressed
  • Showing the trade-offs that are going to be made in reconciling the potentially conflicting concerns of different stakeholders

Without the enterprise architecture, it is highly unlikely that all the concerns and requirements will be considered and met.

 What is an architecture framework?

An architecture framework is a foundational structure, or set of structures, which can be used for developing a broad range of different architectures. It should describe a method for designing a target state of the enterprise in terms of a set of building blocks, and for showing how the building blocks fit together. It should contain a set of tools and provide a common vocabulary. It should also include a list of recommended standards and compliant products that can be used to implement the building blocks.

 Why do I need TOGAF as a framework for enterprise architecture?

TOGAF has been developed through the collaborative efforts of over 300 Architecture Forum member companies from some of the world's leading companies and organizations. Using TOGAF results in enterprise architecture that is consistent, reflects the needs of stakeholders, employs best practice, and gives due consideration both to current requirements and the perceived future needs of the business.

Developing and sustaining an enterprise architecture is a technically complex process which involves many stakeholders and decision processes in the organization. TOGAF plays an important role in standardizing and de-risks the architecture development process. TOGAF provides a best practice framework for adding value, and enables the organization to build workable and economic solutions which address their business issues and needs.

 Who would benefit from using TOGAF?

Any organization undertaking, or planning to undertake, the development and implementation of an enterprise architecture for the support of business transformation will benefit from use of TOGAF.

Organizations seeking Boundaryless Information Flow can use TOGAF to define and implement the structures and processes to enable access to integrated information within and between enterprises.

Organizations that design and implement enterprise architectures using TOGAF are assured of a design and a procurement specification that can facilitate an open systems implementation, thus enabling the benefits of open systems with reduced risk.


Core Concepts

URL de origem: http://pubs.opengroup.org/architecture/togaf9-doc/arch/chap02.html

2.1 What is TOGAF?

TOGAF is an architecture framework. TOGAF provides the methods and tools for assisting in the acceptance, production, use, and maintenance of an enterprise architecture. It is based on an iterative process model supported by best practices and a re-usable set of existing architecture assets.

 2.2 What is Architecture in the Context of TOGAF?

ISO/IEC 42010:2007 defines "architecture" as:

"The fundamental organization of a system, embodied in its components, their relationships to each other and the environment, and the principles governing its design and evolution."

TOGAF embraces but does not strictly adhere to ISO/IEC 42010:2007 terminology. In TOGAF, "architecture" has two meanings depending upon the context:

  1. A formal description of a system, or a detailed plan of the system at component level to guide its implementation
  2. The structure of components, their inter-relationships, and the principles and guidelines governing their design and evolution over time

TOGAF considers the enterprise as a system and endeavors to strike a balance between promoting the concepts and terminology of ISO/IEC 42010:2007 - ensuring that usage of terms defined by ISO/IEC 42010:2007 is consistent with the standard - and retaining other commonly accepted terminology that is familiar to the majority of the TOGAF readership. For more on terminology, refer to 3. Definitions and Part IV, 35. Architectural Artifacts.

 2.3 What Kind of Architecture Does TOGAF Deal With?

There are four architecture domains that are commonly accepted as subsets of an overall enterprise architecture, all of which TOGAF is designed to support:

  • The Business Architecture defines the business strategy, governance, organization, and key business processes.
  • The Data Architecture describes the structure of an organization's logical and physical data assets and data management resources.
  • The Application Architecture provides a blueprint for the individual applications to be deployed, their interactions, and their relationships to the core business processes of the organization.
  • The Technology Architecture describes the logical software and hardware capabilities that are required to support the deployment of business, data, and application services. This includes IT infrastructure, middleware, networks, communications, processing, standards, etc.

 2.4 Architecture Development Method

The TOGAF Architecture Development Method (ADM) provides a tested and repeatable process for developing architectures. The ADM includes establishing an architecture framework, developing architecture content, transitioning, and governing the realization of architectures.

All of these activities are carried out within an iterative cycle of continuous architecture definition and realization that allows organizations to transform their enterprises in a controlled manner in response to business goals and opportunities.

Phases within the ADM are as follows:

  • The Preliminary Phase describes the preparation and initiation activities required to create an Architecture Capability including customization of TOGAF and definition of Architecture Principles.
  • Phase A: Architecture Vision describes the initial phase of an architecture development cycle. It includes information about defining the scope of the architecture development initiative, identifying the stakeholders, creating the Architecture Vision, and obtaining approval to proceed with the architecture development.
  • Phase B: Business Architecture describes the development of a Business Architecture to support the agreed Architecture Vision.
  • Phase C: Information Systems Architectures describes the development of Information Systems Architectures to support the agreed Architecture Vision.
  • Phase D: Technology Architecture describes the development of the Technology Architecture to support the agreed Architecture Vision.
  • Phase E: Opportunities & Solutions conducts initial implementation planning and the identification of delivery vehicles for the architecture defined in the previous phases.
  • Phase F: Migration Planning addresses how to move from the Baseline to the Target Architectures by finalizing a detailed Implementation and Migration Plan.
  • Phase G: Implementation Governance provides an architectural oversight of the implementation.
  • Phase H: Architecture Change Management establishes procedures for managing change to the new architecture.
  • Requirements Management examines the process of managing architecture requirements throughout the ADM.

 2.5 Deliverables, Artifacts, and Building Blocks

Architects executing the ADM will produce a number of outputs as a result of their efforts, such as process flows, architectural requirements, project plans, project compliance assessments, etc. The TOGAF Architecture Content Framework (see Part IV, 33. Introduction) provides a structural model for architectural content that allows major work products to be consistently defined, structured, and presented.

The Architecture Content Framework uses the following three categories to describe the type of architectural work product within the context of use:

  • A deliverable is a work product that is contractually specified and in turn formally reviewed, agreed, and signed off by the stakeholders. Deliverables represent the output of projects and those deliverables that are in documentation form will typically be archived at completion of a project, or transitioned into an Architecture Repository as a reference model, standard, or snapshot of the Architecture Landscape at a point in time.
  • An artifact is an architectural work product that describes an aspect of the architecture. Artifacts are generally classified as catalogs (lists of things), matrices (showing relationships between things), and diagrams (pictures of things). Examples include a requirements catalog, business interaction matrix, and a use-case diagram. An architectural deliverable may contain many artifacts and artifacts will form the content of the Architecture Repository.
  • A building block represents a (potentially re-usable) component of business, IT, or architectural capability that can be combined with other building blocks to deliver architectures and solutions.

    Building blocks can be defined at various levels of detail, depending on what stage of architecture development has been reached. For instance, at an early stage, a building block can simply consist of a name or an outline description. Later on, a building block may be decomposed into multiple supporting building blocks and may be accompanied by a full specification. Building blocks can relate to "architectures" or "solutions".

    • Architecture Building Blocks (ABBs) typically describe required capability and shape the specification of Solution Building Blocks (SBBs). For example, a customer services capability may be required within an enterprise, supported by many SBBs, such as processes, data, and application software.
    • Solution Building Blocks (SBBs) represent components that will be used to implement the required capability. For example, a network is a building block that can be described through complementary artifacts and then put to use to realize solutions for the enterprise.

The relationships between deliverables, artifacts, and building blocks are shown in Figure 2-1.


  Figure 2-1: Relationships between Deliverables, Artifacts, and Building Blocks

For example, an Architecture Definition Document is a deliverable that documents an architecture description. This document will contain a number of complementary artifacts that are views of the building blocks relevant to the architecture. For example, a process flow diagram (an artifact) may be created to describe the target call handling process (a building block). This artifact may also describe other building blocks, such as the actors involved in the process (e.g., a Customer Services Representative). An example of the relationships between deliverables, artifacts, and building blocks is illustrated in Figure 2-2.


  Figure 2-2: Example - Architecture Definition Document

 

 2.6 Enterprise Continuum

TOGAF includes the concept of the Enterprise Continuum, which sets the broader context for an architect and explains how generic solutions can be leveraged and specialized in order to support the requirements of an individual organization. The Enterprise Continuum is a view of the Architecture Repository that provides methods for classifying architecture and solution artifacts as they evolve from generic Foundation Architectures to Organization-Specific Architectures. The Enterprise Continuum comprises two complementary concepts: the Architecture Continuum and the Solutions Continuum.

An overview of the structure and context for the Enterprise Continuum is shown in Figure 2-3.


  Figure 2-3: Enterprise Continuum

 

 2.7 Architecture Repository

Supporting the Enterprise Continuum is the concept of an Architecture Repository which can be used to store different classes of architectural output at different levels of abstraction, created by the ADM. In this way, TOGAF facilitates understanding and co-operation between stakeholders and practitioners at different levels.

By means of the Enterprise Continuum and Architecture Repository, architects are encouraged to leverage all other relevant architectural resources and assets in developing an Organization-Specific Architecture.

In this context, the TOGAF ADM can be regarded as describing a process lifecycle that operates at multiple levels within the organization, operating within a holistic governance framework and producing aligned outputs that reside in an Architecture Repository. The Enterprise Continuum provides a valuable context for understanding architectural models: it shows building blocks and their relationships to each other, and the constraints and requirements on a cycle of architecture development.

The structure of the TOGAF Architecture Repository is shown in Figure 2-4.


  Figure 2-4: TOGAF Architecture Repository Structure

The major components within an Architecture Repository are as follows:

  • The Architecture Metamodel describes the organizationally tailored application of an architecture framework, including a metamodel for architecture content.
  • The Architecture Capability defines the parameters, structures, and processes that support governance of the Architecture Repository.
  • The Architecture Landscape is the architectural representation of assets deployed within the operating enterprise at a particular point in time. The landscape is likely to exist at multiple levels of abstraction to suit different architecture objectives.
  • The Standards Information Base (SIB) captures the standards with which new architectures must comply, which may include industry standards, selected products and services from suppliers, or shared services already deployed within the organization.
  • The Reference Library provides guidelines, templates, patterns, and other forms of reference material that can be leveraged in order to accelerate the creation of new architectures for the enterprise.
  • The Governance Log provides a record of governance activity across the enterprise.

 

 2.8 Establishing and Maintaining an Enterprise Architecture Capability

In order to carry out architectural activity effectively within an enterprise, it is necessary to put in place an appropriate business capability for architecture, through organization structures, roles, responsibilities, skills, and processes. An overview of the TOGAF Architecture Capability is shown in Figure 2-5.


  Figure 2-5: TOGAF Architecture Capability Overview

 

 2.9 Establishing the Architecture Capability as an Operational Entity

Barring architecture capabilities set up to purely support change delivery programs, it is increasingly recognized that a successful enterprise architecture practice must sit on a firm operational footing. In effect, an enterprise architecture practice must be run like any other operational unit within a business; i.e., it should be treated like a business. To this end, and over and above the core processes defined within the ADM, an enterprise architecture practice should establish capabilities in the following areas:

Central to the notion of operating an ongoing architecture is the execution of well-defined and effective governance, whereby all architecturally significant activity is controlled and aligned within a single framework.

As governance has become an increasingly visible requirement for organizational management, the inclusion of governance within TOGAF aligns the framework with current business best practice and also ensures a level of visibility, guidance, and control that will support all architecture stakeholder requirements and obligations.

The benefits of architecture governance include:

  • Increased transparency of accountability, and informed delegation of authority
  • Controlled risk management
  • Protection of the existing asset base through maximizing re-use of existing architectural components
  • Proactive control, monitoring, and management mechanisms
  • Process, concept, and component re-use across all organizational business units
  • Value creation through monitoring, measuring, evaluation, and feedback
  • Increased visibility supporting internal processes and external parties' requirements; in particular, increased visibility of decision-making at lower levels ensures oversight at an appropriate level within the enterprise of decisions that may have far-reaching strategic consequences for the organization
  • Greater shareholder value; in particular, enterprise architecture increasingly represents the core intellectual property of the enterprise - studies have demonstrated a correlation between increased shareholder value and well-governed enterprises
  • Integrates with existing processes and methodologies and complements functionality by adding control capabilities

Further detail on establishing an enterprise Architecture Capability is given in Part VII, 45. Introduction.

 2.10 Using TOGAF with Other Frameworks

Two of the key elements of any enterprise architecture framework are:

  • A definition of the deliverables that the architecting activity should produce
  • A description of the method by which this should be done

With some exceptions, the majority of enterprise architecture frameworks focus on the first of these - the specific set of deliverables - and are relatively silent about the methods to be used to generate them (intentionally so, in some cases).

Because TOGAF is a generic framework and intended to be used in a wide variety of environments, it provides a flexible and extensible content framework that underpins a set of generic architecture deliverables.

As a result, TOGAF may be used either in its own right, with the generic deliverables that it describes; or else these deliverables may be replaced or extended by a more specific set, defined in any other framework that the architect considers relevant.

In all cases, it is expected that the architect will adapt and build on the TOGAF framework in order to define a tailored method that is integrated into the processes and organization structures of the enterprise. This architecture tailoring may include adopting elements from other architecture frameworks, or integrating TOGAF methods with other standard frameworks, such as ITIL, CMMI, COBIT, PRINCE2, PMBOK, and MSP. Guidelines for adapting the TOGAF ADM in such a way are given in Part II, 5.3 Adapting the ADM.

As a generic framework and method for enterprise architecture, TOGAF provides the capability and the collaborative environment to integrate with other frameworks. Organizations are able to fully utilize vertical business domains, horizontal technology areas (such as security or manageability), or application areas (such as e-Commerce) to produce a competitive enterprise architecture framework which maximizes their business opportunities.
return to top of page


Definitions

URL de origem: http://pubs.opengroup.org/architecture/togaf9-doc/arch/chap03.html

3.1 Abstraction

The technique of providing summarized or generalized descriptions of detailed and complex content.

Abstraction, as in "level of abstraction", can also mean providing a focus for analysis that is concerned with a consistent and common level of detail or abstraction. Abstraction in this sense is typically used in architecture to allow a consistent level of definition and understanding to be achieved in each area of the architecture in order to support effective communication and decision-making. It is especially useful when dealing with large and complex architectures as it allows relevant issues to be identified before further detail is attempted.

 3.2 Actor

A person, organization, or system that has a role that initiates or interacts with activities; for example, a sales representative who travels to visit customers. Actors may be internal or external to an organization. In the automotive industry, an original equipment manufacturer would be considered an actor by an automotive dealership that interacts with its supply chain activities.

 3.3 Application

A deployed and operational IT system that supports business functions and services; for example, a payroll. Applications use data and are supported by multiple technology components but are distinct from the technology components that support the application.

 3.4 Application Architecture

A description of the structure and interaction of the applications as groups of capabilities that provide key business functions and manage the data assets.

Note:
Application Architecture is described in Part II, 11. Phase C: Information Systems Architectures - Application Architecture.

 3.5 Application Platform

The collection of technology components of hardware and software that provide the services used to support applications.

 3.6 Application Platform Interface (API)

The interface, or set of functions, between application software and/or the application platform.

 3.7 Architectural Style

The combination of distinctive features in which architecture is performed or expressed.

 3.8 Architecture

  1. A formal description of a system, or a detailed plan of the system at component level, to guide its implementation (source: ISO/IEC 42010:2007).
  2. The structure of components, their inter-relationships, and the principles and guidelines governing their design and evolution over time.

 3.9 Architecture Building Block (ABB)

A constituent of the architecture model that describes a single aspect of the overall model.

See also 3.21 Building Block.

 3.10 Architecture Continuum

A part of the Enterprise Continuum. A repository of architectural elements with increasing detail and specialization. This Continuum begins with foundational definitions like reference models, core strategies, and basic building blocks. From there it spans to Industry Architectures and all the way to an organization's specific architecture.

See also 3.35 Enterprise Continuum.

 3.11 Architecture Development Method (ADM)

The core of TOGAF. A step-by-step approach to develop and use an enterprise architecture.

Note:
The ADM is described in Part II: Architecture Development Method (ADM).

 3.12 Architecture Domain

The architectural area being considered. There are four architecture domains within TOGAF: business, data, application, and technology.

 3.13 Architecture Framework

A conceptual structure used to develop, implement, and sustain an architecture.

 3.14 Architecture Governance

The practice and orientation by which enterprise architectures and other architectures are managed and controlled at an enterprise-wide level. It is concerned with change processes (design governance) and operation of product systems (operational governance).

See also 3.39 Governance.

 3.15 Architecture Landscape

The architectural representation of assets in use, or planned, by the enterprise at particular points in time.

 3.16 Architecture Principles

A qualitative statement of intent that should be met by the architecture. Has at least a supporting rationale and a measure of importance.

Note:
A sample set of Architecture Principles is defined in Part III, 23. Architecture Principles.

 3.17 Architecture Vision

A succinct description of the Target Architecture that describes its business value and the changes to the enterprise that will result from its successful deployment. It serves as an aspirational vision and a boundary for detailed architecture development.
Note:
Phase A (Architecture Vision) is described in Part II, 7. Phase A: Architecture Vision.

 3.18 Artifact

An architectural work product that describes an aspect of the architecture.

See also 3.21 Building Block.

 3.19 Baseline

A specification that has been formally reviewed and agreed upon, that thereafter serves as the basis for further development or change and that can be changed only through formal change control procedures or a type of procedure such as configuration management.

 3.20 Boundaryless Information Flow

  1. A trademark of The Open Group.
  2. A shorthand representation of "access to integrated information to support business process improvements" representing a desired state of an enterprise's infrastructure specific to the business needs of the organization.

An infrastructure that provides Boundaryless Information Flow has open standard components that provide services in a customer's extended enterprise that:

  • Combine multiple sources of information
  • Securely deliver the information whenever and wherever it is needed, in the right context for the people or systems using that information.
Note:
The need for Boundaryless Information Flow is described in Part VI, 44. Integrated Information Infrastructure Reference Model.

 3.21 Building Block

Represents a (potentially re-usable) component of business, IT, or architectural capability that can be combined with other building blocks to deliver architectures and solutions.

Building blocks can be defined at various levels of detail, depending on what stage of architecture development has been reached. For instance, at an early stage, a building block can simply consist of a name or an outline description. Later on, a building block may be decomposed into multiple supporting building blocks and may be accompanied by a full specification. Building blocks can relate to "architectures" or "solutions".

See also 3.18 Artifact.

Note:
Building blocks are described in Part IV, 37. Building Blocks.

 3.22 Business Architecture

A description of the structure and interaction between the business strategy, organization, functions, business processes, and information needs.

Note:
Business Architecture is described in Part II, 8. Phase B: Business Architecture.

 3.23 Business Function

Delivers business capabilities closely aligned to an organization, but not necessarily explicitly governed by the organization.

 3.24 Business Governance

Concerned with ensuring that the business processes and policies (and their operation) deliver the business outcomes and adhere to relevant business regulation.

 3.25 Business Service

Supports business capabilities through an explicitly defined interface and is explicitly governed by an organization.

 3.26 Capability

An ability that an organization, person, or system possesses. Capabilities are typically expressed in general and high-level terms and typically require a combination of organization, people, processes, and technology to achieve. For example, marketing, customer contact, or outbound telemarketing.

 3.27 Capability Architecture

A highly detailed description of the architectural approach to realize a particular solution or solution aspect.

 3.28 Capability Increment

A discrete portion of a capability architecture that delivers specific value. When all increments have been completed, the capability has been realized.

 3.29 Communications and Stakeholder Management

The management of needs of stakeholders of the enterprise architecture practice. It also manages the execution of communication between the practice and the stakeholders and the practice and the consumers of its services.

Note:
Architecture stakeholder management is described in 24. Stakeholder Management.

 3.30 Concerns

The key interests that are crucially important to the stakeholders in a system, and determine the acceptability of the system. Concerns may pertain to any aspect of the system's functioning, development, or operation, including considerations such as performance, reliability, security, distribution, and evolvability.

See also 3.68 Stakeholder.

 3.31 Constraint

An external factor that prevents an organization from pursuing particular approaches to meet its goals. For example, customer data is not harmonized within the organization, regionally or nationally, constraining the organization's ability to offer effective customer service.

 3.32 Data Architecture

A description of the structure and interaction of the enterprise's major types and sources of data, logical data assets, physical data assets, and data management resources.

Note:
Data Architecture is described in Part II, 10. Phase C: Information Systems Architectures - Data Architecture.

 3.33 Deliverable

An architectural work product that is contractually specified and in turn formally reviewed, agreed, and signed off by the stakeholders. Deliverables represent the output of projects and those deliverables that are in documentation form will typically be archived at completion of a project, or transitioned into an Architecture Repository as a reference model, standard, or snapshot of the Architecture Landscape at a point in time.

 3.34 Enterprise

The highest level (typically) of description of an organization and typically covers all missions and functions. An enterprise will often span multiple organizations.

 3.35 Enterprise Continuum

A categorization mechanism useful for classifying architecture and solution artifacts, both internal and external to the Architecture Repository, as they evolve from generic Foundation Architectures to Organization-Specific Architectures.

See also 3.10 Architecture Continuum and 3.67 Solutions Continuum.

 3.36 Foundation Architecture

Generic building blocks, their inter-relationships with other building blocks, combined with the principles and guidelines that provide a foundation on which more specific architectures can be built.

 3.37 Framework

A structure for content or process that can be used as a tool to structure thinking, ensuring consistency and completeness.

 3.38 Gap

A statement of difference between two states. Used in the context of gap analysis, where the difference between the Baseline and Target Architecture is identified.

Note:
Gap analysis is described in Part III, 27. Gap Analysis.

 3.39 Governance

The discipline of monitoring, managing, and steering a business (or IS/IT landscape) to deliver the business outcome required.

See also 3.14 Architecture Governance, 3.24 Business Governance, and A.60 Operational Governance in A. Glossary of Supplementary Definitions.

 3.40 Information

Any communication or representation of facts, data, or opinions, in any medium or form, including textual, numerical, graphic, cartographic, narrative, or audio-visual forms.

 3.41 Information Technology (IT)

  1. The lifecycle management of information and related technology used by an organization.
  2. An umbrella term that includes all or some of the subject areas relating to the computer industry, such as Business Continuity, Business IT Interface, Business Process Modeling and Management, Communication, Compliance and Legislation, Computers, Content Management, Hardware, Information Management, Internet, Offshoring, Networking, Programming and Software, Professional Issues, Project Management, Security, Standards, Storage, Voice and Data Communications. Various countries and industries employ other umbrella terms to describe this same collection.
  3. A term commonly assigned to a department within an organization tasked with provisioning some or all of the domains described in (2) above.
  4. Alternate names commonly adopted include Information Services, Information Management, et al.

 3.42 Interoperability

  1. The ability to share information and services.
  2. The ability of two or more systems or components to exchange and use information.
  3. The ability of systems to provide and receive services from other systems and to use the services so interchanged to enable them to operate effectively together.

 3.43 Logical

An implementation-independent definition of the architecture, often grouping related physical entities according to their purpose and structure. For example, the products from multiple infrastructure software vendors can all be logically grouped as Java application server platforms.

 3.44 Metadata

Data about data, of any sort in any media, that describes the characteristics of an entity.

 3.45 Metamodel

A model that describes how and with what the architecture will be described in a structured way.

 3.46 Method

A defined, repeatable approach to address a particular type of problem.

See also 3.47 Methodology.

 3.47 Methodology

A defined, repeatable series of steps to address a particular type of problem, which typically centers on a defined process, but may also include definition of content.

See also 3.46 Method.

 3.48 Model

A representation of a subject of interest. A model provides a smaller scale, simplified, and/or abstract representation of the subject matter. A model is constructed as a "means to an end". In the context of enterprise architecture, the subject matter is a whole or part of the enterprise and the end is the ability to construct "views" that address the concerns of particular stakeholders; i.e., their "viewpoints" in relation to the subject matter.

See also 3.68 Stakeholder, 3.75 View, and 3.76 Viewpoint.

 3.49 Modeling

A technique through construction of models which enables a subject to be represented in a form that enables reasoning, insight, and clarity concerning the essence of the subject matter.

 3.50 Objective

A time-bounded milestone for an organization used to demonstrate progress towards a goal; for example, "Increase Capacity Utilization by 30% by the end of 2009 to support the planned increase in market share".

 3.51 Patterns

A technique for putting building blocks into context; for example, to describe a re-usable solution to a problem. Building blocks are what you use: patterns can tell you how you use them, when, why, and what trade-offs you have to make in doing so.

See also 3.21 Building Block.

 3.52 Performance Management

The monitoring, control, and reporting of the enterprise architecture practice performance. Also concerned with continuous improvement.

 3.53 Physical

A description of a real-world entity. Physical elements in an enterprise architecture may still be considerably abstracted from Solution Architecture, design, or implementation views.

 3.54 Platform

A combination of technology infrastructure products and components that provides that prerequisites to host application software.

 3.55 Platform Service

A technical capability required to provide enabling infrastructure that supports the delivery of applications.

 3.56 Principle

See 3.16 Architecture Principles.

 3.57 Reference Model (RM)

A reference model is an abstract framework for understanding significant relationships among the entities of [an] environment, and for the development of consistent standards or specifications supporting that environment. A reference model is based on a small number of unifying concepts and may be used as a basis for education and explaining standards to a non-specialist. A reference model is not directly tied to any standards, technologies, or other concrete implementation details, but it does seek to provide common semantics that can be used unambiguously across and between different implementations.

Note:
The source of this definition is OASIS; refer to www.oasis-open.org/committees/tc_home.php?wg_abbrev=soa-rm.

 3.58 Repository

A system that manages all of the data of an enterprise, including data and process models and other enterprise information. Hence, the data in a repository is much more extensive than that in a data dictionary, which generally defines only the data making up a database.

 3.59 Requirement

A statement of need that must be met by a particular architecture or work package.

 3.60 Roadmap

An abstracted plan for business or technology change, typically operating across multiple disciplines over multiple years. Normally used in the phrases Technology Roadmap, Architecture Roadmap, etc.

 3.61 Role

  1. The usual or expected function of an actor, or the part somebody or something plays in a particular action or event. An Actor may have a number of roles.
  2. The part an individual plays in an organization and the contribution they make through the application of their skills, knowledge, experience, and abilities.

See also 3.2 Actor.

 3.62 Segment Architecture

A detailed, formal description of areas within an enterprise, used at the program or portfolio level to organize and align change activity.

See also 3.70 Strategic Architecture.

 3.63 Service Orientation

A way of thinking in terms of services and service-based development and the outcomes of services.

See also 3.64 Service Oriented Architecture (SOA).

 3.64 Service Oriented Architecture (SOA)

An architectural style that supports service orientation. It has the following distinctive features:

  • It is based on the design of the services - which mirror real-world business activities - comprising the enterprise (or inter-enterprise) business processes.
  • Service representation utilizes business descriptions to provide context (i.e., business process, goal, rule, policy, service interface, and service component) and implements services using service orchestration.
  • It places unique requirements on the infrastructure - it is recommended that implementations use open standards to realize interoperability and location transparency.
  • Implementations are environment-specific - they are constrained or enabled by context and must be described within that context.
  • It requires strong governance of service representation and implementation.
  • It requires a "Litmus Test", which determines a "good service".

See also 3.7 Architectural Style and 3.63 Service Orientation.

 3.65 Solution Architecture

A description of a discrete and focused business operation or activity and how IS/IT supports that operation. A Solution Architecture typically applies to a single project or project release, assisting in the translation of requirements into a solution vision, high-level business and/or IT system specifications, and a portfolio of implementation tasks.

 3.66 Solution Building Block (SBB)

A candidate solution which conforms to the specification of an Architecture Building Block (ABB).

 3.67 Solutions Continuum

A part of the Enterprise Continuum. A repository of re-usable solutions for future implementation efforts. It contains implementations of the corresponding definitions in the Architecture Continuum.

See also 3.35 Enterprise Continuum and 3.10 Architecture Continuum.

 3.68 Stakeholder

An individual, team, or organization (or classes thereof) with interests in, or concerns relative to, the outcome of the architecture. Different stakeholders with different roles will have different concerns.

See also A.85 System Stakeholder in A. Glossary of Supplementary Definitions.

 3.69 Standards Information Base (SIB)

A database of standards that can be used to define the particular services and other components of an Organization-Specific Architecture.

Note:
The Standards Information Base is described in Part V, 41.4 Standards Information Base.

 3.70 Strategic Architecture

A summary formal description of the enterprise, providing an organizing framework for operational and change activity, and an executive-level, long-term view for direction setting.

 3.71 Target Architecture

The description of a future state of the architecture being developed for an organization. There may be several future states developed as a roadmap to show the evolution of the architecture to a target state.

 3.72 Taxonomy of Architecture Views

The organized collection of all views pertinent to an architecture.

 3.73 Technology Architecture

A description of the structure and interaction of the platform services, and logical and physical technology components.

Note:
Technology Architecture is described in Part II, 12. Phase D: Technology Architecture.

 3.74 Transition Architecture

A formal description of one state of the architecture at an architecturally significant point in time. One or more Transition Architectures may be used to describe the progression in time from the Baseline to the Target Architecture.

Note:
Transition Architecture is described in Part IV, 36.2.3 Architecture Definition Document.

 3.75 View

The representation of a related set of concerns. A view is what is seen from a viewpoint. An architecture view may be represented by a model to demonstrate to stakeholders their areas of interest in the architecture. A view does not have to be visual or graphical in nature.

See also 3.68 Stakeholder and 3.76 Viewpoint.

 3.76 Viewpoint

A definition of the perspective from which a view is taken. It is a specification of the conventions for constructing and using a view (often by means of an appropriate schema or template). A view is what you see; a viewpoint is where you are looking from - the vantage point or perspective that determines what you see.

See also A.56 Metaview in A. Glossary of Supplementary Definitions.

 3.77 Work Package

A set of actions identified to achieve one or more objectives for the business. A work package can be a part of a project, a complete project, or a program.


Release Notes

URL de origem: http://pubs.opengroup.org/architecture/togaf9-doc/arch/chap04.html

4.1 What's New in TOGAF 9?

This section provides an overview of the major new features within TOGAF 9.

 Modular Structure

One focus of TOGAF 9 development has been to ensure that the specification content is structured in a modular way. The modular seven-part structure of TOGAF allows for the concepts in each part to be developed with limited impacts on other parts. Content that was contained within the TOGAF 8.1.1 Resource Base has been classified and moved into parts that have a defined purpose (as opposed to generic "resources").

The modular structure in TOGAF is intended to support greater usability, as each part has a defined purpose and can be read in isolation as a stand-alone set of guidelines. The modular structure is also expected to support incremental adoption of the TOGAF specification. Finally, the modular structure supports more sophisticated release management of the TOGAF specification. In future, individual parts may evolve at different speeds and the current specification structure is intended to allow changes in one area to take place with limited impacts across the specification.

 Content Framework

A significant addition of new content to the TOGAF specification is the content framework. The TOGAF content framework provides a detailed model of architectural work products, including deliverables, artifacts within deliverables, and the architectural building blocks that artifacts represent. The intention of including a content framework within TOGAF is to drive greater consistency in the outputs that are created when following an Architecture Development Method (ADM).

The benefit of including a content framework applies at a number of levels. Firstly, within a single architecture development initiative the content framework provides a comprehensive checklist of architecture outputs that could be created and consequently reduce the risk of gaps within the final architecture deliverable set.

The second major benefit of inclusion of a content framework applies when attempting to integrate architectural work products across an enterprise. The content framework is intended to be adapted and then adopted by an enterprise in order to mandate standard architectural concepts, terms, and deliverables. If all architecture initiatives use the same models for content, their outputs can be combined much more easily than in situations where each architect uses a completely different approach.

Finally, a substantial benefit of the inclusion of a content framework within TOGAF is that it provides (for the first time) a detailed open standard for how architectures should be described. The existence of this standard allows tools vendors, product vendors, and service vendors to adopt consistent ways of working, which in turn will result in greater consistency between architecture tools, better tool interoperability, more consistent reference architectures, and better comparability between related reference architectures.

 Extended Guidance on Adopting TOGAF within an Enterprise

Within larger organizations, the practice of enterprise architecture requires a number of individuals and teams that work together on many architectures. Although each architecture will address a specific problem, in an ideal situation architectures can be considered as a group in order to develop an overall integrated view of how the enterprise is changing.

This version of TOGAF features an extended set of concepts and guidelines to support the establishment of an integrated hierarchy of architectures being developed by teams that operate within an overarching architectural governance model. In particular, the following concepts are introduced:

  • Partitioning: In order to develop architectures that have manageable levels of cost and complexity, it is necessary to partition the enterprise into specific architectures. TOGAF discusses the concept of partitioning and provides a variety of techniques and considerations on how to partition the various architectures within an enterprise.
  • Architecture Repository: TOGAF provides a logical information model for an Architecture Repository, which can be used as an integrated store for all outputs created by executing the ADM.
  • Capability Framework: This version of TOGAF provides a more structured definition of the organization, skills, roles, and responsibilities required to operate an effective enterprise Architecture Capability. The new TOGAF materials also provide guidance on a process that can be followed to identify and establish an appropriate Architecture Capability.
 Explicit Consideration of Architectural Styles, Including SOA and Security Architecture

The new Part III: ADM Guidelines and Techniques brings together a set of supporting materials that show in more detail how the ADM can be applied to specific situations. The new guidelines discuss:

  • The varying uses of iteration that are possible within the ADM and when each technique should be applied
  • The linkages between the TOGAF ADM and Service Oriented Architecture (SOA)
  • The specific considerations required to address security architecture within the ADM
  • The various types of architecture development required within an enterprise and how these relate to one another
 Additional ADM Detail

This version of the TOGAF specification includes more detailed information supporting the execution of the ADM. Particular areas of enhancement are:

  • The Preliminary Phase, which features extended guidance on establishing an enterprise architecture framework and planning for architecture development. The extended Preliminary Phase also provides pointers to the definition of a governance model for architecture benefit realization and also discusses the linkage between TOGAF and other management frameworks.
  • The Opportunities & Solutions phase and Migration Planning phase, which feature a more detailed and robust method for defining and planning enterprise transformation, based on the principles of capability-based planning.

 4.1.1 Changes Applied in this Edition

This edition of TOGAF 9 includes a set of maintenance updates based on feedback received on the 2009 publication. A separate detailed document of the changes is available as TOGAF 9 Technical Corrigendum No. 1 (Document U112). A summary list of the changes is included below:

  • Definitions of terms where usage by TOGAF is not distinctive from the common dictionary definition have been removed.
  • The usage of the terms "application" versus "system" have been reviewed and made consistent.
  • The Phase E and F descriptions have been reworked to match the level of detail in other phases.
  • The uses of terminology for Transition Architecture/Roadmap/Implementation Strategy have been clarified and made consistent.
  • The concepts of levels/iterations/partitions have been clarified and made consistent. This includes a reorganization of material in Part III, 19. Applying Iteration to the ADM and 20. Applying the ADM across the Architecture Landscape, and Part V, 40. Architecture Partitioning.
  • The "Objectives" sections of the phases have been reworked to focus on actual objectives rather than techniques or a list of steps.
  • The possible artifacts (viewpoints) for each phase are now listed in the description of that phase, not just in Part IV, 35. Architectural Artifacts.
  • The terms "artifact" versus "viewpoint" have been clarified and made consistent. This includes a restructuring of Part IV, 35. Architectural Artifacts.
  • The SOA chapter (Part III, 22. Using TOGAF to Define & Govern SOAs) has been updated to describe the latest SOA Work Group output.
  • Additional introductory text on architectural styles has been added in Part III, 18. Introduction.
  • Minor changes have been made to the Security Architecture chapter (Part III, 21. Security Architecture and the ADM) for consistency with the ADM.
  • Corrections have been made to metamodel diagrams.
  • Corrections have been applied to aspects of the metamodel.
  • The Building Blocks example has been removed.
  • The Document Categorization Model has been removed.
  • Duplicate text in several places has been replaced with an appropriate reference:
  • Some of the artifacts have been renamed to better reflect their usage:
    • System/Data matrix becomes Application/Data matrix
    • Class diagram has been replaced with Conceptual Data diagram and Logical Data diagram
    • System/Organization matrix becomes Application/Organization matrix
    • Role/System matrix becomes Role/Application matrix
    • System/Function matrix becomes Application/Function matrix
    • Process/System Realization diagram becomes Process/Application Realization diagram
    • System Use-Case diagram becomes Application Use-Case diagram
    • System/Technology matrix becomes Application/Technology matrix
  • The description of Architecture Principles now divides them into two types only - Enterprise and Architecture - whereas before they called out IT Principles separately. IT Principles are now seen as just part of Enterprise Principles.
  • The Stakeholder Map included in the Stakeholder Management chapter (Part III, 24. Stakeholder Management) is now explicitly referred to as an example, the table has been highlighted to refer to Stakeholder Concerns, and the list of artifacts for each stakeholder updated.
  • The Business Scenarios chapter (Part III, 26. Business Scenarios and Business Goals) has been renamed to Business Scenarios and Business Goals to better reflect the contents of the chapter.
  • The relationship of the Enterprise Repository to the Architecture Repository is clarified in Part V, 41. Architecture Repository.
  • The Evaluation Criteria and Guidelines have been removed from Part V, 42. Tools for Architecture Development.
  • The chapter on Architecture Maturity Models (Part VII, 51. Architecture Maturity Models) has been editorially revised for consistency and clarity.

 4.2 The Benefits of TOGAF 9

TOGAF 9 provides a wide-ranging set of revisions to the TOGAF specification. When combined, these edits seek to achieve a set of objectives to improve the value of the TOGAF framework.

 Greater Usability

A number of enhancements within TOGAF 9 support greater usability of the overall specification. Firstly, the modular structure of the specification makes it easier for an architect to consider a specific aspect of the Architecture Capability. In all areas, the specification seeks to add detail and clarity above and beyond previous TOGAF versions.

 More Focus on Holistic Enterprise Change

TOGAF has a solid history in IT architecture, considering the ways in which IT can support enterprise change. However, as TOGAF has grown in depth and maturity it has become a framework for managing the entire spectrum of change required to transform an enterprise towards a target operating model. TOGAF 9 continues this evolution and incorporates a broader perspective of change that allows enterprise architecture to be used to specify transformation across the business, data, application, and technology domains.

 More Consistency of Output

Previous versions of TOGAF focused on providing a consistent process for developing architectures. TOGAF 9 includes a greatly enhanced consideration of architectural work products to ensure that a consistent process is used to produce consistent outputs. The Architecture Content Framework provides a detailed model of the outputs to be created by the ADM. Additionally, the Enterprise Continuum, Architecture Partitioning, and Architecture Repository sections provide detailed guidance on how architectural deliverables can be scoped, governed, and integrated.

 4.3 Mapping of the TOGAF 8.1.1 Structure to TOGAF 9

Listed below are the Parts of the TOGAF 8 specification. For each Part, a description is given to explain where the TOGAF 8 content can be found within the current specification.

 Part I: Introduction

The Introduction part of the TOGAF 8.1.1 specification has been used as the basis for creation of Part I: Introduction in TOGAF 9. The introduction to TOGAF 9 reflects the content of TOGAF 9 rather than the content of TOGAF 8.1.1, and also features a number of enhancements to improve accessibility.

 Part II: Architecture Development Method

The essence of the TOGAF 8.1.1 ADM has been retained in TOGAF 9. Part II: Architecture Development Method (ADM) within TOGAF 9 is structured along similar lines to Part II of the TOGAF 8.1.1 document. TOGAF ADM phase inputs and outputs (Chapter 16 of TOGAF 8.1.1) have been moved from the ADM section of TOGAF 8.1.1 to Part IV: Architecture Content Framework of TOGAF 9.

TOGAF 9 ADM features additional content in the majority of ADM phases, which in the most part adds further detail and clarification to the same approach that was described in TOGAF 8.1.1.

 Part III: Enterprise Continuum

The TOGAF 8.1.1 Enterprise Continuum has seen a substantial degree of change. The Enterprise Continuum concept is retained within Part V: Enterprise Continuum & Tools. The TOGAF Technical Reference Model and Integrated Information Infrastructure Reference Model are extracted and placed within Part VI: TOGAF Reference Models in TOGAF 9.

TOGAF 9 adds new materials that describe an approach to architecture partitioning and also provides a structured model of an Architecture Repository. These concepts support and elaborate on the original intent of the Enterprise Continuum.

TOGAF 9 removes the Standards Information Base from the TOGAF specification. However, an example SIB remains at The Open Group web site (www.opengroup.org). The concept of a Standards Information Base is important within TOGAF, but the breadth and speed of change of relevant architectural standards mean that it is impractical to maintain a current and relevant collection of standards within a specification such as TOGAF.

 Part IV: Resource Base

The Resource Base is not included in this version of TOGAF. Some elements of the Resource Base have been deprecated from the TOGAF specification, but will still be available in White Paper form. Other elements of the Resource Base have been moved to other areas of the specification.

The following table illustrates where TOGAF 8.1.1 Resource Base content can now be located.


TOGAF 8.1.1 Resource

Current Location

Architecture Board

Moved to Part VII: Architecture Capability Framework

Architecture Compliance

Moved to Part VII: Architecture Capability Framework

Architecture Contracts

Moved to Part VII: Architecture Capability Framework

Architecture Governance

Moved to Part VII: Architecture Capability Framework

Architecture Maturity Models

Moved to Part VII: Architecture Capability Framework

Architecture Patterns

Moved to Part III: ADM Guidelines and Techniques

Architecture Principles

Moved to Part III: ADM Guidelines and Techniques

Architecture Skills Framework

Moved to Part VII: Architecture Capability Framework

Developing Architecture Views

Elements retained within Part IV: Architecture Content Framework

Building Blocks

Elements retained within Part IV: Architecture Content Framework

Business Process Domain Views

Elements retained within Part IV: Architecture Content Framework

Business Scenarios

Moved to Part III: ADM Guidelines and Techniques

Case Studies

Removed. Case Studies will be available on The Open Group web site.

Glossary

Moved to Part I: Introduction

Other Architectures & Frameworks

Removed. This material will be available on The Open Group web site as a White Paper.

Tools for Architecture Development

Moved to Part V: Enterprise Continuum & Tools

ADM and the Zachman Framework

Removed. This material will be available on The Open Group web site as a White Paper.

 4.4 Mapping of TOGAF 9 Structure to TOGAF 8.1.1

The following table illustrates where TOGAF 9 chapters map to those of TOGAF 8.1.1:


TOGAF 9 Chapter

Derivation from TOGAF 8.1.1

 

Part I: Introduction

 

1

Introduction

Material revised; based on Chapter 1

2

Core Concepts

New chapter

3

Definitions

Material derived from Chapter 36, reworked into formal definitions and abbreviations sections

4

Release Notes

New chapter

 

Part II: Architecture Development Method

 

5

Introduction

Material revised; based on Chapter 3

6

Preliminary Phase

Material revised; based on Chapter 4

7

Phase A: Architecture Vision

Material revised; based on Chapter 5

8

Phase B: Business Architecture

Material revised; based on Chapter 6

9

Phase C: Information Systems Architectures

Material revised; based on Chapter 7

10

Phase C: Data Architecture

Material revised; based on Chapter 8

11

Phase C: Application Architecture

Material revised; based on Chapter 9

12

Phase D: Technology Architecture

Material revised; based on Chapter 10

13

Phase E: Opportunities & Solutions

Material revised; based on Chapter 11

14

Phase F: Migration Planning

Material revised; based on Chapter 12

15

Phase G: Implementation Governance

Material revised; based on Chapter 13

16

Phase H: Architecture Change Management

Material revised; based on Chapter 14

17

ADM Architecture Requirements Management

No material change; maps to Chapter 15

 

Part III: ADM Guidelines and Techniques

 

18

Introduction

New chapter

19

Applying the ADM across the Architecture Landscape

New chapter

20

Applying the ADM at Different Enterprise Levels

New chapter

21

Security Architecture and the ADM

New chapter; derived from Security White Paper (W055)

22

Using TOGAF to Define & Govern SOAs

New chapter

23

Architecture Principles

No material change; maps to Chapter 29

24

Stakeholder Management

New chapter

25

Architecture Patterns

No material change; maps to Chapter 28

26

Business Scenarios

No material change; maps to Chapter 34

27

Gap Analysis

New chapter; derived from Gap Analysis

28

Migration Planning Techniques

New chapter

29

Interoperability Requirements

New chapter

30

Business Transformation Readiness Assessment

New chapter

31

Risk Management

New chapter

32

Capability-Based Planning

New chapter

 

Part IV: Architecture Content Framework

 

33

Introduction

New chapter

34

Content Metamodel

New chapter

35

Architectural Artifacts

Derived from Chapter 31, plus new material

36

Architecture Deliverables

Revised; was Chapter 16

37

Building Blocks

Revised from Chapter 32

 

Part V: Enterprise Continuum & Tools

 

38

Introduction

New chapter

39

Enterprise Continuum

Derived from Chapters 17 and 18 with substantial revisions

40

Architecture Partitioning

New chapter

41

Architecture Repository

New chapter

42

Tools for Architecture Development

Derived from Chapter 38, with the evaluation guidelines removed.

 

Part VI: TOGAF Reference Models

 

43

Foundation Architecture: Technical
Reference Model

No material change; maps to Chapters 19 and 20

44

Integrated Information Infrastructure
Reference Model

No material change; maps to Chapter 22

 

Part VII: Architecture Capability Framework

 

45

Introduction

New chapter

46

Establishing an Architecture Capability

New chapter

47

Architecture Board

Minimal change; maps to Chapter 23

48

Architecture Compliance

Minimal change; maps to Chapter 24

49

Architecture Contracts

Minimal change; maps to Chapter 25

50

Architecture Governance

Minimal change, maps to Chapter 26

51

Architecture Maturity Models

Minimal change; maps to Chapter 27

52

Architecture Skills Framework

Some cosmetic changes; maps to Chapter 30

A

Glossary of Supplementary Definitions

Derived from Chapter 36

B

Abbreviations

Derived from Chapter 36

 4.5 Using TOGAF

 4.5.1 Conditions of Use

The TOGAF documentation is freely available for viewing online without a license. Alternatively, the complete TOGAF documentation set may be downloaded and stored under license, as explained on the TOGAF information web site.

In either case, the TOGAF documentation may be used freely by any organization wishing to do so to develop an architecture for use within that organization. No part of it may be reproduced, stored in a retrieval system, or transmitted, in any form or by any means, electronic, mechanical, photocopying, recording, or otherwise, for any other purpose including, but not by way of limitation, any use for commercial gain, without the prior permission of the copyright owners.

 4.5.2 How Much Does TOGAF Cost?

The Open Group operates as a not-for-profit consortium committed to delivering greater business efficiency by bringing together buyers and suppliers of information systems to lower the barriers of integrating new technology across the enterprise. Its goal is to realize the vision of Boundaryless Information Flow.

TOGAF is a key part of its strategy for achieving this goal, and The Open Group wants TOGAF to be taken up and used in practical architecture projects, and the experience from its use fed back to help improve it.

The Open Group therefore publishes TOGAF on its public web server, and allows and encourages its reproduction and use free-of-charge by any organization wishing to use it internally to develop an enterprise architecture. (There are restrictions on its commercial exploitation, however; see 4.5.1 Conditions of Use.)

 4.5.3 Downloads

Downloads of the TOGAF documentation, including a printable PDF file, are available under license from the TOGAF information web site (refer to www.opengroup.org/architecture/togaf). The license is free to any organization wishing to use TOGAF entirely for internal purposes (for example, to develop an enterprise architecture for use within that organization).

 4.6 Why Join The Open Group?

Organizations wishing to reduce the time, cost, and risk of implementing multi-vendor solutions that integrate within and between enterprises need The Open Group as their key partner.

The Open Group brings together the buyers and suppliers of information systems worldwide, and enables them to work together, both to ensure that IT solutions meet the needs of customers, and to make it easier to integrate IT across the enterprise. TOGAF is a key enabler in this task.

Yes, TOGAF itself is freely available. But how much will you spend on developing or updating your enterprise architecture using TOGAF? And how much will you spend on procurements based on that architecture? The price of membership of The Open Group is insignificant in comparison with these amounts.

In addition to the general benefits of membership, as a member of The Open Group you will be eligible to participate in The Open Group Architecture Forum, which is the development program within which TOGAF is evolved, and in which TOGAF users come together to exchange information and feedback.

Members of the Architecture Forum gain:

  • Immediate access to the fruits of the current TOGAF work program (not publicly available until publication of the next edition of the TOGAF document) - in effect, the latest information on TOGAF
  • Exchange of experience with other customer and vendor organizations involved in enterprise architecture in general, and networking with architects using TOGAF in significant architecture development projects around the world
  • Peer review of specific architecture case study material

Introduction

URL de origem: http://pubs.opengroup.org/architecture/togaf9-doc/arch/chap05.html

5.1 ADM Overview

The TOGAF ADM is the result of continuous contributions from a large number of architecture practitioners. It describes a method for developing and managing the lifecycle of an enterprise architecture, and forms the core of TOGAF. It integrates elements of TOGAF described in this document as well as other available architectural assets, to meet the business and IT needs of an organization.

 5.1.1 The ADM, Enterprise Continuum, and Architecture Repository

The Enterprise Continuum provides a framework and context to support the leverage of relevant architecture assets in executing the ADM. These assets may include architecture descriptions, models, and patterns taken from a variety of sources, as explained in Part V: Enterprise Continuum & Tools.

The Enterprise Continuum categorizes architectural source material - both the contents of the organization's own enterprise repositories and the set of relevant, available reference models and standards in the industry.

The practical implementation of the Enterprise Continuum will typically take the form of an Architecture Repository (see Part V, 41. Architecture Repository) that includes reference architectures, models, and patterns that have been accepted for use within the enterprise, and actual architectural work done previously within the enterprise. The architect would seek to re-use as much as possible from the Architecture Repository that was relevant to the project at hand. (In addition to the collection of architecture source material, the repository would also contain architecture development work-in-progress.)

At relevant places throughout the ADM, there are reminders to consider which, if any, architecture assets from the Architecture Repository the architect should use. In some cases - for example, in the development of a Technology Architecture - this may be the TOGAF Foundation Architecture (see Part VI: TOGAF Reference Models). In other cases - for example, in the development of a Business Architecture - it may be a reference model for e-Commerce taken from the industry at large.

The criteria for including source materials in an organization's Architecture Repository will typically form part of the enterprise architecture governance process. These governance processes should consider available resources both within and outside the enterprise in order to determine when general resources can be adapted for specific enterprise needs and also to determine where specific solutions can be generalized to support wider re-use.

While using the ADM, the architect is developing a snapshot of the enterprise's decisions and their implications at particular points in time. Each iteration of the ADM will populate an organization-specific landscape with all the architecture assets identified and leveraged through the process, including the final organization-specific architecture delivered.

Architecture development is a continuous, cyclical process, and in executing the ADM repeatedly over time, the architect gradually adds more and more content to the organization's Architecture Repository. Although the primary focus of the ADM is on the development of the enterprise-specific architecture, in this wider context the ADM can also be viewed as the process of populating the enterprise's own Architecture Repository with relevant re-usable building blocks taken from the "left", more generic side of the Enterprise Continuum.

In fact, the first execution of the ADM will often be the hardest, since the architecture assets available for re-use will be relatively scarce. Even at this stage of development, however, there will be architecture assets available from external sources such as TOGAF, as well as the IT industry at large, that could be leveraged in support of the effort.

Subsequent executions will be easier, as more and more architecture assets become identified, are used to populate the organization's Architecture Repository, and are thus available for future re-use.

 5.1.2 The ADM and the Foundation Architecture

The ADM is also useful to populate the Foundation Architecture of an enterprise. Business requirements of an enterprise may be used to identify the necessary definitions and selections in the Foundation Architecture. This could be a set of re-usable common models, policy and governance definitions, or even as specific as overriding technology selections (e.g., if mandated by law). Population of the Foundation Architecture follows similar principles as for an enterprise architecture, with the difference that requirements for a whole enterprise are restricted to the overall concerns and thus less complete than for a specific enterprise.

It is important to recognize that existing models from these various sources, when integrated, may not necessarily result in a coherent enterprise architecture. "Integratability" of architecture descriptions is considered in 5.6 Architecture Integration.

 5.1.3 ADM and Supporting Guidelines and Techniques

Part III: ADM Guidelines and Techniques is a set of resources - guidelines, templates, checklists, and other detailed materials - that support application of the TOGAF ADM.

The individual guidelines and techniques are described separately in Part III: ADM Guidelines and Techniques so that they can be referenced from the relevant points in the ADM as necessary, rather than having the detailed text clutter the description of the ADM itself.

 5.2 Architecture Development Cycle

 5.2.1 Key Points

The following are the key points about the ADM:

  • The ADM is iterative, over the whole process, between phases, and within phases (see Part III, 19. Applying Iteration to the ADM). For each iteration of the ADM, a fresh decision must be taken as to:
    • The breadth of coverage of the enterprise to be defined
    • The level of detail to be defined
    • The extent of the time period aimed at, including the number and extent of any intermediate time periods
    • The architectural assets to be leveraged, including:
      • Assets created in previous iterations of the ADM cycle within the enterprise
      • Assets available elsewhere in the industry (other frameworks, systems models, vertical industry models, etc.)
  • These decisions should be based on a practical assessment of resource and competence availability, and the value that can realistically be expected to accrue to the enterprise from the chosen scope of the architecture work.
  • As a generic method, the ADM is intended to be used by enterprises in a wide variety of different geographies and applied in different vertical sectors/industry types. As such, it may be, but does not necessarily have to be, tailored to specific needs. For example, it may be used in conjunction with the set of deliverables of another framework, where these have been deemed to be more appropriate for a specific organization. (For example, many US federal agencies have developed individual frameworks that define the deliverables specific to their particular departmental needs.)

These issues are considered in detail in 5.3 Adapting the ADM.

 5.2.2 Basic Structure

The basic structure of the ADM is shown in Figure 5-1.

Throughout the ADM cycle, there needs to be frequent validation of results against the original expectations, both those for the whole ADM cycle, and those for the particular phase of the process.

Requirements Management  Phase H  Phase G  Phase F  Phase E  Phase D  Phase C  Phase B  Phase A  Preliminary Phase 
  Figure 5-1: Architecture Development Cycle

The phases of the ADM cycle are further divided into steps; for example, the steps within the architecture development phases (B, C, D) are as follows:

  • Select reference models, viewpoints, and tools
  • Develop Baseline Architecture Description
  • Develop Target Architecture Description
  • Perform gap analysis
  • Define candidate roadmap components
  • Resolve impacts across the Architecture Landscape
  • Conduct formal stakeholder review
  • Finalize the Architecture
  • Create Architecture Definition Document

The Requirements Management phase is a continuous phase which ensures that any changes to requirements are handled through appropriate governance processes and reflected in all other phases.

An enterprise may choose to record all new requirements, including those which are in scope of the current Statement of Architecture Work through a single Requirements Repository.

The phases of the cycle are described in detail in the following chapters within Part II.

Note that output is generated throughout the process, and that the output in an early phase may be modified in a later phase. The versioning of output is managed through version numbers. In all cases, the ADM numbering scheme is provided as an example. It should be adapted by the architect to meet the requirements of the organization and to work with the architecture tools and repositories employed by the organization.

In particular, a version numbering convention is used within the ADM to illustrate the evolution of Baseline and Target Architecture Definitions. Table 5-1 describes how this convention is used.


Phase

Deliverable

Content

Version

Description

A: Architecture Vision

Architecture
Vision

Business
Architecture

0.1

Version 0.1 indicates that a high-level outline of the architecture is in place.

 

 

Data
Architecture

0.1

Version 0.1 indicates that a high-level outline of the architecture is in place.

 

 

Application
Architecture

0.1

Version 0.1 indicates that a high-level outline of the architecture is in place.

 

 

Technology
Architecture

0.1

Version 0.1 indicates that a high-level outline of the architecture is in place.

B: Business Architecture

Architecture
Definition
Document

Business
Architecture

1.0

Version 1.0 indicates a formally reviewed, detailed architecture.

C: Information Systems
Architecture

Architecture
Definition
Document

Data
Architecture

1.0

Version 1.0 indicates a formally reviewed, detailed architecture.

 

 

Application
Architecture

1.0

Version 1.0 indicates a formally reviewed, detailed architecture.

D: Technology Architecture

Architecture
Definition
Document

Technology
Architecture

1.0

Version 1.0 indicates a formally reviewed, detailed architecture.

Table 5-1: ADM Version Numbering Convention

 5.3 Adapting the ADM

The ADM is a generic method for architecture development, which is designed to deal with most system and organizational requirements. However, it will often be necessary to modify or extend the ADM to suit specific needs. One of the tasks before applying the ADM is to review its components for applicability, and then tailor them as appropriate to the circumstances of the individual enterprise. This activity may well produce an "enterprise-specific" ADM.

One reason for wanting to adapt the ADM, which it is important to stress, is that the order of the phases in the ADM is to some extent dependent on the maturity of the architecture discipline within the enterprise. For example, if the business case for doing architecture at all is not well recognized, then creating an Architecture Vision is almost always essential; and a detailed Business Architecture often needs to come next, in order to underpin the Architecture Vision, detail the business case for remaining architecture work, and secure the active participation of key stakeholders in that work. In other cases a slightly different order may be preferred; for example, a detailed inventory of the baseline environment may be done before undertaking the Business Architecture.

The order of phases may also be defined by the architecture principles and business principles of an enterprise. For example, the business principles may dictate that the enterprise be prepared to adjust its business processes to meet the needs of a packaged solution, so that it can be implemented quickly to enable fast response to market changes. In such a case, the Business Architecture (or at least the completion of it) may well follow completion of the Information Systems Architecture or the Technology Architecture.

Another reason for wanting to adapt the ADM is if TOGAF is to be integrated with another enterprise framework (as explained in Part I, 2.10 Using TOGAF with Other Frameworks). For example, an enterprise may wish to use TOGAF and its generic ADM in conjunction with the well-known Zachman Framework, or another enterprise architecture framework that has a defined set of deliverables specific to a particular vertical sector: Government, Defense, e-Business, Telecommunications, etc. The ADM has been specifically designed with this potential integration in mind.

Other possible reasons for wanting to adapt the ADM include:

  • The ADM is one of the many corporate processes that make up the corporate governance model. It is complementary to, and supportive of, other standard program management processes, such as those for authorization, risk management, business planning and budgeting, development planning, systems development, and procurement.
  • The ADM is being mandated for use by a prime or lead contractor in an outsourcing situation, and needs to be tailored to achieve a suitable compromise between the contractor's existing practices and the contracting enterprise's requirements.
  • The enterprise is a small-to-medium enterprise, and wishes to use a "cut-down" method more attuned to the reduced level of resources and system complexity typical of such an environment.
  • The enterprise is very large and complex, comprising many separate but interlinked "enterprises" within an overall collaborative business framework, and the architecture method needs to be adapted to recognize this. Different approaches to planning and integration may be used in such cases, including the following (possibly in combination):
    • Top-down planning and development - designing the whole interconnected meta-enterprise as a single entity (an exercise that typically stretches the limits of practicality)
    • Development of a "generic" or "reference" architecture, typical of the enterprises within the organization, but not representing any specific enterprise, which individual enterprises are then expected to adapt in order to produce an architecture "instance" suited to the particular enterprise concerned.
    • Replication - developing a specific architecture for one enterprise, implementing it as a proof-of-concept, and then taking that as a "reference architecture" to be cloned in other enterprises.
  • In a vendor or production environment, a generic architecture for a family of related products is often referred to as a "Product Line Architecture", and the analogous process to that outlined above is termed "(Architecture-based) Product Line Engineering". The ADM is targeted primarily at architects in IT user enterprises, but a vendor organization whose products are IT-based might well wish to adapt it as a generic method for a Product Line Architecture development.

 5.4 Architecture Governance

The ADM, whether adapted by the organization or used as documented here, is a key process to be managed in the same manner as other architecture artifacts classified through the Enterprise Continuum and held in the Architecture Repository. The Architecture Board should be satisfied that the method is being applied correctly across all phases of an architecture development iteration. Compliance with the ADM is fundamental to the governance of the architecture, to ensure that all considerations are made and all required deliverables are produced.

The management of all architectural artifacts, governance, and related processes should be supported by a controlled environment. Typically this would be based on one or more repositories supporting versioned object and process control and status.

The major information areas managed by a governance repository should contain the following types of information:

  • Reference Data (collateral from the organization's own repositories/Enterprise Continuum, including external data; e.g., COBIT, ITIL): Used for guidance and instruction during project implementation. This includes the details of information outlined above. The reference data includes a description of the governance procedures themselves.
  • Process Status: All information regarding the state of any governance processes will be managed; examples of this include outstanding compliance requests, dispensation requests, and compliance assessments investigations.
  • Audit Information: This will record all completed governance process actions and will be used to support:
    • Key decisions and responsible personnel for any architecture project that has been sanctioned by the governance process
    • A reference for future architectural and supporting process developments, guidance, and precedence

The governance artifacts and process are themselves part of the contents of the Architecture Repository.

 5.5 Scoping the Architecture

There are many reasons to constrain (or restrict) the scope of the architectural activity to be undertaken, most of which relate to limits in:

  • The organizational authority of the team producing the architecture
  • The objectives and stakeholder concerns to be addressed within the architecture
  • The availability of people, finance, and other resources

The scope chosen for the architecture activity should ideally allow the work of all architects within the enterprise to be effectively governed and integrated. This requires a set of aligned "architecture partitions" that ensure architects are not working on duplicate or conflicting activities. It also requires the definition of re-use and compliance relationships between architecture partitions.

The division of the enterprise and its architecture-related activity is discussed in more detail in 40. Architecture Partitioning.

Four dimensions are typically used in order to define and limit the scope of an architecture:

  • Breadth: What is the full extent of the enterprise, and what part of that extent will this architecting effort deal with?
    • Many enterprises are very large, effectively comprising a federation of organizational units that could validly be considered enterprises in their own right.
    • The modern enterprise increasingly extends beyond its traditional boundaries, to embrace a fuzzy combination of traditional business enterprise combined with suppliers, customers, and partners.
  • Depth: To what level of detail should the architecting effort go? How much architecture is "enough"? What is the appropriate demarcation between the architecture effort and other, related activities (system design, system engineering, system development)?
  • Time Period: What is the time period that needs to be articulated for the Architecture Vision, and does it make sense (in terms of practicality and resources) for the same period to be covered in the detailed architecture description? If not, how many Transition Architectures are to be defined, and what are their time periods?
  • Architecture Domains: A complete enterprise architecture description should contain all four architecture domains (business, data, application, technology), but the realities of resource and time constraints often mean there is not enough time, funding, or resources to build a top-down, all-inclusive architecture description encompassing all four architecture domains, even if the enterprise scope is chosen to be less than the full extent of the overall enterprise.

Typically, the scope of an architecture is first expressed in terms of breadth, depth, and time. Once these dimensions are understood, a suitable combination of architecture domains can be selected that are appropriate to the problem being addressed. Techniques for using the ADM to develop a number of related architectures are discussed in 20. Applying the ADM across the Architecture Landscape.

The four dimensions of architecture scope are explored in detail below. In each case, particularly in largescale environments where architectures are necessarily developed in a federated manner, there is a danger of architects optimizing within their own scope of activity, instead of at the level of the overall enterprise. It is often necessary to sub-optimize in a particular area, in order to optimize at the enterprise level. The aim should always be to seek the highest level of commonality and focus on scalable and re-usable modules in order to maximize re-use at the enterprise level.

 5.5.1 Breadth

One of the key decisions is the focus of the architecture effort, in terms of the breadth of overall enterprise activity to be covered (which specific business sectors, functions, organizations, geographical areas, etc.).

It is often necessary to have a number of different architectures existing across an enterprise, focused on particular timeframes, business functions, or business requirements.

For large complex enterprises federated architectures - independently developed, maintained, and managed architectures that are subsequently integrated within an integration framework - are typical. Such a framework specifies the principles for interoperability, migration, and conformance. This allows specific business units to have architectures developed and governed as stand-alone architecture projects. More details and guidance on specifying the interoperability requirements for different solutions can be found in Part III, 29. Interoperability Requirements.

The feasibility of a single enterprise-wide architecture for every business function or purpose may be rejected as too complex and unwieldy. In these circumstances it is suggested that a number of different enterprise architectures exist across an enterprise. These enterprise architectures focus on particular timeframes, business segments or functions, and specific organizational requirements. In such a case we need to create the overarching enterprise architecture as a "federation" of these enterprise architectures. An effective way of managing and exploiting these enterprise architectures is to adopt a publish-and-subscribe model that allows architecture to be brought under a governance framework. In such a model, architecture developers and architecture consumers in projects (the supply and demand sides of architecture work) sign up to a mutually beneficial framework of governance that ensures that:

  • Architectural material is of good quality, up-to-date, fit-for-purpose, and published (reviewed and agreed to be made public).
  • Usage of architecture material can be monitored, and compliance with standards, models, and principles can be exhibited, via:
    • A Compliance Assessment process that describes what the user is subscribing to, and assesses their level of compliance
    • A dispensation process that may grant dispensations from adherence to architecture standards and guidelines in specific cases (usually with a strong business imperative)

Publish and subscribe techniques are being developed as part of general IT governance and specifically for the Defense sphere.

 5.5.2 Depth

Care should be taken to judge the appropriate level of detail to be captured, based on the intended use of the enterprise architecture and the decisions to be made based on it. It is important that a consistent and equal level of depth be completed in each architecture domain (business, data, application, technology) included in the architecture effort. If pertinent detail is omitted, the architecture may not be useful. If unnecessary detail is included, the architecture effort may exceed the time and resources available, and/or the resultant architecture may be confusing or cluttered. Developing architectures at different levels of detail within an enterprise is discussed in more detail in 20. Applying the ADM across the Architecture Landscape.

It is also important to predict the future uses of the architecture so that, within resource limitations, the architecture can be structured to accommodate future tailoring, extension, or re-use. The depth and detail of the enterprise architecture needs to be sufficient for its purpose, and no more.

Iterations of the ADM will build on the artifacts and the capabilities created during previous iteration.

There is a need to document all the models in an enterprise, to the level of detail appropriate to the need of the current ADM cycle. The key is to understand the status of the enterprise's architecture work, and what can realistically be achieved with the resources and competencies available, and then focus on identifying and delivering the value that is achievable. Stakeholder value is a key focus: too broad a scope may deter some stakeholders (no return on investment).

 5.5.3 Time Period

The ADM is described in terms of a single cycle of Architecture Vision, and a set of Target Architectures (Business, Data, Application, Technology) that enable the implementation of the vision.

In such cases, a wider view may be taken, whereby an enterprise is represented by several different architecture instances (for example, strategic, segment, capability), each representing the enterprise at a particular point in time. One architecture instance will represent the current enterprise state (the "as-is", or baseline). Another architecture instance, perhaps defined only partially, will represent the ultimate target end-state (the "vision"). In-between, intermediate or "Transition Architecture" instances may be defined, each comprising its own set of Target Architecture Descriptions. An example of how this might be achieved is given in Part III, 20. Applying the ADM across the Architecture Landscape.

By this approach, the Target Architecture work is split into two or more discrete stages:

  1. First, develop Target Architecture Descriptions for the overall (largescale) system, demonstrating a response to stakeholder objectives and concerns for a relatively distant timeframe (for example, a six-year period).
  2. Then develop one or more "Transition Architecture" descriptions, as increments or plateaus, each in line with and converging on the Target Architecture Descriptions, and describing the specifics of the increment concerned.

In such an approach, the Target Architectures are evolutionary in nature, and require periodic review and update according to evolving business requirements and developments in technology, whereas the Transition Architectures are (by design) incremental in nature, and in principle should not evolve during the implementation phase of the increment, in order to avoid the "moving target" syndrome. This, of course, is only possible if the implementation schedule is under tight control and relatively short (typically less than two years).

The Target Architectures remain relatively generic, and because of that are less vulnerable to obsolescence than the Transition Architectures. They embody only the key strategic architectural decisions, which should be blessed by the stakeholders from the outset, whereas the detailed architectural decisions in the Transition Architectures are deliberately postponed as far as possible (i.e., just before implementation) in order to improve responsiveness vis a vis new technologies and products.

The enterprise evolves by migrating to each of these Transition Architectures in turn. As each Transition Architecture is implemented, the enterprise achieves a consistent, operational state on the way to the ultimate vision. However, this vision itself is periodically updated to reflect changes in the business and technology environment, and in effect may never actually be achieved, as originally described. The whole process continues for as long as the enterprise exists and continues to change.

Such a breakdown of the architecture description into a family of related architecture products of course requires effective management of the set and their relationships.

 5.5.4 Architecture Domains

A complete enterprise architecture should address all four architecture domains (business, data, application, technology), but the realities of resource and time constraints often mean there is not enough time, funding, or resources to build a top-down, all-inclusive architecture description encompassing all four architecture domains.

Architecture descriptions will normally be built with a specific purpose in mind - a specific set of business drivers that drive the architecture development - and clarifying the specific issue(s) that the architecture description is intended to help explore, and the questions it is expected to help answer, is an important part of the initial phase of the ADM.

For example, if the purpose of a particular architecture effort is to define and examine technology options for achieving a particular capability, and the fundamental business processes are not open to modification, then a full Business Architecture may well not be warranted. However, because the Data, Application, and Technology Architectures build on the Business Architecture, the Business Architecture still needs to be thought through and understood.

While circumstances may sometimes dictate building an architecture description not containing all four architecture domains, it should be understood that such an architecture cannot, by definition, be a complete enterprise architecture. One of the risks is lack of consistency and therefore ability to integrate. Integration either needs to come later - with its own costs and risks - or the risks and trade-offs involved in not developing a complete and integrated architecture need to be articulated by the architect, and communicated to and understood by the enterprise management.

 5.6 Architecture Integration

Architectures that are created to address a subset of issues within an enterprise require a consistent frame of reference so that they can be considered as a group as well as point deliverables. The dimensions that are used to define the scope boundary of a single architecture (e.g., level of detail, architecture domain, etc.) are typically the same dimensions that must be addressed when considering the integration of many architectures. Figure 5-2 illustrates how different types of architecture need to co-exist.

At the present time, the state of the art is such that architecture integration can be accomplished only at the lower end of the integratability spectrum. Key factors to consider are the granularity and level of detail in each artifact, and the maturity of standards for the interchange of architectural descriptions.


  Figure 5-2: Integration of Architecture Artifacts

As organizations address common themes (such as Service Oriented Architecture (SOA), and integrated information infrastructure), and universal data models and standard data structures emerge, integration toward the high end of the spectrum will be facilitated. However, there will always be the need for effective standards governance to reduce the need for manual co-ordination and conflict resolution.

 5.7 Summary

The TOGAF ADM defines a recommended sequence for the various phases and steps involved in developing an architecture, but it cannot recommend a scope - this has to be determined by the organization itself, bearing in mind that the recommended sequence of development in the ADM process is an iterative one, with the depth and breadth of scope and deliverables increasing with each iteration. Each iteration will add resources to the organization's Architecture Repository.

While a complete framework is useful (indeed, essential) to have in mind as the ultimate long-term goal, in practice there is a key decision to be made as to the scope of a specific enterprise architecture effort. This being the case, it is vital to understand the basis on which scoping decisions are being made, and to set expectations right for what is the goal of the effort.

The main guideline is to focus on what creates value to the enterprise, and to select horizontal and vertical scope, and time periods, accordingly. Whether or not this is the first time around, understand that this exercise will be repeated, and that future iterations will build on what is being created in the current effort, adding greater width and depth.


Preliminary Phase

URL de origem: http://pubs.opengroup.org/architecture/togaf9-doc/arch/chap06.html
  Figure 6-1: Preliminary Phase

 6.1 Objectives

The objectives of the Preliminary Phase are:

  1. Determine the Architecture Capability desired by the organization:
    • Review the organizational context for conducting enterprise architecture
    • Identify and scope the elements of the enterprise organizations affected by the Architecture Capability
    • Identify the established frameworks, methods, and processes that intersect with the Architecture Capability
    • Establish Capability Maturity target
  2. Establish the Architecture Capability:
    • Define and establish the Organizational Model for Enterprise Architecture
    • Define and establish the detailed process and resources for architecture governance
    • Select and implement tools that support the Architecture Capability
    • Define the Architecture Principles

 6.2 Approach

This Preliminary Phase is about defining "where, what, why, who, and how we do architecture" in the enterprise concerned. The main aspects are as follows:

  • Defining the enterprise
  • Identifying key drivers and elements in the organizational context
  • Defining the requirements for architecture work
  • Defining the Architecture Principles that will inform any architecture work
  • Defining the framework to be used
  • Defining the relationships between management frameworks
  • Evaluating the enterprise architecture maturity

The enterprise architecture provides a strategic, top-down view of an organization to enable executives, planners, architects, and engineers to coherently co-ordinate, integrate, and conduct their activities. The enterprise architecture framework provides the strategic context for this team to operate within.

Therefore, developing the enterprise architecture is not a solitary activity and the enterprise architects need to recognize the interoperability between their frameworks and the rest of the business.

Strategic, interim, and tactical business objectives and aspirations need to be met. Similarly, the enterprise architecture needs to reflect this requirement and allow for operation of architecture discipline at different levels within the organization.

Depending on the scale of the enterprise and the level of budgetary commitment to enterprise architecture discipline, a number of approaches may be adopted to sub-divide or partition architecture teams, processes, and deliverables. Approaches for architecture partitioning are discussed in Part V, 40. Architecture Partitioning. The Preliminary Phase should be used to determine the desired approach to partitioning and to establish the groundwork for the selected approach to be put into practice.

The Preliminary Phase may be revisited, from the Architecture Vision phase (see Part III, 19. Applying Iteration to the ADM), in order to ensure that the organization's Architecture Capability is suitable to address a specific architecture problem.

 6.2.1 Enterprise

One of the main challenges of enterprise architecture is that of enterprise scope.

The scope of the enterprise, and whether it is federated, will determine those stakeholders who will derive most benefit from the enterprise Architecture Capability. It is imperative that a sponsor is appointed at this stage to ensure that the resultant activity has resources to proceed and the clear support of the business management. The enterprise may encompass many organizations and the duties of the sponsor are to ensure that all stakeholders are included in defining, establishing, and using the Architecture Capability.

 6.2.2 Organizational Context

In order to make effective and informed decisions about the framework for architecture to be used within a particular enterprise, it is necessary to understand the context surrounding the architecture framework. Specific areas to consider would include:

  • The commercial models for enterprise architecture and budgetary plans for enterprise architecture activity. Where no such plans exist, the Preliminary Phase should be used to develop a budget plan.
  • The stakeholders for architecture in the enterprise; their key issues and concerns.
  • The intentions and culture of the organization, as captured within board business directives, business imperatives, business strategies, business principles, business goals, and business drivers.
  • Current processes that support execution of change and operation of the enterprise, including the structure of the process and also the level of rigor and formality applied within the organization. Areas for focus should include:
    • Current methods for architecture description
    • Current project management frameworks and methods
    • Current systems management frameworks and methods
    • Current project portfolio management processes and methods
    • Current application portfolio management processes and methods
    • Current technology portfolio management processes and methods
    • Current information portfolio management processes and methods
    • Current systems design and development frameworks and methods
  • The Baseline Architecture landscape, including the state of the enterprise and also how the landscape is currently represented in documentation form.
  • The skills and capabilities of the enterprise and specific organizations that will be adopting the framework.

Review of the organizational context should provide valuable requirements on how to tailor the architecture framework in terms of:

  • Level of formality and rigor to be applied
  • Level of sophistication and expenditure required
  • Touch-points with other organizations, processes, roles, and responsibilities
  • Focus of content coverage

 6.2.3 Requirements for Architecture Work

The business imperatives behind the enterprise architecture work drive the requirements and performance metrics for the architecture work. They should be sufficiently clear so that this phase may scope the business outcomes and resource requirements, and define the outline enterprise business information requirements and associated strategies of the enterprise architecture work to be done. For example, these may include:

  • Business requirements
  • Cultural aspirations
  • Organization intents
  • Strategic intent
  • Forecast financial requirements

Significant elements of these need to be articulated so that the sponsor can identify all the key decision-makers and stakeholders involved in defining and establishing an Architecture Capability.

 6.2.4 Principles

The Preliminary Phase 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 III, 23. Architecture Principles.

The definition of Architecture Principles is fundamental to the development of an enterprise architecture. Architecture work is informed by business principles as well as Architecture Principles. The Architecture Principles themselves 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, 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.

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 for resolving architecture issues. The issues involved in governance are explained in Part VII, 50. Architecture Governance.

 6.2.5 Management Frameworks

The TOGAF Architecture Development Method (ADM) 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).

TOGAF has to co-exist with and enhance the operational capabilities of other management frameworks that are present within any organization either formally or informally. In addition to these frameworks, most organizations have a method for the development of solutions, most of which have an IT component. The significance of systems is that it brings together the various domains (also known as People, Processes, and Material/Technology) to deliver a business capability.

The main frameworks suggested to be co-ordinated with TOGAF are:

  • Business Capability Management (Business Direction and Planning) that determines what business capabilities are required to deliver business value including the definition of return on investment and the requisite control/performance measures.
  • Portfolio/Project Management Methods that determine how a company manages its change initiatives.
  • Operations Management Methods that describe how a company runs its day-to-day operations, including IT.
  • Solution Development Methods that formalize the way that business systems are delivered in accordance with the structures developed in the IT architecture.

As illustrated in Figure 6-2, these frameworks are not discrete and there are significant overlaps between them and the Business Capability Management. The latter includes the delivery of performance measured business value.

The overall significance is that the enterprise architect applying TOGAF cannot narrowly focus on the IT implementation, but must be aware of the impact that the architecture has on the entire enterprise.


  Figure 6-2: Management Frameworks to Co-ordinate with TOGAF

The Preliminary 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 in 5.3 Adapting the ADM.

 6.2.6 Relating the Management Frameworks

Figure 6-3 illustrates a more detailed set of dependencies between the various frameworks and business planning activity that incorporates the enterprise's strategic plan and direction. The enterprise architecture can be used to provide a structure for all of the corporate initiatives, the Portfolio Management Framework can be used to deliver the components of the architecture, and the Operations Management Framework supports incorporation of these new components within the corporate infrastructure.

The business planners are present throughout the process and are in a position to support and enforce the architecture by retaining approval for resources at the various stages of planning and development.

The solution development methodology is used within the Portfolio Management Framework to plan, create, and deliver the architectural components specified in the portfolio and project charters. These deliverables include, but are not exclusively, IT; for example, a new building, a new set of skills, production equipment, hiring, marketing, and so on. Enterprise architecture potentially provides the context for all enterprise activities.

The management frameworks are required to complement each other and work in close harmony for the good of the enterprise.


  Figure 6-3: Interoperability and Relationships between Management Frameworks

Business planning at the strategy level provides the initial direction to enterprise architecture. Updates at the annual planning level provide a finer level of ongoing guidance. Capability-based Planning is one of many popular techniques for business planning.

Enterprise architecture structures the business planning into an integrated framework that regards the enterprise as a system or system of systems. This integrated approach will validate the business plan and can provide valuable feedback to the corporate planners. In some organizations, the enterprise architects have been moved to or work very closely with the strategic direction groups. TOGAF delivers a framework for enterprise architecture.

Portfolio/project management is the delivery framework that receives the structured, detailed direction that enables them to plan and build what is required, knowing that each assigned deliverable will be in context (i.e., the piece of the puzzle that they deliver will fit into the corporate puzzle that is the enterprise architecture). Often this framework is based upon the Project Management Institute or UK Office of Government Commerce (PRINCE2) project management methodologies. Project architectures and detailed out-of-context design are often based upon systems design methodologies.

Operations management receives the deliverables and then integrates and sustains them within the corporate infrastructure. Often the IT service management services are based upon ISO 20000 or BS15000 (ITIL).

 6.2.7 Planning for Enterprise Architecture/Business Change Maturity Evaluation

Capability Maturity Models (detailed in Part VII, 51. Architecture Maturity Models) are useful ways of assessing the ability of an enterprise to exercise different capabilities.

Capability Maturity Models typically identify selected factors that are required to exercise a capability. An organization's ability to execute specific factors provides a measure of maturity and can be used to recommend a series of sequential steps to improve a capability. It is an assessment that gives executives an insight into pragmatically improving a capability.

A good enterprise architecture maturity model covers the characteristics necessary to develop and consume enterprise architecture. Organizations can determine their own factors and derive the appropriate maturity models, but it is recommended to take an existing model and customize it as required.

Several good models exist, including NASCIO, and the US Department of Commerce Architecture Capability Maturity Model.

The use of Capability Maturity Models is detailed in Part VII, 51. Architecture Maturity Models.

Other examples include the US Federal Enterprise Architecture Maturity Model. Even though the models are originally from government, they are equally applicable to industry.

 6.3 Inputs

This section defines the inputs to the Preliminary Phase.

 6.3.1 Reference Materials External to the Enterprise

  • TOGAF
  • Other architecture framework(s), if required

 6.3.2 Non-Architectural Inputs

  • Board strategies and board business plans, business strategy, IT strategy, business principles, business goals, and business drivers, when pre-existing
  • Major frameworks operating in the business; e.g., portfolio/project management
  • Governance and legal frameworks, including architecture governance strategy, when pre-existing
  • Architecture capability
  • Partnership and contract agreements

 6.3.3 Architectural Inputs

Pre-existing models for operating an enterprise Architecture Capability can be used as a baseline for the Preliminary Phase. Inputs would include:

  • Organizational Model for Enterprise Architecture (see Part IV, 36.2.16 Organizational Model for Enterprise Architecture), including:
    • Scope of organizations impacted
    • Maturity assessment, gaps, and resolution approach
    • Roles and responsibilities for architecture team(s)
    • Budget requirements
    • Governance and support strategy
  • Existing Architecture Framework, if any, including:
    • Architecture method
    • Architecture content
    • Configured and deployed tools
    • Architecture Principles
    • Architecture Repository

 6.4 Steps

The TOGAF ADM 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. The Preliminary Phase therefore involves doing any necessary work to initiate and adapt the ADM to define an organization-specific framework. The issues involved with adapting the ADM to a specific organizational context are discussed in detail in 5.3 Adapting the ADM.

The level of detail addressed in the Preliminary Phase will depend on the scope and goals of the overall architecture effort.

The order of the steps in the Preliminary Phase (see below) as well as the time at which they are formally started and completed should be adapted to the situation at hand in accordance with the established architecture governance.

The steps within the Preliminary Phase are as follows:

 6.4.1 Scope the Enterprise Organizations Impacted

  • Identify core enterprise (units) - those who are most affected and achieve most value from the work
  • Identify soft enterprise (units) - those who will see change to their capability and work with core units but are otherwise not directly affected
  • Identify extended enterprise (units) - those units outside the scoped enterprise who will be affected in their own enterprise architecture
  • Identify communities involved (enterprises) - those stakeholders who will be affected and who are in groups of communities
  • Identify governance involved, including legal frameworks and geographies (enterprises)

 6.4.2 Confirm Governance and Support Frameworks

The architecture framework will form the keystone to the flavor (centralized or federated, light or heavy, etc.) of architecture governance organization and guidelines that need to be developed. Part of the major output of this phase is a framework for architecture governance. We need to understand how architectural material (standards, guidelines, models, compliance reports, etc.) is brought under governance; i.e., what type of governance repository characteristics are going to be required, what relationships and status recording are necessary to ascertain which governance process (dispensation, compliance, take-on, retirement, etc.) has ownership of an architectural artifact.

It is likely that the existing governance and support models of an organization will need to change to support the newly adopted architecture framework.

To manage the organizational change required to adopt the new architectural framework, the current enterprise governance and support models will need to be assessed to understand their overall shape and content. Additionally, the sponsors and stakeholders for architecture will need to be consulted on potential impacts that could occur.

Upon completion of this step, the architecture touch-points and likely impacts should be understood and agreed by relevant stakeholders.

 6.4.3 Define and Establish Enterprise Architecture Team and Organization

  • Determine existing enterprise and business capability
  • Conduct an enterprise architecture/business change maturity assessment, if required
  • Identify gaps in existing work areas
  • Allocate key roles and responsibilities for enterprise Architecture Capability management and governance
  • Define requests for change to existing business programs and projects:
    • Inform existing enterprise architecture and IT architecture work of stakeholder requirements
    • Request assessment of impact on their plans and work
    • Identify common areas of interest
    • Identify any critical differences and conflicts of interest
    • Produce requests for change to stakeholder activities
  • Determine constraints on enterprise architecture work
  • Review and agree with sponsors and board
  • Assess budget requirements

 6.4.4 Identify and Establish Architecture Principles

Architecture Principles (see Part III, 23. Architecture Principles) are based on business principles and are critical in setting the foundation for architecture governance. Once the organizational context is understood, define a set of Architecture Principles that is appropriate to the enterprise.

 6.4.5 Tailor TOGAF and, if any, Other Selected Architecture Framework(s)

In this step, determine what tailoring of TOGAF is required. Consider the need for:

  • Terminology Tailoring: Architecture practitioners should use terminology that is generally understood across the enterprise. Tailoring should produce an agreed terminology set for description of architectural content.
  • Process Tailoring: The TOGAF ADM provides a generic process for carrying out architecture. Process tailoring provides the opportunity to remove tasks that are already carried out elsewhere in the organization, add organization-specific tasks (such as specific checkpoints) and to align the ADM processes to external process frameworks and touch-points. Key touch-points to be addressed would include:
    • Links to (project and service) portfolio management processes
    • Links to project lifecycle
    • Links to operations handover processes
    • Links to operational management processes (including configuration management, change management, and service management)
    • Links to procurement processes
  • Content Tailoring: Using the TOGAF Architecture Content Framework and Enterprise Continuum as a basis, tailoring of content structure and classification approach allows adoption of third-party content frameworks and also allows for customization of the framework to support organization-specific requirements.

 6.4.6 Implement Architecture Tools

The level of formality used to define and manage architecture content will be highly dependent on the scale, sophistication, and culture of the architecture function within the organization. With an understanding of the desired approach to architecture, it is possible to select appropriate architecture tools to underpin the architecture function.

The approach to tools may be based on relatively informal usage of standard office productivity applications, or may be based on a customized deployment of specialist architecture tools. Depending on the level of sophistication, the implementation of tools may range from a trivial task to a more involved system implementation activity.

Issues in tools standardization are discussed in Part V, 42. Tools for Architecture Development.

 6.5 Outputs

The outputs of the Preliminary Phase may include, but are not restricted to:

The outputs may include some or all of the following:

  • Catalogs:
    • Principles catalog

Phase A: Architecture Vision

URL de origem: http://pubs.opengroup.org/architecture/togaf9-doc/arch/chap07.html
  Figure 7-1: Phase A: Architecture Vision

 7.1 Objectives

The objectives of Phase A are to:

  • Develop a high-level aspirational vision of the capabilities and business value to be delivered as a result of the proposed enterprise architecture
  • Obtain approval for a Statement of Architecture Work that defines a program of works to develop and deploy the architecture outlined in the Architecture Vision

 7.2 Approach

 7.2.1 General

Phase A starts with receipt of a Request for Architecture Work from the sponsoring organization to the architecture organization.

The issues involved in ensuring proper recognition and endorsement from corporate management, and the support and commitment of line management, are discussed in Part VII, 50.1.4 IT Governance.

Phase A also defines what is in and what is outside the scope of the architecture effort and the constraints that must be dealt with. Scoping decisions need to be made on the basis of a practical assessment of resource and competence availability, and the value that can realistically be expected to accrue to the enterprise from the chosen scope of architecture work. The issues involved in this are discussed in 5.5 Scoping the Architecture. Scoping issues addressed in the Architecture Vision phase will be restricted to the specific objectives for this ADM cycle and will be constrained within the overall scope definition for architecture activity as established within the Preliminary Phase and embodied within the architecture framework.

In situations where the architecture framework in place is not appropriate to achieve the desired Architecture Vision, revisit the Preliminary Phase and extend the overall architecture framework for the enterprise.

The constraints will normally be informed by the business principles and Architecture Principles, developed as part of the Preliminary Phase (see 6. Preliminary Phase).

Normally, the business principles, business goals, and strategic drivers of the organization are already defined elsewhere in the enterprise. If so, the activity in Phase A is involved with ensuring that existing definitions are current, and clarifying any areas of ambiguity. Otherwise, it involves defining these essential items for the first time.

Similarly, the Architecture Principles that form part of the constraints on architecture work will normally have been defined in the Preliminary Phase (see 6. Preliminary Phase). The activity in Phase A is concerned with ensuring that the existing principles definitions are current, and clarifying any areas of ambiguity. Otherwise, it entails defining the Architecture Principles for the first time, as explained in Part III, 23. Architecture Principles.

 7.2.2 Creating the Architecture Vision

The Architecture Vision provides the sponsor with a key tool to sell the benefits of the proposed capability to stakeholders and decision-makers within the enterprise. Architecture Vision describes how the new capability will meet the business goals and strategic objectives and address the stakeholder concerns when implemented.

Clarifying and agreeing the purpose of the architecture effort is one of the key parts of this activity, and the purpose needs to be clearly reflected in the vision that is created. Architecture projects are often undertaken with a specific purpose in mind - a specific set of business drivers that represent the return on investment for the stakeholders in the architecture development. Clarifying that purpose, and demonstrating how it will be achieved by the proposed architecture development, is the whole point of the Architecture Vision.

Normally, key elements of the Architecture Vision - such as the enterprise mission, vision, strategy, and goals - have been documented as part of some wider business strategy or enterprise planning activity that has its own lifecycle within the enterprise. In such cases, the activity in Phase A is concerned with verifying and understanding the documented business strategy and goals, and possibly bridging between the enterprise strategy and goals on the one hand, and the strategy and goals implicit within the current architecture reality.

In other cases, little or no Business Architecture work may have been done to date. In such cases, there will be a need for the architecture team to research, verify, and gain buy-in to the key business objectives and processes that the architecture is to support. This may be done as a free-standing exercise, either preceding architecture development, or as part of the ADM initiation phase (Preliminary Phase).

The Architecture Vision provides a first-cut, high-level description of the Baseline and Target Architectures, covering the business, data, application, and technology domains. These outline descriptions are developed in subsequent phases.

Business scenarios are an appropriate and useful technique to discover and document business requirements, and to articulate an Architecture Vision that responds to those requirements. Business scenarios are described in Part III, 26. Business Scenarios and Business Goals.

Once an Architecture Vision is defined and documented in the Statement of Architecture Work, it is critical to use it to build a consensus, as described in Part VII, 50.1.4 IT Governance. Without this consensus it is very unlikely that the final architecture will be accepted by the organization as a whole. The consensus is represented by the sponsoring organization signing the Statement of Architecture Work.

 7.2.3 Business Scenarios

The ADM has its own method (a "method-within-a-method") for identifying and articulating the business requirements implied in new business capability to address key business drivers, and the implied architecture requirements. This process is known as "business scenarios", and is described in Part III, 26. Business Scenarios and Business Goals. The technique may be used iteratively, at different levels of detail in the hierarchical decomposition of the Business Architecture.

 7.3 Inputs

This section defines the inputs to Phase A.

 7.3.1 Reference Materials External to the Enterprise

 7.3.2 Non-Architectural Inputs

 7.3.3 Architectural Inputs

  • Organizational Model for Enterprise Architecture (see Part IV, 36.2.16 Organizational Model for Enterprise Architecture), including:
    • Scope of organizations impacted
    • Maturity assessment, gaps, and resolution approach
    • Roles and responsibilities for architecture team(s)
    • Constraints on architecture work
    • Re-use requirements
    • Budget requirements
    • Requests for change
    • Governance and support strategy
  • Tailored Architecture Framework (see Part IV, 36.2.21 Tailored Architecture Framework), including:
    • Tailored architecture method
    • Tailored architecture content (deliverables and artifacts)
    • Architecture principles (see Part IV, 36.2.4 Architecture Principles), including business principles, when pre-existing
    • Configured and deployed tools
  • Populated Architecture Repository (see Part IV, 36.2.5 Architecture Repository) - existing architectural documentation (framework description, architectural descriptions, baseline descriptions, ABBs, etc.)

 7.4 Steps

The level of detail addressed in Phase A will depend on the scope and goals of the Request for Architecture Work, or the subset of scope and goals associated with this iteration of architecture development.

The order of the steps in Phase A (see below) as well as the time at which they are formally started and completed should be adapted to the situation at hand in accordance with the established architecture governance.

The steps in Phase A are as follows:

 7.4.1 Establish the Architecture Project

Execution of ADM cycles should be conducted within the project management framework of the enterprise. In some cases, architecture projects will be stand-alone. In other cases, architectural activities will be a subset of the activities within a larger project. In either case, architecture activity should be planned and managed using accepted practices for the enterprise.

Conduct the necessary procedures to secure recognition of the project, the endorsement of corporate management, and the support and commitment of the necessary line management. Include references to other management frameworks in use within the enterprise, explaining how this project relates to those frameworks.

 7.4.2 Identify Stakeholders, Concerns, and Business Requirements

Identify the key stakeholders and their concerns/objectives, and define the key business requirements to be addressed in the architecture engagement. Stakeholder engagement at this stage is intended to accomplish three objectives:

  • To identify candidate vision components and requirements to be tested as the Architecture Vision is developed
  • To identify candidate scope boundaries for the engagement to limit the extent of architectural investigation required
  • To identify stakeholder concerns, issues, and cultural factors that will shape how the architecture is presented and communicated

The major product resulting from this step is a stakeholder map for the engagement, showing which stakeholders are involved with the engagement, their level of involvement, and their key concerns (see Part III, 24.3 Steps in the Stakeholder Management Process and 24.4 Template Stakeholder Map). The stakeholder map is used to support various outputs of the Architecture Vision phase, and to identify:

Another key task will be to consider which architecture views and viewpoints need to be developed to satisfy the various stakeholder requirements. As described in Part III, 24. Stakeholder Management, understanding at this stage which stakeholders and which views need to be developed is important in setting the scope of the engagement.

During the Architecture Vision phase, new requirements generated for future architecture work within the scope of the selected requirements need to be documented within the Architecture Requirements Specification, and new requirements which are beyond the scope of the selected requirements must be input to the Requirements Repository for management through the Requirements Management process.

 7.4.3 Confirm and Elaborate Business Goals, Business Drivers, and Constraints

Identify the business goals and strategic drivers of the organization.

If these have already been defined elsewhere within the enterprise, ensure that the existing definitions are current, and clarify any areas of ambiguity. Otherwise, go back to the originators of the Statement of Architecture Work and work with them to define these essential items and secure their endorsement by corporate management.

Define the constraints that must be dealt with, including enterprise-wide constraints and project-specific constraints (time, schedule, resources, etc.). The enterprise-wide constraints may be informed by the business and Architecture Principles developed in the Preliminary Phase or clarified as part of Phase A.

 7.4.4 Evaluate Business Capabilities

It is valuable to understand a collection of capabilities within the enterprise. One part refers to the capability of the enterprise to develop and consume the architecture. The second part refers to the baseline and target capability level of the enterprise.

Gaps identified in the Architecture Capability require iteration between Architecture Vision and Preliminary Phase to ensure that the Architecture Capability is suitable to address the scope of the architecture project (see Part III, 19. Applying Iteration to the ADM).

Gaps, or limitations, identified in the enterprise's capability to execute on change will inform the architect on the description of the Target Architecture and on the Implementation and Migration Plan (see Part IV, 36.2.14 Implementation and Migration Plan) created in Phase E and Phase F.

This step seeks to understand the capabilities and desires of the enterprise at an appropriate level of abstraction (see 20. Applying the ADM across the Architecture Landscape). Consideration of the gap between the baseline and target capability of the enterprise is critical. Showing the baseline and target capabilities within the context of the overall enterprise can be supported by creating Value Chain diagrams that show the linkage of related capabilities.

The results of the assessment are documented in a Capability Assessment (see Part IV, 36.2.10 Capability Assessment).

 7.4.5 Assess Readiness for Business Transformation

A Business Transformation Readiness Assessment can be used to evaluate and quantify the organization's readiness to undergo a change. This assessment is based upon the determination and analysis/rating of a series of readiness factors, as described in 30. Business Transformation Readiness Assessment.

The results of the readiness assessment should be added to the Capability Assessment (see Part IV, 36.2.10 Capability Assessment). These results are then used to shape the scope of the architecture, to identify activities required within the architecture project, and to identify risk areas to be addressed.

 7.4.6 Define Scope

Define what is inside and what is outside the scope of the Baseline Architecture and Target Architecture efforts, understanding that the baseline and target need not be described at the same level of detail. In many cases, the Baseline is described at a higher level of abstraction, so more time is available to specify the Target in sufficient detail. The issues involved in this are discussed in 5.5 Scoping the Architecture. In particular, define:

  • The breadth of coverage of the enterprise
  • The level of detail required
  • The partitioning characteristics of the architecture (see Part V, 40. Architecture Partitioning for more details)
  • The specific architecture domains to be covered (business, data, application, technology)
  • The extent of the time period aimed at, plus the number and extent of any intermediate time period
  • The architectural assets to be leveraged, or considered for use, from the organization's Enterprise Continuum:
    • Assets created in previous iterations of the ADM cycle within the enterprise
    • Assets available elsewhere in the industry (other frameworks, systems models, vertical industry models, etc.)

 7.4.7 Confirm and Elaborate Architecture Principles, including Business Principles

Review the principles under which the architecture is to be developed. Architecture principles are normally based on the principles developed as part of the Preliminary Phase. They are explained, and an example set given, in Part III, 23. Architecture Principles. Ensure that the existing definitions are current, and clarify any areas of ambiguity. Otherwise, go back to the body responsible for architecture governance and work with them to define these essential items for the first time and secure their endorsement by corporate management.

 7.4.8 Develop Architecture Vision

Based on the stakeholder concerns, business capability requirements, scope, constraints, and principles, create a high-level view of the Baseline and Target Architectures. The Architecture Vision typically covers the breadth of scope identified for the project, at a high level. Informal techniques are often employed. A common practice is to draw a simple solution concept diagram that illustrates concisely the major components of the solution and how the solution will result in benefit for the enterprise.

Business scenarios are an appropriate and useful technique to discover and document business requirements, and to articulate an Architecture Vision that responds to those requirements. Business scenarios may also be used at more detailed levels of the architecture work (e.g., in Phase B) and are described in Part III, 26. Business Scenarios and Business Goals.

This step generates the first, very high-level definitions of the baseline and target environments, from a business, information systems, and technology perspective, as described in 7.5 Outputs.

These initial versions of the architecture should be stored in the Architecture Repository, organized according to the standards and guidelines established in the architecture framework.

 7.4.9 Define the Target Architecture Value Propositions and KPIs

  • Develop the business case for the architectures and changes required
  • Produce the value proposition for each of the stakeholder groupings
  • Assess and define the procurement requirements
  • Review and agree the value propositions with the sponsors and stakeholders concerned
  • Define the performance metrics and measures to be built into the enterprise architecture to meet the business needs
  • Assess the business risk (see Part III, 31. Risk Management)

The outputs from this activity should be incorporated within the Statement of Architecture Work to allow performance to be tracked accordingly.

 7.4.10 Identify the Business Transformation Risks and Mitigation Activities

Identify the risks associated with the Architecture Vision and assess the initial level of risk (e.g., catastrophic, critical, marginal, or negligible) and the potential frequency associated with it. Assign a mitigation strategy for each risk. A risk management framework is described in Part III, 31. Risk Management.

There are two levels of risk that should be considered, namely:

  • Initial Level of Risk: Risk categorization prior to determining and implementing mitigating actions.
  • Residual Level of Risk: Risk categorization after implementation of mitigating actions (if any).

Risk mitigation activities should be considered for inclusion within the Statement of Architecture Work.

 7.4.11 Develop Statement of Architecture Work; Secure Approval

Assess the work products that are required to be produced (and by when) against the set of business performance requirements. This will involve ensuring that:

  • Performance metrics are built into the work products.
  • Specific performance-related work products are available.

Then, activities will include:

  • Identify new work products that will need to be changed
  • Provide direction on which existing work products, including building blocks, will need to be changed and ensure that all activities and dependencies on these are co-ordinated
  • Identify the impact of change on other work products and dependence on their activities
  • Based on the purpose, focus, scope, and constraints, determine which architecture domains should be developed, to what level of detail, and which architecture views should be built
  • Assess the resource requirements and availability to perform the work in the timescale required; this will include adhering to the organization's planning methods and work products to produce the plans for performing a cycle of the ADM
  • Estimate the resources needed, develop a roadmap and schedule for the proposed development, and document all these in the Statement of Architecture Work
  • Define the performance metrics to be met during this cycle of the ADM by the enterprise architecture team
  • Develop the specific enterprise architecture Communications Plan and show where, how, and when the enterprise architects will communicate with the stakeholders, including affinity groupings and communities, about the progress of the enterprise architecture developments
  • Review and agree the plans with the sponsors, and secure formal approval of the Statement of Architecture Work under the appropriate governance procedures
  • Gain sponsor's sign-off to proceed

 7.5 Outputs

The outputs of Phase A may include, but are not restricted to:

Note:
Multiple business scenarios may be used to generate a single Architecture Vision.

The outputs may include some or all of the following:

  • Matrices:
    • Stakeholder Map matrix
  • Diagrams:
    • Value Chain diagram
    • Solution Concept diagram

Phase B: Business Architecture

URL de origem: http://pubs.opengroup.org/architecture/togaf9-doc/arch/chap08.html
  Figure 8-1: Phase B: Business Architecture

 8.1 Objectives

The objectives of Phase B are to:

  • Develop the Target Business Architecture that describes how the enterprise needs to operate to achieve the business goals, and respond to the strategic drivers set out in the Architecture Vision, in a way that addresses the Request for Architecture Work and stakeholder concerns
  • Identify candidate Architecture Roadmap components based upon gaps between the Baseline and Target Business Architectures

 8.2 Approach

In summary, the Business Architecture describes the product and/or service strategy, and the organizational, functional, process, information, and geographic aspects of the business environment.

 8.2.1 General

A knowledge of the Business Architecture is a prerequisite for architecture work in any other domain (Data, Application, Technology), and is therefore the first architecture activity that needs to be undertaken, if not catered for already in other organizational processes (enterprise planning, strategic business planning, business process re-engineering, etc.).

In practical terms, the Business Architecture is also often necessary as a means of demonstrating the business value of subsequent architecture work to key stakeholders, and the return on investment to those stakeholders from supporting and participating in the subsequent work.

The scope of the work in Phase B will depend to a large extent on the enterprise environment. In some cases, key elements of the Business Architecture may be done in other activities; for example, the enterprise mission, vision, strategy, and goals may be documented as part of some wider business strategy or enterprise planning activity that has its own lifecycle within the enterprise.

In such cases, there may be a need to verify and update the currently documented business strategy and plans, and/or to bridge between high-level business drivers, business strategy, and goals on the one hand, and the specific business requirements that are relevant to this architecture development effort. The business strategy typically defines what to achieve - the goals and drivers, and the metrics for success - but not how to get there. That is role of the Business Architecture.

In other cases, little or no Business Architecture work may have been done to date. In such cases, there will be a need for the architecture team to research, verify, and gain buy-in to the key business objectives and processes that the architecture is to support. This may be done as a free-standing exercise, either preceding architecture development, or as part of Phase A.

In both of these cases, the business scenario technique (see Part III, 26. Business Scenarios and Business Goals) of the TOGAF ADM, or any other method that illuminates the key business requirements and indicates the implied technical requirements for IT architecture, may be used.

A key objective is to re-use existing material as much as possible. In architecturally more mature environments, there will be existing Architecture Definitions, which (hopefully) will have been maintained since the last architecture development cycle. Where architecture descriptions exist, these can be used as a starting point, and verified and updated if necessary; see Part V, 39.4.1 Architecture Continuum.

Gather and analyze only that information that allows informed decisions to be made relevant to the scope of this architecture effort. If this effort is focused on the definition of (possibly new) business processes, then Phase B will necessarily involve a lot of detailed work. If the focus is more on the Target Architectures in other domains (data/information, application systems, infrastructure) to support an essentially existing Business Architecture, then it is important to build a complete picture in Phase B without going into unnecessary detail.

 8.2.2 Developing the Baseline Description

If an enterprise has existing architecture descriptions, they should be used as the basis for the Baseline Description. This input may have been used already in Phase A in developing an Architecture Vision, and may even be sufficient in itself for the Baseline Description.

Where no such descriptions exist, information will have to be gathered in whatever format comes to hand.

The normal approach to Target Architecture development is top-down. In the Baseline Description, however, the analysis of the current state often has to be done bottom-up, particularly where little or no architecture assets exist. In such a case, the architect simply has to document the working assumptions about high-level architectures, and the process is one of gathering evidence to turn the working assumptions into fact, until the law of diminishing returns sets in.

Business processes that are not to be carried forward have no intrinsic value. However, when developing Baseline Descriptions in other architecture domains, architectural components (principles, models, standards, and current inventory) that are not to be carried forward may still have an intrinsic value, and an inventory may be needed in order to understand the residual value (if any) of those components.

Whatever the approach, the goal should be to re-use existing material as much as possible, and to gather and analyze only that information that allows informed decisions to be made regarding the Target Business Architecture. It is important to build a complete picture without going into unnecessary detail.

 8.2.3 Business Modeling

Business models should be logical extensions of the business scenarios from the Architecture Vision, so that the architecture can be mapped from the high-level business requirements down to the more detailed ones.

A variety of modeling tools and techniques may be employed, if deemed appropriate (bearing in mind the above caution not to go into unnecessary detail). For example:

  • Activity Models (also called Business Process Models) describe the functions associated with the enterprise's business activities, the data and/or information exchanged between activities (internal exchanges), and the data and/or information exchanged with other activities that are outside the scope of the model (external exchanges). Activity models are hierarchical in nature. They capture the activities performed in a business process, and the ICOMs (inputs, controls, outputs, and mechanisms/resources used) of those activities. Activity models can be annotated with explicit statements of business rules, which represent relationships among the ICOMs. For example, a business rule can specify who can do what under specified conditions, the combination of inputs and controls needed, and the resulting outputs. One technique for creating activity models is the IDEF (Integrated Computer Aided Manufacturing (ICAM) DEFinition) modeling technique.

    The Object Management Group (OMG) has developed the Business Process Modeling Notation (BPMN), a standard for business process modeling that includes a language with which to specify business processes, their tasks/steps, and the documents produced.

  • Use-Case Models can describe either business processes or systems functions, depending on the focus of the modeling effort. A use-case model describes the business processes of an enterprise in terms of use-cases and actors corresponding to business processes and organizational participants (people, organizations, etc.). The use-case model is described in use-case diagrams and use-case specifications.
  • Class Models are similar to logical data models. A class model describes static information and relationships between information. A class model also describes informational behaviors. Like many of the other models, it can also be used to model various levels of granularity. Depending on the intent of the model, a class model can represent business domain entities or systems implementation classes. A business domain model represents key business information (domain classes), their characteristics (attributes), their behaviors (methods or operations), and relationships (often referred to as multiplicity, describing how many classes typically participate in the relationship), and cardinality (describes required or optional participation in the relationship). Specifications further elaborate and detail information that cannot be represented in the class diagram.


  Figure 8-2: UML Business Class Diagram

All three types of model above can be represented in the Unified Modeling Language (UML), and a variety of tools exist for generating such models.

Certain industry sectors have modeling techniques specific to the sector concerned. For example, the Defense sector uses the following models. These models have to be used carefully, especially if the location and conduct of business processes will be altered in the visionary Business Architecture.

  • The Node Connectivity Diagram describes the business locations (nodes), the "needlines" between them, and the characteristics of the information exchanged. Node connectivity can be described at three levels: conceptual, logical, and physical. Each needline indicates the need for some kind of information transfer between the two connected nodes. A node can represent a role (e.g., a CIO), an organizational unit, a business location or facility, and so on. An arrow indicating the direction of information flow is annotated to describe the characteristics of the data or information - for example, its content, media, security or classification level, timeliness, and requirements for information system interoperability.
  • The Information Exchange Matrix documents the information exchange requirements for an enterprise architecture. Information exchange requirements express the relationships across three basic entities (activities, business nodes and their elements, and information flow), and focus on characteristics of the information exchange, such as performance and security. They identify who exchanges what information with whom, why the information is necessary, and in what manner.

Although originally developed for use in the Defense sector, these models are finding increasing use in other sectors of government, and may also be considered for use in non-government environments.

 8.2.4 Architecture Repository

As part of Phase B, the architecture team will need to consider what relevant Business Architecture resources are available from the Architecture Repository (see Part V, 41. Architecture Repository), in particular:

  • Generic business models relevant to the organization's industry sector. These are "Industry Architectures", in terms of the Enterprise Continuum. They are held in the Reference Library of the Architecture Repository (see Part V, 41.3 Reference Library). For example:
    • The Object Management Group (OMG) - www.omg.org - has a number of vertical Domain Task Forces developing business models relevant to specific vertical domains such as Healthcare, Transportation, Finance, etc.
    • The TeleManagement Forum (TMF) - www.tmforum.org - has developed detailed business models relevant to the Telecommunications industry.
    • Government departments and agencies in different countries have reference models and frameworks mandated for use, intended to promote cross-departmental integration and interoperability. An example is the Federal Enterprise Architecture Business Reference Model, which is a function-driven framework for describing the business operations of the Federal Government independent of the agencies that perform them.
  • Business models relevant to common high-level business domains. For example:
    • The Resource-Event-Agent (REA) business model was originally created by William E. McCarthy (refer to www.msu.edu/user/mccarth4) of Michigan State University, mainly for modeling of accounting systems. It has proved so useful for better understanding of business processes that it has become one of the major modeling frameworks for both traditional enterprises and e-Commerce systems.
    • The STEP Framework (STandard for the Exchange of Product model data) is concerned with product design and supply chain interworking. STEP is an ISO standard (ISO 10303). Implementation of the STEP standard has been led by some large aerospace manufacturers, and has also been taken up in other industries that have a need for complex graphic and process data, such as the construction industry.
    • RosettaNet - www.rosettanet.org - is a consortium created by leading companies in the computer, electronic component, and semiconductor manufacturing supply chains. Its mission is to develop a complete set of standard e-Business processes for these supply chains, and to promote and support their adoption and use.
  • Enterprise-specific building blocks (process components, business rules, job descriptions, etc.).
  • Applicable standards.

 8.3 Inputs

This section defines the inputs to Phase B.

 8.3.1 Reference Materials External to the Enterprise

 8.3.2 Non-Architectural Inputs

 8.3.3 Architectural Inputs

  • Organizational Model for Enterprise Architecture (see Part IV, 36.2.16 Organizational Model for Enterprise Architecture), including:
    • Scope of organizations impacted
    • Maturity assessment, gaps, and resolution approach
    • Roles and responsibilities for architecture team(s)
    • Constraints on architecture work
    • Budget requirements
    • Governance and support strategy
  • Tailored Architecture Framework (see Part IV, 36.2.21 Tailored Architecture Framework), including:
    • Tailored architecture method
    • Tailored architecture content (deliverables and artifacts)
    • Configured and deployed tools
  • Approved Statement of Architecture Work (see Part IV, 36.2.20 Statement of Architecture Work)
  • Architecture principles (see Part IV, 36.2.4 Architecture Principles), including business principles, when pre-existing
  • Enterprise Continuum (see Part V, 39. Enterprise Continuum)
  • Architecture Repository (see Part IV, 36.2.5 Architecture Repository), including:
    • Re-usable building blocks
    • Publicly available reference models
    • Organization-specific reference models
    • Organization standards
  • Architecture Vision (see Part IV, 36.2.8 Architecture Vision), including:
    • Problem description
    • Objective of the Statement of Architecture Work
    • Summary views
    • Business Scenario (optional)
    • Refined key high-level stakeholder requirements
  • Draft Architecture Definition Document, including (when in scope):
    • Baseline Business Architecture, Version 0.1
    • Baseline Technology Architecture, Version 0.1
    • Baseline Data Architecture, Version 0.1
    • Baseline Application Architecture, Version 0.1
    • Target Business Architecture, Version 0.1
    • Target Technology Architecture, Version 0.1
    • Target Data Architecture, Version 0.1
    • Target Application Architecture, Version 0.1

 8.4 Steps

The level of detail addressed in Phase B will depend on the scope and goals of the overall architecture effort.

New business processes being introduced as part of this effort will need to be defined in detail during Phase B. Existing business processes to be carried over and supported in the target environment may already have been adequately defined in previous architectural work; but, if not, they too will need to be defined in Phase B.

The order of the steps in Phase B (see below) as well as the time at which they are formally started and completed should be adapted to the situation at hand, in accordance with the established architecture governance. In particular, determine whether in this situation it is appropriate to conduct Baseline or Target Architecture development first, as described in Part III, 19. Applying Iteration to the ADM.

All activities that have been initiated in these steps must be closed during the Finalize the Business Architecture step (see 8.4.8 Finalize the Business Architecture). The documentation generated from these steps must be formally published in the Create Architecture Definition Document step (see 8.4.9 Create Architecture Definition Document).

The steps in Phase B are as follows:

 8.4.1 Select Reference Models, Viewpoints, and Tools

Select relevant Business Architecture resources (reference models, patterns, etc.) from the Architecture Repository, on the basis of the business drivers, and the stakeholders and concerns.

Select relevant Business Architecture viewpoints (e.g., operations, management, financial); i.e., those that will enable the architect to demonstrate how the stakeholder concerns are being addressed in the Business Architecture.

Identify appropriate tools and techniques to be used for capture, modeling, and analysis, in association with the selected viewpoints. Depending on the degree of sophistication warranted, these may comprise simple documents or spreadsheets, or more sophisticated modeling tools and techniques, such as activity models, business process models, use-case models, etc.

 8.4.1.1 Determine Overall Modeling Process

For each viewpoint, select the models needed to support the specific view required, using the selected tool or method.

Ensure that all stakeholder concerns are covered. If they are not, create new models to address concerns not covered, or augment existing models (see 8.2.3 Business Modeling). Business scenarios are a useful technique to discover and document business requirements, and may be used iteratively, at different levels of detail in the hierarchical decomposition of the Business Architecture. Business scenarios are described in Part III, 26. Business Scenarios and Business Goals.

Activity models, use-case models, and class models are mentioned earlier as techniques to enable the definition of an organization's business architecture. In many cases, all three approaches can be utilized in sequence to progressively decompose a business.

  • Structured Analysis: Identifies the key business functions within the scope of the architecture, and maps those functions onto the organizational units within the business.
  • Use-case Analysis: The breakdown of business-level functions across actors and organizations allows the actors in a function to be identified and permits a breakdown into services supporting/delivering that functional capability.
  • Process Modeling: The breakdown of a function or business service through process modeling allows the elements of the process to be identified, and permits the identification of lower-level business services or functions.

The level and rigor of decomposition needed varies from enterprise to enterprise, as well as within an enterprise, and the architect should consider the enterprise's goals, objectives, scope, and purpose of the enterprise architecture effort to determine the level of decomposition.

 8.4.1.2 Identify Required Service Granularity Level, Boundaries, and Contracts

The TOGAF content framework differentiates between the functions of a business and the services of a business. Business services are specific functions that have explicit, defined boundaries that are explicitly governed. In order to allow the architect flexibility to define business services at a level of granularity that is appropriate for and manageable by the business, the functions are split as follows: micro-level functions will have explicit, defined boundaries, but may not be explicitly governed. Likewise, macro business functions may be explicitly governed, but may not have explicit, defined boundaries.

The Business Architecture phase therefore needs to identify which components of the architecture are functions and which are services. Services are distinguished from functions through the explicit definition of a service contract. When Baseline Architectures are being developed, it may be the case that explicit contracts do not exist and it would therefore be at the discretion of the architect to determine whether there is merit in developing such contracts before examining any Target Architectures.

A service contract covers the business/functional interface and also the technology/data interface. Business Architecture will define the service contract at the business/functional level, which will be expanded on in the Application and Technology Architecture phases.

The granularity of business services should be determined according to the business drivers, goals, objectives, and measures for this area of the business. Finer-grained services permit closer management and measurement (and can be combined to create coarser-grained services), but require greater effort to govern. Guidelines for identification of services and definition of their contracts can be found in Part III, 22. Using TOGAF to Define & Govern SOAs.

 8.4.1.3 Identify Required Catalogs of Business Building Blocks

Catalogs capture inventories of the core assets of the business. Catalogs are hierarchical in nature and capture the decomposition of a building block and also decompositions across related building blocks (e.g., organization/actor).

Catalogs form the raw material for development of matrices and views and also act as a key resource for portfolio managing business and IT capability.

The following catalogs should be considered for development within a Business Architecture:

  • Organization/Actor catalog
  • Driver/Goal/Objective catalog
  • Role catalog
  • Business Service/Function catalog
  • Location catalog
  • Process/Event/Control/Product catalog
  • Contract/Measure catalog

The structure of catalogs is based on the attributes of metamodel entities, as defined in Part IV, 34. Content Metamodel.

 8.4.1.4 Identify Required Matrices

Matrices show the core relationships between related model entities.

Matrices form the raw material for development of views and also act as a key resource for impact assessment, carried out as a part of gap analysis.

The following matrices should be considered for development within a Business Architecture:

  • Business interaction matrix (showing dependency and communication between organizations and actors)
  • Actor/role matrix (showing the roles undertaken by each actor)

The structure of matrices is based on the attributes of metamodel entities, as defined in Part IV, 34. Content Metamodel.

 8.4.1.5 Identify Required Diagrams

Diagrams present the Business Architecture information from a set of different perspectives (viewpoints) according to the requirements of the stakeholders.

The following Diagrams should be considered for development within a Business Architecture:

  • Business Footprint diagram
  • Business Service/Information diagram
  • Functional Decomposition diagram
  • Goal/Objective/Service diagram
  • Use-case diagram
  • Organization Decomposition diagram
  • Process Flow diagram
  • Events diagram

The structure of diagrams is based on the attributes of metamodel entities, as defined in Part IV, 34. Content Metamodel.

 8.4.1.6 Identify Types of Requirement to be Collected

Once the Business Architecture catalogs, matrices, and diagrams have been developed, architecture modeling is completed by formalizing the business-focused requirements for implementing the Target Architecture.

These requirements may:

  • Relate to the business domain
  • Provide requirements input into the Data, Application, and Technology Architectures
  • Provide detailed guidance to be reflected during design and implementation to ensure that the solution addresses the original architecture requirements

Within this step, the architect should identify requirements that should be met by the architecture (see 17.2.2 Requirements Development).

In many cases, the Architecture Definition will not be intended to give detailed or comprehensive requirements for a solution (as these can be better addressed through general requirements management discipline). The expected scope of requirements content should be established during the Architecture Vision phase and documented in the approved Statement of Architecture Work.

Any requirement or change in requirement that is outside of the scope defined in the Statement of Architecture Work must be submitted to the Requirements Repository for management through the governed Requirements Management process.

 8.4.2 Develop Baseline Business Architecture Description

Develop a Baseline Description of the existing Business Architecture, to the extent necessary to support the Target Business Architecture. The scope and level of detail to be defined will depend on the extent to which existing business elements are likely to be carried over into the Target Business Architecture, and on whether architecture descriptions exist, as described in 8.2 Approach. To the extent possible, identify the relevant Business Architecture building blocks, drawing on the Architecture Repository (see Part V, 41. Architecture Repository).

Where new architecture models need to be developed to satisfy stakeholder concerns, use the models identified within Step 1 as a guideline for creating new architecture content to describe the Baseline Architecture.

 8.4.3 Develop Target Business Architecture Description

Develop a Target Description for the Business Architecture, to the extent necessary to support the Architecture Vision. The scope and level of detail to be defined will depend on the relevance of the business elements to attaining the Target Architecture Vision, and on whether architectural descriptions exist. To the extent possible, identify the relevant Business Architecture building blocks, drawing on the Architecture Repository (see Part V, 41. Architecture Repository).

Where new architecture models need to be developed to satisfy stakeholder concerns, use the models identified within Step 1 as a guideline for creating new architecture content to describe the Target Architecture.

 8.4.4 Perform Gap Analysis

Verify the architecture models for internal consistency and accuracy:

  • Perform trade-off analysis to resolve conflicts (if any) among the different views
  • Validate that the models support the principles, objectives, and constraints
  • Note changes to the viewpoint represented in the selected models from the Architecture Repository, and document
  • Test architecture models for completeness against requirements

Identify gaps between the baseline and target, using the Gap Analysis technique as described in Part III, 27. Gap Analysis.

 8.4.5 Define Candidate Roadmap Components

Following creation of a Baseline Architecture, Target Architecture, and gap analysis results, a business roadmap is required to prioritize activities over the coming phases.

This initial Business Architecture roadmap will be used as raw material to support more detailed definition of a consolidated, cross-discipline roadmap within the Opportunities & Solutions phase.

 8.4.6 Resolve Impacts Across the Architecture Landscape

Once the Business Architecture is finalized, it is necessary to understand any wider impacts or implications.

At this stage, other architecture artifacts in the Architecture Landscape should be examined to identify:

  • Does this Business Architecture create an impact on any pre-existing architectures?
  • Have recent changes been made that impact on the Business Architecture?
  • Are there any opportunities to leverage work from this Business Architecture in other areas of the organization?
  • Does this Business Architecture impact other projects (including those planned as well as those currently in progress)?
  • Will this Business Architecture be impacted by other projects (including those planned as well as those currently in progress)?

 8.4.7 Conduct Formal Stakeholder Review

Check the original motivation for the architecture project and the Statement of Architecture Work against the proposed Business Architecture, asking if it is fit for the purpose of supporting subsequent work in the other architecture domains. Refine the proposed Business Architecture only if necessary.

 8.4.8 Finalize the Business Architecture

  • Select standards for each of the building blocks, re-using as much as possible from the reference models selected from the Architecture Repository
  • Fully document each building block
  • Conduct final cross-check of overall architecture against business goals; document rationale for building block decisions in the architecture document
  • Document final requirements traceability report
  • Document final mapping of the architecture within the Architecture Repository; from the selected building blocks, identify those that might be re-used (working practices, roles, business relationships, job descriptions, etc.), and publish via the Architecture Repository
  • Finalize all the work products, such as gap analysis results

 8.4.9 Create Architecture Definition Document

  • Document rationale for building block decisions in the Architecture Definition Document
  • Prepare the business sections of the Architecture Definition Document, comprising some or all of:
    • A business footprint (a high-level description of the people and locations involved with key business functions)
    • A detailed description of business functions and their information needs
    • A management footprint (showing span of control and accountability)
    • Standards, rules, and guidelines showing working practices, legislation, financial measures, etc.
    • A skills matrix and set of job descriptions

    If appropriate, use reports and/or graphics generated by modeling tools to demonstrate key views of the architecture. Route the document for review by relevant stakeholders, and incorporate feedback.

     

 8.5 Outputs

The outputs of Phase B may include, but are not restricted to:

  • Refined and updated versions of the Architecture Vision phase deliverables, where applicable, including:
  • Draft Architecture Definition Document (see Part IV, 36.2.3 Architecture Definition Document), including:
    • Baseline Business Architecture, Version 1.0 (detailed), if appropriate
    • Target Business Architecture, Version 1.0 (detailed), including:
      • Organization structure - identifying business locations and relating them to organizational units
      • Business goals and objectives - for the enterprise and each organizational unit
      • Business functions - a detailed, recursive step involving successive decomposition of major functional areas into sub-functions
      • Business services - the services that the enterprise and each enterprise unit provides to its customers, both internally and externally
      • Business processes, including measures and deliverables
      • Business roles, including development and modification of skills requirements
      • Business data model
      • Correlation of organization and functions - relate business functions to organizational units in the form of a matrix report
    • Views corresponding to the selected viewpoints addressing key stakeholder concerns
  • Draft Architecture Requirements Specification (see Part IV, 36.2.6 Architecture Requirements Specification), including such Business Architecture requirements as:
    • Gap analysis results
    • Technical requirements - identifying, categorizing, and prioritizing the implications for work in the remaining architecture domains; for example, by a dependency/priority matrix (for example, guiding trade-off between speed of transaction processing and security); list the specific models that are expected to be produced (for example, expressed as primitives of the Zachman Framework)
    • Updated business requirements
  • Business Architecture components of an Architecture Roadmap (see Part IV, 36.2.7 Architecture Roadmap)

The outputs may include some or all of the following:

  • Catalogs:
    • Organization/Actor catalog
    • Driver/Goal/Objective catalog
    • Role catalog
    • Business Service/Function catalog
    • Location catalog
    • Process/Event/Control/Product catalog
    • Contract/Measure catalog
  • Matrices:
    • Business Interaction matrix
    • Actor/Role matrix
  • Diagrams:
    • Business Footprint diagram
    • Business Service/Information diagram
    • Functional Decomposition diagram
    • Product Lifecycle diagram
    • Goal/Objective/Service diagram
    • Use-case diagram
    • Organization Decomposition diagram
    • Process Flow diagram
    • Event diagram

Phase C: Information Systems Architectures

URL de origem: http://pubs.opengroup.org/architecture/togaf9-doc/arch/chap09.html
  Figure 9-1: Phase C: Information Systems Architectures

 9.1 Objectives

The objectives of Phase C are to:

  • Develop the Target Information Systems (Data and Application) Architecture, describing how the enterprise's Information Systems Architecture will enable the Business Architecture and the Architecture Vision, in a way that addresses the Request for Architecture Work and stakeholder concerns
  • Identify candidate Architecture Roadmap components based upon gaps between the Baseline and Target Information Systems (Data and Application) Architectures

 9.2 Approach

Phase C involves some combination of Data and Application Architecture, in either order. Advocates exist for both sequences. For example, Steven Spewak's Enterprise Architecture Planning (EAP) recommends a data-driven approach.

On the other hand, major applications systems - such as those for Enterprise Resource Planning (ERP), Customer Relationship Management (CRM), etc. - often provide a combination of technology infrastructure and business application logic, and some organizations take an application-driven approach, whereby they recognize certain key applications as forming the core underpinning of the mission-critical business processes, and take the implementation and integration of those core applications as the primary focus of architecture effort (the integration issues often constituting a major challenge).

 9.3 Inputs

This section defines the inputs to Phase C.

 9.3.1 Reference Materials External to the Enterprise

 9.3.2 Non-Architectural Inputs

 9.3.3 Architectural Inputs

 9.4 Steps

Detailed steps for Phase C are given separately for each architecture domain:

 9.5 Outputs

The main outputs of Phase C are:

  • Refined and updated versions of the Architecture Vision phase deliverables, where applicable, including:
  • Draft Architecture Definition Document (see Part IV, 36.2.3 Architecture Definition Document), including:
    • Baseline Data Architecture, Version 1.0
    • Target Data Architecture, Version 1.0
    • Baseline Application Architecture, Version 1.0
    • Target Application Architecture, Version 1.0
    • Data Architecture views corresponding to the selected viewpoints addressing key stakeholder concerns
    • Application Architecture views corresponding to the selected viewpoints addressing key stakeholder concerns
  • Draft Architecture Requirements Specification (see Part IV, 36.2.6 Architecture Requirements Specification), including such Information Systems Architecture requirements as:
    • Gap analysis results
    • Relevant technical requirements that will apply to this evolution of the architecture development cycle
    • Constraints on the Technology Architecture about to be designed
    • Updated business requirements, if appropriate
  • Information systems components of an Architecture Roadmap (see Part IV, 36.2.7 Architecture Roadmap)

Phase C: Information Systems Architectures - Data Architecture

URL de origem: http://pubs.opengroup.org/architecture/togaf9-doc/arch/chap10.html

10.1 Objectives

The objectives of the Data Architecture part of Phase C are to:

  • Develop the Target Data Architecture that enables the Business Architecture and the Architecture Vision, while addressing the Request for Architecture Work and stakeholder concerns
  • Identify candidate Architecture Roadmap components based upon gaps between the Baseline and Target Data Architectures

 10.2 Approach

 10.2.1 Key Considerations for Data Architecture

 10.2.1.1 Data Management

When an enterprise has chosen to undertake largescale architectural transformation, it is important to understand and address data management issues. A structured and comprehensive approach to data management enables the effective use of data to capitalize on its competitive advantages.

Considerations include:

  • A clear definition of which application components in the landscape will serve as the system of record or reference for enterprise master data
  • Will there be an enterprise-wide standard that all application components, including software packages, need to adopt (in the main packages can be prescriptive about the data models and may not be flexible)?
  • Clearly understand how data entities are utilized by business functions, processes, and services
  • Clearly understand how and where enterprise data entities are created, stored, transported, and reported
  • What is the level and complexity of data transformations required to support the information exchange needs between applications?
  • What will be the requirement for software in supporting data integration with the enterprise's customers and suppliers (e.g., use of ETL tools during the data migration, data profiling tools to evaluate data quality, etc.)?
 10.2.1.2 Data Migration

When an existing application is replaced, there will be a critical need to migrate data (master, transactional, and reference) to the new application. The Data Architecture should identify data migration requirements and also provide indicators as to the level of transformation, weeding, and cleansing that will be required to present data in a format that meets the requirements and constraints of the target application. The objective being that the target application has quality data when it is populated. Another key consideration is to ensure that an enterprise-wide common data definition is established to support the transformation.

 10.2.1.3 Data Governance

Data governance considerations ensure that the enterprise has the necessary dimensions in place to enable the transformation, as follows:

  • Structure: This dimension pertains to whether the enterprise has the necessary organizational structure and the standards bodies to manage data entity aspects of the transformation.
  • Management System: Here enterprises should have the necessary management system and data-related programs to manage the governance aspects of data entities throughout its lifecycle.
  • People: This dimension addresses what data-related skills and roles the enterprise requires for the transformation. If the enterprise lacks such resources and skills, the enterprise should consider either acquiring those critical skills or training existing internal resources to meet the requirements through a well-defined learning program.

 10.2.2 Architecture Repository

As part of this phase, the architecture team will need to consider what relevant Data Architecture resources are available in the organization's Architecture Repository (see Part V, 41. Architecture Repository), in particular, generic data models relevant to the organization's industry "vertical" sector. For example:

  • ARTS has defined a data model for the Retail industry.
  • Energistics has defined a data model for the Petrotechnical industry.

 10.3 Inputs

This section defines the inputs to Phase C (Data Architecture).

 10.3.1 Reference Materials External to the Enterprise

 10.3.2 Non-Architectural Inputs

 10.3.3 Architectural Inputs

  • Organizational Model for Enterprise Architecture (see Part IV, 36.2.16 Organizational Model for Enterprise Architecture), including:
    • Scope of organizations impacted
    • Maturity assessment, gaps, and resolution approach
    • Roles and responsibilities for architecture team(s)
    • Constraints on architecture work
    • Budget requirements
    • Governance and support strategy
  • Tailored Architecture Framework (see Part IV, 36.2.21 Tailored Architecture Framework), including:
    • Tailored architecture method
    • Tailored architecture content (deliverables and artifacts)
    • Configured and deployed tools
  • Data principles (see Part III, 23.6.2 Data Principles), if existing
  • Statement of Architecture Work (see Part IV, 36.2.20 Statement of Architecture Work)
  • Architecture Vision (see Part IV, 36.2.8 Architecture Vision)
  • Architecture Repository (see Part IV, 36.2.5 Architecture Repository), including:
    • Re-usable building blocks (in particular, definitions of current data)
    • Publicly available reference models
    • Organization-specific reference models
    • Organization standards
  • Draft Architecture Definition Document (see Part IV, 36.2.3 Architecture Definition Document), including:
    • Baseline Business Architecture, Version 1.0 (detailed), if appropriate
    • Target Business Architecture, Version 1.0 (detailed)
    • Baseline Data Architecture, Version 0.1, if available
    • Target Data Architecture, Version 0.1, if available
    • Baseline Application Architecture, Version 1.0 (detailed) or Version 0.1 (Vision)
    • Target Application Architecture, Version 1.0 (detailed) or Version 0.1 (Vision)
    • Baseline Technology Architecture, Version 0.1 (Vision)
    • Target Technology Architecture, Version 0.1 (Vision)
  • Draft Architecture Requirements Specification (see Part IV, 36.2.6 Architecture Requirements Specification), including:
    • Gap analysis results (from Business Architecture)
    • Relevant technical requirements that will apply to this phase
  • Business Architecture components of an Architecture Roadmap (see Part IV, 36.2.7 Architecture Roadmap)

 10.4 Steps

The level of detail addressed in Phase C will depend on the scope and goals of the overall architecture effort.

New data building blocks being introduced as part of this effort will need to be defined in detail during Phase C. Existing data building blocks to be carried over and supported in the target environment may already have been adequately defined in previous architectural work; but, if not, they too will need to be defined in Phase C.

The order of the steps in this phase (see below) as well as the time at which they are formally started and completed should be adapted to the situation at hand in accordance with the established architecture governance. In particular, determine whether in this situation it is appropriate to conduct Baseline Description or Target Architecture development first, as described in Part III, 19. Applying Iteration to the ADM.

All activities that have been initiated in these steps must be closed during the Finalize the Data Architecture step (see 10.4.8 Finalize the Data Architecture). The documentation generated from these steps must be formally published in the Create Architecture Definition Document step (see 10.4.9 Create Architecture Definition Document.

The steps in Phase C (Data Architecture) are as follows:

 10.4.1 Select Reference Models, Viewpoints, and Tools

Review and validate (or generate, if necessary) the set of data principles. These will normally form part of an overarching set of architecture principles. Guidelines for developing and applying principles, and a sample set of data principles, are given in Part III, 23. Architecture Principles.

Select relevant Data Architecture resources (reference models, patterns, etc.) on the basis of the business drivers, stakeholders, concerns, and Business Architecture.

Select relevant Data Architecture viewpoints (for example, stakeholders of the data - regulatory bodies, users, generators, subjects, auditors, etc.; various time dimensions - real-time, reporting period, event-driven, etc.; locations; business processes); i.e., those that will enable the architect to demonstrate how the stakeholder concerns are being addressed in the Data Architecture.

Identify appropriate tools and techniques (including forms) to be used for data capture, modeling, and analysis, in association with the selected viewpoints. Depending on the degree of sophistication warranted, these may comprise simple documents or spreadsheets, or more sophisticated modeling tools and techniques such as data management models, data models, etc. Examples of data modeling techniques are:

  • Entity-relationship diagram
  • Class diagrams
 10.4.1.1 Determine Overall Modeling Process

For each viewpoint, select the models needed to support the specific view required, using the selected tool or method.

Ensure that all stakeholder concerns are covered. If they are not, create new models to address concerns not covered, or augment existing models (see above).

The recommended process for developing a Data Architecture is as follows:

  • Collect data-related models from existing Business Architecture and Application Architecture materials
  • Rationalize data requirements and align with any existing enterprise data catalogs and models; this allows the development of a data inventory and entity relationship
  • Update and develop matrices across the architecture by relating data to business service, business function, access rights, and application
  • Elaborate Data Architecture views by examining how data is created, distributed, migrated, secured, and archived
 10.4.1.2 Identify Required Catalogs of Data Building Blocks

The organization's data inventory is captured as a catalog within the Architecture Repository. Catalogs are hierarchical in nature and capture a decomposition of a metamodel entity and also decompositions across related model entities (e.g., logical data component -> physical data component ->] data entity).

Catalogs form the raw material for development of matrices and diagrams and also act as a key resource for portfolio managing business and IT capability.

During the Business Architecture phase, a Business Service/Information diagram was created showing the key data entities required by the main business services. This is a prerequisite to successful Data Architecture activities.

Using the traceability from application to business function to data entity inherent in the content framework, it is possible to create an inventory of the data needed to be in place to support the Architecture Vision.

Once the data requirements are consolidated in a single location, it is possible to refine the data inventory to achieve semantic consistency and to remove gaps and overlaps.

The following catalogs should be considered for development within a Data Architecture:

  • Data Entity/Data Component catalog

The structure of catalogs is based on the attributes of metamodel entities, as defined in Part IV, 34. Content Metamodel.

 10.4.1.3 Identify Required Matrices

Matrices show the core relationships between related model entities.

Matrices form the raw material for development of diagrams and also act as a key resource for impact assessment.

At this stage, an entity to applications matrix could be produced to validate this mapping. How data is created, maintained, transformed, and passed to other applications, or used by other applications, will now start to be understood. Obvious gaps such as entities that never seem to be created by an application or data created but never used, need to be noted for later gap analysis.

The rationalized data inventory can be used to update and refine the architectural diagrams of how data relates to other aspects of the architecture.

Once these updates have been made, it may be appropriate to drop into a short iteration of Application Architecture to resolve the changes identified.

The following matrices should be considered for development within a Data Architecture:

  • Data Entity/Business Function (showing which data supports which functions and which business function owns which data)
  • Business Service/Information (developed during the Business Architecture phase)
  • Application/Data (developed across the Application Architecture and Data Architecture phases)

The structure of matrices is based on the attributes of metamodel entities, as defined in Part IV, 34. Content Metamodel.

 10.4.1.4 Identify Required Diagrams

Diagrams present the Data Architecture information from a set of different perspectives (viewpoints) according to the requirements of the stakeholders.

Once the data entities have been refined, a diagram of the relationships between entities and their attributes can be produced.

It is important to note at this stage that information may be a mixture of enterprise-level data (from system service providers and package vendor information) and local-level data held in personal databases and spreadsheets.

The level of detail modeled needs to be carefully assessed. Some physical system data models will exist down to a very detailed level; others will only have core entities modeled. Not all data models will have been kept up-to-date as applications were modified and extended over time. It is important to achieve a balance in the level of detail provided (e.g., reproducing existing detailed system physical data schemas or presenting high-level process maps and data requirements, highlight the two extreme views).

The following diagrams should be considered for development within a Data Architecture:

  • Conceptual Data diagram
  • Logical Data diagram
  • Data Dissemination diagram
  • Data Lifecycle diagram
  • Data Security diagram
  • Data Migration diagram
 10.4.1.5 Identify Types of Requirement to be Collected

Once the Data Architecture catalogs, matrices, and diagrams have been developed, architecture modeling is completed by formalizing the data-focused requirements for implementing the Target Architecture.

These requirements may:

  • Relate to the data domain
  • Provide requirements input into the Application, and Technology Architectures
  • Provide detailed guidance to be reflected during design and implementation to ensure that the solution addresses the original architecture requirements

Within this step, the architect should identify requirements that should be met by the architecture (see 17.2.2 Requirements Development).

 10.4.2 Develop Baseline Data Architecture Description

Develop a Baseline Description of the existing Data Architecture, to the extent necessary to support the Target Data Architecture. The scope and level of detail to be defined will depend on the extent to which existing data elements are likely to be carried over into the Target Data Architecture, and on whether architectural descriptions exist, as described in 10.2 Approach. To the extent possible, identify the relevant Data Architecture building blocks, drawing on the Architecture Repository (see Part V, 41. Architecture Repository).

Where new architecture models need to be developed to satisfy stakeholder concerns, use the models identified within Step 1 as a guideline for creating new architecture content to describe the Baseline Architecture.

 10.4.3 Develop Target Data Architecture Description

Develop a Target Description for the Data Architecture, to the extent necessary to support the Architecture Vision and Target Business Architecture. The scope and level of detail to be defined will depend on the relevance of the data elements to attaining the Target Architecture, and on whether architectural descriptions exist. To the extent possible, identify the relevant Data Architecture building blocks, drawing on the Architecture Repository (see Part V, 41. Architecture Repository).

Where new architecture models need to be developed to satisfy stakeholder concerns, use the models identified within Step 1 as a guideline for creating new architecture content to describe the Target Architecture.

 10.4.4 Perform Gap Analysis

Verify the architecture models for internal consistency and accuracy:

  • Perform trade-off analysis to resolve conflicts (if any) among the different views
  • Validate that the models support the principles, objectives, and constraints
  • Note changes to the viewpoint represented in the selected models from the Architecture Repository, and document
  • Test architecture models for completeness against requirements

Identify gaps between the baseline and target, using the Gap Analysis technique as described in Part III, 27. Gap Analysis.

 10.4.5 Define Candidate Roadmap Components

Following creation of a Baseline Architecture, Target Architecture, and gap analysis, a data roadmap is required to prioritize activities over the coming phases.

This initial Data Architecture roadmap will be used as raw material to support more detailed definition of a consolidated, cross-discipline roadmap within the Opportunities & Solutions phase.

 10.4.6 Resolve Impacts Across the Architecture Landscape

Once the Data Architecture is finalized, it is necessary to understand any wider impacts or implications.

At this stage, other architecture artifacts in the Architecture Landscape should be examined to identify:

  • Does this Data Architecture create an impact on any pre-existing architectures?
  • Have recent changes been made that impact the Data Architecture?
  • Are there any opportunities to leverage work from this Data Architecture in other areas of the organization?
  • Does this Data Architecture impact other projects (including those planned as well as those currently in progress)?
  • Will this Data Architecture be impacted by other projects (including those planned as well as those currently in progress)?

 10.4.7 Conduct Formal Stakeholder Review

Check the original motivation for the architecture project and the Statement of Architecture Work against the proposed Data Architecture. Conduct an impact analysis to identify any areas where the Business and Application Architectures (e.g., business practices) may need to change to cater for changes in the Data Architecture (for example, changes to forms or procedures, applications, or database systems).

If the impact is significant, this may warrant the Business and Application Architectures being revisited.

Identify any areas where the Application Architecture (if generated at this point) may need to change to cater for changes in the Data Architecture (or to identify constraints on the Application Architecture about to be designed).

If the impact is significant, it may be appropriate to drop into a short iteration of the Application Architecture at this point.

Identify any constraints on the Technology Architecture about to be designed, refining the proposed Data Architecture only if necessary.

 10.4.8 Finalize the Data Architecture

  • Select standards for each of the building blocks, re-using as much as possible from the reference models selected from the Architecture Repository
  • Fully document each building block
  • Conduct final cross-check of overall architecture against business requirements; document rationale for building block decisions in the architecture document
  • Document final requirements traceability report
  • Document final mapping of the architecture within the Architecture Repository; from the selected building blocks, identify those that might be re-used, and publish via the Architecture Repository
  • Finalize all the work products, such as gap analysis

 10.4.9 Create Architecture Definition Document

Document rationale for building block decisions in the Architecture Definition Document.

Prepare Data Architecture sections of the Architecture Definition Document, comprising some or all of:

  • Business data model
  • Logical data model
  • Data management process model
  • Data Entity/Business Function matrix
  • Data interoperability requirements (e.g., XML schema, security policies)
  • If appropriate, use reports and/or graphics generated by modeling tools to demonstrate key views of the architecture; route the document for review by relevant stakeholders, and incorporate feedback

 10.5 Outputs

The outputs of Phase C (Data Architecture) may include, but are not restricted to:

  • Refined and updated versions of the Architecture Vision phase deliverables, where applicable:
  • Draft Architecture Definition Document (see Part IV, 36.2.3 Architecture Definition Document), including:
    • Baseline Data Architecture, Version 1.0, if appropriate
    • Target Data Architecture, Version 1.0
      • Business data model
      • Logical data model
      • Data management process models
      • Data Entity/Business Function matrix
    • Views corresponding to the selected viewpoints addressing key stakeholder concerns
  • Draft Architecture Requirements Specification (see Part IV, 36.2.6 Architecture Requirements Specification), including such Data Architecture requirements as:
    • Gap analysis results
    • Data interoperability requirements
    • Relevant technical requirements that will apply to this evolution of the architecture development cycle
    • Constraints on the Technology Architecture about to be designed
    • Updated business requirements, if appropriate
    • Updated application requirements, if appropriate
  • Data Architecture components of an Architecture Roadmap (see Part IV, 36.2.7 Architecture Roadmap)

The outputs may include some or all of the following:

  • Catalogs:
    • Data Entity/Data Component catalog
  • Matrices:
    • Data Entity/Business Function matrix
    • Application/Data matrix
  • Diagrams:
    • Conceptual Data diagram
    • Logical Data diagram
    • Data Dissemination diagram
    • Data Security diagram
    • Data Migration diagram
    • Data Lifecycle diagram

Phase C: Information Systems Architectures - Application Architecture

URL de origem: http://pubs.opengroup.org/architecture/togaf9-doc/arch/chap11.html

11.1 Objectives

The objectives of the Application Architecture part of Phase C are to:

  • Develop the Target Application Architecture that enables the Business Architecture and the Architecture Vision, while addressing the Request for Architecture Work and stakeholder concerns
  • Identify candidate Architecture Roadmap components based upon gaps between the Baseline and Target Application Architectures

 11.2 Approach

 11.2.1 Architecture Repository

As part of this phase, the architecture team will need to consider what relevant Application Architecture resources are available in the Architecture Repository (see Part V, 41. Architecture Repository).

In particular:

  • Generic business models relevant to the organization's industry "vertical" sector; for example:
    • The TeleManagement Forum (TMF) - www.tmforum.org - has developed detailed applications models relevant to the Telecommunications industry.
    • The Object Management Group (OMG) - www.omg.org - has a number of vertical Domain Task Forces developing software models relevant to specific vertical domains such as Healthcare, Transportation, Finance, etc.
  • Application models relevant to common high-level business functions, such as electronic commerce, supply chain management, etc.

The Open Group has a Reference Model for Integrated Information Infrastructure (III-RM) - see Part VI, 44. Integrated Information Infrastructure Reference Model - that focuses on the application-level components and services necessary to provide an integrated information infrastructure.

 11.3 Inputs

This section defines the inputs to Phase C (Application Architecture).

 11.3.1 Reference Materials External to the Enterprise

 11.3.2 Non-Architectural Inputs

 11.3.3 Architectural Inputs

  • Organizational Model for Enterprise Architecture (see Part IV, 36.2.16 Organizational Model for Enterprise Architecture), including:
    • Scope of organizations impacted
    • Maturity assessment, gaps, and resolution approach
    • Roles and responsibilities for architecture team(s)
    • Constraints on architecture work
    • Budget requirements
    • Governance and support strategy
  • Tailored Architecture Framework (see Part IV, 36.2.21 Tailored Architecture Framework), including:
    • Tailored architecture method
    • Tailored architecture content (deliverables and artifacts)
    • Configured and deployed tools
  • Application principles (see Part III, 23.6.3 Application Principles), if existing
  • Statement of Architecture Work (see Part IV, 36.2.20 Statement of Architecture Work)
  • Architecture Vision (see Part IV, 36.2.8 Architecture Vision)
  • Architecture Repository (see Part IV, 36.2.5 Architecture Repository), including:
    • Re-usable building blocks
    • Publicly available reference models
    • Organization-specific reference models
    • Organization standards
  • Draft Architecture Definition Document (see Part IV, 36.2.3 Architecture Definition Document), including:
    • Baseline Business Architecture, Version 1.0 (detailed), if appropriate
    • Target Business Architecture, Version 1.0 (detailed)
    • Baseline Data Architecture, Version 1.0 (detailed), or Version 0.1 (Vision)
    • Target Data Architecture, Version 1.0 (detailed), or Version 0.1 (Vision)
    • Baseline Application Architecture, Version 0.1, if appropriate and if available
    • Target Application Architecture, Version 0.1, if available
    • Baseline Technology Architecture, Version 0.1 (Vision)
    • Target Technology Architecture, Version 0.1 (Vision)
  • Draft Architecture Requirements Specification (see Part IV, 36.2.6 Architecture Requirements Specification), including:
    • Gap analysis results (from Business Architecture and Data Architecture, if available)
    • Relevant technical requirements that will apply to this phase
  • Business and Data Architecture components of an Architecture Roadmap, if available (see Part IV, 36.2.7 Architecture Roadmap)

 11.4 Steps

The level of detail addressed in Phase C will depend on the scope and goals of the overall architecture effort.

New application building blocks being introduced as part of this effort will need to be defined in detail during Phase C. Existing application building blocks to be carried over and supported in the target environment may already have been adequately defined in previous architectural work; but, if not, they too will need to be defined in Phase C.

The order of the steps in this phase (see below as well as the time at which they are formally started and completed should be adapted to the situation at hand in accordance with the established architecture governance. In particular, determine whether in this situation it is appropriate to conduct Baseline Description or Target Architecture development first, as described in Part III, 19. Applying Iteration to the ADM.

All activities that have been initiated in these steps must be closed during the Finalize the Application Architecture step (see 11.4.8 Finalize the Application Architecture). The documentation generated from these steps must be formally published in the Create Architecture Definition Document step (see 11.4.9 Create Architecture Definition Document).

The steps in Phase C (Application Architecture) are as follows:

 11.4.1 Select Reference Models, Viewpoints, and Tools

Review and validate (or generate, if necessary) the set of application principles. These will normally form part of an overarching set of architecture principles. Guidelines for developing and applying principles, and a sample set of application principles, are given in Part III, 23. Architecture Principles.

Select relevant Application Architecture resources (reference models, patterns, etc.) from the Architecture Repository, on the basis of the business drivers, the stakeholders, and their concerns.

Select relevant Application Architecture viewpoints (for example, stakeholders of the applications - viewpoints relevant to functional and individual users of applications, etc.); i.e., those that will enable the architect to demonstrate how the stakeholder concerns are being addressed in the Application Architecture.

Identify appropriate tools and techniques to be used for capture, modeling, and analysis, in association with the selected viewpoints. Depending on the degree of sophistication warranted, these may comprise simple documents or spreadsheets, or more sophisticated modeling tools and techniques.

Consider using platform-independent descriptions of business logic. For example, the OMG's Model Driven Architecture (MDA) offers an approach to modeling Application Architectures that preserves the business logic from changes to the underlying platform and implementation technology.

 11.4.1.1 Determine Overall Modeling Process

For each viewpoint, select the models needed to support the specific view required, using the selected tool or method.

Ensure that all stakeholder concerns are covered. If they are not, create new models to address concerns not covered, or augment existing models (see above).

The recommended process for developing an Application Architecture is as follows:

  • Understand the list of applications or application components that are required, based on the baseline Application Portfolio, what the requirements are, and the business architecture scope
  • Simplify complicated applications by decomposing them into two or more applications
  • Ensure that the set of application definitions is internally consistent, by removing duplicate functionality as far as possible, and combining similar applications into one
  • Identify logical applications and the most appropriate physical applications
  • Develop matrices across the architecture by relating applications to business service, business function, data, process, etc.
  • Elaborate a set of Application Architecture views by examining how the application will function, capturing integration, migration, development, and operational concerns

The level and rigor of decomposition needed varies from enterprise to enterprise, as well as within an enterprise, and the architect should consider the enterprise's goals, objectives, scope, and purpose of the enterprise architecture effort to determine the level of decomposition.

The level of granularity should be sufficient to enable identification of gaps and the scope of candidate work packages.

 11.4.1.2 Identify Required Catalogs of Application Building Blocks

The organization's Application Portfolio is captured as a catalog within the Architecture Repository. Catalogs are hierarchical in nature and capture a decomposition of a metamodel entity and also decompositions across related model entities (e.g., logical application component -> physical application component ->] information system service).

Catalogs form the raw material for development of matrices and diagrams and also act as a key resource for portfolio managing business and IT capability.

The structure of catalogs is based on the attributes of metamodel entities, as defined in Part IV, 34. Content Metamodel.

The following catalogs should be considered for development within an Application Architecture:

  • Application Portfolio catalog
  • Interface catalog
 11.4.1.3 Identify Required Matrices

Matrices show the core relationships between related model entities.

Matrices form the raw material for development of diagrams and also act as a key resource for impact assessment.

Once the baseline Application Portfolio has been assembled, it is necessary to map the applications to their purpose in supporting the business. The initial mapping should focus on business services within the Business Architecture, as this is the level of granularity where architecturally significant decisions are most likely to be needed.

Once applications are mapped to business services, it will also be possible to make associations from applications to data, through the business-information diagrams developed during Business Architecture.

If readily available, baseline application data models may be used to validate the Business Architecture and also to identify which data is held locally and which is accessed remotely.

The Data Architecture phase will focus on these issues, so at this point it may be appropriate to drop into a short iteration of Data Architecture if it is deemed to be valuable to scope of the architecture engagement.

Using existing information in the baseline application catalog, the Application Architecture should identify user and organizational dependencies on applications. This activity will support future state planning by determining impacted user communities and also facilitating the grouping of application by user type or user location.

A key user community to be specifically considered is the operational support organization. This activity should examine application dependencies on shared operations capabilities and produce a diagram on how each application is effectively operated and managed.

Specifically considering the needs of the operational community may identify requirements for new or extended governance capabilities and applications.

The following matrices should be considered for development within an Application Architecture:

  • Application/Organization matrix
  • Role/Application matrix
  • Application Interaction matrix
  • Application/Function matrix

The structure of matrices is based on the attributes of metamodel entities, as defined in Part IV, 34. Content Metamodel.

 11.4.1.4 Identify Required Diagrams

Diagrams present the Application Architecture information from a set of different perspectives (viewpoints) according to the requirements of the stakeholders.

Once the desired functionality of an application is known, it is necessary to perform an internal assessment of how the application should be best structured to meet its requirements.

In the case of packaged applications, it is likely to be the case that the application supports a number of configuration options, add-on modules, or application services that may be applied to the solution. For custom developed applications, it is necessary to identify the high-level structure of the application in terms of modules or sub-systems as a foundation to organize design activity.

The following diagrams should be considered for development within an Application Architecture:

  • Application Communication diagram
  • Application and User Location diagram
  • Enterprise Manageability diagram
  • Process/Application Realization diagram
  • Application Migration diagram
  • Software Distribution diagram
  • Software Engineering diagram
  • Application Use-Case diagram

The structure of diagrams is based on the attributes of metamodel entities, as defined in Part IV, 34. Content Metamodel.

 11.4.1.5 Identify Types of Requirement to be Collected

Once the Application Architecture catalogs, matrices, and diagrams have been developed, architecture modeling is completed by formalizing the application-focused requirements for implementing the Target Architecture.

These requirements may:

  • Relate to the application domain
  • Provide requirements input into the Data and Technology Architectures
  • Provide detailed guidance to be reflected during design and implementation to ensure that the solution addresses the original architecture requirements

Within this step, the architect should identify requirements that should be met by the architecture (see 17.2.2 Requirements Development).

 11.4.2 Develop Baseline Application Architecture Description

Develop a Baseline Description of the existing Application Architecture, to the extent necessary to support the Target Application Architecture. The scope and level of detail to be defined will depend on the extent to which existing applications are likely to be carried over into the Target Application Architecture, and on whether architecture descriptions exist, as described in 11.2 Approach. To the extent possible, identify the relevant Application Architecture building blocks, drawing on the Architecture Repository (see Part V, 41. Architecture Repository). If not already existing within the Architecture Repository, define each application in line with the Application Portfolio catalog (see Part IV, 34. Content Metamodel).

Where new architecture models need to be developed to satisfy stakeholder concerns, use the models identified within Step 1 as a guideline for creating new architecture content to describe the Baseline Architecture.

 11.4.3 Develop Target Application Architecture Description

Develop a Target Description for the Application Architecture, to the extent necessary to support the Architecture Vision, Target Business Architecture, and Target Data Architecture. The scope and level of detail to be defined will depend on the relevance of the applications elements to attaining the Target Architecture Vision, and on whether architectural descriptions exist. To the extent possible, identify the relevant Application Architecture building blocks, drawing on the Architecture Repository (see Part V, 41. Architecture Repository).

Where new architecture models need to be developed to satisfy stakeholder concerns, use the models identified within Step 1 as a guideline for creating new architecture content to describe the Target Architecture.

 11.4.4 Perform Gap Analysis

Verify the architecture models for internal consistency and accuracy:

  • Perform trade-off analysis to resolve conflicts (if any) among the different views
  • Validate that the models support the principles, objectives, and constraints
  • Note changes to the viewpoint represented in the selected models from the Architecture Repository, and document
  • Test architecture models for completeness against requirements

Identify gaps between the baseline and target, using the Gap Analysis technique as described in Part III, 27. Gap Analysis.

 11.4.5 Define Candidate Roadmap Components

Following creation of a Baseline Architecture, Target Architecture, and gap analysis, an application roadmap is required to prioritize activities over the coming phases.

This initial Application Architecture roadmap will be used as raw material to support more detailed definition of a consolidated, cross-discipline roadmap within the Opportunities & Solutions phase.

 11.4.6 Resolve Impacts Across the Architecture Landscape

Once the Application Architecture is finalized, it is necessary to understand any wider impacts or implications.

At this stage, other architecture artifacts in the Architecture Landscape should be examined to identify:

  • Does this Application Architecture create an impact on any pre-existing architectures?
  • Have recent changes been made that impact the Application Architecture?
  • Are there any opportunities to leverage work from this Application Architecture in other areas of the organization?
  • Does this Application Architecture impact other projects (including those planned as well as those currently in progress)?
  • Will this Application Architecture be impacted by other projects (including those planned as well as those currently in progress)?

 11.4.7 Conduct Formal Stakeholder Review

Check the original motivation for the architecture project and the Statement of Architecture Work against the proposed Application Architecture. Conduct an impact analysis, to identify any areas where the Business and Data Architectures (e.g., business practices) may need to change to cater for changes in the Application Architecture (for example, changes to forms or procedures, applications, or database systems). If the impact is significant, this may warrant the Business and Data Architectures being revisited.

Identify any constraints on the Technology Architecture (especially the infrastructure) about to be designed.

 11.4.8 Finalize the Application Architecture

  • Select standards for each of the building blocks, re-using as much as possible from the reference models selected from the Architecture Repository
  • Fully document each building block
  • Conduct final cross-check of overall architecture against business requirements; document rationale for building block decisions in the architecture document
  • Document final requirements traceability report
  • Document final mapping of the architecture within the Architecture Repository; from the selected building blocks, identify those that might be re-used, and publish via the Architecture Repository
  • Finalize all the work products, such as gap analysis

 11.4.9 Create Architecture Definition Document

  • Document rationale for building block decisions in the Architecture Definition Document
  • Prepare Application Architecture sections of the Architecture Definition Document; if appropriate, use reports and/or graphics generated by modeling tools to demonstrate key views of the architecture; route the document for review by relevant stakeholders, and incorporate feedback

 11.5 Outputs

The outputs of Phase C (Application Architecture) may include, but are not restricted to:

  • Refined and updated versions of the Architecture Vision phase deliverables, where applicable:
  • Draft Architecture Definition Document (see Part IV, 36.2.3 Architecture Definition Document), including:
    • Baseline Application Architecture, Version 1.0, if appropriate
    • Target Application Architecture, Version 1.0
      • Process systems model
      • Place systems model
      • Time systems model
      • People systems model
    • Views corresponding to the selected viewpoints, addressing key stakeholder concerns
  • Draft Architecture Requirements Specification (see Part IV, 36.2.6 Architecture Requirements Specification), including such Application Architecture requirements as:
    • Gap analysis results
    • Applications interoperability requirements
    • Relevant technical requirements that will apply to this evolution of the architecture development cycle
    • Constraints on the Technology Architecture about to be designed
    • Updated business requirements, if appropriate
    • Updated data requirements, if appropriate
  • Application Architecture components of an Architecture Roadmap (see Part IV, 36.2.7 Architecture Roadmap)

The outputs may include some or all of the following:

  • Catalogs:
    • Application Portfolio catalog
    • Interface catalog
  • Matrices:
    • Application/Organization matrix
    • Role/Application matrix
    • Application/Function matrix
    • Application Interaction matrix
  • Diagrams:
    • Application Communication diagram
    • Application and User Location diagram
    • Application Use-Case diagram
    • Enterprise Manageability diagram
    • Process/Application Realization diagram
    • Software Engineering diagram
    • Application Migration diagram
    • Software Distribution diagram

Phase D: Technology Architecture

URL de origem: http://pubs.opengroup.org/architecture/togaf9-doc/arch/chap12.html
  Figure 12-1: Phase D: Technology Architecture

 12.1 Objectives

The objectives of Phase D are to:

  • Develop the Target Technology Architecture that enables the logical and physical application and data components and the Architecture Vision, addressing the Request for Architecture Work and stakeholder concerns
  • Identify candidate Architecture Roadmap components based upon gaps between the Baseline and Target Technology Architectures

 12.2 Approach

 12.2.1 Architecture Repository

As part of Phase D, the architecture team will need to consider what relevant Technology Architecture resources are available in the Architecture Repository (see Part V, 41. Architecture Repository).

In particular:

  • Existing IT services as documented in the IT repository or IT service catalog
  • TOGAF Technical Reference Model (TRM)
  • Generic technology models relevant to the organization's industry "vertical" sector

    For example, the TeleManagement Forum (TMF) - www.tmforum.org - has developed detailed technology models relevant to the Telecommunications industry.

  • Technology models relevant to Common Systems Architectures

    For example, The Open Group has a Reference Model for Integrated Information Infrastructure (III-RM) - see Part VI, 44. Integrated Information Infrastructure Reference Model - that focuses on the application-level components and underlying services necessary to provide an integrated information infrastructure.

 12.3 Inputs

This section defines the inputs to Phase D.

 12.3.1 Reference Materials External to the Enterprise

 12.3.2 Non-Architectural Inputs

 12.3.3 Architectural Inputs

 12.4 Steps

The level of detail addressed in Phase D will depend on the scope and goals of the overall architecture effort.

New technology building blocks being introduced as part of this effort will need to be defined in detail during Phase D. Existing technology building blocks to be supported in the target environment may need to be redefined in Phase D to ensure interoperability and fit-for-purpose within this specific Technology Architecture.

The order of the steps in Phase D (see below) as well as the time at which they are formally started and completed should be adapted to the situation at hand in accordance with the established architecture governance. In particular, determine whether in this situation it is appropriate to conduct Baseline Description or Target Architecture development first, as described in Part III, 19. Applying Iteration to the ADM.

All activities that have been initiated in these steps must be closed during the Finalize the Technology Architecture step (see 12.4.8 Finalize the Technology Architecture). The documentation generated from these steps must be formally published in the Create Architecture Definition Document step (see 12.4.9 Create Architecture Definition Document).

The steps in Phase D are as follows:

 12.4.1 Select Reference Models, Viewpoints, and Tools

Review and validate the set of technology principles. These will normally form part of an overarching set of architecture principles. Guidelines for developing and applying principles, and a sample set of technology principles, are given in Part III, 23. Architecture Principles.

Select relevant Technology Architecture resources (reference models, patterns, etc.) from the Architecture Repository (see Part V, 41. Architecture Repository), on the basis of the business drivers, stakeholders, and their concerns.

Select relevant Technology Architecture viewpoints that will enable the architect to demonstrate how the stakeholder concerns are being addressed in the Technology Architecture.

Identify appropriate tools and techniques to be used for capture, modeling, and analysis, in association with the selected viewpoints. Depending on the degree of sophistication required, these may comprise simple documents and spreadsheets, or more sophisticated modeling tools and techniques.

 12.4.1.1 Determine Overall Modeling Process

For each viewpoint, select the models needed to support the specific view required, using the selected tool or method. Ensure that all stakeholder concerns are covered. If they are not, create new models to address them, or augment existing models (see above).

The process to develop a Technology Architecture incorporates the following steps:

  • Define a taxonomy of platform services and logical technology components (including standards)
  • Identify relevant locations where technology is deployed
  • Carry out a physical inventory of deployed technology and abstract up to fit into the taxonomy
  • Look at application and business requirements for technology
  • Is the technology in place fit-for-purpose to meet new requirements (i.e., does it meet functional and non-functional requirements)?
    • Refine the taxonomy
    • Product selection (including dependent products)
  • Determine configuration of the selected technology
  • Determine impact:
    • Sizing and costing
    • Capacity planning
    • Installation/governance/migration impacts

In the earlier phases of the ADM, certain decisions made around service granularity and service boundaries will have implications on the technology component and the platform service. The areas where the Technology Architecture may be impacted will include the following:

  • Performance: The granularity of the service will impact on platform service requirements. Coarse-grained services contain several units of functionality with potentially varying non-functional requirements, so platform performance should be considered. In addition, coarse-grained services can sometimes contain more information than actually required by the requesting system.
  • Maintainability: If service granularity is too coarse, then introducing changes to that service becomes difficult and impacts the maintenance of the service and the platform on which it is delivered.
  • Location and Latency: Services might interact with each other over remote links and inter-service communication will have in-built latency. Drawing service boundaries and setting the service granularity should consider platform/location impact of these inter-service communications.
  • Availability: Service invocation is subject to network and/or service failure. So high communication availability is an important consideration during service decomposition and defining service granularity

Product selection processes may occur within the Technology Architecture phase where existing products are re-used, incremental capacity is being added, or product selection decisions are a constraint during project initiation.

Where product selection deviates from existing standards, involves significant effort, or has wide-ranging impact, this activity should be flagged as an opportunity and addressed through the Opportunities & Solutions phase.

 12.4.1.2 Identify Required Catalogs of Technology Building Blocks

Catalogs are inventories of the core assets of the business. Catalogs are hierarchical in nature and capture a decomposition of a metamodel entity and also decompositions across related model entities (e.g., platform service -> logical technology component ->] physical technology component).

Catalogs form the raw material for development of matrices and diagrams and also act as a key resource for portfolio managing business and IT capability.

The Technology Architecture should create technology catalogs as follows:

  • Based on existing technology catalogs and analysis of applications carried out in the Application Architecture phase, collect a list of products in use.
  • If the requirements identified in the Application Architecture are not met by existing products, extend the product list by examining products available on the market that provide the functionality and meet the required standards.
  • Classify products against the TOGAF TRM if appropriate, extending the model as necessary to fit the classification of technology products in use.
  • If technology standards are currently in place, apply these to the technology component catalog to gain a baseline view of compliance with technology standards.

The following catalogs should be considered for development within a Technology Architecture:

  • Technology standards
  • Technology portfolio

The structure of catalogs is based on the attributes of metamodel entities, as defined in Part IV, 34. Content Metamodel.

 12.4.1.3 Identify Required Matrices

Matrices show the core relationships between related model entities.

Matrices form the raw material for development of diagrams and also act as a key resource for impact assessment.

The following matrix should be considered for development within a Technology Architecture:

  • Application/Technology matrix
 12.4.1.4 Identify Required Diagrams

Diagrams present the Technology Architecture information from a set of different perspectives (viewpoints) according to the requirements of the stakeholders.

This activity provides a link between platform requirements and hosting requirements, as a single application may need to be physically located in several environments to support local access, development lifecycles, and hosting requirements.

For major baseline applications or application platforms (where multiple applications are hosted on the same infrastructure stack), produce a stack diagram showing how hardware, operating system, software infrastructure, and packaged applications combine.

If appropriate, extend the Application Architecture diagrams of software distribution to show how applications map onto the technology platform.

For each environment, produce a logical diagram of hardware and software infrastructure showing the contents of the environment and logical communications between components. Where available, collect capacity information on the deployed infrastructure.

For each environment, produce a physical diagram of communications infrastructure, such as routers, switches, firewalls, and network links. Where available, collect capacity information on the communications infrastructure.

The following diagrams should be considered for development within a Technology Architecture:

  • Environments and Locations diagram
  • Platform Decomposition diagram
  • Processing diagram
  • Networked Computing/Hardware diagram
  • Communications Engineering diagram

The structure of diagrams is based on the attributes of metamodel entities, as defined in Part IV, 34. Content Metamodel.

 12.4.1.5 Identify Types of Requirement to be Collected

Once the Technology Architecture catalogs, matrices, and diagrams have been developed, architecture modeling is completed by formalizing the technology-focused requirements for implementing the Target Architecture.

These requirements may:

  • Relate to the technology domain
  • Provide detailed guidance to be reflected during design and implementation to ensure that the solution addresses the original architecture requirements

Within this step, the architect should identify requirements that should be met by the architecture (see 17.2.2 Requirements Development).

 12.4.1.6 Select Services

The services portfolios are combinations of basic services from the service categories in the TOGAF TRM that do not conflict. The combination of services are again tested to ensure support for the applications. This is a prerequisite to the later step of defining the architecture fully.

The previously identified requirements can provide more detailed information about:

  • Requirements for organization-specific elements or pre-existing decisions (as applicable)
  • Pre-existing and unchanging organizational elements (as applicable)
  • Inherited external environment constraints

Where requirements demand definition of specialized services that are not identified in TOGAF, consideration should be given to how these might be replaced if standardized services become available in the future.

For each building block, build up a service description portfolio as a set of non-conflicting services. The set of services must be tested to ensure that the functionality provided meets application requirements.

 12.4.2 Develop Baseline Technology Architecture Description

Develop a Baseline Description of the existing Technology Architecture, to support the Target Technology Architecture. The scope and level of detail to be defined will depend on the extent to which existing technology components are likely to be carried over into the Target Technology Architecture, and on whether architectural descriptions exist, as described in 12.2 Approach.

Identify the relevant Technology Architecture building blocks, drawing on any artifacts held in the Architecture Repository. If nothing exists within the Architecture Repository, define each application in line with the Technology Portfolio catalog (see Part IV, 34. Content Metamodel).

Begin by converting the description of the existing environment into the terms of the organization's Foundation Architecture (e.g., the TOGAF Foundation Architecture's TRM). This will allow the team developing the architecture to gain experience with the model and to understand its component parts. The team may be able to take advantage of a previous architectural definition, but it is assumed that some adaptation may be required to match the architectural definition techniques described as part of this process. Another important task is to set down a list of key questions which can be used later in the development process to measure the effectiveness of the new architecture.

Where new architecture models need to be developed to satisfy stakeholder concerns, use the models identified within Step 1 as a guideline for creating new architecture content to describe the Baseline Architecture.

 12.4.3 Develop Target Technology Architecture Description

Develop a Target Description for the Technology Architecture, to the extent necessary to support the Architecture Vision, Target Business Architecture, and Target Information Systems Architecture. The scope and level of detail to be defined will depend on the relevance of the technology elements to attaining the Target Architecture, and on whether architectural descriptions exist. To the extent possible, identify the relevant Technology Architecture building blocks, drawing on the Architecture Repository (see Part V, 41. Architecture Repository).

A key process in the creation of a broad architectural model of the target system is the conceptualization of building blocks. Architecture Building Blocks (ABBs) describe the functionality and how they may be implemented without the detail introduced by configuration or detailed design. The method of defining building blocks, along with some general guidelines for their use in creating an architectural model, is described in Part IV, 37.3 Building Blocks and the ADM.

Where new architecture models need to be developed to satisfy stakeholder concerns, use the models identified within Step 1 as a guideline for creating new architecture content to describe the Target Architecture.

 12.4.4 Perform Gap Analysis

Verify the architecture models for internal consistency and accuracy:

  • Perform trade-off analysis to resolve conflicts (if any) among the different views
  • Validate that the models support the principles, objectives, and constraints
  • Note changes to the viewpoint represented in the selected models from the Architecture Repository, and document
  • Test architecture models for completeness against requirements

Identify gaps between the baseline and target, using the Gap Analysis technique as described in Part III, 27. Gap Analysis.

 12.4.5 Define Candidate Roadmap Components

Following creation of a Baseline Architecture, Target Architecture, and gap analysis, a Technology Roadmap is required to prioritize activities over the coming phases.

This initial Technology Architecture roadmap will be used as raw material to support more detailed definition of a consolidated, cross-discipline roadmap within the Opportunities & Solutions phase.

 12.4.6 Resolve Impacts Across the Architecture Landscape

Once the Technology Architecture is finalized, it is necessary to understand any wider impacts or implications.

At this stage, other architecture artifacts in the Architecture Landscape should be examined to identify:

  • Does this Technology Architecture create an impact on any pre-existing architectures?
  • Have recent changes been made that impact the Technology Architecture?
  • Are there any opportunities to leverage work from this Technology Architecture in other areas of the organization?
  • Does this Technology Architecture impact other projects (including those planned as well as those currently in progress)?
  • Will this Technology Architecture be impacted by other projects (including those planned as well as those currently in progress)?

 12.4.7 Conduct Formal Stakeholder Review

Check the original motivation for the architecture project and the Statement of Architecture Work against the proposed Technology Architecture, asking if it is fit for the purpose of supporting subsequent work in the other architecture domains. Refine the proposed Technology Architecture only if necessary.

 12.4.8 Finalize the Technology Architecture

  • Select standards for each of the building blocks, re-using as much as possible from the reference models selected from the Architecture Repository
  • Fully document each building block
  • Conduct final cross-check of overall architecture against business goals; document rationale for building block decisions in the architecture document
  • Document final requirements traceability report
  • Document final mapping of the architecture within the Architecture Repository; from the selected building blocks, identify those that might be re-used (working practices, roles, business relationships, job descriptions, etc.), and publish via the Architecture Repository
  • Finalize all the work products, such as gap analysis

 12.4.9 Create Architecture Definition Document

Document the rationale for building block decisions in the Architecture Definition Document.

Prepare the technology sections of the Architecture Definition Document, comprising some or all of:

  • Fundamental functionality and attributes - semantic, unambiguous including security capability and manageability
  • Dependent building blocks with required functionality and named interfaces
  • Interfaces - chosen set, supplied (APIs, data formats, protocols, hardware interfaces, standards)
  • Map to business/organizational entities and policies

If appropriate, use reports and/or graphics generated by modeling tools to demonstrate key views of the architecture. Route the document for review by relevant stakeholders, and incorporate feedback.

 12.5 Outputs

The outputs of Phase D may include, but are not restricted to:

  • Refined and updated versions of the Architecture Vision phase deliverables, where applicable:
  • Draft Architecture Definition Document (see Part IV, 36.2.3 Architecture Definition Document), including:
    • Target Technology Architecture, Version 1.0 (detailed), including:
      • Technology Components and their relationships to information systems
      • Technology platforms and their decomposition, showing the combinations of technology required to realize a particular technology "stack"
      • Environments and locations - a grouping of the required technology into computing environments (e.g., development, production)
      • Expected processing load and distribution of load across technology components
      • Physical (network) communications
      • Hardware and network specifications
    • Baseline Technology Architecture, Version 1.0 (detailed), if appropriate
    • Views corresponding to the selected viewpoints addressing key stakeholder concerns
  • Draft Architecture Requirements Specification (see Part IV, 36.2.6 Architecture Requirements Specification), including such Technology Architecture requirements as:
    • Gap analysis results
    • Requirements output from Phases B and C
    • Updated technology requirements
  • Technology Architecture components of an Architecture Roadmap (see Part IV, 36.2.7 Architecture Roadmap)

The outputs may include some or all of the following:

  • Catalogs:
    • Technology Standards catalog
    • Technology Portfolio catalog
  • Matrices:
    • Application/Technology matrix
  • Diagrams:
    • Environments and Locations diagram
    • Platform Decomposition diagram
    • Processing diagram
    • Networked Computing/Hardware diagram
    • Communications Engineering diagram

 12.6 Postscript

Choosing the scope of an architecture development cycle carefully will accelerate the pay-back. In contrast, an excessively large scope is unlikely to lead to successful implementation.


Phase E: Opportunities & Solutions

URL de origem: http://pubs.opengroup.org/architecture/togaf9-doc/arch/chap13.html
  Figure 13-1: Phase E: Opportunities & Solutions

 13.1 Objectives

The objectives of Phase E are to:

  • Generate the initial complete version of the Architecture Roadmap, based upon the gap analysis and candidate Architecture Roadmap components from Phases B, C, and D
  • Determine whether an incremental approach is required, and if so identify Transition Architectures that will deliver continuous business value

 13.2 Approach

Phase E concentrates on how to deliver the architecture. It takes into account the complete set of gaps between the Target and Baseline Architectures in all architecture domains, and logically groups changes into work packages within the enterprise's portfolios. This is an effort to build a best-fit roadmap that is based upon the stakeholder requirements, the enterprise's business transformation readiness, identified opportunities and solutions, and identified implementation constraints. The key is to focus on the final target while realizing incremental business value.

Phase E is the initial step on the creation of the Implementation and Migration Plan which is completed in Phase F. It provides the basis of a well considered Implementation and Migration Plan that is integrated into the enterprise's portfolio in Phase F.

The following four concepts are key to transitioning from developing to delivering a Target Architecture:

  • Architecture Roadmap
  • Work Packages
  • Transition Architectures
  • Implementation and Migration Plan

The Architecture Roadmap lists individual work packages in a timeline that will realize the Target Architecture.

Each work package identifies a logical group of changes necessary to realize the Target Architecture.

A Transition Architecture describes the enterprise at an architecturally significant state between the Baseline and Target Architectures. Transition Architectures provide interim Target Architectures upon which the organization can converge.

The Implementation and Migration Plan provides a schedule of the projects that will realize the Target Architecture.

 13.3 Inputs

This section defines the inputs to Phase E.

 13.3.1 Reference Materials External to the Enterprise

 13.3.2 Non-Architectural Inputs

 13.3.3 Architectural Inputs

  • Organizational Model for Enterprise Architecture (see Part IV, 36.2.16 Organizational Model for Enterprise Architecture), including:
    • Scope of organizations impacted
    • Maturity assessment, gaps, and resolution approach
    • Roles and responsibilities for architecture team(s)
    • Constraints on architecture work
    • Budget requirements
    • Governance and support strategy
  • Governance models and frameworks for:
    • Corporate Business Planning
    • Enterprise Architecture
    • Portfolio, Program, Project Management
    • System Development/Engineering
    • Operations (Service)
  • Tailored Architecture Framework (see Part IV, 36.2.21 Tailored Architecture Framework), including:
    • Tailored architecture method
    • Tailored architecture content (deliverables and artifacts)
    • Configured and deployed tools
  • Statement of Architecture Work (see Part IV, 36.2.20 Statement of Architecture Work)
  • Architecture Vision (see Part IV, 36.2.8 Architecture Vision)
  • Architecture Repository (see Part IV, 36.2.5 Architecture Repository), including:
    • Re-usable building blocks
    • Publicly available reference models
    • Organization-specific reference models
    • Organization standards
  • Draft Architecture Definition Document (see Part IV, 36.2.3 Architecture Definition Document), including:
    • Baseline Business Architecture, Version 1.0 (detailed)
    • Target Business Architecture, Version 1.0 (detailed)
    • Baseline Data Architecture, Version 1.0 (detailed)
    • Target Data Architecture, Version 1.0 (detailed)
    • Baseline Application Architecture, Version 1.0 (detailed)
    • Target Application Architecture, Version 1.0 (detailed)
    • Baseline Technology Architecture, Version 1.0 (detailed)
    • Target Technology Architecture, Version 1.0 (detailed)
  • Draft Architecture Requirements Specification (see Part IV, 36.2.6 Architecture Requirements Specification), including:
    • Architectural requirements
    • Gap analysis results (from Business, Data, Application, and Technology Architecture)
    • IT Service Management requirements
  • Change Requests for existing business programs and projects (see Part IV, 36.2.11 Change Request)
  • Candidate Architecture Roadmap components from Phases B, C, and D

 13.4 Steps

The level of detail addressed in Phase E will depend on the scope and goals of the overall architecture effort.

The order of the steps in Phase E (see below) as well as the time at which they are formally started and completed should be adapted to the situation at hand in accordance with the established architecture governance.

All activities that have been initiated in these steps must be closed during the Create the Architecture Roadmap & Implementation and Migration Plan step (see 13.4.11 Create the Architecture Roadmap & Implementation and Migration Plan).

The steps in Phase E are as follows:

 13.4.1 Determine/Confirm Key Corporate Change Attributes

This step determines how the enterprise architecture can be best implemented to take advantage of the organization's business culture. This should include the creation of an Implementation Factor Assessment and Deduction matrix (see Part III, 28.1 Implementation Factor Assessment & Deduction Matrix) to serve as a repository for architecture implementation and migration decisions. The step also includes assessments of the transition capabilities of the organization units involved (including culture and abilities), and assessments of the enterprise (including culture and skill sets).

The resulting factors from the assessments should be documented in the Implementation Factor Assessment and Deduction matrix. For organizations where enterprise architecture is well established, this step can be simple, but the matrix has to be established so that it can be used as an archive and record of decisions taken.

 13.4.2 Determine Business Constraints for Implementation

Identify any business drivers that would constrain the sequence of implementation. This should include a review of the business and strategic plans, at both a corporate and line-of-business level, and a review of the Enterprise Architecture Maturity Assessment.

 13.4.3 Review and Consolidate Gap Analysis Results from Phases B to D

Consolidate and integrate the gap analysis results from the Business, Information Systems, and Technology Architectures (created in Phases B to D) and assess their implications with respect to potential solutions and inter-dependencies. This should be done by creating a Consolidated Gaps, Solutions, and Dependencies matrix, as shown in Part III, 28.2 Consolidated Gaps, Solutions, & Dependencies Matrix, which will enable the identification of Solution Building Blocks (SBBs) that could potentially address one or more gaps and their associated Architecture Building Blocks (ABBs).

Review the Phase B, C, and D gap analysis results and consolidate them in a single list. The gaps should be consolidated along with potential solutions to the gaps and dependencies. A recommended technique for determining the dependencies is to use sets of views such as the Business Interaction matrix, the Data Entity/Business Function matrix, and the Application/Function matrix to completely relate elements from different architectural domains.

Rationalize the Consolidated Gaps, Solutions, and Dependencies matrix. Once all of the gaps have been documented, re-organize the gap list and place similar items together. When grouping the gaps, refer to the Implementation Factor Assessment and Deduction matrix and review the implementation factors. Any additional factors should be added to the Implementation Factor Assessment and Deduction matrix.

 13.4.4 Review Consolidated Requirements Across Related Business Functions

Assess the requirements, gaps, solutions, and factors to identify a minimal set of requirements whose integration into work packages would lead to a more efficient and effective implementation of the Target Architecture across the business functions that are participating in the architecture. This functional perspective leads to the satisfaction of multiple requirements through the provision of shared solutions and services. The implications of this consolidation of requirements with respect to architectural components can be significant with respect to the provision of resources. For example, several requirements raised by several lines of business can be resolved through the provision of a shared set of Business Services and Information System Services within a work package or project.

 13.4.5 Consolidate and Reconcile Interoperability Requirements

Consolidate the interoperability requirements identified in previous phases. The Architecture Vision and Target Architectures, as well as the Implementation Factor Assessment and Deduction matrix and Consolidated Gaps, Solutions, and Dependencies matrix, should be consolidated and reviewed to identify any constraints on interoperability required by the potential set of solutions.

A key outcome is to minimize interoperability conflicts, or to ensure such conflicts are addressed in the architecture. Re-used Solution Building Blocks (SBBs), Commercial Off-The-Shelf (COTS) products, and third-party service providers typically impose interoperability requirements that conflict. Any such conflicts must be addressed in the architecture, and conflicts must be considered across all architecture domains (Business, Applications, Data, and Technology).

There are two basic approaches to interoperability conflicts; either create a building block that transforms or translates between conflicting building blocks, or make a change to the specification of the conflicting building blocks.

 13.4.6 Refine and Validate Dependencies

Refine the initial dependencies, ensuring that any constraints on the Implementation and Migration Plans are identified. There are several key dependencies that should be taken into account, such as dependencies on existing implementations of Business Services and Information System Services or changes to them. Dependencies should be used for determining the sequence of implementation and identifying the coordination required. A study of the dependencies should group activities together, creating a basis for projects to be established. Examine the relevant projects and see whether logical increments of deliverables can be identified. The dependencies will also help to identify when the identified increments can be delivered. Once finished, an assessment of these dependencies should be documented as part of the Architecture Roadmap and any necessary Transition Architectures.

Addressing dependencies serves as the basis for most migration planning.

 13.4.7 Confirm Readiness and Risk for Business Transformation

Review the findings of the Business Transformation Readiness Assessment previously conducted in Phase A and determine their impact on the Architecture Roadmap and the Implementation and Migration Strategy. It is important to identify, classify, and mitigate risks associated with the transformation effort. Risks should be documented in the Consolidated Gaps, Solutions, and Dependencies matrix.

 13.4.8 Formulate Implementation and Migration Strategy

Create an overall Implementation and Migration Strategy that will guide the implementation of the Target Architecture, and structure any Transition Architectures. The first activity is to determine an overall strategic approach to implementing the solutions and/or exploiting opportunities. There are three basic approaches as follows:

  • Greenfield: A completely new implementation.
  • Revolutionary: A radical change (i.e., switch on, switch off).
  • Evolutionary: A strategy of convergence, such as parallel running or a phased approach to introduce new capabilities.

Next, determine an approach for the overall strategic direction that will address and mitigate the risks identified in the Consolidated Gaps, Solutions, and Dependencies matrix. The most common implementation methodologies are:

  • Quick win (snapshots)
  • Achievable targets
  • Value chain method

These approaches and the identified dependencies should become the basis for the creation of the work packages. This activity terminates with agreement on the Implementation and Migration Strategy for the enterprise.

 13.4.9 Identify and Group Major Work Packages

Key stakeholders, planners, and the enterprise architects should assess the missing business capabilities identified in the Architecture Vision and Target Architecture.

Using the Consolidated Gaps, Solutions, and Dependencies matrix together with the Implementation Factor Assessment and Deduction matrix, logically group the various activities into work packages.

Fill in the "Solution" column in the Consolidated Gaps, Solutions, and Dependencies matrix to recommend the proposed solution mechanisms. Indicate for every gap/activity whether the solution should be oriented towards a new development, or be based on an existing product, and/or use a solution that can be purchased. An existing system may resolve the requirement with minor enhancements. For new development this is a good time to determine whether the work should be conducted in-house or through a contract.

Classify every current system that is under consideration as:

  • Mainstream: Part of the future information system.
  • Contain: Expected to be replaced or modified in the planning horizon (next three years).
  • Replace: To be replaced in the planning horizon.

Supporting top-level work packages should then in turn be decomposed into increments to deliver the capability increments. Analyze and refine these work packages, or increments with respect to their business transformation issues and the strategic implementation approach. Finally, group the work packages into portfolios and projects within a portfolio, taking into consideration the dependencies and the strategic implementation approach.

 13.4.10 Identify Transition Architectures

Where the scope of change to implement the Target Architecture requires an incremental approach, then one or more Transition Architectures may be necessary. These provide an ability to identify clear targets along the roadmap to realizing the Target Architecture. The Transition Architectures should provide measurable business value. The time-span between successive Transition Architectures does not have to be of uniform duration.

Development of Transition Architectures must be based upon the preferred implementation approach, the Consolidated Gaps, Solutions, and Dependencies matrix, the listing of projects and portfolios, as well as the enterprise's capacity for creating and absorbing change.

Determine where the difficult activities are, and unless there are compelling reasons, implement them after other activities that most easily deliver missing capability.

 13.4.11 Create the Architecture Roadmap & Implementation and Migration Plan

Consolidate the work packages and Transition Architectures into the Architecture Roadmap, Version 0.1, which describes a timeline of the progression from the Baseline Architecture to the Target Architecture. The timeline informs the Implementation and Migration Plan. The Architecture Roadmap frames the migration planning in Phase F. Identified Transition Architectures and work packages should have a clear set of outcomes. The Architecture Roadmap must demonstrate how the selection and timeline of Transition Architectures and work packages realizes the Target Architecture.

The detail of the Architecture Roadmap, Version 0.1 should be expressed at a similar level of detail to the Architecture Definition Document developed in Phases B, C, and D. Where significant additional detail is required before implementation the architecture is likely transitioning to a different level. See Part III, 19. Applying Iteration to the ADM and 20. Applying the ADM across the Architecture Landscape for techniques to manage iteration and different levels of detail.

The Implementation and Migration Plan must demonstrate the activity necessary to realize the Architecture Roadmap. The Implementation and Migration Plan forms the basis of the migration planning in Phase F. The detail of the Implementation and Migration Plan, Version 0.1 must be aligned to the detail of the Architecture Roadmap and be sufficient to identify the necessary projects and resource requirements to realize the roadmap.

When creating the Implementation and Migration Plan there are many approaches to consider, such as a data-driven sequence, where application systems that create data are implemented first, then applications that process the data. A clear understanding of the dependencies and lifecycle of in-place SBBs is required for an effective Implementation and Migration Plan.

Finally, update the Architecture Vision, Architecture Definition Document, and Architecture Requirements Specification with any additional relevant outcomes from this phase.

 13.5 Outputs

The outputs of Phase E may include, but are not restricted to:

  • Refined and updated version of the Architecture Vision phase deliverables, where applicable, including:
  • Draft Architecture Definition Document (see Part IV, 36.2.3 Architecture Definition Document), including:
    • Baseline Business Architecture, Version 1.0 updated if necessary
    • Target Business Architecture, Version 1.0 updated if necessary
    • Baseline Data Architecture, Version 1.0 updated if necessary
    • Target Data Architecture, Version 1.0 updated if necessary
    • Baseline Application Architecture, Version 1.0 updated if necessary
    • Target Application Architecture, Version 1.0 updated if necessary
    • Baseline Technology Architecture, Version 1.0 updated if necessary
    • Target Technology Architecture, Version 1.0 updated if necessary
    • Transition Architecture, number and scope as necessary
    • Views corresponding to the selected viewpoints addressing key stakeholder concerns
  • Draft Architecture Requirements Specification (see Part IV, 36.2.6 Architecture Requirements Specification), including:
    • Consolidated Gaps, Solutions, and Dependencies Assessment
  • Capability Assessments, including:
    • Business Capability Assessment
    • IT Capability Assessment
  • Architecture Roadmap (see Part IV, 36.2.7 Architecture Roadmap), including:
    • Work package portfolio:
      • Work package description (name, description, objectives)
      • Functional requirements
      • Dependencies
      • Relationship to opportunity
      • Relationship to Architecture Definition Document and Architecture Requirements Specification
      • Relationship to any capability increments
      • Business value
      • Implementation Factor Assessment and Deduction Matrix
      • Impact
    • Identification of Transition Architectures, if any, including:
      • Relationship to Architecture Definition Document
    • Implementation recommendations:
      • Criteria measures of effectiveness
      • Risks and issues
      • Solution Building Blocks (SBBs)
  • Implementation and Migration Plan, Version 0.1, including:
    • Implementation and Migration Strategy

The outputs may include some or all of the following:

  • Diagrams:
    • Project Context diagram
    • Benefits diagram

Phase F: Migration Planning

URL de origem: http://pubs.opengroup.org/architecture/togaf9-doc/arch/chap14.html
  Figure 14-1: Phase F: Migration Planning

 14.1 Objectives

The objectives of Phase F are to:

  • Finalize the Architecture Roadmap and the supporting Implementation and Migration Plan
  • Ensure that the Implementation and Migration Plan is coordinated with the enterprise's approach to managing and implementing change in the enterprise's overall change portfolio
  • Ensure that the business value and cost of work packages and Transition Architectures is understood by key stakeholders

 14.2 Approach

The focus of Phase F is the creation of an Implementation and Migration Plan in co-operation with the portfolio and project managers.

Phase E provides an incomplete Architecture Roadmap and Implementation and Migration Plan that address the Request for Architecture Work. In Phase F this Roadmap and the Implementation and Migration Plan are integrated with the enterprise's other change activity.

Activities include assessing the dependencies, costs, and benefits of the various migration projects within the context of the enterprise's other activity. The Architecture Roadmap, Version 0.1 and Implementation and Migration Plan, Version 0.1 from Phase E will form the basis of the final Implementation and Migration Plan that will include portfolio and project-level detail.

The architecture development cycle should then be completed and lessons learned documented to enable continuous process improvement.

 14.3 Inputs

This section defines the inputs to Phase F.

 14.3.1 Reference Materials External to the Enterprise

 14.3.2 Non-Architectural Inputs

 14.3.3 Architectural Inputs

  • Organizational Model for Enterprise Architecture (see Part IV, 36.2.16 Organizational Model for Enterprise Architecture), including:
    • Scope of organizations impacted
    • Maturity assessment, gaps, and resolution approach
    • Roles and responsibilities for architecture team(s)
    • Constraints on architecture work
    • Budget requirements
    • Governance and support strategy
  • Governance models and frameworks for:
    • Corporate Business Planning
    • Enterprise Architecture
    • Portfolio, Program, Project Management
    • System Development/Engineering
    • Operations (Service)
  • Tailored Architecture Framework (see Part IV, 36.2.21 Tailored Architecture Framework), including:
    • Tailored architecture method
    • Tailored architecture content (deliverables and artifacts)
    • Configured and deployed tools
  • Statement of Architecture Work (see Part IV, 36.2.20 Statement of Architecture Work)
  • Architecture Vision (see Part IV, 36.2.8 Architecture Vision)
  • Architecture Repository (see Part IV, 36.2.5 Architecture Repository), including:
    • Re-usable building blocks
    • Publicly available reference models
    • Organization-specific reference models
    • Organization standards
  • Draft Architecture Definition Document (see Part IV, 36.2.3 Architecture Definition Document), including:
    • Baseline Business Architecture, Version 1.0 (detailed)
    • Target Business Architecture, Version 1.0 (detailed)
    • Baseline Data Architecture, Version 1.0 (detailed)
    • Target Data Architecture, Version 1.0 (detailed)
    • Baseline Application Architecture, Version 1.0 (detailed)
    • Target Application Architecture, Version 1.0 (detailed)
    • Baseline Technology Architecture, Version 1.0 (detailed)
    • Target Technology Architecture, Version 1.0 (detailed)
    • Transition Architectures, if any
  • Draft Architecture Requirements Specification (see Part IV, 36.2.6 Architecture Requirements Specification), including:
    • Architectural requirements
    • Gap analysis results (from Business, Data, Application, and Technology Architecture)
    • IT Service Management requirements
  • Change Requests for existing business programs and projects (see Part IV, 36.2.11 Change Request)
  • Architecture Roadmap, Version 0.1 (see Part IV, 36.2.7 Architecture Roadmap), including:
    • Identification of work packages
    • Identification of Transition Architectures
    • Implementation Factor Assessment and Deduction Matrix
  • Capability Assessment (see Part IV, 36.2.10 Capability Assessment), including:
    • Business Capability Assessment
    • IT Capability Assessment
  • Implementation and Migration Plan, Version 0.1 (see Part IV, 36.2.14 Implementation and Migration Plan) including the high-level Implementation and Migration Strategy

 14.4 Steps

The level of detail addressed in Phase F will depend on the scope and goals of the overall architecture effort.

The order of the steps in Phase F (see below) as well as the time at which they are formally started and completed should be adapted to the situation at hand in accordance with the established architecture governance.

All activities that have been initiated in these steps must be closed during the Complete the architecture development cycle and document lessons learned step (see 14.4.7 Complete the Architecture Development Cycle and Document Lessons Learned).

The steps in Phase F are as follows:

 14.4.1 Confirm Management Framework Interactions for the Implementation and Migration Plan

This step is about coordinating the Implementation and Migration Plan with the management frameworks within the organization. There are typically four management frameworks that have to work closely together for the Implementation and Migration Plan to succeed:

  • Business Planning that conceives, directs, and provides the resources for all of the activities required to achieve concrete business objectives/outcomes.
  • Enterprise Architecture that structures and gives context to all enterprise activities delivering concrete business outcomes primarily but not exclusively in the IT domain.
  • Portfolio/Project Management that co-ordinates, designs, and builds the business systems that deliver the concrete business outcomes.
  • Operations Management that integrates, operates, and maintains the deliverables that deliver the concrete business outcomes.

The Implementation and Migration Plan will impact the outputs of each of these frameworks and consequently has to be reflected in them. In the course of this step, understand the frameworks within the organization and ensure that these plans are coordinated and inserted (in a summary format) within the plans of each one of these frameworks.

The outcome of this step may well be that the Implementation and Migration Plan could be part of a different plan produced by another one of the frameworks with enterprise architecture participation.

 14.4.2 Assign a Business Value to Each Work Package

Establish and assign business values to all of the work packages. The intent is to first establish what constitutes business value within the organization, how value can be measured, and then apply this to each one of the projects and project increments.

If Capability-Based Planning has been used, then the business values associated with the capabilities and associated capability increments should be used to assign the business values for deliverables.

There are several issues to address in this activity:

  • Performance Evaluation Criteria are used by portfolio and capability managers to approve and monitor the progress of the architecture transformation.
  • Return-on-Investment Criteria have to be detailed and signed off by the various executive stakeholders.
  • Business Value has to be defined as well as techniques, such as the value chain, which are to be used to illustrate the role in achieving tangible business outcomes. Business value will be used by portfolio and capability managers to allocate resources and, in cases where there are cutbacks, business value in conjunction with return on investment can be used to determine whether an endeavor proceeds, is delayed, or is canceled.
  • Critical Success Factors (CSFs) should be established to define success for a project and/or project increment. These will provide managers and implementers with a gauge as to what constitutes a successful implementation.
  • Measures of Effectiveness (MOE) are often performance criteria and many corporations include them in the CSFs. Where they are treated discretely, it should be clear as to how these criteria are to be grouped.
  • Strategic Fit based upon the overall enterprise architecture (all tiers) will be the critical factor for allowing the approval of any new project or initiative and for determining the value of any deliverable.

Use the work packages as a basis of identifying projects that will be in the Implementation and Migration Plan. The identified projects will be fully developed in other steps in Phase F. The projects, and project increments, may require adjustment of the Architecture Roadmap and Architecture Definition Document.

Risks should then be assigned to the projects and project increments by aggregating risks identified in the Consolidated Gaps, Solutions, and Dependencies Matrix (from Phase E).

Estimate the business value for each project using the Business Value Assessment Technique (see Part III, 28.5 Business Value Assessment Technique).

 14.4.3 Estimate Resource Requirements, Project Timings, and Availability/Delivery Vehicle

This step determines the required resources and times for each project and their increments and provides the initial cost estimates. The costs should be broken down into capital (to create the capability) and operations and maintenance (to run and sustain the capability). Opportunities should be identified where the costs associated with delivering new and/or better capability can be offset by decommissioning existing systems. Assign required resources to each activity and aggregate them at the project increment and project level.

 14.4.4 Prioritize the Migration Projects through the Conduct of a Cost/Benefit Assessment and Risk Validation

Prioritize the projects by ascertaining their business value against the cost of delivering them. The approach is to first determine, as clearly as possible, the net benefit of all of the SBBs delivered by the projects, and then verify that the risks have been effectively mitigated and factored in. Afterwards, the intent is to gain the requisite consensus to create a prioritized list of projects that will provide the basis for resource allocation.

It is important to discover all costs, and to ensure that decision-makers understand the net benefit over time.

Review the risks to ensure that the risks for the project deliverables have been mitigated as much as possible. The project list is then updated with risk-related comments.

Have the stakeholders agree upon a prioritization of the projects. Prioritization criteria will use elements identified in creation of the draft Architecture Roadmap in Phase E as well as those relating to individual stakeholders' agendas. Notice that it is possible for a project to earn a high priority if it provides a critical deliverable on the path to some large benefit, even if the immediate benefit of the project itself is small.

Formally review the risk assessment and revise it as necessary ensuring that there is a full understanding of the residual risk associated with the prioritization and the projected funding line.

 14.4.5 Confirm Architecture Roadmap and Update Architecture Definition Document

Update the Architecture Roadmap including any Transition Architectures. Review the work to date to assess what the time-spans between Transition Architecture should be, taking into consideration the increments in business value and capability and other factors, such as risk. Once the capability increments have been finalized, consolidate the deliverables by project. This will result in a revised Architecture Roadmap.

This is needed in order to co-ordinate the development of several concurrent instances of the various architectures. A Transition Architecture State Evolution Table (see Part III, 28.4 Transition Architecture State Evolution Table) can be used to show the proposed state of the domain architectures at various levels of detail.

If the implementation approach has shifted as a result of confirming the implementation increments, update the Architecture Definition Document. This may include assigning project objectives and aligning projects and their deliverables with the Transition Architectures to create an Architecture Definition Increments Table (see Part III, 28.3 Architecture Definition Increments Table).

 14.4.6 Generate the Implementation and Migration Plan

Generate the completed Implementation and Migration Plan. Much of the detail for the plan has already been gathered and this step brings it all together using accepted planning and management techniques.

This should include integrating all of the projects and activities as well as dependencies and impact of change into a project plan. Any Transition Architectures will act as portfolio milestones.

All external dependencies should be captured and included, and the overall availability of resources assessed. Project plans may be included within the Implementation and Migration Plan.

 14.4.7 Complete the Architecture Development Cycle and Document Lessons Learned

This step transitions governance from the development of the architecture to the realization of the architecture. If the maturity of the Architecture Capability warrants, an Implementation Governance Model may be produced (see Part IV, 36.2.15 Implementation Governance Model).

Lessons learned during the development of the architecture should be documented and captured by the appropriate governance process in Phase H as inputs to managing the Architecture Capability.

The detail of the Architecture Roadmap and the Implementation and Migration Plan should be expressed at a similar level of detail to the Architecture Definition Document developed in Phases B, C, and D. Where significant additional detail is required by the next phase the architecture is likely transitioning to a different level. Depending upon the level of the Target Architecture and Implementation and Migration Plan it may be necessary to iterate another ADM cycle at a lower level of detail. See Part III, 19. Applying Iteration to the ADM and 20. Applying the ADM across the Architecture Landscape for techniques to manage iteration and different levels of detail.

 14.5 Outputs

The outputs of Phase F may include, but are not restricted to:


Phase G: Implementation Governance

URL de origem: http://pubs.opengroup.org/architecture/togaf9-doc/arch/chap15.html
  Figure 15-1: Phase G: Implementation Governance

 15.1 Objectives

The objectives of Phase G are to:

  • Ensure conformance with the Target Architecture by implementation projects
  • Perform appropriate Architecture Governance functions for the solution and any implementation-driven architecture Change Requests

 15.2 Approach

It is here that all the information for successful management of the various implementation projects is brought together. Note that, in parallel with Phase G, there is the execution of an organizational-specific development process, where the actual development happens.

To enable early realization of business value and benefits, and to minimize the risk in the transformation and migration program, the favored approach is to deploy the Target Architecture as a series of transitions. Each transition represents an incremental step towards the target, and each delivers business benefit in its own right. Therefore, the overall approach in Phase G is to:

  • Establish an implementation program that will enable the delivery of the Transition Architectures agreed for implementation during the Migration Planning phase
  • Adopt a phased deployment schedule that reflects the business priorities embodied in the Architecture Roadmap
  • Follow the organization's standard for corporate, IT, and architecture governance
  • Use the organization's established portfolio/program management approach, where this exists
  • Define an operations framework to ensure the effective long life of the deployed solution

Phase G establishes the connection between architecture and implementation organization, through the Architecture Contract.

Project details are developed, including:

  • Name, description, and objectives
  • Scope, deliverables, and constraints
  • Measures of effectiveness
  • Acceptance criteria
  • Risks and issues

Implementation governance is closely allied to overall architecture governance, which is discussed in Part VII, 50. Architecture Governance.

A key aspect of Phase G is ensuring compliance with the defined architecture(s), not only by the implementation projects, but also by other ongoing projects within the enterprise. The considerations involved with this are explained in detail in Part VII, 48. Architecture Compliance.

 15.3 Inputs

This section defines the inputs to Phase G.

 15.3.1 Reference Materials External to the Enterprise

 15.3.2 Non-Architectural Inputs

 15.3.3 Architectural Inputs

 15.4 Steps

The level of detail addressed in Phase G will depend on the scope and goals of the overall architecture effort.

The order of the steps in Phase G (see below) as well as the time at which they are formally started and completed should be adapted to the situation at hand in accordance with the established architecture governance.

The steps in Phase G are as follows:

 15.4.1 Confirm Scope and Priorities for Deployment with Development Management

  • Review migration planning outputs and produce recommendations on deployment
  • Identify enterprise architecture priorities for development teams
  • Identify deployment issues and make recommendations
  • Identify building blocks for replacement, update, etc.
  • Perform gap analysis on enterprise architecture and solutions framework

    The gaps in the existing enterprise solutions framework need to be identified and the specific Solution Building Blocks (SBBs) required to fill these gaps will be the identified by the solutions architects. These SBBs may have a one-to-one or many-to-one relationship with the projects. The solutions architects need to define exactly how this will be done. There may be other projects working on these same capabilities and the solutions architects need to ensure that they can leverage best value from these investments.

  • Produce a gap analysis report

 15.4.2 Identify Deployment Resources and Skills

The project resources will include the development resources which will need to be educated in the overall enterprise architecture deliverables and expectations from the specific development and implementation projects.

The following considerations should be addressed in this step:

  • Identify system development methods required for solutions development
    Note:
    There are a range of systems development methods and tools available to the project teams. The method should ideally be able to interoperate with the architecture outputs; for example, generate code from architecture artifacts delivered to date. This could be achieved through the use of modeling languages used for the enterprise architecture development that may be captured as inputs to the systems development tools and thereby reduce the cost of solutions development.
  • Ensure that the systems development method enables feedback to the architecture team on designs

     

 15.4.3 Guide Development of Solutions Deployment

  • Formulate project recommendation

    For each separate implementation and deployment project, do the following:

    • Document scope of individual project in impact analysis
    • Document strategic requirements (from the architectural perspective) in impact analysis
    • Document change requests (such as support for a standard interface) in impact analysis
    • Document rules for conformance in impact analysis
    • Document timeline requirements from roadmap in impact analysis
  • Document Architecture Contract
    • Obtain signature from all developing organizations and sponsoring organization
  • Update Enterprise Continuum directory and repository for solutions
  • Guide development of business & IT operating models for services
  • Provide service requirements derived from enterprise architecture
  • Guide definition of business & IT operational requirements
  • Carry out gap analysis between the Solution Architecture and operations
  • Produce Implementation Plan

 15.4.4 Perform Enterprise Architecture Compliance Reviews

  • Review ongoing implementation governance and architecture compliance for each building block
  • Conduct post-development reviews
  • Close development part of deployment projects

 15.4.5 Implement Business and IT Operations

  • Carry out the deployment projects including: IT services delivery implementation; business services delivery implementation; skills development & training implementation; communications documentation publication
  • Publish new Baseline Architectures to the Architecture Repository and update other impacted repositories, such as operational configuration management stores

 15.4.6 Perform Post-Implementation Review and Close the Implementation

  • Conduct post-implementation reviews
  • Publish reviews and close projects

Closure on Phase G will be when the solutions are fully deployed once.

 15.5 Outputs

The outputs of Phase G may include, but are not restricted to:

  • Architecture Contract (signed) (see Part VII, 49. Architecture Contracts), as recommended in the architecture-compliant implemented architectures
  • Compliance Assessments (see Part IV, 36.2.13 Compliance Assessment)
  • Change Requests (see Part IV, 36.2.11 Change Request)
  • Architecture-compliant solutions deployed including:
    • The architecture-compliant implemented system
      Note:
      The implemented system is actually an output of the development process. However, given the importance of this output, it is stated here as an output of the ADM. The direct involvement of architecture staff in implementation will vary according to organizational policy, as described in Part VII, 50. Architecture Governance.
    • Populated Architecture Repository
    • Architecture compliance recommendations and dispensations
    • Recommendations on service delivery requirements
    • Recommendations on performance metrics
    • Service Level Agreements (SLAs)
    • Architecture Vision, updated post-implementation
    • Architecture Definition Document, updated post-implementation
    • Business and IT operating models for the implemented solution

Phase H: Architecture Change Management

URL de origem: http://pubs.opengroup.org/architecture/togaf9-doc/arch/chap16.html
  Figure 16-1: Phase H: Architecture Change Management

 16.1 Objectives

The objectives of Phase H are to:

  • Ensure that the architecture lifecycle is maintained
  • Ensure that the Architecture Governance Framework is executed
  • Ensure that the enterprise Architecture Capability meets current requirements

 16.2 Approach

The goal of an architecture change management process is to ensure that the architecture achieves its original target business value. This includes managing changes to the architecture in a cohesive and architected way.

This process will typically provide for the continual monitoring of such things as governance requests, new developments in technology, and changes in the business environment. When changes are identified, change management will determine whether to formally initiate a new architecture evolution cycle.

Additionally, the architecture change management process aims to establish and support the implemented enterprise architecture as a dynamic architecture; that is, one having the flexibility to evolve rapidly in response to changes in the technology and business environment.

Monitoring business growth and decline is a critical aspect of this phase. Usage of the enterprise architecture is the most important part of the architecture development cycle. All too often the business has been left with an enterprise architecture that works for the organization of yesterday but may not give back sufficient capability to meet the needs of the enterprise of today and tomorrow.

In many cases the architecture continues to fit, but the solutions underlying them may not, and some changes are required. The enterprise architect needs to be aware of these change requirements and considers this an essential part of constant renewal of the architecture.

Capacity measurement and recommendations for planning is a key aspect of this phase. While the architecture has been built to deliver a steady state Business Architecture with agreed capacity during the lifecycle of this enterprise architecture, the growth or decline in usage needs to be continually assessed to ensure that maximum business value is achieved.

For example, some Solution Architectures may not lend themselves to be scalable by a large factor - say 10 - or alternative solutions may be more economic when scaled up. While the architecture specifications may not change, the solutions or their operational context may change.

If the performance management and reporting has been built into the work products through previous phases, then this phase is about ensuring the effectiveness of these. If there needs to be additional monitoring or reporting, then this phase will handle the changes.

The value and change management process, once established, will determine:

  • The circumstances under which the enterprise architecture, or parts of it, will be permitted to change after deployment, and the process by which that will happen
  • The circumstances under which the architecture development cycle will be initiated again to develop a new architecture

The architecture change management process is very closely related to the architecture governance processes of the enterprise, and to the management of the Architecture Contract (see Part VII, 49. Architecture Contracts) between the architecture function and the business users of the enterprise.

In Phase H it is critical that the governance body establish criteria to judge whether a Change Request warrants just an architecture update or whether it warrants starting a new cycle of the Architecture Development Method (ADM). It is especially important to avoid "creeping elegance", and the governance body must continue to look for changes that relate directly to business value.

An Architecture Compliance report should state whether the change is compliant to the current architecture. If it is non-compliant, an exemption may be granted with valid rationale. If the change has high impact on the architecture, then a strategy to manage its impact should be defined.

Guidelines for establishing these criteria are difficult to prescribe, as many companies accept risk differently, but as the ADM is exercised, the maturity level of the governance body will improve, and criteria will become clear for specific needs.

 16.2.1 Drivers for Change

The main purpose for the development of the enterprise architecture so far has been strategic direction and top-down architecture and project generation to achieve corporate capabilities. However, enterprise architecture does not operate in a vacuum. There is usually an existing infrastructure and business which is already providing value.

There are also probably drivers for change which are often bottom-up, based upon modifying the existing infrastructure to enhance functionality. Enterprise architecture changes this paradigm by a strategic top-down approach to a degree, although the delivery of increments makes the equation more complex.

There are three ways to change the existing infrastructure that have to be integrated:

  • Strategic, top-down directed change to enhance or create new capability (capital)
  • Bottom-up changes to correct or enhance capability (operations and maintenance) for infrastructure under operations management
  • Experiences with the previously delivered project increments in the care of operations management, but still being delivered by ongoing projects

Governance will have to handle the co-ordination of these Requests for Change, plus there needs to be a lessons learned process to allow for problems with the recently delivered increments to be resolved and changes made to the Target Architectures being designed and planned.

A lessons learned process ensures that mistakes are made once and not repeated. They can come from anywhere and anyone and cover any aspect of the enterprise architecture at any level (strategic, enterprise architecture definition, transition, or project). Often an enterprise architecture-related lesson may be an indirect outcome of a lesson learned elsewhere in the organization.

The Architecture Board (see Part VII, 47. Architecture Board) assesses and approves Requests for Change (RFC). An RFC is typically in response to known problems but can also include improvements. A challenge for the Architecture Board when handling an RFC is to determine whether it should be approved or whether a project in a Transition Architecture will resolve the issue.

When assessing project or solution fit into the architecture, there may also be the case when an innovative solution or RFC drives a change in the architecture.

In addition, there are many technology-related drivers for architecture Change Requests. For example:

  • New technology reports
  • Asset management cost reductions
  • Technology withdrawal
  • Standards initiatives

This type of Change Request is normally manageable primarily through an enterprise's change management and architecture governance processes.

In addition, there are business drivers for architecture change, including:

  • Business-as-usual developments
  • Business exceptions
  • Business innovations
  • Business technology innovations
  • Strategic change

This type of Change Request often results in a complete re-development of the architecture, or at least in an iteration of a part of the architecture development cycle, as explained below.

 16.2.2 Enterprise Architecture Change Management Process

The enterprise architecture change management process needs to determine how changes are to be managed, what techniques are to be applied, and what methodologies used. The process also needs a filtering function that determines which phases of the architecture development process are impacted by requirements. For example, changes that affect only migration may be of no interest in the architecture development phases.

There are many valid approaches to change management, and various management techniques and methodologies that can be used to manage change; for example, project management methods such as PRINCE2, service management methods such as ITIL, management consultancy methods such as Catalyst, and many others. An enterprise that already has a change management process in place in a field other than architecture (for example, in systems development or project management) may well be able to adapt it for use in relation to architecture.

The following describes an approach to change management, aimed particularly at the support of a dynamic enterprise architecture, which may be considered for use if no similar process currently exists.

The approach is based on classifying required architectural changes into one of three categories:

  • Simplification change: A simplification change can normally be handled via change management techniques.
  • Incremental change: An incremental change may be capable of being handled via change management techniques, or it may require partial re-architecting, depending on the nature of the change (see 16.2.3 Guidelines for Maintenance versus Architecture Redesign for guidelines).
  • Re-architecting change: A re-architecting change requires putting the whole architecture through the architecture development cycle again.

Another way of looking at these three choices is to say that a simplification change to an architecture is often driven by a requirement to reduce investment; an incremental change is driven by a requirement to derive additional value from existing investment; and a re-architecting change is driven by a requirement to increase investment in order to create new value for exploitation.

To determine whether a change is simplification, incremental, or re-architecting, the following activities are undertaken:

  1. Registration of all events that may impact the architecture
  2. Resource allocation and management for architecture tasks
  3. The process or role responsible for architecture resources has to make assessment of what should be done
  4. Evaluation of impacts

 16.2.3 Guidelines for Maintenance versus Architecture Redesign

A good rule-of-thumb is:

  • If the change impacts two stakeholders or more, then it is likely to require an architecture redesign and re-entry to the ADM.
  • If the change impacts only one stakeholder, then it is more likely to be a candidate for change management.
  • If the change can be allowed under a dispensation, then it is more likely to be a candidate for change management.

For example:

  • If the impact is significant for the business strategy, then there may be a need to redo the whole enterprise architecture - thus a re-architecting approach.
  • If a new technology or standards emerge, then there may be a need to refresh the Technology Architecture, but not the whole enterprise architecture - thus an incremental change.
  • If the change is at an infrastructure level - for example, ten systems reduced or changed to one system - this may not change the architecture above the physical layer, but it will change the Baseline Description of the Technology Architecture. This would be a simplification change handled via change management techniques.

In particular, a refreshment cycle (partial or complete re-architecting) may be required if:

  • The Foundation Architecture needs to be re-aligned with the business strategy.
  • Substantial change is required to components and guidelines for use in deployment of the architecture.
  • Significant standards used in the product architecture are changed which have significant end-user impact; e.g., regulatory changes.

If there is a need for a refreshment cycle, then a new Request for Architecture Work must be issued (to move to another cycle).

 16.3 Inputs

This section defines the inputs to Phase H.

 16.3.1 Reference Materials External to the Enterprise

 16.3.2 Non-Architectural Inputs

 16.3.3 Architectural Inputs

 16.4 Steps

The level of detail addressed in Phase H will depend on the scope and goals of the overall architecture effort.

The order of the steps in Phase H (see below) as well as the time at which they are formally started and completed should be adapted to the situation at hand in accordance with the established architecture governance.

The steps in Phase H are as follows:

 16.4.1 Establish Value Realization Process

Influence business projects to exploit the enterprise architecture for value realization (outcomes).

 16.4.2 Deploy Monitoring Tools

Ensure monitoring tools are deployed and applied to enable the following:

  • Monitor technology changes which could impact the Baseline Architecture
  • Monitor business changes which could impact the Baseline Architecture
  • Business value tracking; e.g., investment appraisal method to determine value metrics for the business objectives
  • Monitor enterprise Architecture Capability maturity
  • Track and assess asset management programs
  • Track the QoS performances and usage
  • Determine and track business continuity requirements

 16.4.3 Manage Risks

Manage enterprise architecture risks and provide recommendations for IT strategy.

 16.4.4 Provide Analysis for Architecture Change Management

Provide analysis for architecture change management:

  • Analyze performance
  • Conduct enterprise architecture performance reviews with service management
  • Assess Change Requests and reporting to ensure that the expected value realization and Service Level Agreement (SLA) expectations of the customers are met
  • Undertake a gap analysis of the performance of the enterprise architecture
  • Ensure change management requests adhere to the enterprise architecture governance and framework

 16.4.5 Develop Change Requirements to Meet Performance Targets

Make recommendations on change requirements to meet performance targets and development of position to act.

 16.4.6 Manage Governance Process

Manage governance process and framework for architecture:

  • Arrange meeting of Architecture Board (or other Governing Council)
  • Hold meeting of the Architecture Board with the aim of the meeting to decide on handling changes (technology and business and dispensations)

 16.4.7 Activate the Process to Implement Change

Activate the architecture process to implement change:

  • Produce a new Request for Architecture Work and request for investment
  • Ensure any changes implemented in this phase are captured and documented in the Architecture Repository

 16.5 Outputs

The outputs of Phase H may include, but are not restricted to:


ADM Architecture Requirements Management

URL de origem: http://pubs.opengroup.org/architecture/togaf9-doc/arch/chap17.html
  Figure 17-1: ADM Architecture Requirements Management

 17.1 Objectives

The objectives of the Requirements Management phase are to:

  • Ensure that the Requirements Management process is sustained and operates for all relevant ADM phases
  • Manage architecture requirements identified during any execution of the ADM cycle or a phase
  • Ensure that relevant architecture requirements are available for use by each phase as the phase is executed

 17.2 Approach

 17.2.1 General

As indicated by the "Requirements Management" circle at the center of the ADM graphic, the ADM is continuously driven by the requirements management process.

It is important to note that the Requirements Management circle denotes not a static set of requirements, but a dynamic process whereby requirements for enterprise architecture and subsequent changes to those requirements are identified, stored, and fed into and out of the relevant ADM phases, and also between cycles of the ADM.

The ability to deal with changes in requirements is crucial. Architecture is an activity that by its very nature deals with uncertainty and change - the "grey area" between what stakeholders aspire to and what can be specified and engineered as a solution. Architecture requirements are therefore invariably subject to change in practice. Moreover, architecture often deals with drivers and constraints, many of which by their very nature are beyond the control of the enterprise (changing market conditions, new legislation, etc.), and which can produce changes in requirements in an unforeseen manner.

Note also that the Requirements Management process itself does not dispose of, address, or prioritize any requirements; this is done within the relevant phase of the ADM. It is merely the process for managing requirements throughout the overall ADM.

It is recommended that a Requirements Repository (see Part IV, 41.6.1 Requirements Repository) is used to record and manage all architecture requirements. Unlike the Architecture Requirements Specification, and the Requirements Impact Assessment, the Requirements Repository can hold information from multiple ADM cycles.

 17.2.2 Requirements Development

The first high-level requirements are articulated as part of the Architecture Vision, generated by means of the business scenario or analogous technique.

Each phase of the ADM, from Preliminary to Phase H, must select the approved requirements for that phase as held in the Requirements Repository and Architecture Requirements Specification. At the completion of the phase the status of all such requirements needs to be updated. During the phase execution new requirements generated for future architecture work within the scope of the current Statement of Architecture Work need to be documented within the Architecture Requirements Specification, and new requirements which are outside of the scope of the current Statement of Architecture Work must be input to the Requirements Repository for management through the Requirements Management process.

In each relevant phase of the ADM the architect should identify types of requirement that must be met by the architecture, including applicable:

  • Functional requirements
  • Non-functional requirements

When defining requirements the architect should take into account:

  • Assumptions for requirements
  • Constraints for requirements
  • Domain-specific principles that drive requirements
  • Policies affecting requirements
  • Standards that requirements must meet
  • Organization guidelines for requirements
  • Specifications for requirements

Deliverables in later ADM phases also contain mappings to the design requirements, and may also generate new types of requirements (for example, conformance requirements, time windows for implementation).

 17.2.3 Resources

The world of requirements engineering is rich with emerging recommendations and processes for requirements management. TOGAF does not mandate or recommend any specific process or tool; it simply states what an effective requirements management process should achieve (i.e., the "requirements for requirements", if you like).

 17.2.3.1 Business Scenarios

One effective technique that is described in TOGAF itself is business scenarios, which are an appropriate and useful technique to discover and document business requirements, and to articulate an Architecture Vision that responds to those requirements. Business scenarios are described in detail in Part III, 26. Business Scenarios and Business Goals.

 17.2.3.2 Requirements Tools

There is a large, and increasing, number of Commercial Off-The-Shelf (COTS) tools available for the support of requirements management, albeit not necessarily designed for architecture requirements. The Volere web site has a very useful list of leading requirements tools (see www.volere.co.uk/tools.htm).

 17.3 Inputs

Inputs to the Requirements Management phase are:

 17.4 Steps

The steps in the Requirements Management phase are described in the table below:


 

Requirements Management Steps

ADM Phase Steps

Step 1

 

Identify/document requirements - use business scenarios, or an analogous technique

Step 2

Baseline requirements:

  1. Determine priorities arising from current phase of ADM
  2. Confirm stakeholder buy-in to resultant priorities
  3. Record requirements priorities and place in Requirements Repository

 

Step 3

Monitor baseline requirements

 

Step 4

 

Identify changed requirements:

  1. Remove or re-assess priorities
  2. Add requirements and re-assess priorities
  3. Modify existing requirements

Step 5

Identify changed requirements and record priorities:

  1. Identify changed requirements and ensure the requirements are prioritized by the architect(s) responsible for the current phase, and by the relevant stakeholders
  2. Record new priorities
  3. Ensure that any conflicts are identified and managed through the phases to a successful conclusion and prioritization
  4. Generate Requirements Impact Statement (see 36.2.18 Requirements Impact Assessment) for steering the architecture team

Notes

  • Changed requirements can come in through any route. To ensure that the requirements are properly assessed and prioritized, this process needs to direct the ADM phases and record the decisions related to the requirements.
  • The Requirements Management phase needs to determine stakeholder satisfaction with the decisions. Where there is dissatisfaction, the phase remains accountable to ensure the resolution of the issues and determine next steps.

 

Step 6

 

  1. Assess impact of changed requirements on current (active) phase
  2. Assess impact of changed requirements on previous phases
  3. Determine whether to implement change, or defer to later ADM cycle; if decision is to implement, assess timescale for change management implementation
  4. Issue Requirements Impact Statement, Version n+1

Step 7

 

Implement requirements arising from Phase H

The architecture can be changed through its lifecycle by the Architecture Change Management phase (Phase H). The requirements management process ensures that new or changing requirements that are derived from Phase H are managed accordingly.

Step 8

Update the Requirements Repository with information relating to the changes requested, including stakeholder views affected

 

Step 9

 

Implement change in the current phase

Step 10

 

Assess and revise gap analysis for past phases

The gap analysis in the ADM Phases B through D identifies the gaps between Baseline and Target Architectures. Certain types of gap can give rise to gap requirements.

The ADM describes two kinds of gap:

  • Something that is present in the baseline, but not in the target (i.e., eliminated - by accident or design)
  • Something not in the baseline, but present in the target (i.e., new)

A "gap requirement" is anything that has been eliminated by accident, and therefore requires a change to the Target Architecture.

If the gap analysis generates gap requirements, then this step will ensure that they are addressed, documented, and recorded in the Requirements Repository, and that the Target Architecture is revised accordingly.

 17.5 Outputs

The outputs of the Requirements Management process may include, but are not restricted to:

The Requirements Repository will be updated as part of the Requirements Management phase and should contain all requirements information.

When new requirements arise, or existing ones are changed, a Requirements Impact Statement is generated, which identifies the phases of the ADM that need to be revisited to address the changes. The statement goes through various iterations until the final version, which includes the full implications of the requirements (e.g., costs, timescales, and business metrics) on the architecture development. Once requirements for the current ADM cycle have been finalized then the Architecture Requirements Specification should be updated


Introduction

URL de origem: http://pubs.opengroup.org/architecture/togaf9-doc/arch/chap18.html

18.1 Guidelines for Adapting the ADM Process

The Architecture Development Method (ADM) process can be adapted to deal with a number of different usage scenarios, including different process styles (e.g., the use of iteration) and also specific specialist architectures (such as security). Guidelines included within this part of TOGAF are as follows:

  • Applying Iteration to the ADM (see 19. Applying Iteration to the ADM) discusses the concept of iteration and shows potential strategies for applying iterative concepts to the ADM.
  • Applying the ADM across the Architecture Landscape (see 20. Applying the ADM across the Architecture Landscape) discusses the different types of architecture engagement that may occur at different levels of the enterprise. This section then also discusses how the ADM process can be focused to support different types of engagement.
  • Security Architecture and the ADM (see 21. Security Architecture and the ADM) provides an overview of specific security considerations that should be considered during different phases of the ADM.
  • Using TOGAF to Define & Govern SOAs (see 22. Using TOGAF to Define & Govern SOAs) shows how SOA concepts can be supported by the TOGAF framework and the specific SOA considerations for different phases of the ADM.

 18.2 Techniques for Architecture Development

The following techniques are described within Part III: ADM Guidelines and Techniques to support specific tasks within the ADM:

  • Architecture Principles (see 23. Architecture Principles) - principles for the use and deployment of IT resources across the enterprise - describes how to develop the set of general rules and guidelines for the architecture being developed.
  • Stakeholder Management (see 24. Stakeholder Management) describes Stakeholder Management, an important discipline that successful architecture practitioners can use to win support for their projects.
  • Architecture Patterns (see 25. Architecture Patterns) provides guidance on using architectural patterns.
  • Business Scenarios (see 26. Business Scenarios and Business Goals) describes the Business Scenarios technique, a method for deriving business requirements for architecture and the implied technical requirements.
  • Gap Analysis (see 27. Gap Analysis) describes the technique known as gap analysis. It is widely used in the TOGAF ADM to validate an architecture that is being developed.
  • Migration Planning Techniques (see 28. Migration Planning Techniques) describes a number of techniques to support migration planning in Phases E and F.
  • Interoperability Requirements (see 29. Interoperability Requirements) describes a technique for determining interoperability requirements.
  • Business Transformation Readiness Assessment (see 30. Business Transformation Readiness Assessment) describes a technique for identifying business transformation issues.
  • Risk Management (see 31. Risk Management) describes a technique for managing risk during an architecture/business transformation project.
  • Capability-Based Planning (see 32. Capability-Based Planning) describes the technique of capability-based planning.

 18.3 Using TOGAF with Different Architectural Styles

TOGAF is designed to be flexible and it can be used with various architectural styles. This part of TOGAF includes two chapters that are intended as useful examples.

Architectural styles differ in terms of focus, form, techniques, materials, subject, and time period. Some styles can be considered as fashionable, others focused on particular aspects of enterprise architecture. TOGAF is a generic framework and intended to be used in a wide variety of environments. It is a flexible and extensible framework that can be readily adapted to a number of architectural styles.

An organization's Architecture Landscape can be expected to contain architecture work that is developed in many architectural styles. TOGAF ensures that the needs of each stakeholder are appropriately addressed in the context of other stakeholders and the Baseline Architecture.

When using TOGAF to support a specific architectural style the practitioner must take into account the combination of distinctive features in which architecture is performed or expressed. As a first step, the distinctive features of a style must be identified.

For example, The Open Group definition for SOA identifies the following distinctive features:

  • It is based on the design of the services - which mirror real-world business activities - comprising the enterprise (or inter-enterprise) business processes.
  • Service representation utilizes business descriptions to provide context (i.e., business process, goal, rule, policy, service interface, and service component) and implements services using service orchestration.
  • It places unique requirements on the infrastructure - it is recommended that implementations use open standards to realize interoperability and location transparency.
  • Implementations are environment-specific - they are constrained or enabled by context and must be described within that context.

The second step is determining how these distinctive features will be addressed. Addressing a distinctive style should not call for significant changes to TOGAF; instead it should adjust the models, viewpoints, and tools used by the practitioner.

In Phase B, Phase C, and Phase D the practitioner is expected to select the relevant architecture resources, including models, viewpoints, and tools, to properly describe the architecture domain and demonstrate that stakeholder concerns are addressed (see Part II, 8.4.1 Select Reference Models, Viewpoints, and Tools, 10.4.1 Select Reference Models, Viewpoints, and Tools, 11.4.1 Select Reference Models, Viewpoints, and Tools, and 12.4.1 Select Reference Models, Viewpoints, and Tools). Depending upon the distinctive features, different architectural styles will add new elements that must be described, highlight existing elements, adjust the notation used to describe the architecture, and focus the architect on some stakeholders or stakeholder concerns.

Addressing the distinctive features will usually include extensions to the Architecture Content Metamodel and the use of specific notation or modeling techniques and the identification of viewpoints. Whether the style is dominant will determine whether it is necessary to revisit the Preliminary Phase and make changes to the Architecture Capability or whether support for the distinctive feature is possible within the scope of selection expected within a single ADM cycle.

Style-specific reference models and maturity models are commonly used tools that support a practitioner.

Over time new architectural styles are expected to arise to address the key problems facing practitioners. Some styles will be transitory, some will endure in a niche, and some will merge into the mainstream. The Open Group Forums and Work Groups exist to address the challenges facing the industry. These bodies produce a wide range of material that is useful to a practitioner interested in adapting TOGAF, or a particular ADM cycle, to a particular architectural style for current materials, including White Papers and Standards that are applicable (see www.opengroup.org/togaf_docs).


Applying Iteration to the ADM

URL de origem: http://pubs.opengroup.org/architecture/togaf9-doc/arch/chap19.html

19.1 Overview

The graphical representation of the TOGAF ADM, as shown in Figure 5-1, and the description of the ADM phases discretely in order in Part II, can be read to imply a deterministic waterfall methodology. This method of presentation is provided for the purpose of quickly communicating the basics of architecture development and the architecture lifecycle. In practice, two key concepts are used to manage the complexity of developing an enterprise architecture and managing its lifecycle - iteration and levels (see 20. Applying the ADM across the Architecture Landscape). The two concepts are tightly linked.

The ADM supports a number of concepts that are characterized as iteration. First, iteration describes the process of both describing a comprehensive Architecture Landscape through multiple ADM cycles based upon individual initiatives bound to the scope of the Request for Architecture Work. Second, iteration describes the integrated process of developing an architecture where the activities described in different ADM phases interact to produce an integrated architecture. In order to concisely describe the activity and outputs, this latter iteration is described in sequential terms. Third, iteration describes the process of managing change to the organization's Architecture Capability.

Iteration to develop a comprehensive Architecture Landscape:

  • Projects will exercise through the entire ADM cycle, commencing with Phase A. Each cycle of the ADM will be bound by a Request for Architecture Work. The architecture output will populate the Architecture Landscape, either extending the landscape described, or changing the landscape where required.
  • Separate projects may operate their own ADM cycles concurrently, with relationships between the different projects.
  • One project may trigger the initiation of another project. Typically, this is used when higher-level architecture initiatives identify opportunities or solutions that require more detailed architecture, or when a project identifies landscape impacts outside the scope of its Request for Architecture Work.

Iteration within an ADM cycle (Architecture Development iteration):

  • Projects may operate multiple ADM phases concurrently. Typically, this is used to manage the inter-relationship between Business Architecture, Information Systems Architecture, and Technology Architecture.
  • Projects may cycle between ADM phases, in planned cycles covering multiple phases. Typically, this is used to converge on a detailed Target Architecture when higher-level architecture does not exist to provide context and constraint.
  • Projects may return to previous phases in order to circle back and update work products with new information. Typically, this is used to converge on an executable Architecture Roadmap or Implementation and Migration Plan, when the implementation details and scope of change trigger a change or re-prioritization of stakeholder requirements.

Iteration to manage the Architecture Capability (Architecture Capability iteration):

  • Projects may require a new iteration of the Preliminary Phase to (re-)establish aspects of the Architecture Capability identified in Phase A to address a Request for Architecture Work.
  • Projects may require a new iteration of the Preliminary Phase to adjust the organization's Architecture Capability as a result of identifying new or changed requirements for Architecture Capability as a result of a Change Request in Phase H.

 19.2 Iteration Cycles

The suggested iteration cycles for the TOGAF ADM are shown in Figure 19-1, and can be used to effectively group related architectural activities to achieve a specific purpose. These iteration cycles are referenced in 19.3 Classes of Architecture Engagement and 19.5 Iteration Considerations.


  Figure 19-1: Iteration Cycles
  • Architecture Capability iterations support the creation1 and evolution of the required Architecture Capability. This includes the initial mobilization of the architecture activity for a given purpose or architecture engagement type by establishing or adjusting the architecture approach, principles, scope, vision, and governance.
  • Architecture Development iterations allow the creation of architecture content by cycling through, or integrating, Business, Information Systems, and Technology Architecture phases. These iterations ensure that the architecture is considered as a whole. In this type of iteration stakeholder reviews are typically broader. As the iterations converge on a target, extensions into the Opportunities and Solutions and Migration Planning phases ensure that the architecture's implementability is considered as the architecture is finalized.
  • Transition Planning iterations support the creation of formal change roadmaps for a defined architecture.
  • Architecture Governance iterations support governance of change activity progressing towards a defined Target Architecture.

 19.3 Classes of Architecture Engagement

An architecture function or services organization may be called on to assist an enterprise in a number of different contexts, as the architectures developed can range from summary to detail, broad to narrow coverage, and current state to future state. In these contexts the concept of iteration should be used in developing the architecture.

Typically, there are three areas of engagement for architects:

  • Identification of Required Change: Outside the context of any change initiative, architecture can be used as a technique to provide visibility of the IT capability in order to support strategic decision-making and alignment of execution.
  • Definition of Change: Where a need to change has been identified, architecture can be used as a technique to define the nature and extent of change in a structured fashion. Within largescale change initiatives, architectures can be developed to provide detailed Architecture Definition for change initiatives that are bounded by the scope of a program or portfolio.
  • Implementation of Change: Architecture at all levels of the enterprise can be used as a technique to provide design governance to change initiatives by providing big-picture visibility, supplying structural constraints, and defining criteria on which to evaluate technical decisions.

Figure 19-2 and the following table show the classes of enterprise architecture engagement.


  Figure 19-2: Classes of Enterprise Architecture Engagement

Each of these architecture engagement types is described in the table below.


Area of

Architecture

 

Engagement

Engagement

Description

Identification of Required Change

Supporting Business Strategy

As the business strategies, objectives, goals, and drivers change, it is necessary for the enterprise to change in order to maintain alignment.

The creation of new business strategies can be supported by enterprise architecture by:

  • Providing visibility of change opportunities
  • Providing elaboration on the practical impacts of a particular strategic choice
  • Providing tests on the feasibility or viability of a particular strategic direction

 

Architectural Portfolio Management of the Landscape

It is common practice across large organizations for a service management organization to provide operational reporting and management of the IT portfolio.

Enterprise architecture can add a further dimension to service management reporting, by supporting a linkage between operational performance and the strategic need for IT.

Using the traceability between IT and business inherent in enterprise architecture, it is possible to evaluate the IT portfolio against operational performance data and business needs (e.g., cost, functionality, availability, responsiveness) to determine areas where misalignment is occurring and change needs to take place.

 

Architectural Portfolio Management of Projects

It is common practice across large organizations for a program management organization to provide operational reporting and management of the change portfolio.

Enterprise architecture can add a further dimension to project portfolio management reporting, by supporting a linkage between project scope, architectural impact and business value.

Architectural factors can be added to other quantitative project factors to support strategic decision-making on project priority and funding levels.

Definition of Change

Architectural Definition of Foundational Change Initiatives

Foundational change initiatives are change efforts that have a known objective, but are not strictly scoped or bounded by a shared vision or requirements.

In foundational change initiatives, the initial priority is to understand the nature of the problem and to bring structure to the definition of the problem.

Once the problem is more effectively understood, it is possible to define appropriate solutions and to align stakeholders around a common vision and purpose.

 

Architectural Definition of Bounded Change Initiatives

Bounded change initiatives are change efforts that typically arise as the outcome of a prior architectural strategy, evaluation, or vision.

In bounded change initiatives, the desired outcome is already understood and agreed upon. The focus of architectural effort in this class of engagement is to effectively elaborate a baseline solution that addresses the identified requirements, issues, drivers, and constraints.

Implementation of Change

Architectural Governance of Change Implementation

Once an architectural solution model has been defined, it provides a basis for design and implementation.

In order to ensure that the objectives and value of the defined architecture are appropriately realized, it is necessary for continuing architecture governance of the implementation process to support design review, architecture refinement, and issue escalation.

Different classes of architecture engagement at different levels of the enterprise will require focus in specific areas, as shown below.


Engagement Type

Focus Iteration Cycles

Scope Focus

Supporting Business Strategy

Architecture Capability

Architecture Development
(Baseline First)

Broad, shallow consideration given to the Architecture Landscape in order to address a specific strategic question and define terms for more detailed architecture efforts to address strategy realization.

Architectural Portfolio Management of the Landscape

Architecture Capability

Architecture Development
(Baseline First)

Focus on physical assessment of baseline applications and technology infrastructure to identify improvement opportunities, typically within the constraints of maintaining business as usual.

Architectural Portfolio Management of Projects

Transition Planning

Architecture Governance

Focus on projects, project dependencies, and landscape impacts to align project sequencing in a way that is architecturally optimized.

Architectural Definition of Foundational Change Initiatives

Architecture Capability

Architecture Development
(Baseline First)

Transition Planning

Focus on elaborating a vision through definition of baseline and identifying what needs to change to transition the baseline to the target.

Architectural Definition of Bounded Change Initiatives

Architecture Development
(Target First)

Transition Planning

Focus on elaborating the target to meet a previously defined and agreed vision, scope, or set of constraints. Use the target as a basis for analysis to avoid perpetuation of baseline, sub-optimal architectures.

Architectural Governance of Change Implementation

Architecture Governance

Use the Architecture Vision, constraints, principles, requirements, Target Architecture definition, and transition roadmap to ensure that projects realize their intended benefit, are aligned with each other, and are aligned with wider business need.

 19.4 Approaches to Architecture Development

Two approaches can be adopted within the ADM for the development of architectures:

  • Baseline First: In this style, an assessment of the baseline landscape is used to identify problem areas and improvement opportunities. This process is most suitable when the baseline is complex, not clearly understood, or agreed upon. This approach is common where organizational units have had a high degree of autonomy.
  • Target First: In this style, the target solution is elaborated in detail and then mapped back to the baseline, in order to identify change activity. This process is suitable when a target state is agreed at a high level and where the enterprise wishes to effectively transition to the target model.

Typically, if the baseline is broadly understood a higher value will be obtained focusing on the target first then baseline to the extent necessary to identify changes.

In practical terms, an architecture team will always give informal consideration to the baseline when analyzing the target (and vice versa). In situations where baseline and target are expected to be considered in parallel by stakeholders, it is recommended that the architecture team focuses priority on one state in order to maintain focus and consistency of execution.

 19.5 Iteration Considerations

Some iteration cycles can be executed once, whereas others have a natural minimum number of cycles. For some iteration cycles, each iteration follows the same process; where there is more than one iteration within a cycle, the process differs slightly for each of the iterations.

When considering the usage of iteration cycles, it is also necessary to consider where to place appropriate checkpoints within the process. If the expected level of stakeholder involvement is high, it may be sensible to carry out very frequent but informal checkpoints to ensure that the process is moving in the intended direction. If stakeholders are less closely involved, then checkpoints may be less frequent but more formal. Checkpoints at the completion of each iteration cycle, or at the end of several iteration cycles, are common.

 19.5.1 Iteration between ADM Cycles

Each iteration completes an ADM cycle at a single level of architecture description. This approach to the ADM uses Phase F (Migration Planning) to initiate new more detailed architecture development projects. This approach is illustrated in Figure 19-3. This type of iteration highlights the need for higher-level architecture to guide and constrain more detailed architecture. It also highlights that the complete Architecture Landscape is developed by multiple ADM iterations.


  Figure 19-3: A Hierarchy of ADM Processes Example

 19.5.2 Iteration within an ADM Cycle

Each iteration cycle crosses multiple TOGAF ADM phases. The following tables show at a high level which phases should be completed for which iteration cycle, showing activity that is core (i.e., the primary focus of the iteration), activity that is light (i.e., the secondary focus of the iteration), and activity that may be informally conducted (i.e., some activity may be carried out, but it is not explicitly mentioned in the ADM).


  Figure 19-4: Activity by Iteration for Baseline First Architecture Definition


  Figure 19-5: Activity by Iteration for Target First Architecture Definition

The suggested iteration cycles mapped to the TOGAF phases are described in the following table:


Iteration Cycle

Iteration

Purpose

Description

Architecture Development
(Baseline First)

Iteration 1

Define the Baseline Architecture.

This iteration comprises a pass through the Business Architecture, Information Systems Architecture, and Technology Architecture phases of the ADM, focusing on definition of the baseline.

Opportunities, solutions, and migration plans are also considered to drive out the focus for change and test feasibility.

 

Iteration 2

Define the Target Architecture and gaps.

This iteration comprises a pass through the Business Architecture, Information Systems Architecture, and Technology Architecture phases of the ADM, focusing on definition of the target and analyzing gaps against the baseline.

Opportunities, solutions, and migration plans are also considered to test viability.

 

Iteration n

Refine baseline, target, and gaps.

Subsequent Architecture Development iterations attempt to correct and refine the target to achieve an outcome that is beneficial, feasible, and viable.

Architecture Development
(Target First)

Iteration 1

Define the Target Architecture.

This iteration comprises a pass through the Business Architecture, Information Systems Architecture, and Technology Architecture phases of the ADM, focusing on definition of the target.

Opportunities, solutions, and migration plans are also considered to drive out the focus for change and test feasibility.

 

Iteration 2

Define the Baseline Architecture and gaps.

This iteration comprises a pass through the Business Architecture, Information Systems Architecture, and Technology Architecture phases of the ADM, focusing on definition of the baseline and analyzing gaps against the target.

Opportunities, solutions, and migration plans are also considered to test viability.

 

Iteration n

Refine baseline, target, and gaps.

Subsequent Architecture Development iterations attempt to correct and refine the target to achieve an outcome that is beneficial, feasible, and viable.

Transition Planning

Iteration 1

Define and agree a set of improvement opportunities, aligned against a provisional Transition Architecture.

The initial iteration of Transition Planning seeks to gain buy-in to a portfolio of solution opportunities in the Opportunities & Solutions phase of ADM.

This iteration also delivers a provisional Migration Plan.

 

Iteration n

Agree the Transition Architecture, refining the identified improvement opportunities to fit.

Subsequent iterations of Transition Planning seek to refine the migration plan, feeding back issues into the Opportunities & Solutions phase for refinement.

Architecture Governance

Iteration 1

Mobilize architecture governance and change management processes.

The initial Architecture Governance iteration establishes a process for governance of change and also puts in place the appropriate people, processes, and technology to support managed access to and change of the defined architecture.

 

Iteration n

Carry out architecture governance and change control.

Subsequent iterations of the Architecture Governance cycle focus on periodic reviews of change initiatives to resolve issues and ensure compliance. Results of a change request may trigger another phase to be revisited; for example, feeding back a new requirement to the Preliminary Phase to improve the Architecture Capability, or a new requirement for the architecture into the Architecture Development phases.

 19.6 Conclusions

All of these techniques are valid applications of the ADM. Combined together, they represent how the ADM can be used in practice. The ADM should always be used in an iterative process. How this process is exercised is dependent upon organizational factors. Particular factors for consideration include:

  • The formality and nature of established process checkpoints within the organization. Does the organization mandate that certain groups of activities are carried out between checkpoints? Does the organization mandate that certain activities must be finalized before other activities can be carried out?
  • The level of stakeholder involvement expected within the process. Are stakeholders expecting to be closely involved within the development of a solution, or are they expecting to see a complete set of deliverables for review and approval?
  • The number of teams involved and the relationships between different teams. Is the entire architecture being developed by a specific team, or is there a hierarchy of teams with governance relationships between them?
  • The maturity of the solution area and the expected amount of rework and refinement required to arrive at an acceptable solution. Can the solution be achieved in a single pass, or does it require extensive proof-of-concept and prototyping work to evolve a suitable outcome?
  • Attitude to risk. Does the organizational culture react negatively to partially complete work products being circulated? Does the organizational culture require solutions to be proved in a trial environment before they can be implemented for mainstream application?
  • The class of engagement. What is the context for development of the enterprise architecture?

Applying the ADM across the Architecture Landscape

URL de origem: http://pubs.opengroup.org/architecture/togaf9-doc/arch/chap20.html

20.1 Overview

In a typical enterprise, many architectures will be described in the Architecture Landscape at any point in time. Some architectures will address very specific needs; others will be more general. Some will address detail; some will provide a big picture. To address this complexity TOGAF uses the concepts of levels and the Enterprise Continuum to provide a conceptual framework for organizing the Architecture Landscape. These concepts are tightly linked with organizing actual content in the Architecture Repository and any architecture partitions discussed in Part V.

 20.2 Architecture Landscape

Levels provide a framework for dividing the Architecture Landscape into three levels of granularity:

  1. Strategic Architecture provides an organizing framework for operational and change activity and allows for direction setting at an executive level.
  2. Segment Architecture provides an organizing framework for operational and change activity and allows for direction setting and the development of effective architecture roadmaps at a program or portfolio level.
  3. Capability Architecture provides an organizing framework for change activity and the development of effective architecture roadmaps realizing capability increments.

Figure 20-1 shows a summary of the classification model for Architecture Landscapes.


  Figure 20-1: Summary Classification Model for Architecture Landscapes

The Architecture Continuum provides a method of dividing each level of the Architecture Landscape (see 39.4.1 Architecture Continuum) by abstraction. It offers a consistent way to define and understand the generic rules, representations, and relationships in an architecture, including traceability and derivation relationships. The Architecture Continuum shows the relationships from foundation elements to organization-specific architecture, as shown in Figure 20-2.

The Architecture Continuum is a useful tool to discover commonality and eliminate unnecessary redundancy.


  Figure 20-2: Summary of Architecture Continuum

Levels and the Architecture Continuum provide a comprehensive mechanism to describe and classify the Architecture Landscape. These concepts can be used to organize the Architecture Landscape into a set of related architectures with:

  • Manageable complexity for each individual architecture or solution
  • Defined groupings
  • Defined hierarchies and navigation structures
  • Appropriate processes, roles, and responsibilities attached to each grouping

There is no definitive organizing model for architecture, as each enterprise should adopt a model that reflects its own operating model.

 20.3 Organizing the Architecture Landscape to Understand the State of the Enterprise

The following characteristics are typically used to organize the Architecture Landscape:

  • Breadth: The breadth (subject matter) area is generally the primary organizing characteristic for describing an Architecture Landscape. Architectures are functionally decomposed into a hierarchy of specific subject areas or segments.
  • Depth: With broader subject areas, less detail is needed to ensure that the architecture has a manageable size and complexity. More specific subject matter areas will generally permit (and require) more detailed architectures.
  • Time: For a specific breadth and depth an enterprise can create a Baseline Architecture and a set of Target Architectures that stretch into the future. Broader and less detailed architectures will generally be valid for longer periods of time and can provide a vision for the enterprise that stretches further into the future.
  • Recency: Finally, each architecture view will progress through a development cycle where it increases in accuracy until finally approved. After approval, an architecture will begin to decrease in accuracy if not actively maintained. In some cases recency may be used as an organizing factor for historic architectures.

Using the criteria above, architectures can be grouped into Strategic, Segment, and Capability Architecture levels, as described in Figure 20-1.

 20.4 Developing Architectures at Different Levels

The previous sections have identified that different types of architecture are required to address different stakeholder needs at different levels of the organization. Each architecture typically does not exist in isolation and must therefore sit within a governance hierarchy. Broad, summary architectures set the direction for narrow and detailed architectures.

A number of techniques can be employed to use the ADM as a process that supports such hierarchies of architectures. Essentially there are two strategies that can be applied:

  1. Architectures at different levels can be developed through iterations within a single cycle of the ADM process.
  2. Architectures at different levels can be developed through a hierarchy of ADM processes, executed concurrently.

At the extreme ends of the scale, either of these two options can be fully adopted. In practice, an architect is likely to need to blend elements of each to fit the exact requirements of their Request for Architecture Work. Each of these approaches is described in 19. Applying Iteration to the ADM.


Security Architecture and the ADM

URL de origem: http://pubs.opengroup.org/architecture/togaf9-doc/arch/chap21.html

21.1 Overview

The goal of this chapter is to explain the security considerations that need to be addressed during application of the TOGAF Architecture Development Method (ADM).

 21.2 Introduction

Architecture development methods are tools in the hands of the security practitioner to be used to create best practice and organization-specific security capability.

The guidance included here is intended to help both enterprise architects and security practitioners to avoid missing critical security concerns.

This chapter informs the enterprise architect of what the security architect will need to carry out during the security architecture work.

Often the security architecture is treated as a separate architecture domain within the enterprise architecture while needing to be fully integrated in it. The focus of the security architect is enforcement of security policies of the enterprise without inhibiting value.

Security architectures generally have the following characteristics:

  • Security architecture has its own discrete security methodology.
  • Security architecture composes its own discrete views and viewpoints.
  • Security architecture addresses non-normative flows through systems and among applications.
  • Security architecture introduces its own normative flows through systems and among applications.
  • Security architecture introduces unique, single-purpose components in the design.
  • Security architecture calls for its own unique set of skills and competencies of the enterprise and IT architects.

 21.3 Guidance on Security for the Architecture Domains

Security concerns are pervasive throughout the architecture domains and in all phases of the architecture development. Security is called out separately because it is infrastructure that is rarely visible to the business function. Its fundamental purpose is to protect the value of the systems and information assets of the enterprise. Often the nature of security in the enterprise is that it is deemed successful if either nothing happens that is visible to the user or other observer, and/or no damage or losses occur to the enterprise. For example, the data in a customer records database is not leaked or damaged - or an intangible issue such as the company name appears in an article in the news saying that its data systems had been compromised.

The security architecture does have its own single-purpose components and is experienced as a quality of systems in the architecture. The Enterprise Security view of the architecture has its own unique building blocks, collaborations, and interfaces. These security-unique elements must interface with the business systems in a balanced and cost-effective way, so as to maintain the security policies of the enterprise, yet not interfere with system operations and functions. It is least costly and most effective to plan for and implement security-specific functions in the Target Architecture as early as possible in the development cycle to avoid costly retrofit or rework because required building blocks for security were not added or used during systems development and deployment. The approach of the security architect considers not only the normal flow of the application, but also the abnormal flows, failure modes, and ways the systems and applications can be interrupted and fail.

All groups of stakeholders in the enterprise will have security concerns and it is desirable to bring a security architect into the project as early as possible. Throughout the phases of the ADM, guidance will be offered on security-specific information which should be gathered, steps which should be taken, and artifacts which should be created. Architecture decisions related to security should be traceable to business and policy decisions and their risk management.

The generally accepted areas of concern for the security architect are:

  • Authentication: The substantiation of the identity of a person or entity related to the enterprise or system in some way.
  • Authorization: The definition and enforcement of permitted capabilities for a person or entity whose identity has been established.
  • Audit: The ability to provide forensic data attesting that the systems have been used in accordance with stated security policies.
  • Assurance: The ability to test and prove that the enterprise architecture has the security attributes required to uphold the stated security policies.
  • Availability: The ability of the enterprise to function without service interruption or depletion despite abnormal or malicious events.
  • Asset Protection: The protection of information assets from loss or unintended disclosure, and resources from unauthorized and unintended use.
  • Administration: The ability to add and change security policies, add or change how policies are implemented in the enterprise, and add or change the persons or entities related to the systems.
  • Risk Management: The organization's attitude and tolerance for risk. (This risk management is different from the special definition found in financial markets and insurance institutions that have formal risk management departments.)

Typical security architecture artifacts would include:

  • Business rules regarding handling of data/information assets
  • Written and published security policy
  • Codified data/information asset ownership and custody
  • Risk analysis documentation
  • Data classification policy documentation

 21.4 ADM Architecture Requirements Management

The security policy and security standards become part of the enterprise requirements management process. Security policy is established at an executive level of the business, is long-lived, and resistant to whimsical change. Security policy is not tied to any specific technology. Once the security policies are established, they can be referred to as requirements for all architecture projects.

Security standards change more frequently and state technology preferences used to support security policies. New technologies that support the implementation of security policies in a better way can be adopted as needed. The improvements can be in reduced costs or increased benefits. Security standards will manifest themselves as security-related building blocks in the Enterprise Continuum. Security patterns for deploying these security-related building blocks are referred to in the Security Guidance to Phase E.

New security requirements arise from many sources:

  1. A new statutory or regulatory mandate
  2. A new threat realized or experienced
  3. A new IT architecture initiative discovers new stakeholders and/or new requirements

In the case where 1. and 2. above occur, these new requirements would be drivers for input to the change management system discussed in Phase H. A new architecture initiative might be launched to examine the existing infrastructure and applications to determine the extent of changes required to meet the new demands. In the case of 3. above, a new security requirement will enter the requirements management system.

 Is our security good?

This question inevitably comes from management to the security architect. No security measures are ever perfect, and the potential exists for the amount of money and effort expended to become very large for little additional return. Security assurance testing should be in place so that the security systems can be measured to ensure that they keep the security policies for which they were designed. Security policy audits should be held and might be mandatory by statute or regulation. These security audits and possible security policy changes are the exact reason why separation of policy enforcement from application code is so strongly emphasized.

 Nothing useful can be said about a security measure outside the context of an application, or a system and its environment

The efficacy of a security measure is considered in relation to the risk it mitigates. An enterprise cannot determine how much it will be willing to spend on securing an asset until it understands the asset value. For example, the use of that asset in an application and the concomitant risk the asset is exposed to as a result, will determine the true requirements for security. Additionally, the organization's tolerance for risk is a factor. In other words, the question asked should not be: "Is it secure?" but rather: "Is it secure enough?" The latter is ultimately a question to be answered by risk analysis.

 21.5 Preliminary Phase

 Scope the enterprise organizations impacted by the security architecture
  • Identify core enterprise (units) - those who are most affected and achieve most value from the security work
  • Identify soft enterprise (units) - those who will see change to their capability and work with core units but are otherwise not directly affected
  • Identify extended enterprise (units) - those units outside the scoped enterprise who will need to enhance their security architecture for interoperability purposes
  • Identify communities involved (enterprises) - those stakeholders who will be affected by security capabilities and who are in groups of communities
  • Identify the security governance involved, including legal frameworks and geographies (enterprises)

If the business model of the organization does encompass federation with other organizations, the extent of the security federation should be established at this point in the process. Contractual federation agreements should be examined for their security implications and agreements. It may be necessary to establish joint architecture meetings with other members of a federation to establish interfaces and protocols for exchange of security information related to federated identity, authentication, and authorization.

 Define and document applicable regulatory and security policy requirements

The framework and principles rarely change, and so the security implications called out in the objectives of this phase should be fairly straightforward. A written security policy for the organization must be in place, and there should be regular notification and education established for employees. ISO/IEC 17799:2005 is a good place to start the formation of a security policy, and can be used to assess the security readiness of an organization. Without a written and published security policy, enforcement is difficult. Security policies refer to many aspects of security for the organization - such as physical premises security - that are remotely related to security of systems and applications. The security policy should be examined to find relevant sections, and updated if necessary. Architecture constraints established in the security policy must be communicated to the other members of the architecture team.

In a similar fashion, there may be regulatory requirements that specify obligations the system must fulfil or actions that must be taken. Whether the system will be subject to regulation will depend upon the functionality of the system and the data collected or maintained. In addition, the jurisdiction where the system or service is deployed, where the users reside, or under which the deploying entity is chartered or incorporated will inform this decision. It may be wise to obtain legal counsel regarding these obligations at the outset of activities.

 Define the required security capability as part of Architecture Capability

Agreement on the role of the security architect in the enterprise architecture process and in the architecture and IT governance should also be established. Security considerations can conflict with functional considerations and a security advocate is required to ensure that all issues are addressed and conflicts of interest do not prevent explicit consideration of difficult issues. Executive policy decisions should be established at this point about what security policies can be negotiable and which policies must be enforced for regulatory or statutory reasons.

 Implement security architecture tools

The level of formality used to define and manage security architecture content will be highly dependent on the scale, sophistication, and culture of the security architecture function.

The approach to security tools may be based on relatively informal usage of standard office productivity applications, or may be based on a customized deployment of specialist security architecture tools and techniques.

 21.5.1 Security Inputs

  • Written security policy
  • Relevant statutes
  • List of applicable jurisdictions

 21.5.2 Security Outputs

  • List of applicable regulations
  • List of applicable security policies
  • Security team roster
  • List of security assumptions and boundary conditions

 21.6 Phase A: Architecture Vision

Security considerations have an impact on Phases A to H of the TOGAF ADM. The following security specifics appropriate to the security architecture must be addressed within each phase in addition to the generic phase activities.

The steps of the Architecture Vision phase are applicable to ensuring that security requirements are addressed in subsequent phases of the ADM. Security considerations will have an effect on the enterprise such that all enterprise architecture development needs to be informed and utilize the security policy, constraints, governance, artifacts, and building blocks.

After establishing any enterprise architecture project, the following specific security-related activities need to be undertaken.

Definition of relevant stakeholders and discovery of their concerns and objectives will require development of a high-level scenario. Key business requirements will also be established through this early scenario work. The TOGAF ADM business scenario process may be useful here and at later stages.

 Obtain management support for security measures

In similar fashion to obtaining management recognition and endorsement for the overall architecture project, so too endorsement of the security-related aspects of the architecture development effort should be obtained. Recognition that the project might have development and infrastructure impact that are not readily visible by looking solely at the systems in question should be made clear. Thorough consideration and mitigation of issues related to risk and security may be perceived as a waste of resources and time; the level of management support must be understood and communicated throughout the team.

 Define necessary security-related management sign-off milestones of this architecture development cycle

The traceability of security-related architecture decisions should be documented and the appropriate executives and line management who need to be informed of security-related aspects of the project need to be identified and the frequency of reporting should be established. It should be recognized that the tension between delivery of new business function and enforcement of security policies does exist, and that a process for resolving such disputes that arise should be established early in the project. Such tensions often have the result of putting the security architect seemingly "in the way of completing the project". It needs to be understood by management and the other architects involved that the role of the security architect is to safeguard the assets of the enterprise.

 Determine and document applicable disaster recovery or business continuity plans/requirements

Any existing disaster recovery and business continuity plans must be understood and their relationship with the planned system defined and documented.

 Identify and document the anticipated physical/business/regulatory environment(s) in which the system(s) will be deployed

All architecture decisions must be made within the context of the environments within which the system will be placed and operate. Physical environments that should be documented may include battlefield environments, commercial environments, outdoor environments, mobile environments, and the like. In a similar fashion, the business environment must be defined. Potential business environments may include different assumptions regarding users and interfaces, and those users or interfaces may carry the onus of regulatory environments in which the system must operate (users under the age of thirteen in the US, for example).

 Determine and document the criticality of the system: safety-critical/mission-critical/non-critical

Safety-critical systems place lives in danger in case of failure or malfunction.

Mission-critical systems place money, market share, or capital at risk in case of failure.

Non-critical systems have little or no consequence in case of failure.

 21.6.1 Security Inputs

  • List of applicable security policies
  • List of applicable jurisdictions
  • Complete disaster recovery and business continuity plans

 21.6.2 Security Outputs

  • Physical security environment statement
  • Business security environment statement
  • Regulatory environment statement
  • Security policy cover letter signed by CEO or delegate
  • List of architecture development checkpoints for security sign-off
  • List of applicable disaster recovery and business continuity plans
  • Systems criticality statement

 21.7 Phase B: Business Architecture

 Determine who are the legitimate actors who will interact with the product/service/process

Development of the business scenarios and subsequent high-level use-cases of the project concerned will bring to attention the people actors and system actors involved. Many subsequent decisions regarding authorization will rely upon a strong understanding of the intended users, administrators, and operators of the system, in addition to their expected capabilities and characteristics. It must be borne in mind that users may not be humans; software applications may be legitimate users. Those tending to administrative needs, such as backup operators, must also be identified, as must users outside boundaries of trust, such as Internet-based customers.

 Assess and baseline current security-specific business processes (enhancement of existing objective)

The business process regarding how actors are vetted as proper users of the system should be documented. Consideration should also be made for actors from outside the organization who are proper users of the system. The outside entities will be determined from the high-level scenarios developed as part of Phase A.

 Determine whom/how much it is acceptable to inconvenience in utilizing security measures

Security measures, while important, can impose burden on users and administrative personnel. Some will respond to that burden by finding ways to circumvent the measures. Examples include administrators finding ways to create "back doors" or customers choosing a competitor to avoid the perceived burden of the infrastructure. The trade-offs can require balancing security advantages against business advantages and demand informed judicious choice.

 Identify and document interconnecting systems beyond project control

Every cybernetic or business system must rely upon existing systems beyond the control of the project. These systems possess advantages and disadvantages, risks and benefits. Examples include the Domain Name System (DNS) that resolves computer and service names to Internet addresses, or paper currency issued by the local treasury. The address returned by the host or service DNS may not always be trustworthy; paper currency may not always be genuine, and recourse will vary in efficacy between jurisdictions. These interfaces must be understood and documented.

 Determine the assets at risk if something goes wrong - "What are we trying to protect?"

Assets are not always tangible and are not always easy to quantify. Examples include: loss of life, loss of customer good will, loss of a AAA bond rating, loss of market share.

 Determine the cost (both qualitative and quantitative) of asset loss/impact in failure cases

It must be remembered that those assets most challenging to quantify can be the most valuable and must not be neglected. Even qualitative estimates will prove valuable in assessing comparative risks.

 Identify and document the ownership of assets

Assets may be owned by outside entities, or by inside entities. Inside entities may be owned by individuals or by organizations. Determine:

  • Where trust is assumed
  • How it is established
  • How it is communicated

Always trace it to the real world; i.e.:

  • Assessment (credit searches, personal vouching)
  • Liability (monetary damages, jail terms, sanctions)

All security decisions rely upon trust that has been established in some fashion. No trust assumptions have any value if they cannot be rooted in real-world assessment and liability. In most business environments, trust is established through contracts that define liability where the trust is breached. The onus for assessing trust is the responsibility of those choosing to enter into the contracts and their legal counsel. It is important to note that technology (e.g., digital certificates, SAML, etc.) cannot create trust, but can only convey in the electronic world the trust that already exists in the real world through business relationships, legal agreements, and security policy consistencies.

 Determine and document appropriate security forensic processes

To be able to enforce security policies, breaches of security need to be properly captured so that problem determination and possible policy or legal action can be taken against the entity causing the breach. Forensic practices suitable to provide evidence where necessary need to be established and documented. Security personnel should be trained to follow the forensic procedures and training material regarding the need to collect evidence should be considered for the standard security education given to employees.

 Identify the criticality of the availability and correct operation of the overall service

The risks associated with loss of availability may have already been adequately considered in the foregoing mission-critical/safety-critical assessment.

 Determine and document how much security (cost) is justified by the threats and the value of the assets at risk

A risk analysis (an understanding of the value of assets at risk and the likelihood of potential threats) provides an important guideline for investments in mitigation strategies for the identified threats.

 Reassess and confirm Architecture Vision decisions

Business analysis involves a number of rigorous thought exercises and may call into question the initial assumptions identified in the Architecture Vision.

 Assess alignment or conflict of identified security policies with business goals

The security policies identified in the Preliminary Phase may have provisions that are difficult or impossible to reconcile with the business goals in light of the identified risks. Possible responses include alteration of aspects of the business environment, modification of the intended user population, or technical mitigation of risks (addressed in Phase C).

 Determine "what can go wrong?"

Perform a threat analysis that identifies the high-level threats bearing upon the system and their likelihood.

 21.7.1 Security Inputs

  • Initial business and regulatory security environment statements
  • List of applicable disaster recovery and business continuity plans
  • List of applicable security policies and regulations

 21.7.2 Security Outputs

  • List of forensic processes
  • List of new disaster recovery and business continuity requirements
  • Validated business and regulatory environment statements
  • List of validated security policies and regulations
  • List of target security processes
  • List of baseline security processes
  • List of security actors
  • List of interconnecting systems
  • Statement of security tolerance for each class of security actor
  • Asset list with values and owners
  • List of trust paths
  • Availability impact statement(s)
  • Threat analysis matrix

 21.8 Phase C: Information Systems Architectures

 Assess and baseline current security-specific architecture elements (enhancement of existing objective)

A full inventory of architecture elements that implement security services must be compiled in preparation for a gap analysis.

 Identify safe default actions and failure states

Every state change in any system is precipitated by some trigger. Commonly, an enumerated set of expected values of that trigger initiates a change in state. However, there are likely other potential trigger inputs that must be accommodated in non-normative cases. Additionally, system failure may take place at any point in time. Safe default actions and failure modes must be defined for the system informed by the current state, business environment, applicable policies, and regulatory obligations. Safe default modes for an automobile at zero velocity may no longer be applicable at speed. Safe failure states for medical devices will differ markedly from safe failure states for consumer electronics.

 Identify and evaluate applicable recognized guidelines and standards

Standards are justly credited for reducing cost, enhancing interoperability, and leveraging innovation. From a security standpoint, standard protocols, standard object libraries, and standard implementations that have been scrutinized by experts in their fields help to ensure that errors do not find their way into implementations. From a security standpoint, errors are security vulnerabilities.

 Revisit assumptions regarding interconnecting systems beyond project control

In light of the risk assessments performed, assumptions regarding interconnecting systems may require modification.

 Determine and document the sensitivity or classification level of information stored/created/used

Information stored, created, or manipulated by the system may or may not be subject to an official classification that defines its sensitivity and the obligations to which the system and its owners are subject. The absence of any official classification does not necessarily absolve the onus on maintaining the confidentiality of data. Consideration must be made for different legislative burden that may hold jurisdiction over the system and the data stored.

 Identify and document custody of assets

All assets of value are kept and maintained on behalf of the owner. The specific persons or organizations charged with this responsibility must be identified.

 Identify the criticality of the availability and correct operation of each function

Presumably, in the event of system failure or loss of functionality, some value is lost to stakeholders. The cost of this opportunity loss should be quantified, if possible, and documented.

 Determine the relationship of the system under design with existing business disaster/continuity plans

Existing business disaster/continuity plans may accommodate the system under consideration. If not, some analysis is called for to determine the gap and the cost if that gap goes unfilled.

 Identify what aspects of the system must be configurable to reflect changes in policy/business environment/access control

No environment is static and systems must evolve to accommodate change. Systems architected for ready reconfiguration will better reflect that change and result in lower cost over the life of the system. Security is enhanced when security-related changes can be implemented inexpensively and are, hence, not sidelined. Security is also enhanced when changes require no changes to code; changes to code introduce bugs and bugs introduce security vulnerabilities.

 Identify lifespan of information used as defined by business needs and regulatory requirements

Information maintained beyond its useful lifespan represents wasted resources and, potentially, business decisions based upon suboptimal data. Regulation, however, sometimes mandates the timetable for maintenance of information as archival data.

 Determine approaches to address identified risks:
  • Mitigate
  • Accept
  • Transfer
  • Avoid

There are several standard ways to address identified and quantified risk. The list above is not intended to be exhaustive for all approaches.

 Identify actions/events that warrant logging for later review or triggering forensic processes

Anomalous actions and states will outnumber planned actions and states. These transitions will warrant logging to reconstruct chains of events, facilitate root cause analysis, and, potentially, establish evidence for civil or criminal action. It must be borne in mind that logs must be regularly reviewed to be introduced as evidence into a court of law in some jurisdictions.

 Identify and document requirements for rigor in proving accuracy of logged events (non-repudiation)

Since malicious tampering of systems is commonly accompanied by tampering of logged data to thwart investigation and apprehension, the ability to protect and establish the veracity of logs through cryptographic methods will remove uncertainty from investigations and bolster cases in legal proceedings.

 Identify potential/likely avenues of attack

Thinking like an adversary will prepare the architect for creation of a robust system that resists malicious tampering and, providentially, malfunction arising from random error.

 Determine "what can go wrong?"

 21.8.1 Security Inputs

  • Threat analysis matrix
  • Risk analysis
  • Documented forensic processes
  • Validated business policies and regulations
  • List of interconnecting systems
  • New disaster recovery and business continuity requirements

 21.8.2 Security Outputs

  • Event log-level matrix and requirements
  • Risk management strategy
  • Data lifecycle definitions
  • List of configurable system elements
  • Baseline list of security-related elements of the system
  • New or augmented security-related elements of the system
  • Security use-case models:
    • Normative models
    • Non-normative models
  • List of applicable security standards:
    • Protocols
    • Object libraries
    • Others ...
  • Validated interconnected system list
  • Information classification report
  • List of asset custodians
  • Function criticality statement
  • Revised disaster recovery and business continuity plans
  • Refined threat analysis matrix

 21.9 Phase D: Technology Architecture

 Assess and baseline current security-specific technologies (enhancement of existing objective)
 Revisit assumptions regarding interconnecting systems beyond project control
 Identify and evaluate applicable recognized guidelines and standards
 Identify methods to regulate consumption of resources

Every system will rely upon resources that may be depleted in cases that may or may not be anticipated at the point of system design. Examples include network bandwidth, battery power, disk space, available memory, and so on. As resources are utilized approaching depletion, functionality may be impaired or may fail altogether. Design steps that identify non-renewable resources, methods that can recognize resource depletion, and measures that can respond through limiting the causative factors, or through limiting the effects of resource depletion to non-critical functionality, can enhance the overall reliability and availability of the system.

 Engineer a method by which the efficacy of security measures will be measured and communicated on an ongoing basis

As systems are deployed and operated in dynamic environments, security measures will perform to varying degrees of efficacy as unexpected threats arise and as expected threats change in the environment. A method that facilitates ongoing evaluation of the value of security measures will inform ongoing changes to the system in response to changing user needs, threat patterns, and problems found.

 Identify the trust (clearance) level of:
  • All users of the system
  • All administrators of the system
  • All interconnecting systems beyond project control

Regulatory requirements, information classification levels, and business needs of the asset owners will all influence the required level of trust that all interactive entities will be required to fulfil to qualify for access to data or services.

 Identify minimal privileges required for any entity to achieve a technical or business objective

Granting sweeping capabilities to any user, application, or other entity can simplify successful transaction completion at the cost of complicating or precluding effective control and audit. Many regulatory obligations are more challenging to demonstrate compliance where privileges are sweeping and controls are loose.

 Identify mitigating security measures, where justified by risk assessment

This objective is where the classic security services of identification, authentication, authorization, data confidentiality, data integrity, non-repudiation, assurance, and audit are brought into play, after their applicability is determined and the cost/value of protection has been identified.

 Determine "what can go wrong?"

 21.9.1 Security Inputs

  • List of security-related elements of the system
  • List of interconnected systems
  • List of applicable security standards
  • List of security actors
  • Risk management strategy
  • Validated security policies
  • Validated regulatory requirements
  • Validated business policies related to trust requirements

 21.9.2 Security Outputs

  • Baseline list of security technologies
  • Validated interconnected systems list
  • Selecte