Session 1

State of The Art of

Enterprise
Architecture

Why TOGAF?

TOGAF Training
Definition : Enterprise?
Definition : Enterprise?
Definition : Enterprise
The term enterprise is generally applicable in many
circumstances, including :
• Public or private sector organizations
• An entire business or corporation
• A part of a larger enterprise (such as a business unit)
• A conglomerate of several organizations, such as a joint venture or partnership
• A multiply outsourced business operation
• Many collaborating public and/or private organizations in multiple countries
The Open Group :
"enterprise" as any collection of organizations that has a
common set of goals
Definition : Architecture?
Definition : Architecture
• The art and science of designing and erecting buildings and other
physical structures.
• The style and method of design and construction of buildings and other
physical structures.
• The design activity of the architect, from the macro-level (urban design,
landscape architecture) to the micro-level (construction details and
furniture).
• The term "architecture" has been adopted to describe the activity of
designing any kind of system, and is also commonly used in describing
information technology.
TOGAF, defines "architecture" as :
• 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
Definition : Enterprise Architecture

1
“Enterprise Architecture is the set of design artifacts or descriptive
representations that are relevant for describing an enterprise such
that can be produced to management’s requirement (Quality) and it
can be maintained over the period of its useful life” – www.zifa.com

2
“Enterprise Architecture is a process that expreses enterprise’s business key,
information, application and technology strategies and their impact on
business functions and proceses. EA institutionalizes disciplined analysis and
decision making. It must be driven by the enterprise business strategy. It
must represent holistic view across the enterprise” - Meta Group

3
Enterprise Architecure (EA) adalah suatu blueprint yang merupakan sekumpulan
rancangan artifak, representasi deskriptif yang relevan untuk menggambarkan
perusahaan (‘enterprise’) saat ini (‘current’) dan yang akan datang (‘future’), dalam
konteks bisnis, sistem dan teknologi informasi untuk digunakan dalam mencapai tujuan
perusahaan dan dipelihara selama diperlukan
Enterprise Architecture : Basic Concept
Enterprise Goals

ENTERPRISE

Technology Plan &

Business Plan &

Information
Strategy
Strategy
Technology
Customer
Driven
Driven

Business Architect IT. Architect

Enterprise Architecture
Enterprise Architecture : Why?
• IT act not only as “Business Support” but already become
“Business Enabler”
• Many IT Program or Project fail to fulfil business need
• IT Benefit can’t be reached as expected
• IT solution become more and more complex
• Need of alignment between business and IT
• Need for more efficient IT operation
• Need for better return on existing investment, reduced risk
for future investment
• Need for faster, simpler, and cheaper procurement
Architecture Case : Building a House !
Architecture Case : Building a Multi-Purpose Business Complex
Architecture Case : Architecting and Planning a City
How Building Architectures relate to IT Scope ?

Building
Architecture

Information Single Function – Multi Function – An Enterprise Wide – A

Architecture A Project Initiative giant Program
Scope No Politics – one Small Community Large Community –
family - private - Limited to house language - culture
department footprint - BU Large ecosystem
Limited to house Common Services Mix bag (Legacy, New,
footprint IT: Integrated obsolete)
Limited Services Application (ERP, CRM, Shared Services
IT: Functional BI, IT: Forward Looking
Modules (Ex : Finance) Corporate Portal…) IS Initiative
All things considered.
Manfaat Enterprise Architecture
Enterprise Architecture Domains
 Enterprise Architecture Benefit

• Alignment : creating alignment between the IT environment and the company's business
needs
• Integration : standard for interface and information flow
• Time-to-market : reducing application and system development cycles
• Convergence : seeks a portfolio of standard IT products
• Compatibility : Increase compatibility among the various solutions developed by each
department
• Re- Use : Allows reusing solutions that have been created, thereby reducing the cost of IT
investment.
• Common Process : Provide methods and processes together
• Productivity : Increase productivity and reduce learning curve from developers and
users.
• Communication : Improve communication between IT users with developers.
• Identification : Helps identify the skills needed
Objectives & Benefits of EA?

