What is Enterprise

Architecture?
An enterprise?
• An organizational unit – from a
department to a whole corporation

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

Source: TOGAF Version 9.1, 2011

What is Enterprise
Architecture?

• A formal description of an
enterprise, a detailed map of
the enterprise at component
level to guide its changes.

• The structure of an
enterprise’s components, their
inter-relationships, and the
principles and guidelines
governing their design and Source: TOGAF Version 9.1, 2011
evolution over time.
Enterprise Architecture Domains
Princip
les
Principles
guide the
Rules and guidelines for the
architectur use and deployment of all IT
resources and assets across
e to “where the enterprise.

you want to Principles reflect a level of consensus

among the various elements of the
be” enterprise, and form the basis for
making future IT decisions.

Principles must be clearly related

back to the business objectives and
key architecture drivers
 Principles
Statement (A clearly articulated purpose of the
principle)
• Enterprise Service is preferred over the development of
similar or identical service for a particular business unit
Rationale (Reason for the principle and it’s value
to the Business)
• Saves money (resources), improves quality, consistent
controls
Implications (What will it require to implement
the Principle)
• Who owns the service? Changing existing applications to use
common Services; Education and close coordination among
BU-IT groups; Centrally managed service capability
enhancement could delay/impact a BU operation;
Exceptions has to be justified
 Principles
Complete examples:
Business Data Application Technology
Principles Principles Principles Principles
Maximize Technology
Benefit to the Interoperability
Data is an Asset Independence
Enterprise

Information
Control
Management is
Everybody’s Data is Shared Easy of Use Technical
Diversity
Business

Common
Business Vocabulary and
Continuity Data Definitions

Compliance with
Law Data Security
 Role of EA Frameworks

Business, Application, Process Domain: Business

Technology Process Models,
Value Chain Diagrams,
Organization Charts

Process, Product, Risk Assessment, Gap

Information, Analysis,
Technical, Application Transition’s Supporting
Resources
How to Evaluate/ Compare Frameworks

A Good EA Framework should :

Comparison Parameter :
1.Have a top down approach Taxonomy Completeness
that encourages architecture
driven out of business strategy Process Completeness
Reference Model Guidance
2.Support abstraction to allow Practice Guidance
removal of complicating factors
Maturity Model
3.Contain a robust set of Business Focus
constructs for all levels of the EA
and well-developed language Governance Guidance
Partitioning Guidance
4.Aligned to process for
developing EA Prescriptive Catalog
Vendor Neutrality
5.Provide advice on architecture Information Ability
governance
Time to Value
 What TOGAF What TOGAF
is TOGAF as is not
• Generic
• Process Driven
a • Prescriptive
about how to
• “One size fits Framewor customize the
all framework
organizations” k is a
TOGAF • Prescriptive
• Flexible generic Artifact Driven
• Set of framework, it • Specific to
Conceptual must be company size
Tools adapted to or to an
• Providing satisfy industry
generic organization • Ontology
deliverables specific Driven
requirements • Tool
• Prescribing a
 Structure of
TOGAF 9.1 (1)
TOGAF 9.1 is divided into seven sections as
follows:

PART I: Introduction
A high-level introduction to the key concepts
behind 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

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

A collection of guidelines and techniques
available for use in applying TOGAF and the
TOGAF ADM.
 Structure of
TOGAF 9.1 (2)
PART IV: Architecture Content Framework
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

Taxonomies and tools to categorize and store
the outputs of architecture activity within an
enterprise.

PART VI: TOGAF Reference Models

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

