ToGaF9

38: Introduction

The Enterprise Continuum provides a view of the Architecture Repository that shows the evolution of these related architectures from generic to specific, from abstract to concrete, and from logical to physical.

the Enterpr ise Continuum is as a view of the repository of all the architecture assets It can contain architecture descriptions, models, building blocks, patterns,
viewpoints, and other artifacts

levels:
n Logical to physical
n Hor izontal (IT-focused) to ver tical (business-focused)
n Generalization to specialization
n Taxonomy to complete and specific architecture specification

39: Enterprise Continuum

Architecture Continuum :
- Foundation Architecture
- Common Systems Architectures
- Industr y Architectures
- Organization-Specific Architectures

characteristics of Common Systems Architectures include:
n Reflects requirements specific to a generic problem domain
n Defines building blocks specific to a generic problem domain
n Defines business, data, application, or technology standards for implementing these building blocks
n Provides building blocks for easy re-use and lower costs

character istics of Industry Architectures include:
n Reflects requirements and standards specific to a ver tical industr y
n Defines building blocks specific to a generic problem domain
n Contains industry-specific logical data and process models
n Contains industry-specific applications and process models, as well as industry-specific business rules
n Provides guidelines for testing collections of systems
n Encourages levels of interoperability throughout the industry

Organization-Specific Architecture has the following character istics:
n Provides a means to communicate and manage business operations across all four architectural domains
n Reflects requirements specific to a particular enterpr ise
n Defines building blocks specific to a particular enterpr ise
n Contains organization-specific business models, data, applications, and technologies
n Provides a means to encourage implementation of appropriate solutions to meet business needs
n Provides the criter ia to measure and select appropriate products, solutions, and services
n Provides an evolutionar y path to support growth and new business needs

Solutions Continuum :
- Foundation Solutions
- Common Systems Solutions
- Industr y Solutions
- Organization-Specific Solutions

40: Architecture Par titioning

We need to partition architectures because:
n Addressing all problems within a single architecture is too complex.
n Different architectures conflict with one another
n Different people need to wor k on different elements of architecture at the same time.....
n Effective architecture re-use requires modular architecture segments.....

Characteristics of Solutions :
- Subject Matter:
- Time:
- Maturity/Volatility:

Characteristics of Architectures
- Subject Matter:
- Viewpoint:
- Level of Detail:
- Level of Abstraction:
- Accuracy:

41: Architecture Repository

six classes of architectural information to be held within an Architecture Repository:
- Architecture Metamodel
- Architecture Capability
- Architecture Landscape
- Standards Information Base
- Reference Library
- Governance Log

Architecture Landscape :
- Strategic Architectures
- Segment Architectures
- Capability Architectures

The Reference Library provides a repository area to hold best practice or template materials that can be used to construct architectures within an enterpr ise.

The Standards Information Base provides a repository area to hold a set of specifications, to which architectures must confor m. Establishment of a Standards Infor mation Base provides an unambiguous basis for architectural governance

Types of SIB Standard :
- Legal and Regulatory Obligations:
- Industry Standards:
- Organizational Standards:

The Governance Log provides a repository area to hold shared infor mation relating to the ongoing governance of projects.

Governance Log contain these items:
- Decision Log:
- Compliance Assessments:
- Capability Assessments:
- Calendar:
- Project Por tfolio:
- Performance Measurement:

42: Tools for Architecture Development

43: Foundation Architecture: Technical
Reference Model

The TOGAF Foundation Architecture is an architecture of generic services and functions that provides a foundation on which more specific architectures and architectural components can be built. This Foundation Architecture is embodied within the Technical Reference Model (TRM),
which provides a model and taxonomy of gener ic platfor m ser vices.

TRM Has Two Main Component :

1. A taxonomy, which defines terminology, and provides a coherent description of the components and conceptual structure of an infor mation system
2. An associated TRM graphic, which provides a visual representation of the taxonomy, as an aid to understanding