Source: Infosys EA Survey 2008

EA vs TATA KELOLA IT
Enterprise Architecture Framework

What is Framework?

framework is a real or conceptual structure intended to serve

as a support or guide for the building of something that
expands the structure into something useful.

What is EA 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.
Role OF EA Framework
The value of framework
• Provides a practical starting point for
an Architecture Project

• Avoids the initial panic when the scale of

the task becomes apparent
• Systematic – “Codified common sense”
• Captures what others have found to work
in real life
• Contains a Baseline set of resources for
reuse
 Enterprise Architecture Framework

Type of Framework
1. Consortia-developed frameworks
2. Defence Industry Framework
3. Government Framework
4. Open-source frameworks
5. Proprietary Framework
Enterprise Architecture Framework

1. Consortia-developed frameworks 4. Open-source frameworks

• Generalised Enterprise Reference • LEAD Frameworks.
Architecture and Methodology (GERAM)
• MEGAF
• IDEAS Group • TRAK
• ISO 19439 Framework for enterprise 5. Proprietary Framework
modelling
• Integrated Architecture Framework (IAF)
• TOGAF – The Open Group Architecture
Framework • CIMOSA
• SAP EA Framework (Extended EA Framework)
2. Defence Industry Framework
• Oracle EA Framework
• C41SR/ DoDAF – the US Department of
Defense Architecture Framework • Gartner EA Framework
• MODAF – the UK Ministry of Defence • Zachman Framework
Architecture Framework
• NAF – the NATO Architecture Framework
3. Government Framework
• Federal Enterprise Architecture
Framework (FEAF)
• NIST Enterprise Architecture Model
• Treasury Enterprise Architecture
Framework (TEAF)
Adoption of Framework
TOGAF provide the architecture framework
• An architecture framework is a toolkit which can be used for
developing a broad range of different architectures
• It should describe a method for designing an information system 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 TOGAF?

• 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 to the perceived future needs of the business
• 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
 TOGAF Development
1994 Requirement Proof of need
1995 TOGAF Version 1 Proof of concept
1996 TOGAF Version 2 Proof of application
1997 TOGAF Version 3 Relevance to practical architectures (building blocks)
1998 TOGAF Version 4 Enterprise Continuum (TOGAF in context)
1999 TOGAF Version 5 Business Scenarios (architecture requirements)
2000 TOGAF Version 6 Architecture Views (IEEE Std 1471)
2001 TOGAF Version 7 Architecture Principles; Compliance Reviews
2002 TOGAF Version 8 Extension to Enterprise Architecture
2003 TOGAF Version 8.1 Requirements Management; Governance; Maturity Models; Skills
Framework
2006 TOGAF Version 8.1.1 Technical Corrigendum 1 applied
2009 TOGAF Version 9 Evolutionary restructure; Architecture Content Framework
TOGAF Version 9.1 Quality improvements to ensure consistent use of terminology
2018 TOGAF Version 9.2 The TOGAF manual has been broken down into a modular structure
The Content Metamodel unit has had a significant update
The Business Architecture unit has been expanded and developed
TOGAF 9 Components
TOGAF 9 Components
• Architecture Development Method (ADM)
• An iterative sequence of steps to develop an enterprise-wide architecture
• ADM Guidelines and Techniques
• Guidelines and techniques to support the application of the ADM
• Architecture Content Framework
• A detailed model of architectural work products, including deliverables,
artifacts within deliverables, and the Architecture Building Blocks (ABBs) that
deliverables represent.
TOGAF 9 Components
• The Enterprise Continuum
• A model for structuring a virtual repository and methods for classifying
architecture and solution artifacts
• TOGAF Reference Models:
• The TOGAF Technical Reference Model (TRM)
• The Integrated Information Infrastructure Model (III-RM)
• The Architecture Capability Framework
• A structured definition of the organizations, skills, roles and responsibilities to
establish and operate an Enterprise Architecture
TOGAF 9 Document Structures
 Enterprise Architecture Development Method