The organization, processes, skills, roles, and
responsibilities required to establish and
operate an architecture function within an
enterprise.
ADM
ADM Phases
Each phase includes objectives,
approach, inputs, steps, and
outputs
• Prepare the organization for successful TOGAF
architecture projects.
• Undertake the preparation and initiation activities
Preliminary Phase required to create an Architecture Capability,
including the Customization of TOGAF, selection of
tools, and the definition of Architecture Principles.
• Ensure that every stage of a TOGAF project is based
on and validates business requirements.
Requirements • Requirements are identified, stored, and fed into
Management and out of the relevant ADM phases, which dispose
of, address, and prioritize requirements.
• Set the scope, constraints, and expectations for a
Phase A: TOGAF project.
Architecture Vision • Create the Architecture Vision.
• Identify stakeholders.
• Validate the business context (business principles,
>> Initial phase of business goals, and strategic drivers) and create the
architecture development Statement of Architecture Work.
phase • Obtain approvals.
• Develop architectures in four domains:
1. Business
Phase B: 2. Information Systems – Application
Business Architecture 3. Information Systems – Data
Phase C: 4. Technology
Information Systems • In each domain, develop the Baseline and Target
Architectures Architecture and analyze gaps.
Phase D: • Select relevant viewpoint for key stakeholders in
Technology Architecture each domain.
ADM ADM Phases
• Opportunities for delivering the Target Architecture
by implementing specific Solutions
• Perform initial implementation planning and the
Phase E: identification of delivery vehicles for the building
Opportunities and blocks identified in the previous phases.
Solutions • Determine whether an incremental approach is
required, and if so identify Transition Architectures.

• Develop detailed Implementation and Migration

Phase F: Plan that addresses how to move from the Baseline
Migration Planning to the Target Architecture.

• Provide architectural oversight for the

Phase G: implementation.
Implementation • Prepare and issue Architecture Contracts.
Governance • Ensure that the implementation project conforms
to the architecture.

• Provide continual monitoring and a change

management process to ensure that the
architecture responds to the needs of the
enterprise, and maximizes the business value.
• Approach:
1. Monitoring business growth
Phase H: 2. Capacity measurement
Architecture Change 3. Change management process
Management • Change management process categories:
1. Simplification change
2. Incremental change
Each phase includes objectives, 3. Re-architecting change
approach, inputs, steps, and
outputs
ADM
ADM Deliverables
Architecture Contract (Phase Architecture Vision (Phase A)
G)
01 the joint agreements between
development partners and sponsors 04 provides a high-level summary of the
changes to the enterprise that will
on the deliverables, quality, and follow from successful deployment of
fitness-for-purpose of an the Target Architecture a key tool to
Architecture
architecture. Definition Document sell the benefits of the proposed
(Phase B, C, D) capability to stakeholders and
02 the deliverable container for the core
architectural artifacts created during
decision-makers within the enterprise
a project and for important related Request for Architecture Work
information (Preliminary Phase)
a document that is sent from the
Architecture Requirements Specification 05 sponsoring organization to the
(Phase B, C, D) architecture organization to trigger
03 a set of quantitative statements that
outline what an implementation project
the start of an ADM Cycle
must do in order to comply with the Statement of Architecture Work (Phase
architecture
Architecture Roadmap (Phase B, C,
.
D) individual work packages that will
06 A)
defines the scope and approach that
will be used to complete an
04 lists
realize the Target Architecture and architecture development cycle
lays them out on a timeline to show
progression from the Baseline
Architecture to the Target
Architecture Principles

01 Architecture principles are a set of

principles that relate to architecture
work.

02 They reflect consensus across the

enterprise, and embody the spirit of the
enterprise architecture.

03 Architecture principles govern the

architecture process, affecting the
development, maintenance, and use of
the enterprise architecture.
ADM GUIDELINES AND
TECHNIQUES Architecture Principles
Section Description
Name The essence of the rule and be easy to remember
Statement A clearly articulated purpose of the principle
Rationale Reason for the principle and it’s value to the Business Objectives
Implications What will it require to implement the Principle

• Example – Simple Principle

Self-Serve
Statement Customers should be able to serve themselves.
Applying this principle will improve customer satisfaction, reduce
Rationale
administrative overhead, and potentially improve revenue.
There is an implication to improve ease-of-use and minimize training
Implications needs; for example, members should be able to update their contact
details, etc. and be able to buy additional membership products online.
 Architecture Principles