The high-level TRM seeks to emphasize two major common architectural objectives:
1. Application Portability, via the Application Platfor m Interface — identifying the set of ser vices that are to be made available in a standard way to applications via the platform
2. Interoperability, via the Communications Infrastr ucture Interface — identifying the set of Communications Infrastr ucture ser vices that are to be leveraged in a standard way by the platform

The three entities of TRM:
— Application Software
— Application Platform
— Communications Infrastr ucture
The two interfaces of TRM:
— Application Platfor m Interface
— Communications Infrastr ucture Interface

Chapter 44: Integrated Information Infrastructure
Reference Model

the III-RM has two main components:
1. A taxonomy, which defines terminology, and provides a coherent description of the components and conceptual structure of an integrated infor mation infrastr ucture
2. An associated III-RM graphic, which provides a visual representation of

The III-RM has the following core components:
n Business Applications :
— Brokering Applications, which manage the requests from any number of clients to and across any number of Infor mation Provider Applications
— Information Provider Applications, which provide responses to client requests and rudimentar y access to data managed by a par ticular server
— Information Consumer Applications, which deliver content to the user of the system, and provide services to request access to infor mation in the system on the user’s behalf
n Infrastructure Applications:
- Development Tools
- Management Utilities
n An Application Platform
n The Interfaces
n The Qualities

45: Introduction

Architecture Capability Framework provides a set of reference materials for how to establish such an architecture function.

Part VII: Architecture Capability Framework is str uctured as follows:

n Architecture Capability
n Architecture Board
n Architecture Compliance
n Architecture Contracts
n Architecture Governance
n Architecture Maturity Models
n Architecture Skills Framework

46: Establishing an Architecture Capability

47: Architecture Board

Architecture Boards typically comprise representatives from the organization at a minimum of two levels:
n Local (domain experts, line responsibility)
n Global (organization-wide responsibility)

48: Architecture Compliance

The Meaning of Architecture Compliance :
Irrelevant:
The implementation has no features in common with the
architecture specification (so the question of conformance
does not arise).
Consistent:
The implementation has some features in common with the
architecture specification,
Compliant:
Some features in the architecture specification are not
implemented, but all features implemented are covered by the specification, and in accordance with it.
Conformant:
All the features in the architecture specification are
implemented in accordance with the specification, but
some more features are implemented that are not
in accordance with it.
Fully Conformant:
There is full correspondence between architecture
specification and implementation. All specified features
are implemented in accordance with the specification,
and there are no features implemented that are not
covered by the specification.
Non-conformant:
Any of the above in which some features in the architecture specification are implemented not in accordance with the specification.

49: Architecture Contracts

Architecture Contracts are the joint agreements between development partners and sponsors on the deliverables, quality, and fitness-for-pur pose of an architecture.

Subtopic

50: Architecture Governance

Governance is essentially about ensuring that business is conducted properly.

domains with their own disciplines and processes:
n Corporate governance
n Technology governance
n IT governance
n Architecture governance

Character istics of Governance :
- Discipline
- Transparency
- Independence
- Accountability
- Responsibility
- Fairness

51: Architecture Maturity Models

52: Architecture Skills Framework

33: Introduction

The content framework provides a structural model for architectural content that allows the major work products that an architect creates to be consistently defined, structured, and presented.

type of architectural wor k product within the context of use:
A deliverable - An ar tifact - A building block

The content metamodel provides a definition of all the types of building blocks that may exist within an architecture, showing how these building blocks can be described and related to one another.

34: Content Metamodel

the core concepts that make up the TOGAF content metamodel:
- Core and Extension Content
- Core Metamodel Entities
- Catalog, Matrix, and Diagram Concept

Core Metamodel Entities