A comprehensive general Vendor, tool and technology

method neutral open standard

Complementary to, not

Avoids re-inventing the wheel
competing with, other
framework

Widely adopted in market Business – IT Alignment

Tailorable to meet an
organization and industry Based-on best practices
needs

Available under a free Possible to participate in the

perpetual license evolution of the framework
ADM Basic Principles
• An iterative method, over the whole process,
between phases and within phases
• Each iteration = new decisions:
• Enterprise coverage
• Level of detail
• Time horizon
• Architecture asset re-use:
• previous ADM iterations other
frameworks, system models, industry
models,…
• Decisions based on:
• Competence / resource availability
• Value accruing to the enterprise.
• Every phase is validated against and validates
the current requirements of the business
Preliminary Phase
• This phase prepares the organization for
undertaking successful enterprise architecture
projects
• Understand business environment
• High level management
commitment
• Agreement on scope
• Establish principles
• Establish governance structure
• Agree method to be adopted
Phase A – Architecture Vision
• Initiates one iteration of the architecture
process
• Sets scope, constraints, expectations
• Required at the start of every
architecture cycle
• Create the Architecture Vision
• Validates business context
• Creates Statement of Architecture work
Phase B – Business Architecture
• The fundamental organization of a business,
embodied in
• its business processes and people
• their relationships to each other and
the environment
• and the principles governing its
design and evolution
• Shows how the organization meets its business
goals
Phase C – Information System Architecture
• The fundamental organization of an IT system,
embodied in
• The major types of information and
application systems that process
them
• relationships to each other and the
environment, and the principles
governing its design and evolution
• Shows how the IT systems meets the business
goals of the enterprise

Training TOGAF for CIMB Niaga - Session

1: State of The Art of Enterprise
Architecture
Data or Application First?
• It is usually necessary to address both
• Not always the case, depending on
project scope
• May be developed in either order, or in parallel
• Theory suggests Data Architecture
comes first
• Practical considerations may mean
that starting with Application
Systems may be more efficient
• There will need to be some iteration to ensure
consistency
Phase D – Technology Architecture
• The fundamental organization of an IT system,
embodied in
• its hardware, software and
communications technology
• their relationships to each other and
the environment
• and the principles governing its
design and evolution
Phase E – Opportunities & Solutions
• Perform initial implementation planning
• Identify the major implementation projects
• Group projects into \Transition Architectures
• Decide on approach
• Make v Buy v Re-Use
• Outsource
• COTS
• Open Source
• Assess priorities
• Identify dependencies
Phase F – Migration Planning
• For projects identified in Phase E perform
• Cost/benefit analysis
• Risk assessment
• Develop a detailed Implementation and
Migration Plan
Phase G – Implementation Governance
• Provide architectural oversight for the
implementation.
• Defines architecture constraints on
implementation projects
• Architecture contract
• Monitors implementation work for conformance
• Produce a Business Value Realization.
Phase H – Architecture Change Management
• Provide continual monitoring and a change
management process
• Ensures that changes to the architecture are
managed in a cohesive and architected way
• Establishes and supports the Enterprise
Architecture to provide flexibility to evolve
rapidly in response to changes in the technology
or business environment
• Monitors the business and capacity
management.
Conclusion about TOGAF 9
• An effective, industry standard framework and
method for enterprise architecture.
• Complementary to, not competing with, other
enterprise frameworks
• A repository of best practice
• “Demystifies” architecture development
• Vendor, tool, and technology neutral
• A framework and method for achieving the
“Boundaryless Information Flow” vision
The Architecture Repository
The Architecture 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.
At a high level, six classes of architectural information in an Architecture Repository:
1. The Architecture Metamodel describes the organizationally tailored application of an architecture framework,
including a method for architecture development and a metamodel for architecture content.
2. The Architecture Capability defines the parameters, structures, and processes that support governance of the
Architecture Repository.
3. The Architecture Landscape shows an architectural view of the building blocks that are in use within the organization
today (e.g., a list of the live applications). The landscape is likely to exist at multiple levels of granularity to suit
different architecture objectives.
4. The Standards Information Base 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.
5. 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.
6. The Governance Log provides a record of governance activity across the enterprise.
Content Metamodel Overview
Architecture Landscape
The Architecture Landscape holds architectural views of the
state of the enterprise at particular points in time, divided
into three levels of granularity:
• Strategic Architectures, show a long-term summary view of the entire enterprise.
• Segment Architectures , provide more detailed operating models for areas within
an enterprise.
• Capability Architectures ,show in a more detailed fashion how the enterprise can
support a particular unit of capability. Capability Architectures are used to provide
an overview of current capability, target capability, and capability increments and
allow for individual work packages and projects to be grouped within managed
portfolios and programs.
Standard Information Base
The Standards Information Base provides a repository area to hold a set of specifications, to
which architectures must conform
Standards classified in line with the TOGAF architecture domains :
1. Business Standards:
• Standard shared business functions
• Standard role and actor definitions
• Security and governance standards for business activity