Development of
principles
influenced by:
1 Enterprise mission and plans

2 Enterprise strategic initiatives

3 External constraints

4 Current systems and technology

5 Emerging industry trends

Architecture Principles
Five criteria that distinguish a good set of principles

03 01
Complet Understanda
05 e ble
Stab
le

04
Consist
ent 02
Robust
ADM GUIDELINES AND
TECHNIQUES Architecture Principles
Business Data Application Technology
Principles Principles Principles Principles
1. Primary of
Principles 1. Technology 1. Requirements-
1. Data is an Asset
Maximize Benefit to independence Based Change
the Enterprise
Responsive Change
Information Data is Shared Ease-of-Use
Management
Management is
Everybody’s
Business Control Technical
Data is Accessible
Diversity
Business Continuity
Common Use
Applications Data Trustee Interoperability
Service Orientation
Compliance with Law Common Vocabulary
IT Responsibility and Data Definitions Each principle is documented in
the recommended format:
Protection of
Intellectual Property Data Security Name, Statement, Rationale,
Implications

Example Set of Architecture Principles

 Source : https://unsplash.com/photos/2g
YsZUmockw

Gap Analysis

• Gap analysis is widely used in the Get a modern

PowerPoint
TOGAF ADM to validate an
Presentation that is
architecture that is being beautifully designed.
• The basic premise is to highlight a
developed
shortfall between the Baseline
Architecture and the Target
Architecture; that is, items that
have been deliberately omitted,
accidentally left out, or not yet
defined.
ADM GUIDELINES AND
TECHNIQUES Gap Analysis
Potential sources of
gaps:
Business domain gaps Data domain gaps
• People gaps (e.g., cross-training
requirements) • Data not of sufficient currency
• Process gaps (e.g., process inefficiencies) • Data not located where it is needed
• Tools gaps (e.g., duplicate or missing tool • Not the data that is needed
functionality) • Data not available when needed
• Information gaps • Data not created
• Measurement gaps • Data not consumed
• Data relationship gaps
• Financial gaps
• Facilities gaps (buildings, office space,
etc.) Applications impacted, eliminated, or
created

Technologies impacted, eliminated, or

created
Deliverable, Artifacts and Building Blocks
Deliverable
is a work product that is contractually specified and
in turn formally reviewed, agreed, and signed off by
the stakeholders.

Artifact
is an architectural work product that describes an
aspect of the architecture. Generally classified as:
• Catalogs (lists of things) e.g. requirement catalog
• Matrices (showing relationships between things)
e.g. business interaction matrix
• Diagram (pictures of things) e.g. use case diagram

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.
Deliverable, Artifacts and Building Blocks
Deliverable, Artifacts and Building Blocks

Example – Architecture Definition Document

Architecture Solution Building
Blocks (SBBs) represent
Building Blocks, components that will
be used to implement
and Solution the required capability
Architecture • SBBs are more
Building Blocks Building Blocks closely related to
(ABBs) typically packaged products
describe or solutions; they
required What is can be, for instance,
What is capability and Solution certified tools, COTS
Architecture shape the Building software, personal
Building specification of Blocks? computers or other
Blocks? Solution types of packaged
Building Blocks products or
(SBBs) capabilities.
Architecture Building Blocks, and Solution Building Blocks
Views, Viewpoints and Stakeholders

A view
• A view is a representation of a system from the
1 perspective of a related set of concerns.
• A view is what you see (or what a stakeholder sees)

A viewpoint
2 A viewpoint defines the perspective from which a
view is taken

Stakeholders
3 Stakeholders are people who have key roles in, or
concerns about, the system
Views, Viewpoints and Stakeholders
Viewpoint
Element Description

Stakeholders Management Board,

Chief Executive Officer