n Actor: A person, organization, or system that is outside the consideration of the architecture model, but interacts with it.
n Application Component: An encapsulation of application functionality that is aligned to mplementation structur ing.
n Business Service: Suppor ts business capabilities through an explicitly defined interface and is explicitly governed by an organization.
n Data Entity: An encapsulation of data that is recognized by a business domain exper t as a discrete concept.
n Function: Delivers business capabilities closely aligned to an organization
n Organization: A self-contained unit of resources with line management responsibility, goals, objectives, and measures.
n Platform Service: A technical capability required to provide enabling infrastructure that supports the delivery of applications.
n Role: An actor assumes a role to perform a task.
n Technology Component: An encapsulation of technology infrastructure that represents a class of technology product

The content metamodel defines a set of entities that allow architectural concepts to be captured, stored, filtered, queried, and represented in a way that supports consistency, completeness, and traceability.

Acoordind to ADM Phase , it divide to 5 lines :
- Architecture Principles, Vision, and Requirements
- Business Architecture
- Information Systems Architecture
- Technology Architecture
- Architecture Realization

Imporant : Read Page 393 to 396

35: Architectural Artifacts

Talking about View and viewpoint

The specific classes of viewpoint are as follows:
- Catalogs are specific foundational viewpoints that represent lists of building blocks.
- Matrices are specific foundational viewpoints that show the relationships between building blocks of specific types.
- Diagrams are graphical viewpoints that present building blocks in a rich and visual way, more suited to stakeholder communication. (Diagram are two : core and Extension)

Many points about classes above for each ADM phase

The RM-ODP Reference Modeldefines a set of distribution transparencies that are applicable to the TOGAF Software
Engineer ing view.
- Access Transparency
- Failure Transparency
- Location Transparency
- Migration Transparency
- Relocation Transparency
- Replication Transparency
- Transaction Transparency

A DBMS perfor ms the following functions:
Str uctures data in a consistent way
n Provides access to the data
n Minimizes duplication
n Allows reorganization; that is, changes in data content, structure, and size
n Suppor ts programming interfaces
n Provides security and control

A DBMS must provide:
n Persistence; the data continues to exist after the application’s execution has completed
n Secondar y storage management
n Concurrency
n Recovery
n Data Definition/Data Manipulation Language (DDL/DML), which may be a graphical interface