2. Data Standards:
• Standard coding and values for data
• Standard structures and formats for data
• Standards for origin and ownership of data
• Restrictions on replication and access

3. Applications Standards:
• Standard/shared applications supporting specific business functions
• Standards for application communication and interoperation
• Standards for access, presentation, and style

4. Technology Standards;
• Standard hardware products
• Standard software products
• Standards for software development
Reference Library
The Reference Library provides a repository area to hold best
practice or template materials that can be used to construct
architectures within an enterprise. Reference materials held in
the Reference Library may be obtained from a variety of sources,
including:
• Standards bodies
• Product and service vendors
• Industry communities or forums
• Corporately defined templates
• Best practice resulting from project implementation
Reference Library can use the Architecture Continuum as a
method for classification
Governance Log
The Governance Log provides a repository area to hold shared information relating to the ongoing
governance of projects.
The Governance Log should contain the following items:
1. Decision Log: A log of all architecturally significant decisions that have been made in the
organization.
2. Compliance Assessments: At key checkpoint milestones in the progress of a project, a formal
architecture review will be carried out. This review will measure the compliance of the project to
the defined architecture standards.
3. Capability Assessments: Depending on their objectives, some projects will carry out assessments
of business, IT, or architecture capability.
4. Calendar: The Calendar should show a schedule of in-flight projects and formal review sessions to
be held against these projects.
5. Project Portfolio: The Project Portfolio should hold summary information about all in-flight
projects that fall under architectural governance
6. Performance Measurement: Based on a charter for the architecture function, a number of
performance criteria will typically be defined.
The Enterprise Continuum
Enterprise Continuum
The Enterprise Continuum is a view of the Architecture Repository that provides methods 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.

The Enterprise Continuum is an important aid to communication and understanding, both

within individual enterprises, and between customer enterprises and vendor organizations.

The Enterprise Continuum represents an aid to organizing re-usable architecture and solution
assets
Enterprise Continuum
Enterprise Continuum
The Enterprise Continuum classifies assets related to the context
of the overall enterprise architecture, contains two
specializations :
1. 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.
2. 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 commonalities and differences
among the products, systems, and services of implemented
systems.
Architecture Continuum
The Architecture Continuum illustrates how architectures are developed and evolved across a
continuum ranging from Foundation Architectures, through Common Systems Architectures, and
Industry Architectures, and to an enterprise's own Organization-Specific Architectures.

Ex : TOGAF TRM III-RM Retail industry's "Active Store"