Concerns Show the top-level

relationships between
geographical sites and
business functions.

Modelling Nested boxes diagram.

technique Outer boxes = locations;
inner boxes = business
functions.
Semantics of nesting =
functions performed in
the locations.

Viewpoint View
ENTERPRISE CONTINUUM
AND TOOLS Enterprise Continuum
The Enterprise Continuum classifies
assets related to the context of the
overall enterprise architecture,
contains two specializations:
• The Architecture Continuum
offers a consistent way to define
and understand the generic
rules, representations, and
relationships in an architecture,
including traceability and
derivation relationships.
• The Solutions Continuum
provides a consistent way to
describe and understand the
implementation of the assets
defined in the Architecture
Continuum. The Solutions
Continuum addresses the
ENTERPRISE CONTINUUM
AND TOOLS Enterprise Continuum
(Architecture Continuum)

TOGAF TRM
A Foundation Architecture consists of generic components, inter-
relationships, principles, and guidelines that provide a foundation on
which more specific architectures can be built. Example: TOGAF TRM
Common Systems Architectures guide the selection and integration
of specific services from the Foundation Architecture to create an
architecture useful for building common (i.e., highly re-usable)
solutions across a wide number of relevant domains. Example: III-RM

III-RM
ENTERPRISE CONTINUUM
AND TOOLS Enterprise Continuum
(Architecture Continuum)

Industry Architectures guide

the integration of common
systems components with
industry-specific components,
and guide the creation of
industry solutions for targeted
customer problems within a
particular industry. Example:
ARTS (Retail) Operational Data
Model
Organization-Specific
Architectures describe and
guide the final deployment of
solution components for a
particular enterprise or
extended network of connected
enterprises.
ARTS ODM
 Phase A (Architecture Vision)
Inputs, Steps, Outputs

INPUTS STEPS OUTPUTS

• Architecture • Architecture
Building Blocks Principles
• Architecture • Business
Principles Establish the architecture
project
Identify stakeholders,
concerns, and business
Confirm and elaborate
business goals, business Principles-Goals-
requirements drivers and constraints

• Architecture Vision Drivers

• Business Principles- • Statement of
Goals-Drivers Define scope
Assess readiness for Evaluate business
Architecture Work
business transformation capabilities

• Organizational • Architecture
model for EA
Vision
• Request for
• Communications
Confirm and elaborate
Define the target
architecture principles,
Develop architecture vision architecture value

Architecture Work including business

principles
propositions and KPIs

Plan
• Statement of
Architecture Work • Capability
Assessment
Develop enterprise
Identify the business

• Tailored
architecture plans and
transformation risks and
Statement of Architecture
mitigation activities
Work; secure approval

Architecture • Tailored
Framework Architecture
Framework

Note Core Deliverables

 Phase A (Architecture Vision)
Artifacts: Solution Concept Diagram Example

Interaction Component

Entity Application Component

Interaction Component

Entity Application Component

Process Component

Solution Concept Diagram Example 2 – Mortgage Loan Company

 Phase B (Business Architecture)
Inputs, Steps, Outputs

INPUTS STEPS OUTPUTS

• Architecture Building • Architecture
Blocks Select reference Develop Baseline
models, viewpoints Business Architecture
Principles
• Architecture and tools Description

principles • Architecture
• Architecture Vision Definition
• Business Principles- Perform Gap Analysis
Develop Target
Business Architecture Document
Description
Goals-Drivers • Architecture
• Request for Requirements
Architecture Work Resolve impacts Specification
Define Roadmap across the
• Capability
• Architecture
Components Architecture
Landscape
Assessment
• Communications Plan Roadmap
• Organization model • Business
Finalize the Business Conduct formal
for EA Architecture stakeholder review
Principles-Goals-
• Statement of Drivers
Architecture Work • Statement of
• Tailored Architecture Create Architecture
Definition Document Architecture Work
Framework

Note Core Deliverables