Database Models
The logical data model that underlies the database character izes a DBMS. The common logical data models are as follows:
- Relational Model:
- Hierarchical Model: e.g Information Management System (IMS)
- Network Model:e.g Data Systems Languages (CODASYL
- Object-Oriented Model:e.g C, or C++
- Flat Files:e.g Method (ISAM).

The Acquirer view is concer ned with acquiring Commercial Off-The-Shelf (COTS) software and
hardware.

36: Architecture Deliverables

Read 481 -482 for the input and output of Deliverables

Deliverables are :
Architecture Building Blocks
Architecture Contract
Architecture Definition Document
Architecture Principles
Architecture Repository
Architecture Requirements Specification
Architecture Roadmap
Architecture Vision
Business Principles, Business,Goals, and Business Drivers
Capability Assessment
Change Request
Communications Plan
Compliance Assessment
Implementation and Migration Plan
Implementation Governance Model
Organizational Model for Enterprise Architecture
Request for Architecture Work
Requirements Impact Assessment
Solution Building Blocks
Statement of Architecture Work
Tailored Architecture Framework
Transition Architecture

As deliverables are typically the contractual or for mal work products of an architecture project

37: Building Blocks

Building blocks have gener ic character istics as follows:
n A building block is a package of functionality defined to meet the business needs across an organization.
n A building block has a type that corresponds to the TOGAF content metamodel (such as actor, business service, application, or data entity)
n A building block has a defined boundary and is generally recognizable as ‘‘a thing’’ by domain exper ts.
n A building block may interoperate with other, inter-dependent, building blocks.

A good building block has the following character istics:
— It considers implementation and usage, and evolves to exploit technology and standards.
— It may be assembled from other building blocks.
— It may be a subassembly of other building blocks.
— Ideally a building block is re-usable and replaceable, and well specified.

ABBs Character istics :
n Capture architecture requirements; e.g., business, data, application, and technology requirements
n Direct and guide the development of SBBs

ABB specifications include the following as a minimum:
n Fundamental functionality and attributes: semantic, unambiguous, including security capability and manageability
n Interfaces: chosen set, supplied
n Interoperability and relationship with other building blocks
n Dependent building blocks with required functionality and named user interfaces
n Map to business/organizational entities and policies

SBBs Character istics:
n Define what products and components will implement the functionality
n Define the implementation
n Fulfil business requirements
n Are product or vendor-aware

SBB specifications include the following as a minimum:
n Specific functionality and attributes
n Interfaces; the implemented set

19: Applying Iteration to the ADM

n Architecture Context iterations allow initial mobilization of architecture activity by establishing the architecture approach, principles, scope, and vision.
n Architecture Definition iterations allow the creation of architecture content by cycling through Business, Infor mation Systems, and Technology Architecture phases. These
iterations also allow viability and feasibility tests to be carried out by looking at oppor tunities and migration planning.
n Transition Planning iterations support the creation of for mal change roadmaps for a defined architecture.
n Architecture Governance iterations support gover nance of change activity progressing towards a defined Target Architecture.

20: Applying the ADM at Different
Levels

there are three areas of engagement for
architects:
n 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
suppor t strategic decision-making and alignment of execution.
n 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 por tfolio.
n Implementation of Change: Architecture at all levels of the enterpr ise can be used as a technique to provide design governance to change initiatives by providing big-picture visibility, supplying structural constraints, and defining criter ia on which to evaluate technical decisions.

21: Security Architecture and the ADM

Secur ity architectures generally have the following character istics:
n Secur ity architecture has its own methods. These methods might be the basis for a
discreet security methodology.
n Secur ity architecture composes its own discrete view and viewpoints.
n Secur ity architecture addresses non-normative flows through systems and among
applications.
n Secur ity architecture introduces its own normative flows through systems and among
applications.
n Secur ity architecture introduces unique, single-pur pose components in the design.
n Secur ity architecture calls for its own unique set of skill requirements in the IT architect.

The generally accepted areas of
concer n for the security architect are:
n Authentication: The substantiation of the identity of a person or entity related to the
system in some way.
n Authorization: The definition and enforcement of permitted capabilities for a person or
entity whose identity has been established.
n Audit: The ability to provide forensic data attesting that the system was used in
accordance with stated security policies.
Assurance: The ability to test and prove that the system has the security attributes required to uphold the stated security policies.
n Availability: The ability of the system to function without service interruption or depletion
despite abnormal or malicious events.
n Asset Protection: The protection of infor mation assets from loss or unintended disclosure,
and resources from unauthorized and unintended use.
n Administration: The ability to add and change security policies, add or change how policies are implemented in the system, and add or change the persons or entities related
to the system.
n 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 for mal risk management departments.)

Read from 234 - 248 each phase the input and out put

22: Using TOGAF to Define & Govern SOAs

SOA = Ser vice Or iented Architecture

Fundamental to the business-led SOA approach is:
n Rich domain knowledge of both horizontal, cross-cutting concerns, such as human
resources (HR), finance, and procurement alongside ver tical, industr y-specific concer ns
n A str uctured, quantitative understanding of business value, costs, differentiators, and
quality measures
n Broad understanding of current capability, showing both business capability and how it is
suppor ted by IT
n Broad understanding of the feasibility and viability of particular SOA technology-dr iven
solutions

Business-led SOA considers a business service to be a unit of business capability supported by a combination of people, process, and technology. A business service may be:
n Fulfilled by manual processes, or may be fully automated
n Fulfilled within an organization, or outsourced to a partner
n Exposed to any combination of employees, customers, par tners, and suppliers
n Fulfilled at the point of use, at a divisional level, or as a corporate competency center