The enterprise needs and business requirements are addressed in increasing detail from left to right. The
architect will typically look to find re-usable architectural elements toward the left of the continuum. When
elements are not found, the requirements for the missing elements are passed to the left of the continuum
for incorporation. Those implementing architectures within their own organizations can use the same
continuum models specialized for their business.
Solution Continuum
The Solutions Continuum represents the detailed specification and construction of
the architectures at the corresponding levels of the Architecture Continuum

Foundation Solutions ex : programming languages, operating systems, foundational data structures (such as EDIFACT),
generic approaches to organization structuring, foundational structures for organizing IT operations (such as ITIL), etc
Common System Solution ex : an enterprise management system product or a security system product.
Industry Solutions ex : a physical database schema or an industry-specific point-of-service device.
Relationships between the Architecture Continuum and Solutions Continuum
Relationship between the Enterprise Continuum and TOGAF ADM
• TOGAF ADM describes the process of developing an enterprise-specific architecture and an
enterprise-specific solution which conform to that architecture by adopting and adapting
generic architectures and solutions
• In developing architectures in the various domains within an overall enterprise architecture,
the architect will need to consider the use and re-use of a wide variety of different
architecture assets, and the Enterprise Continuum provides an approach for categorizing
and communicating these different assets

Example :

Reference model for e-Commerce taken from the

industry at large

TOGAF Foundation Architecture from Enterprise Continuum

- TRM (TOGAF Reference Model)
- III-RM (Integrated Information Infrastructure Reference Model
The Architecture Content Framework
The architecture content framework
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 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.
It’s Managed :
1. Deliverable is a work product that is contractually specified and in turn formally
reviewed, agreed, and signed off by the stakeholders.
2. Artifact is a more granular architectural work product that describes an
architecture from a specific viewpoint. Examples include a network diagram, a
server specification, a use-case specification, a list of architectural requirements,
and a business interaction matrix.
3. 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.
Relationships between Deliverables, Artifacts, and Building Blocks
Relationships between Deliverables, Artifacts, and Building Blocks

• Example
TOGAF ADM Artifact & Deliverable : Catalogs, Matrix, Diagrams
The Architecture Content Metamodel
The architecture content metamodel
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.
• example, when creating an architecture, an architect will identify applications, "data entities" held
within applications, and technologies that implement those applications. These applications will
in turn support particular groups of business user or actor, and will be used to fulfil "business
services".

TOGAF Content Metamodel and its

Extensions .
Core Metamodel Entities
• Actor: A person, organization, or system that is outside the consideration of the architecture model, but
interacts with it.
• Application Component: An encapsulation of application functionality that is aligned to implementation
structuring.
• Business Service: Supports business capabilities through an explicitly defined interface and is explicitly
governed by an organization.
• Data Entity: An encapsulation of data that is recognized by a business domain expert as a discrete concept.
Data entities can be tied to applications, repositories, and services and may be structured according to
implementation considerations.
• Function: Delivers business capabilities closely aligned to an organization, but not explicitly governed by the
organization.
• Organization: A self-contained unit of resources with line management responsibility, goals, objectives, and
measures. Organizations may include external parties and business partner organizations.
• Platform Service: A technical capability required to provide enabling infrastructure that supports the delivery
of applications.
• Role: An actor assumes a role to perform a task.
• Technology Component: An encapsulation of technology infrastructure that represents a class of technology
product or specific technology product.
Core Entities and their Relationships
Content Metamodel Overview
Entities and Relationships Present within the Core Content Metamodel
Content
Metamodel
with
Extensions
 Relationships
between Entities
in the Full
Metamodel

Training TOGAF for CIMB Niaga - Session

2: TOGAF Construction (1)
Governance
Extensions:
Changes to
Metamodel
Services
Extension:
Changes to
Metamodel
Process Modeling
Extensions:
Changes to
Metamodel
Data Extensions: Changes to Metamodel
Infrastructure Consolidation Extensions: Changes to Metamodel