A number of concepts are captured in the TOGAF content metamodel that support the modeling
of SOA concepts:
n Function: A function is a thing that a business does. Ser vices suppor t functions, are
functions, and have functions, but functions are not necessarily services. Ser vices have
more specific constraints than functions.
n Business Service: A business service is a thing that a business does that has a defined,
measured interface and has contracts with consumers of the service. A business service is
suppor ted by combinations of people, process, and technology.
n Information System Service: An infor mation system service is a thing that a business
does that has a defined, measured interface and has contracts with consumers of the
ser vice. Infor mation system services are directly supported by applications and have
associations to SOA ser vice interfaces.
n Application Component: An application component is a configured and deployed system,
or independently governed piece of a configured and deployed system. Application
components provide infor mation system services. Application components can be physical
applications and also logical applications that group together applications of a similar type.
n Technology Component: A technology component is a piece of software or hardware that
can be purchased from an internal or exter nal supplier. Technology components are
configured, combined, built on, and deployed in order to produce application components.

In any ser vice consumer/provider relationship, there are two different senses of contract:
n A Governance Contract between two business entities which specifies what interaction is
needed, inputs, outputs, SLAs, OLAs, and KPIs
n A Operational Contract which specifies the actual communication protocols and message
formats

23: Architecture Principles

for defining Princeples : Name - Statement - Rationale - Implications

the development of architecture principles is typically
influenced by the following:
- Enterprise mission and plans
- Enterprise strategic initiatives
- External constraints
- Current systems and technology
- Computer industry trends

five criteria that distinguish a good set of principles:
Understandable:
Robust
Complete
Consistent
Stable:

Examples of principles (US Government’s Federal
Enter prise Architecture Framework (FEAF)) :
23.6.1 Business Principles : Primacy of Principles - Business Continuity- Common Use Applications - Ser vice Orientation
23.6.2 Data Principles : Data is an Asset - Data is Shared - Data is Accessible - Data Trustee - Data Security
23.6.3 Application Principles : Technology Independence - Ease-of-Use -
23.6.4 Technology Principles : Requirements-Based Change - Control Technical Diversity

24: Stakeholder Management

Steps in the Stakeholder Management Process:
24.3.1 Identify Stakeholders
24.3.2 Classify Stakeholder Positions
24.3.3 Determine Stakeholder Management Approach
24.3.4 Tailor Engagement Deliverables

25: Architecture Patterns

A ‘‘pattern’’ defined as: ‘‘an idea that has been useful in one practical context and will probably be useful in others’’ in ToGaF : a way of putting building blocks into context. e.g : Building blocks are what you use: patterns can tell you how you use them.

Content of a Pattern : Name - Problem - Context - Forces -Solution - Resulting Context - Examples - Rationale - Related Patterns - Known Uses

EXAMPLES OF Patterns :

1- The US Treasury Architecture Development Guidance (TADG) document — for merly known as the Treasur y Infor mation System Architecture Framework (TISAF) — provides a number of explicit architecture patterns.
2- IBM Patterns for e-Business

26: Business Scenarios

Business scenarios are an important technique that may be used at var ious stages of the enterprise architecture, principally the Architecture Vision and the Business Architecture,

A business scenario describes:
n A business process, application, or set of applications that can be enabled by the
architecture
n The business and technology environment
n The people and computing components (called ‘‘actors’’) who execute the scenario
n The desired outcome of proper execution

A good business scenario is also ‘‘SMART’’:
n Specific,
n Measurable,
n Actionable,
n Realistic,
n Time-bound,

Creating a business scenario involves the following:
1. Identifying, documenting, and ranking the problem
2. Identifying the business and technical environment
3. Identifying and documenting desired objectives
4. Identifying the human actors (participants)
5. Identifying computer actors
6. Identifying and documenting roles, responsibilities, and measures of success
7. Checking for ‘‘fitness-for-pur pose’’ and refining

1- The Gathering phase is where infor mation is collected on each of the areas.
2- The Analyzing phase is where a great deal of real Business Architecture wor k is actually done:
n Constituencies
n Human Actors
n Computer Actors
n Issues
n Objectives
3- The Reviewing phase is where the results are fed back to the sponsors of the project to ensure that there is a shared understanding of the full scope of the problem, and the potential depth of the technical impact.

27: Gap Analysis

Potential sources of gaps include:
n Business domain gaps:
n Data domain gaps:
n Applications impacted, eliminated
n Technologies impacted,

28: Migration Planning Techniques

- Implementation Factor Assessment and Deduction Matrix
- Consolidated Gaps, Solutions, and Dependencies Matrix
- Architecture Definition Increments Table
- Enterprise Architecture State Evolution Table
- Business Value Assessment Technique

Just See there fig (324 - 328)

29: Interoperability Requirements

امتطلبات التشغيل البيني

A definition of interoperability is ‘‘the ability to share infor mation and services’’. Defining the degree to which the infor mation and services are to be shared is a ver y useful architectural requirement, especially in a complex organization and/or extended enterprise.

The determination of interoperability is present throughout the Architecture Development Method (ADM) as follows:
n In the Architecture Vision (Phase A), the nature and security considerations of the infor mation and service exchanges are first revealed within the business scenarios.
n In the Business Architecture (Phase B), the infor mation and service exchanges are further defined in business terms.
n In the Data Architecture (Phase C), the content of the infor mation exchanges are detailed using the corporate data and/or infor mation exchange model.
n In the Application Architecture (Phase C), the way that the var ious applications are to share the infor mation and services is specified.
n In the Technology Architecture (Phase D), the appropriate technical mechanisms to permit the infor mation and service exchanges are specified.
n In Opportunities & Solutions (Phase E), the actual solutions (e.g., Commercial Off-The- Shelf (COTS) packages) are selected.
n In Migration Planning (Phase F), the interoperability is logically implemented.

Subtopic

30: Business Transformation Readiness
Assessment

used for evaluating and quantifying an organization’s readiness to undergo change.

Steps :
n Deter mine the readiness factors that will impact the organization
n Present the readiness factors using maturity models
n Assess the readiness factors, including determination of readiness factor ratings
n Assess the risks for each readiness factor and identify improvement actions to mitigate the risk
n Work these actions into Phase E and F Implementation and Migration Plan

The Canadian Government Business Transfor mation Enablement Program (BTEP) provides guidance on how to identify the business transfor mation-related issues.

factors drawn from the BTEP :
Vision - Desire , Willingness, and Resolve - Need - Funding
Governance - Accountability - IT Capacity

31: Risk Management

activities:
n Risk classification
n Risk identification
n Initial risk assessment
n Risk mitigation and residual risk assessment
n Risk monitoring

There are two levels of risk that should be considered, namely:
1. Initial Level of Risk: Risk categorization prior to determining and implementing mitigating actions.
2. Residual Level of Risk: Risk categorization after implementation of mitigating actions.

Effect could be assessed
using the following example criter ia:
Catastrophic - Critical- Marginal - Negligible

Frequency could be indicated as follows:
Frequent: - Likely: - Occasional:- Seldom:- Unlikely

A potential scheme to assess corporate impact
could be as follows:
Extremely High Risk (E):- High Risk (H):- Moderate Risk (M):- Low Risk (L):

32: Capability-Based Planning

a business planning technique that
focuses on business outcomes

Capability Dimensions :
- People Dimension : (Individual Training - Collective Training - Professional Development)

- Process Dimension : (Concepts - Business Processes
- Information Management)

- Material Dimension : (Infrastructure - Information Technology - Equipment)

sepearate Mind Map

porpose

1-optimize enterprise the often fragmented legacy of processes (both manual and automated) into an integrated environment to change and supportive of the deliver y of the business strategy.
2- achieve the right balance between IT efficiency and business innovation

Advantage

1-A more efficient IT operation:
— Lower software development
— Increased portability of applications
— Improved interoperability and easier system
— Improved ability to address critical enterprise-wide issues
— Easier upgrade and exchange of system components
2-Better return on investment, reduced risk for future investment:
— Reduced complexity in IT infrastr ucture
— Maximum return on investment in existing IT infra.
— The flexibility to make, buy, or out-source IT solutions
— Reduced risk overall in new investment,costs of IT ownership
3-Faster, simpler, and cheaper procurement:
— Buying decisions are simpler
— The procurement process is faster — maximizing procurement speed and flexibility.
— The ability to procure heterogeneous, multi-vendor open systems.

A Frame.

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 enterpr ise in terms of a set of building blocks.

ToGaF Def

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

Archit. Def on ToGaf

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 deal with

- The Business Architecture defines the business strategy, governance, org., and key business processes.
- The Data Architecture describes the structure of an org. logical and physical data assets and data manag. resources.
- The Application Architecture provides a bluepr int for the individual application systems to be deployed, their interactions, and their relationships to the core business processes of the org.
- 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 infrastr ucture, middleware, networ ks, communications, processing, standards, etc.

ADM Def

- The Preliminary Phase describes the preparation and initiation activities required to prepare to meet the business directive for a new E arch. , including the definition of an Org-Specific Arch. framework and the definition of principles.
- Phase A: Architecture Vision describes the initial phase of an arch. development cycle. It includes information about defining the scope, identifying the stakeholders, creating the Architecture Vision, and obtaining approvals.
- Phase B: Business Architecture describes the development of a Business Arch. to support an agreed Arch. Vision.
- Phase C: Information Systems Architectures descr bes the development of Information Systems Arch. for an arch. project, including the development of Data and Application Architectures.
- Phase D: Technology Architecture describes the development of the Technology Architecture for an arch. project.
- Phase E: Oppor tunities & Solutions conducts initial implementation planning and the identification of delivery vehicles for the arch. defined in the previous phases.
- Phase F: Migration Planning addresses the for mulation of a set of detailed sequence of transition architectures with a supporting 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.

Deliver. && Artifacts

- A deliverable is a work product that is contractually specified and in turn for mally 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 Arch. Repository as a reference model, standard, or snapshot of the Arch. Landscape at a point in time.

- An artifact is a more granular architectural work product that describes an architecture from a specific viewpoint. Examples include a networ k diagram, a server specification, a use-case specification, a list of architectural requirements, and a business interaction matr ix. Ar tifacts are generally classified as catalogs (lists of things), matrices (showing
relationships between things), and diagrams (pictures of things). An architectural deliverable may contain many artifacts and artifacts will form the content of the Arch. Repository.

Buildin blocks

- 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 var ious levels of detail, depending on what stage of
arch. development has been reached. For instance, at an ear ly 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:

— 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 E.

Enterprise Continuum

which sets the broader context for an arch. and explains how generic solutions can be leveraged and specialized in order to support the requirements of an individual org. The Enterprise Continuum is a view of the Architecture Repository that provides methods for classifying arch. 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.

Architecture Repository

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

Its Component :

- The Architecture Metamodel describes the organizationally tailored application of an architecture framework, including a metamodel for architecture content.
- The Architecture Capability defines the parameters, str uctures, and processes that support governance of the Architecture Repository.
- The Architecture Landscape shows an architectural view of the building blocks that are in use within the organization today.
- 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, patter ns, and other for ms of reference material that can be leveraged in order to accelerate the creation of new
architectures for the enterpr ise.
- The Governance Log provides a record of governance activity across the enterpr ise.

Arch. capabilities

capabilities in the following areas:
- Financial Management
- Performance Management
- Service Management
- Risk Management
- Resource Management
- Communications and Stakeholder Management
- Quality Management
- Supplier Management
- Configuration Management
- Environment Management

benefits of architecture governance

- 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
- 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 exter nal parties’ requirements;
- Greater shareholder value; in particular, enter prise architecture increasingly represents the core intellectual property of the enterprise — studies have demonstrated a correlation between increased shareholder value and well-governed enterpr ises
- Integrates with existing processes and methodologies and complements functionality by adding control capabilities