Enterprise Architecture and

TOGAF (The Open Group

Architecture Framework)

Alan McSweeney
Objectives

• To provide an overview of the importance of Enterprise

Architecture and to provide an overview of The Open
Group Architecture Framework (TOGAF) version 9
concepts and structure

January 27, 2010 2

Agenda

• Enterprise Architecture
• The Open Group Architecture Framework (TOGAF)
• Using TOGAF Effectively
• Establishment of an Enterprise Architecture Function

January 27, 2010 3

Enterprise Architecture

January 27, 2010 4

Enterprise Architecture

• The phrase “Enterprise Architecture” was first used in 1987 by John

Zachmann in an IBM Systems Journal article titled “A Framework for
Information Systems Architecture” (see
http://www.zachmaninternational.com/images/stories/ibmsj2603e.
pdf)
• Intended to address two problems
− System complexity - organisations were spending more and more money
building IT Systems
− Poor business alignment - organisations were finding it more and more
difficult to keep increasingly expensive IT systems aligned with business needs
• The cost and complexity of IT Systems have exponentially increased
while the chances of deriving real value from the systems has
decreased

January 27, 2010 5

Key Messages Relating to Enterprise Architecture

• IT-business alignment has never been so important

• Alignment must be pursued in the context of
understanding business processes and priorities
• Service-orientation is not just for applications
• Service contracts are not just about function: they
encapsulate and communicate business priorities to IT
delivery organisations
• Enterprise architecture needs to be more inclusive,
sophisticated, flexible and integrated
• IT governance models must take all this into account
January 27, 2010 6
Business Pressures are Driving Business and IT Change

• Globalisation
− Customers, partners, suppliers and greater competition
− Connectedness driving value chains
• Transparency
− Industry regulations, consumer pressure and competition driving openness
• Service focus
− Differentiation and shareholder value increasingly derived from service experience
• Challenging Economic Circumstances
− Need to cut costs and demonstrate real savings
− Justify technology investments
• Consolidation
− Mergers, acquisitions, takeovers of failing companies
• Regulation
− Increased regulation and governance - business is turning to IT to help and IT struggling to respond
in many cases
• Business and Technology Changes
− IT becoming commoditised - growth of standards-based technology means that proprietary
solutions provide less differentiation
− Speed of technology change
− Outsourcing where the right outsourcing decisions require an understanding of how systems
contribute to the business
January 27, 2010 7
IT Too Often Fails to Support Changes Effectively

• Technology integration is costly, risky and complicated

• Information is everywhere but getting access to the right
information at the right time is very difficult
• Modifying system behaviour takes too long and changes
are difficult to communicate and implement effectively
• Much of IT system and operations expenditure is bloated
and fixed where operations run with excess redundant
capacity
• IT seen as a cost centre and not a source of business value

January 27, 2010 8

Business and IT Responses to Misalignment

• IT Response to the Business • Business Response to IT

− Become more precise and defensive − Faced with seemingly arbitrary
− Create technology standards that can standards, not uncommon for the
appear arbitrary to the business business to go its own way and
− Require elaborate time consuming develop applications in isolation from
development processes and detailed IT
documentation for new systems and − Not involve IT in decisions that will
changes to existing systems impact IT
− While IT believe that they are imposing − Leads to further chaos and
a formal discipline on a chaotic system, complexities within the enterprise that
the business could only see that these interferes with the ability of the
strict requirements stifle innovation business to get services from the IT
and make it difficult for the business to organisation
be agile in response to sometimes
rapidly changing market requirements

January 27, 2010 9

Basis for Enterprise Architecture

• IT systems are:
− Unmanageably complex and costly to maintain
− Hindering the organisation's ability to respond to business and economic changing
environment
− Not integrated
• Mission-critical information consistently out-of-date and/or actually incorrect
• A culture of distrust between the business and technology functions of the
organisation
• Unmanaged complexity in IT landscape leads to greater cost and less flexibility
− Issues include lack of standards, redundant applications, multiple platforms, and
inconsistent data
− Enterprise architecture defines a set of tools and methods to address this complexity
− While benefits of Enterprise Architecture are generally understood, measuring value
has been a challenge
• No easy answer but Enterprise Architecture approach is really worth considering

January 27, 2010 10

Issues in Developing Enterprise Architecture

• Issue 1 - Concentrate on the Plan

− Focus too intently on analysis and strategy
− Avoid committing to implementing solutions
− Architecting inhibits value delivery
• Issue 2 - Jumping to the Solution
− Engineering solutions and data implementation
− Technology has difficulty aligning with enterprise
− Reinforces gap between business and IT
• Challenge is to balance evolving strategy, goals, constraints
with technology solutions

January 27, 2010 11

Why Enterprise Architecture

• Enterprise Architecture is part of a continuum and not a project

− Emerging technologies influence direction of architecture
− Must be subject to change management and governance
− Enterprise Architecture and IT governance should be considered together
• Principles of architecture should override IT hype and transient technology
− SOA may be dormant but services and an architectural component continues
− Cloud computing is just another step along the IT/Architectural evolution and another
perspective on the future state
• Need better understanding of integration of enterprise and solutions architecture
• Enterprise Architecture is about achieving a common language between business
and IT
• Enterprise Architecture driven out of the business strategy provides the enterprise
with the highest degree of alignment between the business and IT
• The concept of Enterprise Architecture has expanded well beyond the traditional
notion of technology architecture
− Now the architecture of the whole enterprise

January 27, 2010 12

 Business and IT Alignment

• It is not just about

alignment – it is about
collaboration
Business
• Business and IT must
Influence
collaborate to create an
Investment
Business environment in which
Delivery Change by
Seek
Solutions
in
Collaboration of IT Identifying investment in IT and
Information
From IT Technology
Services Opportunities
Available From
delivery of IT services
Technology
Changes
reflect business priorities
• Business decisions take
IT account of the IT
implications and needs of
those decisions
• IT and business must
collaborate as equals
January 27, 2010 13
Enterprise Architecture - Achieving a Common
Language Between Business and IT
• IT-business alignment requires collaboration between the business
and the IT organisation to align investment and delivery with
business goals and to manage business and technology change
• A common, agreed representation of business activity and goals
• A common, agreed view of how current and future IT provides
structured support to the business
• Key requirements and deliverables:
− Investment prioritised in terms of business need
− Systems that deliver value to the business
− Clear direction from the business about focus, strategy
− Collaborative approach to implementing business change

January 27, 2010 14

Enterprise Architecture and Strategy

• Provides the fundamental technology and process structure for an IT strategy

• Provides a strategic context for the evolution of enterprise IT systems in response to the
constantly changing needs of the business environment
• Allows individual business units to innovate safely in their pursuit of competitive advantage
within the context of an integrated IT strategy
• Enterprise Architecture is designed to ensure alignment between the business and IT
strategies, operating model, guiding principles, and the software development projects and
service delivery
• By taking an enterprise-wide, perspective across all the business services, business units,
business processes, information, applications and technology, Enterprise Architecture
ensures the enterprise goals and objectives are addressed as a whole way across all the
system acquisition/application development projects and their deployment into production
• Organisations use a business strategy driven architecture approach that focuses on
translating the key components of the business strategy into a future state vision and an
architecture road map they can implement
• Enterprise architecture is integrated with other strategic planning disciplines, such as
programme/project and application portfolio and management
• Enterprise Architecture ensures that the long-term vision of the business is preserved as
the enterprise builds new business capabilities and improves on old ones

January 27, 2010 15

Elements of Enterprise Architecture

• Analysis tool:
− To provide abstraction and modeling capabilities at all levels and perspective of the enterprise architecture
− To clearly plot the key relationships and dependencies between the business services, business processes,
applications and technology
• Planning tool:
− To translate strategic thinking into architecture roadmap of future development and integration
• Decision-making tool:
− To provide a framework for evaluating, selecting and justifying strategic development options and architecture
decisions
• Design tool:
− To provide the required support, in the form of industry best practice design approaches, patterns, guidelines,
and reference models
• Change management tool:
− To provide a framework for synchronising and coordinating development activities across multiple development
projects and initiatives
• Governance tool:
− To provide a sole architecture design authority and a master repository for the target enterprise architecture,
and a single architectural blueprint of principles, standards, patterns, policies, guidelines, reference models,
reusable assets and templates
• Alignment tool:
− To provide an essential bridge between business strategy and IT delivery, and to furnish business managers with
a non-technical over view of the enterprise architecture and how it supports the operating model

January 27, 2010 16

Enterprise Architecture Development and
Implementation Process

Architecture
Vision
Architecture
Business
Change
Architecture
Management

Data
Architecture

Information
Implementation Requirements
Systems
Governance Management
Architecture

Solutions and
Application
Architecture
Migration Technology
Planning Architecture

Opportunities
and Solutions

January 27, 2010 17

Key Elements/Subsets of Enterprise Architecture

• There are four key architectural subsets of an overall enterprise

architecture
− Business/Business Process Architecture - this defines the business strategy,
governance, organisation, and key business processes
− Data and Information Architecture - this describes the structure of an
organisation's logical and physical data assets and data management resources
− Solutions/Applications Architecture - this kind of architecture provides a
blueprint for the individual application systems to be deployed, their
interactions, and their relationships to the core business processes of the
organisation
− Technology and Infrastructure Architecture - this describes the logical
software and hardware capabilities that are required to support the
deployment of business, data, and application services and includes IT
infrastructure, middleware, networks, communications, processing, standards,
etc.

January 27, 2010 18

Issues in Key Elements/Subsets of Enterprise
Architecture
• High variability and lack of standardisation across
Business and business units (such as ERP templates), driven by
Business Process
Architecture changes in business strategy, governance,
organisation and process
• Inconsistent data definitions, multiple databases,
Data and releases and configurations which result in
Information duplication of licenses, duplicate and inconsistent
Architecture
information, complexity in testing
• Multiple vendors, multiple instances and versions
Solutions and which add complexity in procurement,
Applications
Architecture development and release management, resulting
in higher costs and longer time to market
• Multiple operating environments, multiple
Technology and hardware vendors and types, leading to higher
Infrastructure maintenance and personnel costs, greater
Architecture
instability and time-to-fix
January 27, 2010 19
Enterprise Architecture Frameworks

• Advantages • Potential Disadvantages

− The frameworks give us a useful − Frameworks evolved from the
language for communicating and creation or change of transactional
sharing ideas about how IT information processing systems
systems can/should support − Real world of IT and business are
business needs much more complex
− Provides a process to assist − Frameworks are idealised versions
development of Enterprise of creating Enterprise Architecture
Architecture and ensures all and need to be customised to suit
aspects are addressed an individual organisation’s needs
− Methodologies like the TOGAF
ADM provide templates for
Enterprise Architecture
development work
− Facilitate collaboration and
communication and describing the
process of Enterprise Architecture

January 27, 2010 20

Enterprise Architecture Process

• Enterprise Architecture is an iterative process that

produces four major deliverables
− A future-state Enterprise Architecture reference model that
realises the business strategy
− Current-state Enterprise Architecture model
− A gap analysis that identifies the shortfalls of the current state in
terms of its ability to support the strategies of the enterprise
− An Architecture Roadmap that defines the initiatives required to
migrate from the current state into the future state

January 27, 2010 21

Benefits of Enterprise Architecture

• Align IT and business for planning and execution purposes

• Optimise resources - technology, people and processes
• Increase business interoperability
• Reduce complexity in IT infrastructure
• Improve business agility to support dynamic change
• Drive re-usability of architecture models and best practices
• Streamline informed decision making
• Standardise IT for cost effective delivery of services
• Eliminate duplication and redundancy and reduce cost of ownership and return on
investment
• Reduce risks for future investment
• Faster, simpler and cheaper procurement
• Manage information/data and knowledge as a corporate asset
• Manage change based on a clear understanding of its impact
January 27, 2010 22
Risks of No Enterprise Architecture

• Inability to rapidly respond to challenges driven by business changes

• Lack of commonality and consistency due to the absence of standards
• Lack of focus on enterprise requirements
• Lack of common direction and savings due to synergies
• Incomplete visibility of the current and future target enterprise architecture vision
• Inability to predict impacts of future changes
• Increased gaps and architecture conflicts
• Dilution and dissipation of critical information and knowledge of the deployed
solutions
• Rigidity, redundancy and lack of scalability and flexibility in the deployed solutions
• Lack of integration, compatibility and interoperability between applications
• Complex, fragile and costly interfaces between applications
• Fragmented and ad hoc software development driven by a tactical and reactive
approach

January 27, 2010 23

Struggle With Enterprise Architecture Investments

• The challenge
− Longer term payback than competing business projects
− Rationale for technical decisions difficult to communicate
− Impact of investments are difficult to measure
− Investment approaches are often complex and different
(applications, infrastructure)

• The value of getting it right

− Too little, on the wrong things – operating costs increase as
technology becomes old, hard to support, overly complex and
inefficient
− Too much – IT becomes bloated and inefficient, building
components that are not properly utilised

January 27, 2010 24

Enterprise Architecture and Change Management

• One significant value of Enterprise Architecture is its ability help organisations

deal with complexity and change
• Greater the complexity and the greater the envisioned change, the greater will be
the Enterprise Architecture value to facilitate that change
• Readily available descriptive representations of the organisation
• Ability to unify and integrate business processes across the organisation
• Ability to unify and integrate data across the organisation
• Increased flexibility of the organisation to link with external partners
• Increased agility by reducing complexity
• Reduced solution delivery time and development costs by maximising reuse of
enterprise models
• Ability to create a common vision of the future shared by the business and IT
communities that ensures continuous business/IT alignment

January 27, 2010 25

The Open Group Architecture Framework (TOGAF)

January 27, 2010 26

Introduction to TOGAF

• TOGAF is a framework - a detailed method and a set of supporting tools — for

developing an enterprise architecture
− TOGAF is not itself an architecture
• Architecture design is a technically complex process and the design of mixed,
multivendor architectures is particularly complex
• TOGAF plays an important role in helping to demystify and reduce the risk in the
architecture development process
• TOGAF provides a platform for adding value and enables users to build genuinely
open systems-based solutions to address their business issues and needs
• Because TOGAF has a detailed implementation framework, the project to
implement it and the associated time and cost can be defined more exactly
• Framework can be customised to suit the requirements of the organisation
• TOGAF has a broad coverage and a business focus and seeks to ensure that IT
delivers what the business needs
• TOGAF focuses on both the “what” and the “how”

January 27, 2010 27

TOGAF V9

• This material is based on TOGAF V9

• Intended to be an introduction to and give a flavour of
TOGAF V9
• Not a substitute for the complete TOGAF -
http://www.opengroup.org/togaf/
• Very (too) comprehensive – must be adapted to suit
organisation needs, especially where some for of de facto
Enterprise Architecture already exists and needs to be
validated/refreshed/enhanced

January 27, 2010 28

TOGAF Architecture Development Method (ADM)
Cycle
Preliminary
• Iterative over the whole
process and between
phases - for each iteration,
decide: A. Architecture
− The breadth of coverage of Vision
the organisation to be H. Architecture
B. Business
Change
defined Management
Architecture

− The level of detail to be

defined
− The extent of the time G. C. Information
period aimed at, including Requirements
Implementation Systems
Management Architecture
the number and extent of Governance
any inter mediate time
periods
• Can be used to populate the F. Migration D. Technology
Foundation Architecture of Planning Architecture

an organisation E.
Opportunities
and Solutions

January 27, 2010 29

TOGAF Architecture Development Method (ADM)
Detailed Structure

January 27, 2010 30

Adapting Architecture Development Method Cycle

• Generic method for architecture development

• Designed to deal with most system and organisational
requirements
• Can be modified or extended to suit specific needs
• Review components for applicability and then tailor them
as appropriate to the circumstances

January 27, 2010 31

Enterprise Architecture

• Enterprise architecture provides a strategic, top-down

view of an organisation to enable executives, planners,
architects, and engineers to coherently co-ordinate,
integrate, and conduct their activities
• Enterprise architecture framework provides the strategic
context for this team to operate within
• Developing the enterprise architecture is not a solitary
activity and the enterprise architects need to recognise the
interoperability between their frameworks and the rest of
the business

January 27, 2010 32

Architecture Domains
Business and
Business Process
Architecture

Technology and Data and

Infrastructure Information
Architecture Architecture

Application
And Solution
Architecture

January 27, 2010 33

Architecture Governance

• Architecture artefacts held in the Architecture Repository

• Architecture Board ensures the method is being applied correctly
across all phases of an architecture development iteration
• Management of all architectural artifacts, governance, and related
processes should be supported by a controlled environment
• Main information areas managed by a governance repository should
contain the following
− Reference Data
− Process Status - information regarding the state of any governance processes
− Audit Information - records all completed governance process actions - key
decisions and responsible personnel

January 27, 2010 34

Four Dimensions that Define the Scope of the
Architecture
• Enterprise Scope and Focus
− How much should the full extent of the enterprise should the
architecting effort cover
• Architecture Domains
− Which of the four architecture domains - business, data,
application, technology - should be covered
• Vertical Scope or Level of Detail
− What level of detail should the architecting effort encompass
• Time Period
− What is the architecture needed and what time is available
• Very important to explicitly define and understand as
these dimensions affect all subsequent effort
January 27, 2010 35
Reasons for Limiting the Scope of the Architecture

• Reducing the scope of the architecture from a top-down,

all-inclusive architecture description encompassing all four
architecture domains
− Limiting the scope of the architectural activity
− 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

January 27, 2010 36

Dimensions - Enterprise Scope and Focus

• Need to decide on the focus of the architecture exercise, in terms of

the breadth of overall organisation activity to be covered (which
specific business sectors, functions, business units, geographical
areas, etc.)
• Complex architectures are hard to manage, not only in terms of the
architecture development process itself, but also in terms of getting
buy-in from large numbers of stakeholders
• Take federated architecture approach consisting of independently
developed, maintained, and managed architectures that are
subsequently integrated within a meta-architecture framework
− Need to identify common architectural components, and management of the
common elements between federated components

January 27, 2010 37

Approaches to Federated Architecture Development
• Vertical • Horizontal
− Each business/organisational unit has − Cross-functional architectural domains
its own enterprise architecture with all − Each architecture domain - business,
four architecture domains - business, data, application, technology - covers
data, application, technology the full extent of the organisation
− Separate, multi-domain architectures
can be developed with a view to
subsequent integration or can be
implemented on their own
Architecture

Technology
Application
Business
Data
Business Unit

Business Unit

Business Unit

Cross Functional Domains

Business Unit

Business Unit

Business Unit
Architecture
Cross Functional Domains

Technology
Application
Business
Architecture Architecture Architecture

Data
Technology

Technology
Application

Application
Application
Technology

Business

Business
Business

Data

Data
Data

January 27, 2010 38

Enterprise Scope and Focus

• Having a single enterprise architecture can be very difficult

• Practical and realistic solution can involve having a number
of different architectures existing across the organisation
• Need to manage and take advantage of federated
architectures
• Implement a governance framework

January 27, 2010 39

Dimension - Architecture Domains

• Complete enterprise architecture should address all four

architecture domains - business, data, application,
technology
• May not be resources to build a top-down, all-inclusive
architecture description encompassing all four
architecture domains
• Architecture descriptions are normally be built with a
specific purpose so focus on the domain - business, data,
application, technology - underlying the need

January 27, 2010 40

Dimension - Vertical Scope or Level of Detail

• Assess and agree 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
• Ensure consistent level of detail be completed for each
architecture domain - business, data, application,
technology
• Determine future uses of the architecture
− Can be structured to accommodate future tailoring, extension, or
reuse
− Detail of the enterprise architecture needs to be sufficient for its
purpose and no more

January 27, 2010 41

Dimension - Time Period

• Split Target Architecture into two (or more) stages

− Develop Target Architecture descriptions for the overall system,
demonstrating a response to stakeholder objectives and concerns
for a longer timeframe
− Develop one or more ‘Transition Architecture descriptions
incrementally converging on the Target Architecture
• Target Architecture requires periodic review and update
according to evolving business requirements and
developments in technology
• Transition Architectures are incremental and should not
evolve during the implementation phase of the increment

January 27, 2010 42

Architecture Development Methodology (ADM)
Structure
Architecture
Development
Methodology
(ADM)

C. Information H. Architecture
A Architecture B. Business D. Technology E. Opportunities F. Migration G. Implementation
Preliminary Systems Change
Vision Architecture Architecture and Solutions Planning Governance
Architecture Management

Objectives

• Each ADM phase has the same

Approach
Elements
structure:
− Objectives
Inputs
− Approach
− Inputs
Steps
− Steps
− Outputs
Output

January 27, 2010 43

Preliminary Phase - Objectives

• To review the organisational context for conducting enterprise architecture

exercise
• To identify the sponsor stakeholder(s) and other major stakeholders impacted by
the directive to create an enterprise architecture and determine their
requirements and priorities from the enterprise
• To ensure that everyone who will be involved is committed to success
• To enable the architecture sponsor to create requirements for work across the
affected business areas
• To identify and scope the elements of the organisation affected by the business
directive and define the constraints and assumptions (particularly in a federated
architecture environment)
• To confirm a governance and support framework that will provide business
process and resources for architecture governance
• To select and implement supporting tools and other infrastructure to support the
architecture activity
• To define the architecture principles that will for m part of the constraints on any
architecture work

January 27, 2010 44

Preliminary Phase - Overview
Preliminary Phase

Approach Elements Inputs Steps Outputs

Reference Materials External Scope the Organisation Units

Enterprise
to the Enterprise Impacted

Confirm Governance and

Organisational Context Non-Architectural Inputs
Support Frameworks

Define and Establish

Requirements for
Architectural Inputs Enterprise Architecture
Architecture Work
Team and Organisation

Identify and Establish

Principles
Architecture Principles

Select and Tailor

Management Frameworks
Architecture Framework(s)

Relating the Management Implement Architecture

Frameworks Tools

Planning for Enterprise

Architecture Maturity

January 27, 2010 45

Preliminary Phase - Approach Overview

• Define the where, what, why, who, and how to do architecture

− Defining the organisation
− Identifying key drivers and elements in the organisational 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
− When using an iterative process for architecture development, the activities
within the
• When using an iterative process for architecture development the
Preliminary phase may be repeated a number of times in order to
ensure that the customised framework is suitable to address the
specific architecture problem
January 27, 2010 46
Preliminary Phase - Approach - Enterprise

• Key challenge of enterprise architecture is scope

• Enterprise architecture can be considered a strategic
planning asset that is becoming increasingly an integral
part of business management
• Scope will determine those stakeholders who will derive
most benefit from a new or enhanced enterprise
architecture
• Sponsor is important to ensure that the resulting activity
has resources to proceed and the support of the business
management

January 27, 2010 47

Preliminary Phase - Approach - Organisational
Context
• To make effective and informed decisions about the framework for
architecture to be used within the organisation, it is necessary to
understand the context surrounding the architecture framework
− Commercial models for enterprise architecture
− Budgetary plans for enterprise architecture
− Key issues and concerns of stakeholders
− Business imperatives, strategies, principles, goals, and drivers
− Processes that support execution of change and operation of IT
• Project management and project portfolio management
• Systems management
• Business analysis and design
• Application, technology and information portfolio management
− Baseline architecture landscape
− Level of formality and rigor to be applied
− Touchpoints with other organisations, processes, roles, and responsibilities
January 27, 2010 48
Preliminary Phase - Approach - Requirements for
Architecture Work
• Business imperatives behind the enterprise architecture
drive the requirements and performance metrics for the
architecture work
• Imperatives should be sufficiently clear so that the
preliminary phase can scope the business outcomes and
resource requirements and define the outline business
information requirements and associated strategies of the
enterprise architecture work to be done

January 27, 2010 49

Preliminary Phase - Approach - Principles

• Definition of architecture principles is key to the development of an

enterprise architecture
• Architecture work is informed by business principles as well as
architecture principles
− Architecture principles are normally based in part on business principles
− Defining business principles usually lies outside the scope of the architecture
function
• Set of architecture principles should refer to business principles,
business goals and strategic business drivers defined elsewhere
within the organisation
• Issue of architecture governance is closely linked to that of
architecture principles
• Those responsible for governance will also usually be responsible for
approving the architecture principles and for resolving architecture
issues

January 27, 2010 50

Preliminary Phase - Approach - Management
Frameworks
• TOGAF Architecture Development Method (ADM) is a generic method
• Must co-exist with and enhance the operational capabilities of other management
frameworks that are present within the organisation
• Types/groups of frameworks include
− Business Capability Management - determine 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 - determine how a company manages its
change initiatives
− Operations Management Methods - describe how a company runs its day-to-day
operations, including IT
− Solution Development Methods - formalise the way that business systems are
delivered in accordance with the structures developed in the IT architecture
• During architecture implementation must be aware of its impact on the whole
organisation
• Preliminary phase involves doing work needed to adapt the ADM to define an
organisation-specific framework

January 27, 2010 51

Preliminary Phase - Approach - Management
Frameworks
Business Capability
Management
Frameworks

Architecture Project/Portfolio Solution

Development Management Development
Method Frameworks Frameworks

Operations
Management
Frameworks

January 27, 2010 52

Preliminary Phase - Approach - Relating the
Management Frameworks
• There are dependencies between the various frameworks and
business planning activity that incorporates the organisation’s
strategic plan and direction
− Enterprise Architecture provides a structure for all of the organisation
initiatives
− Portfolio Management Framework delivers the components of the
architecture
− Operations Management Framework supports incorporation of these new
components within the corporate infrastructure
− Solution Development Framework used to plan, create, and deliver the
architectural components specified in the portfolio and project charters
• Enterprise architecture structures the business planning into an
integrated framework that regards the enterprise as a system or
system of systems

January 27, 2010 53

Preliminary Phase - Approach - Relating the
Management Frameworks

Capacity Planning
Business Business Enterprise
Planning Direction Architecture
Architecture
Governance
Resources Solution
Runs the Structured Development
Enterprise Direction
Architecture
Direction Project
Management
Governance
Project/
Operations
Delivers Portfolio
Management
Management

Delivers
January 27, 2010 54
Preliminary Phase - Approach - Planning for Enterprise
Architecture/Business Change Maturity Evaluation

• Capability Maturity Models (CMM) are useful ways of

assessing levels of maturity to implement Enterprise
Architecture/Business
• The actual levels of maturity provide a strategic measure
of the organisation’s ability to change, as well as a series of
sequential steps to improve that ability
• Good enterprise architecture maturity model covers a
wide range of enterprise characteristics, both business and
technical

January 27, 2010 55

Enterprise Architecture Maturity Evaluation - Key
Capabilities
Capabilities
Framework of standards, templates and specifications for organising and
Architecture Framework presenting business and technical architecture components

Methodology for defining, developing and maintaining architecture

Architecture Processes components
Practices
Principles, decision rights, rules and methods to drive architecture
Architecture Governance development and alignment in the organisation

Defining, measuring and communicating the value / impact of architecture

Architecture Value to the business

Using architecture principles and blueprints to align business needs with IT

Strategic Planning capabilities, define portfolio strategy / direction, and allocate resources
Planning
Defining vision and roadmap for various IT domains by anticipating
Architecture Planning business needs and trends, and developing architecture components

Organisation Defining, planning, and managing roles, responsibilities and skills for
Structure and Skills architecture management
People
Communication and Managing communication and expectations with business and IT
Stakeholder Management stakeholders interested in or influenced by architecture management
January 27, 2010 56
Enterprise Architecture Maturity Evaluation - Key
Capabilities and Maturity Levels
Level 1 Level 2 Level 3 Level 4 Level 5
Prioritisation of project Architecture a key Business / IT planning
Strategic Planning None Project-based portfolio based on input to joint enables efficiency, agility in
roadmap Business / IT planning extended enterprise

Limited vision and Architecture planning Continuous Includes extended

Planning Architecture Planning Project-based
roadmap process established improvement enterprise capabilities

Project-based Central architecture Funded from efficiency Funding by margin on

Funding by transaction
Architecture Funding allocation fund gains services

Limited framework - Covers Information and

Consistently adopted Framework shared
Architecture Framework None covers some process, but adoption not
internally externally
information consistent

Defined processes Defined processes Defined processes with

Project-based Defined processes
Architecture Processes primarily focused on across business and IT clear ability to adapt and
processes across IT domains
infrastructure domains extend
Practices
Some review principles Shared governance Business / IT governance
None / project- defined for some Defined IT governance
Governance model with Business continuously improved to
based components boards and processes
and IT respond to change

Defined and measured

None / project- IT cost performance Business outcomes and IT
Value and Measurement IT cost metrics business objectives,
based metrics performance metrics
performance metrics

Organisation Structure No roles, Formal technology Formalised roles and Clear professional Pro-active development
and Skills responsibilities roles within projects responsibilities career track with external input

People Pro-active
Communication and Key stakeholders Regular consultation communication and Collaboration with
Project-based
Stakeholder Management identified and informed with business feedback with extended enterprise
business
January 27, 2010 57
Preliminary Phase - Approach - Inputs

• Non-Architectural Inputs
− Board strategies and board business plans, business strategy, business
principles, business goals, and business drivers
− Major frameworks operating in the business such as portfolio/project
management
− Governance and legal frameworks, including architecture governance strategy,
when preexisting
− Budget for scoping project
− Partnership and contract agreements
− IT strategy
• Architectural Inputs
− Pre-existing models for operating an enterprise architecture capability can be
used as a baseline for the Preliminary phase
• Organisational Model for Enterprise Architecture
• Existing Architecture Framework, if any
• Existing architecture principles, if any
• Existing Architecture Repository, if any

January 27, 2010 58

Preliminary Phase - Approach - Steps

1. Scope the business units impacted

2. Confirm governance and support frameworks
3. Define and establish enterprise architecture team and
structure
4. Identify and establish architecture principles
5. Select and tailor architecture framework(s)
6. Implement architecture tools

January 27, 2010 59

Preliminary Phase - Step 1 - Scope the Business Units
Impacted
• Identify core business unit(s) — those who are most
affected and achieve most value from the work
• Identify non-core business unit(s) — those who will see
change to their capability and work with core units but are
otherwise not directly affected
• Identify extended business unit(s) — those units outside
the scoped enterprise who will be affected in their own
enterprise architecture
• Identify communities involved — those stakeholders who
will be affected and who are in groups of communities
• Identify governance involved, including legal and
regulatory frameworks and geographies
January 27, 2010 60
Preliminary Phase - Step 2 - Confirm Governance
and Support Frameworks
• Architecture framework is core to the architecture
governance structure and guidelines that need to be
developed
• Understand how architectural material is brought under
governance
• Review existing governance and support models of the
organisation and how they will need to change to support
the newly adopted architecture framework
• Assess, understand and agree architecture touch-points
and likely impacts

January 27, 2010 61

Preliminary Phase - Step 3 - Define and Establish
Enterprise Architecture Team and Organisation
• 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
• Scope new enterprise architecture work
• Deter mine constraints on enterprise architecture work
• Review and agree with sponsors and board
• Assess budget requirements

January 27, 2010 62

Preliminary Phase - Step 4 - Identify and Establish
Architecture Principles
• Architecture principles are based on business principles
and are critical in setting the foundation for architectural
governance
• General rules and guidelines, intended to be enduring and
seldom amended, that inform and support the way in
which an organisation sets about fulfilling its mission
• Need to define a set of architecture principles that is
appropriate to the organisation
− Business Principles
− Data Principles
− Application Principles
− Technology Principles

January 27, 2010 63

Architecture Principles - Sample Business Principles

• These principles of information management apply to all business units within the
organisation
• Information management decisions are made to provide maximum benefit to the
organisation as a whole
• All business units in the organisation participate in information management decisions
needed to accomplish business objectives
• Enterprise operations are maintained in spite of system interruptions
• Development of applications used across the organisation is preferred over the
development of similar or duplicated applications which are only provided to a business
unit
• The architecture is based on a design of services which mirror real-world business activities
comprising the organisation (or inter- organisation) business processes
• Enterprise information management processes comply with all relevant laws, policies, and
regulations
• The IT function is responsible for owning and implementing IT processes and infrastructure
that enable solutions to meet user-defined requirements for functionality, ser vice levels,
cost, and delivery timing
• The organisation’s Intellectual Property (IP) must be protected and this protection must be
reflected in the IT architecture, implementation, and governance processes

January 27, 2010 64

Architecture Principles - Sample Data Principles

• Data is an asset that has value to the organisation and is managed

accordingly
• Users have access to the data necessary to perform their duties and
therefore, data is shared across organisation functions and business
units
• Data is accessible for users to perform their functions
• Each data element has a trustee accountable for data quality
• Data is defined consistently throughout the organisation and the
definitions are understandable and available to all users
• Data is protected from unauthorised use and disclosure

January 27, 2010 65

Architecture Principles - Sample Application
Principles
• Applications are independent of specific technology
choices and therefore can operate on a variety of
technology platforms
• Applications are easy to use and the underlying technology
is transparent to users, so they can concentrate on tasks at
hand

January 27, 2010 66

Architecture Principles - Sample Technology
Principles
• Only in response to business needs are changes to
applications and technology made
• Changes to the enterprise information environment are
implemented in a timely manner
• Technological diversity is controlled to minimise the cost
of maintaining expertise in and connectivity between
multiple processing environments
• Software and hardware should conform to defined
standards that promote interoperability for data,
applications, and technology

January 27, 2010 67

Preliminary Phase - Step 5 - Select and Tailor
Architecture Framework(s)
• Determine what, if any, tailoring is required
• Tailoring should produce an agreed terminology set for
description of architectural content
• Tailor processes
− Remove tasks that are already carried out elsewhere in the
organisation
− Add organisation-specific tasks such as specific checkpoints
− Align the processes to external process frameworks and
touchpoints
• Tailor content structure and classification to allow
adoption of third-party content frameworks and allow for
customisation of the framework to support organisation-
specific requirements
January 27, 2010 68
Preliminary Phase - Step 6 - Implement Architecture
Tools
• Tools approach may be based on of standard office
productivity applications, or may be based on a
customised deployment of specialist architecture tools
• Depending on the level of sophistication, the
implementation of tools may range from a trivial task to a
more complex solution implementation activity

January 27, 2010 69

Preliminary Phase - Outputs

• Organisational Model for Enterprise Architecture

• Tailored Architecture Framework
• Initial Architecture Repository
• Restatement of, or reference to, business principles,
business goals, and business drivers
• Request for Architecture Work
• Governance Framework

January 27, 2010 70

Phase A: Architecture Vision - Objectives

• To ensure that this evolution of the architecture development cycle has proper
recognition and endorsement from the corporate management of the
organisation and the support and commitment of the necessary line management
• To define and organise an architecture development cycle within the overall
context of the architecture framework, as established in the Preliminary phase
• To validate the business principles, business goals, and strategic business drivers
of the organisation and the enterprise architecture Key Performance Indicators
(KPIs)
• To define the relevant stakeholders, and their concerns and objectives
• To define the key business requirements to be addressed in this architecture
effort and the constraints that must be dealt with
• To articulate an Architecture Vision and formalise the value proposition that
demonstrates a response to those requirements and constraints
• To create a comprehensive plan that addresses scheduling, resourcing, financing,
communication, risks, constraints, assumptions, and dependencies, in line with
the project management frameworks adopted by the organisation
• To secure for mal approval to proceed

January 27, 2010 71

Phase A: Architecture Vision - Overview
Phase A: Architecture Vision

Approach Elements Inputs Steps Outputs

Reference Materials External to the

General Establish the Architecture Project
Enterprise

Identify Stakeholders, Concerns, and

Creating the Architecture Vision Non-Architectural Inputs
Business Requirements

Confirm and Elaborate Business Goals,

Business Scenarios Architectural Inputs
Business Drivers, and Constraints

Evaluate Business Capabilities

Assess Readiness for Business

Transformation

Define Scope

Confirm and Elaborate Architecture

Principles Including Business Principles

Develop Architecture Vision

Define the Target Architecture Value

Propositions and KPIs

Identify the Business Transformation

Risks and Mitigation Activities

Develop Enterprise Architecture Plans

and Statement of Architecture Work
and Secure Approval
January 27, 2010 72
Phase A: Architecture Vision - Approach - General

• Phase A starts with receipt of a Request for Architecture Work

• 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 based on a practical assessment
of resource and competence availability and the value that can
realistically be expected to accrue to the organisation from the
chosen scope of architecture work
• Constraints will normally be informed by the business principles and
architecture principles, developed as part of the Preliminary phase
• Architecture principles that form part of the constraints on
architecture work will normally have been defined in the Preliminary
phase

January 27, 2010 73

Phase A: Architecture Vision - Approach - Creating
the Architecture Vision
• Architecture Vision describes how the new capability will meet the
business goals and strategic objectives and address the stakeholder
concerns when implemented
• Key tool to sell the benefits of the proposed capability to
stakeholders and decision-makers within the organisation
• Clarify and agree the purpose of the architecture effort
• Clarify the purpose and demonstrating how it will be achieved by the
proposed architecture development
• Verify and understand the documented business strategy and goals
• Provide a first-cut, high-level description of the Baseline and Target
Architectures, covering the business, data, application, and
technology domains
− Outline descriptions are developed in subsequent phases

January 27, 2010 74

Phase A: Architecture Vision - Approach - Business
Scenarios
• Business scenarios are methods for identifying and
articulating the business requirements implied in new
business capability to address key business drivers, and the
implied architecture requirements
− A business process, application, or set of applications that can be
enabled by the architecture
− The business and technology environment
− The people and computing components (called actors) who
execute the scenario
− The desired outcome of proper execution
• A good business scenario is representative of a significant
business need or problem and enables the value of a
solution to the organisation to be understood

January 27, 2010 75

Phase A: Architecture Vision - Approach - Creating
Business Scenarios
Problem Identifying, documenting, and ranking the problem
Identification driving the scenario

Identifying the business and technical environment

Environment
Identification of the scenario and documenting it in scenario
models

Desired
Objectives Identifying and documenting desired objectives
Identification

Human Identifying the human participants and their place in

Participants
Identification the business model

Automated Identifying computing elements and their place in

Participants
Identification the technology model

Identifying and documenting roles,

Define Roles responsibilities, and measures of success per
and
Responsibilities actor, documenting the required scripts per actor,
and the results of handling the situation
Validate and Checking for fitness-for-purpose and
Refine refining only if necessary

January 27, 2010 76

Phase A: Architecture Vision - Approach - Creating
Business Scenarios
• A business scenario is Develop business scenario over
iterative phases of gathering, analysing, and reviewing the
information
• In each phase, each of the steps above is successively
extended
• Refinement step involves deciding whether to consider the
scenario complete and go to the next phase or whether
further refinement is necessary

January 27, 2010 77

Phase A: Architecture Vision - Approach - Creating
Business Scenarios
Gather Analyse Review
Problem Problem Problem
Identification Identification Identification

Environment Environment Environment

Identification Identification Identification

Desired Desired Desired

Objectives Objectives Objectives
Identification Identification Identification

Human Human Human

Participants Participants Participants
Identification Identification Identification

Automated Automated Automated

Participants Participants Participants
Identification Identification Identification

Define Roles Define Roles Define Roles

and and and
Responsibilities Responsibilities Responsibilities

Validate and Validate and Validate and

Refine Refine Refine
January 27, 2010 78
Phase A: Architecture Vision - Inputs

• Reference Materials External to the Enterprise

• Non-Architectural Inputs
− Request for Architecture Work
− Business principles, business goals, and business drivers
• Architectural Inputs
− Organisational Model for Enterprise Architecture
• Scope of business units 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
• Tailored architecture method
• Tailored architecture content
• Architecture principles
• Configured and deployed tools
− Populated Architecture Repository - existing architectural documentation (framework description,
architectural descriptions, baseline descriptions, etc.)

January 27, 2010 79

Phase A: Architecture Vision - Steps

• Establish the architecture project

• Identify stakeholders, concerns, and business requirements
• Confirm and elaborate business goals, business drivers, and constraints
• Evaluate business capabilities
• Assess readiness for business transformation
• Define scope
• Confirm and elaborate architecture principles, including business principles
• Develop Architecture Vision
• Define the Target Architecture value propositions and KPIs
• Identify the business transformation risks and mitigation activities
• Develop enterprise architecture plans and Statement of Architecture Work and
secure approval

January 27, 2010 80

Phase A: Architecture Vision - Step 1 - Establish the
Architecture Project
• ADM project should be conducted within the project
management framework of the organisation
− Should be planned and managed using accepted practices for the
organisation

January 27, 2010 81

Phase A: Architecture Vision - Step 2 - Identify
Stakeholders, Concerns, and Business Requirements
• Identify the key stakeholders and their concerns/objectives
• Define the key business requirements to be addressed in the
architecture engagement
• Create stakeholder map for the engagement, showing which
stakeholders are involved with the engagement, their level of
involvement, and their key concerns
• 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

January 27, 2010 82

Phase A: Architecture Vision - Step 3 - Confirm and
Elaborate Business Goals, Business Drivers, and Constraints

• Identify the business goals and strategic drivers of the

organisation
• Ensure that the existing definitions are current, and clarify
any areas of ambiguity
• Define the constraints that must be dealt with, including
organisation-wide constraints and project-specific
constraints (time, schedule, resources, etc.)

January 27, 2010 83

Phase A: Architecture Vision - Step 4 - Evaluate
Business Capabilities
• Perform business capability assessment to define what
capabilities an organisation will need to fulfill its business
goals and business drivers
• Understand the capabilities and desires of the business
• Identify options to achieve those capabilities
• Likely implications for the organisation’s technology
capability can be assessed, creating an initial picture of
new IT capability that will be required to support the
Target Architecture Vision
• Document results of the assessment in Capability
Assessment
January 27, 2010 84
Phase A: Architecture Vision - Step 5 - Assess
Readiness for Business Transformation
• Evaluate and quantify the organisation’s readiness to undergo a change
• Assessment based upon analysis/rating of a series of readiness factors:
− Ability to implement and operate
− Departmental capacity to execute
− IT capacity to execute
− Workable approach and execution model
− Accountability
− Governance
− Sponsorship and leadership
− Funding
− Business case
− Need
− Desire/willingness/resolve
− Vision
• 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

January 27, 2010 85

Phase A: Architecture Vision - Step 6 - Define Scope

• Define what is inside and what is outside the scope of the

Baseline Architecture and Target Architecture efforts
− The breadth of coverage of the organisation
− The level of detail required
− The partitioning characteristics of the architecture
− 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

January 27, 2010 86

Phase A: Architecture Vision - Step 7 - Confirm and
Elaborate Architecture Principles, including Business
Principles
• Review the principles under which the architecture is to be
developed
• Normally based on the principles developed as part of the
Preliminary phase
• Ensure that the existing definitions are current, and clarify
any areas of ambiguity and resolve if required

January 27, 2010 87

Phase A: Architecture Vision - Step 8 - Develop
Architecture Vision
• Create a high-level view of the Baseline and Target
Architectures
− Based on the stakeholder concerns, business capability
requirements, scope, constraints, and principles
− Covers the breadth of scope identified for the project, at a high
level
• Creates the first, high-level definitions of the baseline and
target environments, from a business, information
systems, and technology perspective

January 27, 2010 88

Phase A: Architecture Vision - Step 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
• Incorporate into the Statement of Architecture Work to allow
performance to be tracked accordingly

January 27, 2010 89

Phase A: Architecture Vision - Step 10 - Identify the Business
Transformation Risks and Mitigation Activities

• Identify the risks associated with the Architecture Vision

and assess the initial level of risk (catastrophic, critical,
marginal, or negligible) and the potential frequency
• Two levels of risk:
− Initial Level of Risk: Risk categorisation prior to determining and
implementing mitigating actions
− Residual Level of Risk: Risk categorisation after implementation
of mitigating actions (if any)
• Include risk mitigation activities in the Statement of
Architecture Work

January 27, 2010 90

Phase A: Architecture Vision - Step 11 - Develop Enterprise
Architecture Plans and Statement of Architecture Work and
Secure Approval
• Define the work required and by when to deliver the set of business performance
requirements
• Identify new work products
• 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, deter mine 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
• Estimate the resources needed, develop a roadmap and schedule for the proposed
development
• Define the performance metrics to be met by the enterprise architecture team
• Develop the specific enterprise architecture Communications Plan
• Review and agree the plans with the sponsors, and secure formal approval of the
Statement of Architecture Work under the appropriate governance procedures
• Gain sign-off to proceed

January 27, 2010 91

Phase A: Architecture Vision - Outputs
• Approved Statement of Architecture Work
− Scope and constraints
− Plan for the architectural work
− Roles and responsibilities
− Risks and mitigating activity
− Work product performance assessments
− Business case and KPI metrics
• Refined statements of business principles, business goals, and business drivers
• Architecture principles
• Capability Assessment
• Tailored Architecture Framework
− Tailored architecture method
− Tailored architecture content (deliverables and artifacts)
− Configured and deployed tools
• Architecture Vision
− Refined key high-level stakeholder requirements
− Baseline Business Architecture
− Baseline Technology Architecture
− Baseline Data Architecture
− Baseline Application Architecture
− Target Business Architecture
− Target Technology Architecture
− Target Data Architecture
− Target Application Architecture
• Communications Plan

January 27, 2010 92

Phase B: Business Architecture - Objectives

• To describe the Baseline Business Architecture

• To develop a Target Business Architecture, describing the product
and/or service strategy, and the organisational, functional, process,
information, and geographic aspects of the business environment,
based on the business principles, business goals, and strategic
drivers
• To analyse the gaps between the Baseline and Target Business
Architectures
• To select and develop the relevant architecture viewpoints that will
enable the architect to demonstrate how the stakeholder concerns
are addressed in the Business Architecture
• To select the relevant tools and techniques to be used in association
with the selected viewpoints
January 27, 2010 93
Phase B: Business Architecture - Overview
Phase B: Business Architecture

Approach Elements Inputs Steps Outputs

Reference Materials External to Select Reference Models,

General
the Enterprise Viewpoints, and Tools

Developing the Baseline Develop Baseline Business

Non-Architectural Inputs
Description Architecture Description

Develop Target Business

Business Modelling Architectural Inputs
Architecture Description

Architecture Repository Perform Gap Analysis

Define Roadmap Components

Resolve Impacts Across the

Architecture Landscape

Conduct Formal Stakeholder

Review

Finalise the Business

Architecture

Create Architecture Definition

Document
January 27, 2010 94
Phase B: Business Architecture - Approach - General

• Knowledge of the Business Architecture is a prerequisite for architecture work in

any other domain (Data, Application, Technology)
− Therefore the first architecture activity that needs to be undertaken
• Business Architecture can be 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
• Scope of the work in Phase B depends to on the organisation environment
• Re-use existing material as much as possible
• Gather and analyse only that information that allows informed decisions to be
made relevant to the scope of this architecture effort
• May be a need to verify and update the currently documented business strategy
and plans
− Bridge gap 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

January 27, 2010 95

Phase B: Business Architecture - Approach -
Developing the Baseline Description
• If the organisation has existing architecture descriptions,
they should be used as the basis for the Baseline
Description
• Where no descriptions exist, information will have to be
gathered
• Architecture Vision from Phase A may even be sufficient
for the Baseline Description

January 27, 2010 96

Phase B: Business Architecture - Business Modeling

• Business models should be logical extensions of the business scenarios from the
Architecture Vision
• Architecture can be mapped from the high-level business requirements down to
the more detailed ones
• Modelling tools and techniques
− Activity Models (also called Business Process Models) describe the functions associated
with the organisation’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)
− Use-Case Models describe the business processes of an organisation in terms of use-
cases and actors corresponding to business processes and organisational participants
(people, organisations, etc.)
− Class Models describe static information and relationships between information and
informational behaviors
− Node Connectivity Diagrams describe 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
− Information Exchange Matrix documents the information exchange requirements for
an enterprise architecture and expresses 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

January 27, 2010 97

Phase B: Business Architecture - Architecture
Repository
• Consider what relevant Business Architecture resources
are available
− Generic business models relevant to the organisation’s industry
sector
− Business models relevant to common high-level business domains
− Enterprise-specific building blocks (process components, business
rules, job descriptions, etc.)
− Applicable standards

January 27, 2010 98

Phase B: Business Architecture - Architecture
Repository
• Operating a mature architecture capability within a organisation can
creates a large volume of architectural output
• Effective management and leverage of these architectural work
products require a formal structure for different types of
architectural asset
• At a high level, six classes of architectural information are expected
to be held within an Architecture Repository
− Architecture Metamodel
− Architecture Metamodel
− Architecture Landscape
− Standards Information Base
− Reference Library
− Governance Log

January 27, 2010 99

Phase B: Business Architecture - Idealised
Architecture Repository Overview
Artifacts in the
landscape are Best practice
Architecture Metamodel structured according Architecture Landscape creates
to the framework reference
Architecture Content Strategic Segment Capability architecture
Method Metamodel Architectures Architectures Architectures

Adopted by
Best the
Standards Information Base practice organisation
creates Standards
Business standards are complied
Reference Library
Standards Data Standards with
Foundation Common
Architectures Systems
Architectures
Application Technology
Standards Standard Organisation-
Standards have Industry Specific
Reference Architectures Architectures
Compliance implementations
is governed
Governance Log
The Architecture Capability
Decision Log Compliance Capability landscape
Assessments Assessments is Skills Organisation Architecture
governed Repository Structure Charter

Calendar Project Performance

Portfolio Measurement Architecture
Board steers
and manages
Visibility and escalation the capability Reference External
Architecture Models Reference
External Board adopted by Models
Standards Standards adopted the enterprise
by the enterprise
January 27, 2010 100
Phase B: Business Architecture - Inputs - 1

• Reference Materials External to the Enterprise

• Non-Architectural Inputs
− Request for Architecture Work
− Business principles, business goals, and business drivers
− Capability Assessment
− Communications Plan
• Architectural Inputs - 1
− Organisational Model for Enterprise Architecture
• Scope of business units 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
• Tailored architecture method
• Tailored architecture content (deliverables and artifacts)
• Configured and deployed tools
− Approved Statement of Architecture Work

January 27, 2010 101

Phase B: Business Architecture - Inputs - 2

• Architectural Inputs - 2
− Architecture principles including business principles, when pre-existing
− Enterprise Continuum
− Architecture Repository
• Re-usable building blocks
• Publicly available reference models
• Organisation-specific reference models
• Organisation standards
− Architecture Vision
• Refined key high-level stakeholder requirements
• Baseline Business Architecture
• Baseline Technology Architecture
• Baseline Data Architecture
• Baseline Application Architecture
• Target Business Architecture
• #Target Technology Architecture
• Target Data Architecture
• Target Application Architecture

January 27, 2010 102

Phase B: Business Architecture - Steps

• Select reference models, viewpoints, and tools

• Develop Baseline Business Architecture Description
• Develop Target Business Architecture Description
• Perform gap analysis
• Define roadmap components
• Resolve impacts across the Architecture Landscape
• Conduct formal stakeholder review
• Finalise the Business Architecture
• Create Architecture Definition Document
January 27, 2010 103
Phase B: Business Architecture - Step 1 - Select
Reference Models, Viewpoints, and Tools (1)
• 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
• Determine Overall Modelling 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
− Identify the key business functions within the scope of the architecture, and maps those
functions onto the business units within the organisation
− Breakdown business-level functions across actors and business units to allow the actors
in a function to be identified and permits a breakdown into services
supporting/delivering that functional capability
− Breakdown a function or business service through process modeling to allow the
elements of the process to be identified and permit the identification of lower-level
business services or functions

January 27, 2010 104

Phase B: Business Architecture - Step 1 - Select
Reference Models, Viewpoints, and Tools (2)
• Identify Required Service Granularity Level, Boundaries, and
Contracts
− Business Architecture phase therefore needs to identify which components of
the architecture are functions and which are services
• Business services are specific functions that have explicit, defined boundaries that
are explicitly governed
• Services are distinguished from functions through the explicit definition of a service
contract
• 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
− Granularity of business services should be determined according to the
business drivers, goals, objectives, and measures for this area of the business

January 27, 2010 105

Phase B: Business Architecture - Step 1 - Select
Reference Models, Viewpoints, and Tools (3)
• Identify Required Catalogs of Business Building Blocks
− Catalogs capture inventories of the core assets of the business
− 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
− Develop some or all of the following catalogs:
• Organisation/Actor catalog
• Driver/Goal/Objective catalog
• Role catalog
• Business Service/Function catalog
• Location catalog
• Process/Event/Control/Product catalog
• Contract/Measure catalog

January 27, 2010 106

Phase B: Business Architecture - Catalog Structure

• Terms
− Actor: A person, business unit, 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 business unit
− Data Entity: An encapsulation of data that is recognised 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 a business unit, but not
explicitly governed by the business unit
− Business Unit: A self-contained unit of resources with line management responsibility,
goals, objectives, and measures. Business units may include external parties and
business partner business units
− 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
January 27, 2010 107
Phase B: Business Architecture - Catalog Structure

• Key relationships
− Process should normally be used to describe flow
• A process is a flow of interactions between functions and services
• All processes should describe the flow of execution for a function and therefore the
deployment of a process is through the function it supports
• An application implements a function that has a process, not an application implements a
process
− Function describes units of business capability at all levels of granularity
• Function describes a unit of business capability at all levels of granularity, encapsulating terms
such as value chain, process area, capability, business function
− Business services support organisational objectives and are defined at a level of
granularity consistent with the level of governance needed
• Business service operates as a boundary for one or more functions
• Granularity of business services is dependent on the focus and emphasis of the business (as
reflected by its drivers, goals, and objectives)
− Business services are deployed onto application components
• Business services may be realised by business activity that does not relate to IT, or may be
supported by IT
• Business services that are supported by IT are deployed onto application components
• Business service can be supported by multiple application components,
− Application components are deployed onto technology components
• Application component is implemented by a suite of technology components

January 27, 2010 108

Phase B: Business Architecture - Core Entities and
their Relationships Process Business Unit
Business Unit
Actor Function
Function
Function
Function
Business Service
Application

Function
Business Unit
Function Role Actor Role
Function Business Service
Data Entity
Function Application Architecture
Application Component
Function
Business Service Application Component Data Entity

Business Unit Business Service Business Service Data Entity

Actor Business Service Business Service Data Entity

Technology Architecture Technology Architecture

Technology Component Technology Component
Platform Service Platform Service

Platform Service Platform Service

January 27, 2010 109

Phase B: Business Architecture - Step 1 - Select
Reference Models, Viewpoints, and Tools (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
• Business interaction matrix - showing dependency and communication
between business units and actors
• Actor/role matrix - showing the roles undertaken by each actor

January 27, 2010 110

Phase B: Business Architecture - Step 1 - Select
Reference Models, Viewpoints, and Tools (5)
• Identify Required Diagrams
− Diagrams present the Business Architecture information from a
set of different perspectives according to the requirements of the
stakeholders
• Business Footprint diagram
• Business Service/Information diagram
• Functional Decomposition diagram
• Goal/Objective/Service diagram
• Use-case diagram
• Organisation Decomposition diagram
• Process Flow diagram
• Events diagram

January 27, 2010 111

Phase B: Business Architecture - Step 1 - Select
Reference Models, Viewpoints, and Tools (6)
• Identify Types of Requirement to be Collected
− Once the Business Architecture catalogs, matrices, and diagrams have been
developed, architecture modeling is completed by formalising the business-
focused requirements for implementing the Target Architecture
− Requirements may relate to the business domain, or may provide
requirements input into the Data, Application, and Technology Architectures
− Types of requirement
• Functional requirements
• Non-functional requirements
• Assumptions
• Constraints
• Domain-specific Business Architecture principles
• Policies
• Standards
• Guidelines
• Specifications
January 27, 2010 112
Phase B: Business Architecture - Step 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
• 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

January 27, 2010 113

Phase B: Business Architecture - Step 3 - Develop
Target Business Architecture Description
• Develop a Target Description for the Business Architecture,
to the extent necessary to support the Architecture Vision
• Scope and level of detail to be defined will depend on the
relevance of the business elements to attaining the Target
Architecture Vision

January 27, 2010 114

Phase B: Business Architecture - Step 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
• Test architecture models for completeness against
requirements
• Identify gaps between the baseline and target

January 27, 2010 115

Phase B: Business Architecture - Step 5 - Define
Roadmap Components
• Create a business roadmap to prioritise activities over the
coming phases
• Initial Business Architecture roadmap will be used as raw
material to support more detailed definition of a
consolidated, cross-discipline roadmap within the
Opportunities and Solutions phase

January 27, 2010 116

Phase B: Business Architecture - Step 6 - Resolve
Impacts Across the Architecture Landscape
• Understand any wider impacts or implications of proposed
Business Architecture
− 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 organisation?
− 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)?

January 27, 2010 117

Phase B: Business Architecture - Step 7 - Conduct
Formal Stakeholder Review
• Check the original motivation for the architecture project
and the Statement of Architecture Work against the
proposed Business Architecture
• Is fit for the purpose of supporting subsequent work in the
other architecture domains?
• Refine the proposed Business Architecture but only if
necessary

January 27, 2010 118

Phase B: Business Architecture - Step 8 - Finalise 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
• Document each building block
• Conduct final cross-check of overall architecture against business
goals
• Document reason for building block decisions in the architecture
document
• Document final requirements traceability report
• Document final mapping of the architecture within the Architecture
Repository and publish via the Architecture Repository
• Finalise all the work products, such as gap analysis results
January 27, 2010 119
Phase B: Business Architecture - Step 9 - Create
Architecture Definition Document
• Document reasons for building block decisions in the
Architecture Definition Document
• Prepare the business sections of the Architecture
Definition Document
− 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

January 27, 2010 120

Phase B: Business Architecture - Outputs

• Refined and updated versions of the Architecture Vision phase deliverables

− Statement of Architecture Work
− Validated business principles, business goals, and business drivers
− Architecture principles
• Draft Architecture Definition Document
− Baseline Business Architecture
− Target Business Architecture
• Organisation structure — identifying business locations and relating them to business units
• Business goals and objectives — for the enterprise and each business 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 organisation and functions — relate business functions to business units in the form of a
matrix report
− Draft Architecture Requirements Specification
• Gap analysis results
• Technical requirements
• Updated business requirements
− Business Architecture components of an Architecture Roadmap

January 27, 2010 121

Phase C: Information Systems Architectures -
Objectives
• To develop Target Architectures covering either or both
(depending on project scope) of the data and application
systems domains
• Focus on identifying and defining the applications and data
considerations that support an enterprise’s Business
Architecture

January 27, 2010 122

Phase C: Information Systems Architectures -
Overview
Phase C: Information Systems
Architectures

Approach Elements Inputs Steps Outputs

Reference Materials External to Phase C2: Application

Development Phase C1: Data Architecture
the Enterprise Architecture

Select Reference Models, Select Reference Models,

Implementation Non-Architectural Inputs
Viewpoints, and Tools Viewpoints, and Tools

Develop Baseline Data Develop Baseline Application

Architectural Inputs
Architecture Description Architecture Description

Develop Target Data Develop Target Application

Architecture Description Architecture Description

Perform Gap Analysis# Perform Gap Analysis#

Define Roadmap Components Define Roadmap Components

Resolve Impacts Across the Resolve Impacts Across the

Architecture Landscape Architecture Landscape

Conduct Formal Stakeholder Conduct Formal Stakeholder

Review Review

Finalise the Application

Finalise the Data Architecture Architecture

Create Architecture Definition Create Architecture Definition

Document Document

January 27, 2010 123

Phase C: Information Systems Architectures -
Approach - Development
• Phase C involves a combination of Data and Application
Architecture
− Divided into two sub-phases each with common set of steps
• Data
• Application
• Each has common set of steps that are similar to Phase B: Business
Architecture

• Key applications can form the core of mission-critical

business processes
• The implementation and integration of core applications
can be primary focus of architecture effort (the integration
issues often constituting a major challenge)
January 27, 2010 124
Phase C: Information Systems Architectures -
Approach - Implementation
• Implementation of these architectures may not follow the
same order
− Design
• Business Architecture design
• Data (or Application) Architecture design
• Application (or Data) Architecture design
• Technology Architecture design
− Implementation
• Technology Architecture implementation
• Application (or Data) Architecture implementation
• Data (or Application) Architecture implementation
• Business Architecture implementation

January 27, 2010 125

Phase C: Information Systems Architectures - Inputs
• Reference Materials External to the Enterprise
• Non-Architectural Inputs
− Request for Architecture Work
− Capability Assessment
− Communications Plan
• Architectural Inputs
− Organisational Model for Enterprise Architecture
• Scope of business units 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
• Tailored architecture method
• Tailored architecture content (deliverables and artifacts)
• Configured and deployed tools
− Application principles
− Data principles
− Statement of Architecture Work
− Architecture Vision
• Architecture Repository
• Re-usable building blocks
• Organisation-specific reference models
• Organisation standards
− Draft Architecture Definition Document
• Baseline Business Architecture
• Target Business Architecture]
• Baseline Data Architecture
• Target Data Architecture
• Baseline Application Architecture
• Target Application Architecture
− Draft Architecture Requirements Specification
• Gap analysis results (from Business Architecture)
• Relevant technical requirements that will apply to Phase C
− Business Architecture components of an Architecture Roadmap

January 27, 2010 126

Phase C1: Information Systems Architectures
- Data Architecture - Objectives
• To define the major types and sources of data necessary to
support the business, in a way that is:
− Understandable by stakeholders
− Complete and consistent
− Stable
• Define the data entities relevant to the enterprise
• Not concerned with design of logical or physical storage
systems or databases

January 27, 2010 127

Phase C1: Information Systems Architectures - Data
Architecture - Overview
Phase C1: Information Systems
Architectures - Data Architecture

Approach Elements Inputs Steps Outputs

Key Considerations for Data Reference Materials External to the Select Reference Models,
Architecture Enterprise Viewpoints, and Tools

Develop Baseline Data Architecture

Architecture Repository Non-Architectural Inputs
Description

Develop Target Data Architecture

Architectural Inputs
Description

Perform Gap Analysis

Define Roadmap Components

Resolve Impacts Across the

Architecture Landscape

Conduct Formal Stakeholder

Review

Finalise the Data Architecture

Create Architecture Definition

Document
January 27, 2010 128
Phase C1: Information Systems Architectures - Data
Architecture - Approach - Key Considerations for Data
Architecture
• Data Management
− Important to understand and address data management issues
− Structured and comprehensive approach to data management enables the
effective use of data to capitalise on its competitive advantages
− 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
− Understand how data entities are utilised by business functions, processes, and
services
− Understand how and where enterprise data entities are created, stored,
transported, and reported
− Level and complexity of data transformations required to support the
information exchange needs between applications
− Requirement for software in supporting data integration with external
organisations

January 27, 2010 129

Phase C1: Information Systems Architectures - Data
Architecture - Approach - Key Considerations for Data
Architecture
• Data Migration
− Identify data migration requirements and also provide indicators
as to the level of transformation for new/changed applications
− Ensure target application has quality data when it is populated
− Ensure enterprise-wide common data definition is established to
support the transformation

January 27, 2010 130

Phase C1: Information Systems Architectures - Data
Architecture - Approach - Key Considerations for Data
Architecture
• Data Governance
− Ensures that the organisation has the necessary dimensions in
place to enable the data transformation
− Structure – ensures the organisation has the necessary structure
and the standards bodies to manage data entity aspects of the
transformation
− Management System - ensures the organisation has the
necessary management system and data-related programs to
manage the governance aspects of data entities throughout its
lifecycle
− People - addresses what data-related skills and roles the
organisation requires for the transformation

January 27, 2010 131

Phase C1: Information Systems Architectures - Data
Architecture - Approach - Architecture Repository
• Consider what relevant Data Architecture resources are
available in the Architecture Repository
• What generic data models relevant to the organisation’s
sector

January 27, 2010 132

Phase C1: Information Systems Architectures - Data
Architecture - Inputs
• Reference Materials External to the Enterprise
• Non-Architectural Inputs
− Request for Architecture Work
− Capability Assessment
− Communications Plan
• Architectural Inputs
− Organisational Model for Enterprise Architecture
• Scope of business units 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
• Tailored architecture method
• Tailored architecture content (deliverables and artifacts)
• Configured and deployed tools
− Data principles
− Statement of Architecture Work
− Architecture Vision
• Architecture Repository
• Re-usable building blocks
• Organisation-specific reference models
• Organisation standards
− Draft Architecture Definition Document
• Baseline Business Architecture
• Target Business Architecture]
• Baseline Data Architecture
• Target Data Architecture
• Baseline Application Architecture
• Target Application Architecture
− Draft Architecture Requirements Specification
• Gap analysis results (from Business Architecture)
• Relevant technical requirements that will apply to Phase C1
− Business Architecture components of an Architecture Roadmap

January 27, 2010 133

Phase C1: Information Systems Architectures - Data
Architecture - Steps
• Level of detail addressed in Phase C1 will depend on the scope and
goals of the overall architecture effort
• Adapt steps and their order to suit specific requirements
• Phase C1: Information Systems Architectures - Data Architecture
steps
− Select reference models, viewpoints, and tools
− Develop Baseline Data Architecture Description
− Develop Target Data Architecture Description
− Perform gap analysis
− Define roadmap components
− Resolve impacts across the Architecture Landscape
− Conduct formal stakeholder review
− Finalise the Data Architecture
− Create Architecture Definition Document

January 27, 2010 134

Phase C1: Information Systems Architectures - Data
Architecture - Step 1 - Select Reference Models, Viewpoints,
and Tools (1)
• Select relevant Data Architecture resources (reference models, patterns, etc.)
from the Architecture Repository, on the basis of the business drivers, and the
stakeholders and concerns
• Select relevant Data 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 Data Architecture
• Identify appropriate tools and techniques to be used for data capture, modeling,
and analysis
• Determine Overall Modelling 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
− Collect data-related models from existing Business Architecture and Application
Architecture materials
− Rationalise data requirements and align with any existing organisation data catalogs
and models - this allows the development of a data inventor y 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

January 27, 2010 135

Phase C1: Information Systems Architectures - Data
Architecture - Step 1 - Select Reference Models, Viewpoints,
and Tools (2)
• Identify Required Catalogs of Data Building Blocks
− Capture organisation’s data inventory as a catalog within the
Architecture Repository
− Create an inventory of the data needed to be in place to support
the Architecture Vision
− Refer to the Business Service/Information diagram created during
the Business Architecture phase, showing the key data entities
required by the main business services
− Consolidate the data requirements in a single location
− Refine the data inventory to achieve semantic consistency and to
remove gaps and overlaps

January 27, 2010 136

Phase C1: Information Systems Architectures - Data
Architecture - Step 1 - Select Reference Models, Viewpoints,
and Tools (3)
• Identify Required Matrices
− Matrices show the core relationships between related model entities
− Form the raw material for development of diagrams and also act as a key
resource for impact assessment
− Understand how data is created, maintained, transformed, and passed to
other applications, or used by other applications
− Note gaps such as entities that never seem to be created by an application or
data created but never used
− Update and refine the architectural diagrams of how data relates to other
aspects of the architecture
− Suggested matrices
• 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)
• System/Data (developed across the Application Architecture and Data Architecture
phases)

January 27, 2010 137

Phase C1: Information Systems Architectures - Data
Architecture - Step 1 - Select Reference Models, Viewpoints,
and Tools (4)
• Identify Required Diagrams
− Diagrams present the Data Architecture information from a set of
different perspectives 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
• Class diagram
• Data Dissemination diagram
• Data Lifecycle diagram
• Data Security diagram
• Data Migration diagram
• Class Hierarchy diagram

January 27, 2010 138

Phase C1: Information Systems Architectures - Data
Architecture - Step 1 - Select Reference Models, Viewpoints,
and Tools (5)
• Identify Types of Requirement to be Collected
− Once the Data Architecture catalogs, matrices, and diagrams have
been developed, architecture modeling is completed by
formalising the business-focused requirements for implementing
the Target Architecture
− Types of requirement
• Functional requirements
• Non-functional requirements
• Assumptions
• Constraints
• Domain-specific Data Architecture principles
• Policies
• Standards
• Guidelines
• Specifications

January 27, 2010 139

Phase C1: Information Systems Architectures - Data
Architecture - Step 2 - Develop Data Business Architecture
Description
• Develop a Baseline Description of the existing Data
Architecture, to the extent necessary to support the Target
Business Architecture
• 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

January 27, 2010 140

Phase C1: Information Systems Architectures - Data
Architecture - Step 3 - Develop Target Business Architecture
Description
• Develop a Target Description for the Data Architecture, to
the extent necessary to support the Architecture Vision
• Scope and level of detail to be defined will depend on the
relevance of the business elements to attaining the Target
Architecture Vision

January 27, 2010 141

Phase C1: Information Systems Architectures - Data
Architecture - Step 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
• Test architecture models for completeness against requirements
• Identify gaps between the baseline and target
− Create gap matrix
− Identify building blocks to be carried over, classifying as either changed or
unchanged
− Identify eliminated building blocks
− Identify new building blocks
− Identify gaps and classify as those that should be developed and those that
should be procured

January 27, 2010 142

Phase C1: Information Systems Architectures - Data
Architecture - Step 5 - Define Roadmap Components
• Create a data business roadmap to prioritise activities over
the coming phases
• Initial Data Architecture roadmap will be used as raw
material to support more detailed definition of a
consolidated, cross-discipline roadmap within the
Opportunities and Solutions phase

January 27, 2010 143

Phase C1: Information Systems Architectures - Data
Architecture - Step 6 - Resolve Impacts Across the
Architecture Landscape
• Understand any wider impacts or implications of proposed
Data Architecture
− Does this Data Architecture create an impact on any pre-existing
architectures?
− Have recent changes been made that impact on the Data
Architecture?
− Are there any opportunities to leverage work from this Data
Architecture in other areas of the organisation?
− 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)?

January 27, 2010 144

Phase C1: Information Systems Architectures - Data
Architecture - Step 7 - Conduct Formal Stakeholder Review

• Check the original motivation for the architecture project

and the Statement of Architecture Work against the
proposed Data Architecture
• Is fit for the purpose of supporting subsequent work in the
other architecture domains?
• Identify any areas where the Application Architecture (if
generated at this point – Phase C2) may need to change to
cater for changes in the Data Architecture (or to identify
constraints on the Application Architecture about to be
designed)
• Refine the proposed Data Architecture but only if
necessary

January 27, 2010 145

Phase C1: Information Systems Architectures - Data
Architecture - Step 8 - Finalise 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
• Document each building block
• Conduct final cross-check of overall architecture against business
goals
• Document reason for building block decisions in the architecture
document
• Document final requirements traceability report
• Document final mapping of the architecture within the Architecture
Repository and publish via the Architecture Repository
• Finalise all the work products, such as gap analysis results
January 27, 2010 146
Phase C1: Information Systems Architectures - Data
Architecture - Step 9 - Create Architecture Definition
Document
• Document reasons for building block decisions in the
Architecture Definition Document
• Prepare Data Architecture sections of the Architecture
Definition Document
− Business data model
− Logical data model
− Data management process model
− Data Entity/Business Function matrix
− Data interoperability requirements

January 27, 2010 147

Phase C1: Information Systems Architectures - Data
Architecture - Outputs
• Refined and updated versions of the Architecture Vision phase deliverables
− Statement of Architecture Work
− Validated data principles, business goals, and business drivers
• Draft Architecture Definition Document
− Baseline Data Architecture
− Target Data Architecture
• 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
• Gap analysis results
• Data interoperability requirements
• Relevant technical requirements
• Constraints on the Technology Architecture about to be designed
• Updated business requirements
• Updated application requirements
− Data Architecture components of an Architecture Roadmap
January 27, 2010 148
Phase C2: Information Systems Architectures -
Application Architecture - Objectives

• To define the major kinds of application system necessary to process

the data and support the business
• Define what kinds of application systems are relevant to the
organisation and what those applications need to do in order to
manage data and to present information to the human and
computer actors in the organisation
• Not concerned with applications systems design
• Define logical groups of capabilities that manage the data objects in
the Data Architecture and support the business functions in the
Business Architecture
− Without reference to particular technologies
− Applications tend to be stable and relatively unchanging over time, whereas
the technology used to implement them will change over time, based on the
technologies currently available and changing business needs

January 27, 2010 149

Phase C2: Information Systems Architectures -
Application Architecture - Overview Phase C2: Information Systems
Architectures - Application
Architecture

Approach Elements Inputs Steps Outputs

Reference Materials External to the Select Reference Models,

Architecture Repository
Enterprise Viewpoints, and Tools

Develop Baseline Application

Non-Architectural Inputs
Architecture Description

Develop Target Application

Architectural Inputs
Architecture Description

Perform Gap Analysis

Define Roadmap Components

Resolve Impacts Across the

Architecture Landscape

Conduct Formal Stakeholder

Review

Finalise the Application

Architecture

Create Architecture Definition

Document
January 27, 2010 150
Phase C2: Information Systems Architectures -
Application Architecture - Architecture Repository
• Consider what relevant Application Architecture resources
are available in the Architecture Repository
• What generic application models relevant to the
organisation’s sector

January 27, 2010 151

Phase C2: Information Systems Architectures -
Application Architecture - Inputs
• Reference Materials External to the Enterprise
• Non-Architectural Inputs
− Request for Architecture Work
− Capability Assessment
− Communications Plan
• Architectural Inputs
− Organisational Model for Enterprise Architecture
• Scope of business units 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
• Tailored architecture method
• Tailored architecture content (deliverables and artifacts)
• Configured and deployed tools
− Application principles
− Statement of Architecture Work
− Architecture Vision
• Architecture Repository
• Re-usable building blocks
• Organisation-specific reference models
• Organisation standards
− Draft Architecture Definition Document
• Baseline Business Architecture
• Target Business Architecture]
• Baseline Data Architecture
• Target Data Architecture
• Baseline Application Architecture
• Target Application Architecture
− Draft Architecture Requirements Specification
• Gap analysis results (from Business Architecture and Data Architecture,)
• Relevant technical requirements that will apply to Phase C2
− Business and Data Architecture components of an Architecture Roadmap

January 27, 2010 152

Phase C2: Information Systems Architectures -
Application Architecture - Steps
• Level of detail addressed in Phase C2 will depend on the scope and
goals of the overall architecture effort
• Adapt steps and their order to suit specific requirements
• Phase C1: Information Systems Architectures - Application
Architecture steps
− Select reference models, viewpoints, and tools
− Develop Baseline Application Architecture Description
− Develop Target Application Architecture Description
− Perform gap analysis
− Define roadmap components
− Resolve impacts across the Architecture Landscape
− Conduct formal stakeholder review
− Finalise the Application Architecture
− Create Architecture Definition Document

January 27, 2010 153

Phase C2: Information Systems Architectures - Application
Architecture - Step 1 - Select Reference Models, Viewpoints,
and Tools (1)
• Review and validate (or generate, if necessary) the set of application
principles
− Form part of an overarching set of architecture principles
• Select relevant Application Architecture resources (reference
models, patterns, etc.) from the Architecture Repository, on the
basis of the business drivers, and the stakeholders and 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 data
capture, modeling, and analysis
• Consider using platform-independent descriptions of business logic
− Isolate the business logic from changes to the underlying platform and
implementation technology

January 27, 2010 154

Phase C2: Information Systems Architectures - Application
Architecture - Step 1 - Select Reference Models, Viewpoints,
and Tools (2)
• 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
− Process steps
• 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
• 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 of granularity should be sufficient to enable
identification of gaps and the scope of candidate work packages
January 27, 2010 155
Phase C2: Information Systems Architectures - Application
Architecture - Step 1 - Select Reference Models, Viewpoints,
and Tools (3)
• Identify Required Catalogs of Application Building Blocks
− Capture organisation’s Application Portfolio as a catalog within
the Architecture Repository
• Application Portfolio catalog
• Interface catalog

January 27, 2010 156

Phase C2: Information Systems Architectures - Application
Architecture - Step 1 - Select Reference Models, Viewpoints,
and Tools (4)
• Identify Required Matrices
− Matrices show the core relationships between related model entities
− 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
• Initial mapping should focus on business services within the Business Architecture
− Once applications are mapped to business services, it will also be possible to make
associations from applications to data
• Refer to Phase C1: Information Systems Architectures - Data Architecture
− Identify user and organisational dependencies on applications
− Specifically consider the operational support business unit
− Update and refine the architectural diagrams of how data relates to other aspects of
the architecture
− Examine application dependencies on shared operations capabilities and produce a
diagram on how each application is effectively operated and managed
− Suggested matrices
• System/Business Unit matrix
• Role/System matrix
• Application Interaction matrix
• System/Function matrix

January 27, 2010 157

Phase C2: Information Systems Architectures - Application
Architecture - Step 1 - Select Reference Models, Viewpoints,
and Tools (5)
• Identify Required Diagrams
− Diagrams present the Application Architecture information from a set of
different perspectives 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
• Packaged applications
− Numbers of configuration options, add-on modules
• Custom developed applications
− Identify the high-level structure of the application in terms of modules or sub-
systems as a foundation to organise design activity
− Once the application entities have been refined, a diagram of the relationships
between entities and their attributes can be produced
• Application Communication diagram
• Application and User Location diagram
• Enterprise Manageability diagram
• Process/System Realisation diagram
• Application Migration diagram
• Software Distribution diagram
• Software Engineering diagram

January 27, 2010 158

Phase C2: Information Systems Architectures - Application
Architecture - Step 1 - Select Reference Models, Viewpoints,
and Tools (6)
• Identify Types of Requirement to be Collected
− Once the Application Architecture catalogs, matrices, and
diagrams have been developed, architecture modeling is
completed by formalising the application-focused requirements
for implementing the Target Architecture
− Types of requirement
• Functional requirements
• Non-functional requirements
• Assumptions
• Constraints
• Domain-specific Application Architecture principles
• Policies
• Standards
• Guidelines
• Specifications

January 27, 2010 159

Phase C2: Information Systems Architectures - Application
Architecture - Step 2 - Develop Application Business
Architecture Description
• Develop a Baseline Description of the existing Application
Architecture, to the extent necessary to support the Target
Business Architecture
• 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 Application Architecture

January 27, 2010 160

Phase C2: Information Systems Architectures - Application
Architecture - Step 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
• Scope and level of detail to be defined will depend on the
relevance of the business elements to attaining the Target
Architecture Vision

January 27, 2010 161

Phase C2: Information Systems Architectures - Application
Architecture - Step 4 - Perform Gap Analysis

• Verify the architecture models for internal consistency and

accuracy
• Test architecture models for completeness against
requirements
• Identify gaps between the baseline and target
− Create gap matrix
− Identify building blocks to be carried over, classifying as either
changed or unchanged
− Identify eliminated building blocks
− Identify new building blocks
− Identify gaps and classify as those that should be developed and
those that should be procured
January 27, 2010 162
Phase C2: Information Systems Architectures - Application
Architecture - Step 5 - Define Roadmap Components

• Create an application business roadmap to prioritise

activities over the coming phases
• Initial Application Architecture roadmap will be used as
raw material to support more detailed definition of a
consolidated, cross-discipline roadmap within the
Opportunities and Solutions phase

January 27, 2010 163

Phase C2: Information Systems Architectures - Application
Architecture - Step 6 - Resolve Impacts Across the
Architecture Landscape
• Understand any wider impacts or implications of proposed
Application Architecture
− Does this Application Architecture create an impact on any pre-
existing architectures?
− Have recent changes been made that impact on the Application
Architecture?
− Are there any opportunities to leverage work from this
Application Architecture in other areas of the organisation?
− 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)?

January 27, 2010 164

Phase C2: Information Systems Architectures - Application
Architecture - Step 7 - Conduct Formal Stakeholder Review

• Check the original motivation for the architecture project

and the Statement of Architecture Work against the
proposed Application Architecture
• Identify any areas where the 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 for ms or procedures, application
systems, or database systems)
• Identify any constraints on the Technology Architecture
(especially the infrastructure) about to be designed

January 27, 2010 165

Phase C2: Information Systems Architectures - Application
Architecture - Step 8 - Finalise 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
• Document each building block
• Conduct final cross-check of overall architecture against business
goals
• Document reason for building block decisions in the architecture
document
• Document final requirements traceability report
• Document final mapping of the architecture within the Architecture
Repository and publish via the Architecture Repository
• Finalise all the work products, such as gap analysis results
January 27, 2010 166
Phase C2: Information Systems Architectures - Application
Architecture - Step 9 - Create Architecture Definition
Document
• Document reasons for building block decisions in the
Architecture Definition Document
• Prepare Application Architecture sections of the
Architecture Definition Document

January 27, 2010 167

Phase C2: Information Systems Architectures -
Application Architecture - Outputs
• Refined and updated versions of the Architecture Vision phase deliverables
− Statement of Architecture Work
− Validated application principles, or new application principles
• Draft Architecture Definition Document
− Baseline Application Architecture
− Target Application Architecture
− 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
• Gap analysis results
• Applications interoperability requirements
• Relevant technical requirements
• Constraints on the Technology Architecture about to be designed
• Updated business requirements
• Updated data requirements
− Application Architecture components of an Architecture Roadmap
January 27, 2010 168
Phase D: Technology Architecture - Objectives

• To map application components defined in the Application

Architecture phase into a set of technology components,
which represent software and hardware components
• To define the physical realisation of an architectural
solution
• To define baseline (current) and target views of the
technology portfolio, detailing the roadmap towards the
Target Architecture
• To identify key work packages in the roadmap
• To complete the set of architectural information and
therefore supports cost assessment for particular
migration scenarios
January 27, 2010 169
Phase D: Technology Architecture - Overview
Phase D: Technology
Architecture

Approach Elements Inputs Steps Outputs

Reference Materials External to Select Reference Models,

Architecture Repository
the Enterprise Viewpoints, and Tools

Develop Baseline Technology

Non-Architectural Inputs
Architecture Description

Develop Target Technology

Architectural Inputs
Architecture Description

Perform Gap Analysis

Define Roadmap Components

Resolve Impacts Across the

Architecture Landscape

Conduct Formal Stakeholder

Review

Finalise the Technology

Architecture

Create Architecture Definition

Document
January 27, 2010 170
Phase D: Technology Architecture - Architecture
Repository
• Consider what relevant Technology Architecture resources
are available
− Existing IT services as documented in the IT repository or IT
service catalog
− Generic technology models relevant to the organisation’s industry
vertical sector
− Technical Reference Model

January 27, 2010 171

Phase D: Technology Architecture - Technical
Reference Model – High-Level View
• Three major entities (Application Software,
Applications Application Platform, and Communications
Infrastructure) connected by two interfaces
(Application Platform Interface and
Communications Infrastructure Interface)
Application • Technical Reference Model seeks to
Platform Interface emphasise two major common architectural
objectives:
− Application Portability, via the Application
Platform Interface identifying the set of services
that are to be made available in a standard way
Application Platform to applications via the platform
− Interoperability, via the Communications
Infrastructure Interface identifying the set of
Communications Infrastructure ser vices that
Communications are to be leveraged in a standard way by the
Infrastructure platform
Interface
• Objectives are essential to enable integration
within the organisation and trusted
interoperability between enterprises
Communications
Infrastructure

January 27, 2010 172

Phase D: Technology Architecture - Technical
Reference Model – Detailed View
Infrastructure Applications Business Applications • Generic model
Application Platform Interface
• Idealised set of service
categories
System and Network Management

International Operations
• Many architectures will
Transaction Processing

Location and Directory

Software Engineering

Graphics and Image

not include all of these

Data Management
Data Interchange
User Interface

services
Security

• many architectures will

include additional
services to support
Operating System Services
Application Software
Network Services
that is specific to the
Communications Infrastructure Interface
organisation or to its
Communications Infrastructure
vertical industry

January 27, 2010 173

Phase D: Technology Architecture - Inputs
• Reference Materials External to the Enterprise
− Architecture reference materials
− Product information on candidate products
• Non-Architectural Inputs
− Request for Architecture Work
− Capability Assessment
− Communications Plan
• Architectural Inputs
− Organisational Model for Enterprise Architecture
• Scope of business units 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
• Tailored architecture method
• Tailored architecture content (deliverables and artifacts)
• Configured and deployed tools
− Technology principles
− Statement of Architecture Work
− Architecture Vision
− Architecture Repository
• Re-usable building blocks
• Publicly available reference models
• Organisation-specific reference models
• Organisation standards
− Draft Architecture Definition Document
• Baseline Business Architecture
• Target Business Architecture]
• Baseline Data Architecture
• Target Data Architecture
• Baseline Technology Architecture
• Target Technology Architecture
− Draft Architecture Requirements Specification
• Gap analysis results (from Business Architecture)
• Relevant technical requirements that will apply to Phase C
− Business, Data, and Application Architecture components of an Architecture Roadmap

January 27, 2010 174

Phase D: Technology Architecture - Steps

• Select reference models, viewpoints, and tools

• Develop Baseline Technology Architecture Description
• Develop Target Technology Architecture Description
• Perform gap analysis
• Define roadmap components
• Resolve impacts across the Architecture Landscape
• Conduct formal stakeholder review
• Finalise the Technology Architecture
• Create Architecture Definition Document
January 27, 2010 175
Phase D: Technology Architecture - Step 1 - Select
Reference Models, Viewpoints, and Tools (1)
• Review and validate the set of technology principles
• Select relevant Technology Architecture resources
(reference models, patterns, etc.) from the Architecture
Repository
• 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
January 27, 2010 176
Phase D: Technology Architecture - Step 1 - Select
Reference Models, Viewpoints, and Tools (2)
• Determine Overall Modelling Process
− For each viewpoint, select the models needed to support the
specific view required, using the selected tool or method
− Develop a Technology Architecture
• Define a classification of platform services and logical technology
components (including standards)
• Identify relevant locations where technology is deployed
• Carr y out a physical inventor y of deployed technology and abstract up to
fit into the classification
• Look at application and business requirements for technology
• Is the technology in place fit-for-purpose to meet new requirements
• Deter mine configuration of the selected technology
• Determine impact
− Sizing and costing
− Capacity planning
− Installation/governance/migration impacts
January 27, 2010 177
Phase D: Technology Architecture - Step 1 - Select
Reference Models, Viewpoints, and Tools (3)
• Determine Overall Modelling Process
− Technology Architecture may be impacted by earlier decisions made around
service granularity/level of detail and service boundaries
• Performance - Coarse-grained services contain several units of functionality with
potentially varying nonfunctional requirements, so platform performance should be
considered
• Maintainability - If service granularity is too coarse, then introducing changes to
that ser vice 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
• 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 and Solutions phase

January 27, 2010 178

Phase D: Technology Architecture - Step 1 - Select
Reference Models, Viewpoints, and Tools (4)
• Identify Required Catalogs of Technology Building Blocks
− Catalogs are inventories of the core assets of the business
− Catalogs for m the raw material for development of matrices and diagrams and
also act as a key resource for portfolio managing business and IT capability
− 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
− If technology standards are currently in place, apply these to the technology
component catalog to gain a baseline view of compliance with technology
standards
− Create catalogs
• Technology standards
• Technology portfolio

January 27, 2010 179

Phase D: Technology Architecture - Step 1 - Select
Reference Models, Viewpoints, and Tools (5)
• Identify Required Matrices
− Matrices show the core relationships between related model
entities
− Create System/Technology matrix

January 27, 2010 180

Phase D: Technology Architecture - Step 1 - Select
Reference Models, Viewpoints, and Tools (6)
• Identify Required Diagrams
− Diagrams present the Technology Architecture information from a set of different
perspectives (viewpoints) according to the requirements of the stakeholders
• Provide a link between platform requirements 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
− 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
− Create diagrams
• Environments and Locations diagram
• Platform Decomposition diagram
• Processing diagram
• Networked Computing/Hardware diagram
• Communications Engineering diagram

January 27, 2010 181

Phase D: Technology Architecture - Step 1 - Select
Reference Models, Viewpoints, and Tools (7)
• Identify Types of Requirement to be Collected
− Once the Technology Architecture catalogs, matrices, and diagrams have been
developed, architecture modeling is completed by formalising the data-
focused requirements for implementing the Target Architecture
− Identify types of requirement that must be met by the architecture
implementation
• Functional requirements
• Non-functional requirements
• Assumptions
• Constraints
• Domain-specific Technology Architecture principles
• Policies
• Standards
• Guidelines
• Specifications

January 27, 2010 182

Phase D: Technology Architecture - Step 1 - Select
Reference Models, Viewpoints, and Tools (8)
• Select Services
− Services portfolios are combinations of basic services from the
service categories in the Technical Reference Model that do not
conflict
• Requirements for organisation-specific elements or pre-existing decisions
• Pre-existing and unchanging organisational elements
• Inherited external environment constraints
− For each building block, build up a service description portfolio as
a set of non-conflicting ser vices
− Set of services must be tested to ensure that the functionality
provided meets application requirements

January 27, 2010 183

Phase D: Technology Architecture - Step 2 - Develop
Baseline Business Architecture Description
• Develop a Baseline Description of the existing Technology
Architecture to the extent necessary to support the Target
Technology Architecture
• 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
• Identify the relevant Technology Architecture building blocks,
drawing on any artifacts held in the Architecture Repository
• Convert the description of the existing environment into the terms
of the organisation’s Foundation Architecture
• Set down a list of key questions which can be used later in the
development process to measure the effectiveness of the new
architecture
• Use the models identified within Step 1 of Phase D as a guideline for
creating new architecture content to describe the Baseline
Architecture
January 27, 2010 184
Phase D: Technology Architecture - Step 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
• Scope and level of detail to be defined will depend on the relevance
of the business elements to attaining the Target Architecture Vision
• Process in the creation of a broad architectural model of the target
system is the conceptualisation 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
• Where new architecture models need to be developed to satisfy
stakeholder concerns, use the models identified within Step 1 of
Phase D as a guideline for creating new architecture content to
describe the Target Architecture

January 27, 2010 185

Phase D: Technology Architecture - Step 4 - Perform
Gap Analysis
• Verify the architecture models for internal consistency and accuracy
• Note changes to the viewpoint represented in the selected models
from the Architecture Repository
• Test architecture models for completeness against requirements
• Identify gaps between the baseline and target
− Create gap matrix
− Identify building blocks to be carried over, classifying as either changed or
unchanged
− Identify eliminated building blocks
− Identify new building blocks
− Identify gaps and classify as those that should be developed and those that
should be procured

January 27, 2010 186

Phase D: Technology Architecture - Step 5 - Define
Roadmap Components
• Create a business roadmap to prioritise activities over the
coming phases
• Initial Technology Architecture roadmap will be used as
raw material to support more detailed definition of a
consolidated, cross-discipline roadmap within the
Opportunities and Solutions phase

January 27, 2010 187

Phase D: Technology Architecture - Step 6 - Resolve
Impacts Across the Architecture Landscape
• Understand any wider impacts or implications of proposed
Technology Architecture
− Does this Technology Architecture create an impact on any pre-
existing architectures?
− Have recent changes been made that impact on the Technology
Architecture?
− Are there any opportunities to leverage work from this
Technology Architecture in other areas of the organisation?
− 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)?

January 27, 2010 188

Phase D: Technology Architecture - Step 7 - Conduct
Formal Stakeholder Review
• Check the original motivation for the architecture project
and the Statement of Architecture Work against the
proposed Technology Architecture
• Is fit for the purpose of supporting subsequent work in the
other architecture domains?
• Refine the proposed Technology Architecture but only if
necessary

January 27, 2010 189

Phase D: Technology Architecture - Step 8 - Finalise
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
• Document each building block
• Conduct final cross-check of overall architecture against business
goals
• Document reason for building block decisions in the architecture
document
• Document final requirements traceability report
• Document final mapping of the architecture within the Architecture
Repository and publish via the Architecture Repository
− From the selected building blocks, identify those that might be re-used
(working practices, roles, business relationships, job descriptions, etc.),
• Finalise all the work products, such as gap analysis results
January 27, 2010 190
Phase D: Technology Architecture - Step 9 - Create
Architecture Definition Document
• Document reasons for building block decisions in the Architecture
Definition Document
• Prepare the business sections of the Architecture Definition
Document
− 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 for mats, protocols, hardware
interfaces, standards)
− Map to business/organisational entities and policies
• 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

January 27, 2010 191

Phase D: Technology Architecture - Outputs

• Refined and updated versions of the Architecture Vision phase deliverables

− Statement of Architecture Work
− Validated business principles, business goals, and business drivers
− Architecture principles
• Draft Architecture Definition Document
− Target Technology Architecture
− Technology Components and their relationships to information systems
• Technology platforms and their decomposition, showing the combinations of technology
required to realise 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
− Views corresponding to the selected viewpoints addressing key stakeholder concerns
− Draft Architecture Requirements Specification
• Gap analysis results
• Requirements output from Phases B and C, C1 and C2
• Updated technology requirements
− Technology Architecture components of an Architecture Roadmap

January 27, 2010 192

Phase E: Opportunities and Solutions -
Objectives
• To review the target business objectives and capabilities,
consolidate the gaps from Phases B to D, and then
organise groups of building blocks to address these
capabilities
• To review and confirm the organisation’s current
parameters for and ability to absorb change
• To derive a series of Transition Architectures that deliver
continuous business value (e.g., capability increments)
through the exploitation of opportunities to realise the
building blocks
• To generate and gain consensus on an outline
Implementation and Migration Strategy

January 27, 2010 193

Phase E: Opportunities and Solutions - Overview
Phase E: Opportunities and Solutions

Approach Inputs Steps Outputs

Reference Materials External to the Determine/Confirm Key Corporate

Enterprise Change Attributes

Determine Business Constraints for

Non-Architectural Inputs
Implementation

Review and Consolidate Gap Analysis

Architectural Inputs
Results from Phases B to D

Review IT Requirements from a

Functional Perspective

Consolidate and Reconcile

Interoperability Requirements

Refine and Validate Dependencies

Confirm Readiness and Risk for

Business Transformation
Formulate High-Level
Implementation and Migration
Strategy
Identify and Group Major Work
Packages

Identify Transition Architectures

Create Portfolio and Project Charters

and Update the Architectures
January 27, 2010 194
Phase E: Opportunities and Solutions - Inputs
• Reference Materials External to the Enterprise
− Architecture reference materials
− Product information on candidate products
• Non-Architectural Inputs
− Request for Architecture Work
− Capability Assessment
− Communications Plan
• Architectural Inputs
− Organisational Model for Enterprise Architecture
• Scope of business units 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
• Tailored architecture method
• Tailored architecture content (deliverables and artifacts)
• Configured and deployed tools
− Technology principles
− Statement of Architecture Work
− Architecture Vision
− Architecture Repository
• Re-usable building blocks
• Publicly available reference models
• Organisation-specific reference models
• Organisation standards
− Draft Architecture Definition Document
• Baseline Business Architecture
• Target Business Architecture]
• Baseline Data Architecture
• Target Data Architecture
• Baseline Technology Architecture
• Target Technology Architecture
− Draft Architecture Requirements Specification
• Gap analysis results (from Business Architecture)
• Relevant technical requirements that will apply to Phase C
− Business, Data, and Application Architecture components of an Architecture Roadmap

January 27, 2010 195

Phase E: Opportunities and Solutions - Steps
Phase E:
Opportunities
and Solutions -
Steps

Determine/ Review and Formulate High- Create Portfolio

Determine Review IT Consolidate and Confirm
Confirm Key Consolidate Gap Refine and Level Identify and Identify and Project
Business Requirements Reconcile Readiness and
Corporate Analysis Results Validate Implementation Group Major Transition Charters and
Constraints for from a Functional Interoperability Risk for Business
Change from Phases B to Dependencies and Migration Work Packages Architectures Update the
Implementation Perspective Requirements Transformation
Attributes D Strategy Architectures

Create a
Create an Identify
Consolidated Assess the IT Determine
Implementation Consolidate Transition
Review Corporate Gaps, Solutions, Requirements Assess Business Overall Strategic Identify Major Create the
Factor Interoperability Architecture and
Strategic Plan and from a Functional Dependencies Implementation Work Packages Portfolio Charters
Assessment and Requirements Capability
Dependencies Perspective Direction
Deduction Matrix Increments
Matrix

Assess Transition Review the Reconcile Analyse the Work

Determine Issues
Capabilities of Enterprise Review the Phase Interoperability Assess Determine an Packages with Group Portfolios
Associated with Create the
Corporate and Architecture B, C, and D Gap Requirements Information Implementation Respect to and Projects into
Functional Project Charters
Partner Maturity Analysis Results with Potential Dependencies Approach Business Increments
Integration
Organisations Assessment Solutions Transformation

Rationalise the
Assess Transition Review Consolidated
Create the
Capabilities of the Corporate Line- Gaps, Solutions, Assess Workflow
Transition
Organisation and of-Business and Dependencies
Architectures
IT Business Unit Strategic Plans Dependencies
Matrix

Conduct Overall
Assess IT
Architecture
Dependencies
Updates

Assess
Foundation
Dependencies
and Interim
Capabilities

Rationalise and
Consolidate
Dependencies

January 27, 2010 196

Phase E: Opportunities and Solutions - Steps (1)

• Determine/confirm key corporate change attributes

− Create an Implementation Factor Assessment and Deduction Matrix
− Assess Transition Capabilities of Corporate and Partner Organisations
− Assess Transition Capabilities of the Organisation and IT Business Unit
• Deter mine business constraints for implementation
− Review Corporate Strategic Plan
− Review the Enterprise Architecture Maturity Assessment
− Review Corporate Line-of-Business Strategic Plans
• Review and consolidate gap analysis results from Phases B to D
− Create a Consolidated Gaps, Solutions, and Dependencies Matrix
− Review the Phase B, C, and D Gap Analysis Results
− Rationalise the Consolidated Gaps, Solutions, and Dependencies Matrix
• Review IT requirements from a functional perspective
− Assess the IT Requirements from a Functional Perspective
− Determine Issues Associated with Functional Integration
• Consolidate and reconcile interoperability requirements
− Consolidate Interoperability Requirements
− Reconcile Interoperability Requirements with Potential Solutions

January 27, 2010 197

Phase E: Opportunities and Solutions - Steps (2)

• Refine and validate dependencies

− Assess Business Dependencies
− Assess Information Dependencies
− Assess Workflow Dependencies
− Assess IT Dependencies
− Assess Foundation Dependencies and Interim Capabilities
− Rationalise and Consolidate Dependencies
• Confirm readiness and risk for business transformation
• Formulate high-level Implementation and Migration Strategy
− Determine Overall Strategic Implementation Direction
− Determine an Implementation Approach
• Identify and group major work packages
− Identify Major Work Packages
− Analyse the Work Packages with Respect to Business Transformation
• Identify Transition Architectures
− Identify Transition Architecture and Capability Increments
− Group Portfolios and Projects into Increments
• Create portfolio and project charters and update the architectures
− Create the Portfolio Charters
− Create the Project Charters
− Create the Transition Architectures
− Conduct Overall Architecture Updates

January 27, 2010 198

Phase E: Opportunities and Solutions - Step 1 -
Determine/Confirm Key Corporate Change Attributes (1)

• Create an Implementation Factor Assessment and Deduction Matrix

− Matrix should include a list of the factors to be considered, their descriptions,
and the deductions that indicate the actions or constraints that have to be
taken into consideration when formulating the plans
− Ensures that relevant factors are considered and documented
− Become part of the Implementation and Migration Plan and document the
rationale for key architecture decisions
• Assess Transition Capabilities of Corporate and Partner
Organisations
− Assess organisational impact on shaping the Transition Architecture
− Assess assignment of responsibilities within the organisation for the
implementation, so that the enterprise architecture becomes entrenched
within the organisation
− Evaluate corporate cultural influences for handling change
− Document in the Implementation Factor Assessment and Deduction matrix
January 27, 2010 199
Phase E: Opportunities and Solutions - Step 2 -
Determine/Confirm Key Corporate Change Attributes (2)

• Assess Transition Capabilities of the Organisation and IT

Organisation
− Perform a review of the corporate strategic and business plans in
order to validate the fundamental business drivers for the
enterprise architecture so that the enterprise architecture can
explicitly address each one
• Could have a major impact on Transition Architectures and the associated
Implementation and Migration Plan
− Each of the business drivers should be assessed with respect to
implementation issues and documented in the Implementation
Factor Assessment and Deduction matrix

January 27, 2010 200

Phase E: Opportunities and Solutions - Step 2 -
Determine Business Constraints for Implementation
• Review Corporate Strategic Plan
− Conduct an assessment of the organisation and specifically the IT business unit
− Assess the organisation and its culture and the IT business unit
− Assess the organisation personnel skill sets to determine whether training and/or
contracted assistance and/or outsourcing may be required in certain areas
− Perform a gap analysis between the Baseline and Target Architectures
− Document in the Implementation Factor Assessment and Deduction matrix
• Review the Enterprise Architecture Maturity Assessment
− Review the enterprise architecture maturity assessment that was conducted in the
Preliminary phase
− Update the Implementation Factor Assessment and Deduction matrix with any actions,
activities, initiatives, and projects that have to be under taken
• Review Corporate Line-of-Business Strategic Plans
− Perform a review of the line of business strategic and business plans in order to identify
any initiatives, portfolios, projects, or activities that could be leveraged to accelerate
the move to the Target Architecture
− Determine whether there are any initiatives that could create problems for the
enterprise architecture implementation
− Document all of the factors and deduced actions in the Implementation Factor
Assessment and Deduction matrix

January 27, 2010 201

Phase E: Opportunities and Solutions - Step 3 - Review and
Consolidate Gap Analysis Results from Phases B to D

• Create a Consolidated Gaps, Solutions, and Dependencies Matrix

− Group the gaps identified in the domain architecture gap analysis results and
assess potential solutions and dependencies to one or more gaps
− Enables identification of SBBs (Solution Building Blocks) which could potentially
address one or more gaps and their associated ABBs (Architecture Building
Blocks)
• Review the Phase B, C, and D Gap Analysis Results
− Consolidate gap analysis results from each one of the architecture phases in
one long list that will become the basis for the work breakdown structure
− Identify potential solutions to the gaps and dependencies
• Rationalise the Consolidated Gaps, Solutions, and Dependencies
Matrix
− Reorganise the gap list and place like items together

January 27, 2010 202

Phase E: Opportunities and Solutions - Step 4 - Review IT
Requirements from a Functional Perspective

• Assess the IT Requirements from a Functional Perspective

− Review all of the information acquired so far to determine whether the
solutions to the gaps can be functionally consolidated
− Assess Target Architecture, the Consolidated Gaps, Solutions, and
Dependencies matrix, and the Implementation Factor Assessment and
Deduction matrix for verification and review
− Consolidate the requirements functionally and groups them together to act as
the basis for work packages
− Refine the Consolidated Gaps, Solutions, and Dependencies matrix, listing the
new gaps that will for m the basis for work packages
• Determine Issues Associated with Functional Integration
− Assess requirements to determine if same functionality being required (and
possibly delivered) in many different places
− Target Architecture offers an integrated solution with little or no redundancy
but the integration of requirements and the associated funding often by lines
of business may be problematic
− Documented in the Implementation Factor Assessment and Deduction matrix
January 27, 2010 203
Phase E: Opportunities and Solutions - Step 5 - Consolidate
and Reconcile Interoperability Requirements
• Consolidate Interoperability Requirements
− Consolidate the Architecture Vision and Target Architectures, as well as the
Implementation Factor Assessment and Deduction matrix and Consolidated
Gaps, Solutions, and Dependencies matrix
− Review to look for any constraints on interoperability required by the potential
set of solutions
• Reconcile Interoperability Requirements with Potential Solutions
− Ensure that there are no interoperability conflicts
− Most significant issue to be addressed is business interoperability
− Review business processes embedded within the Target Architecture and see
whether they can be aligned with the third-party product/service provider
processes
− Most third-party product/service providers will have their own business
processes
− Changes to embedded business processes will often require so much work that
the advantages of re-using solutions will be lost
− Ensure that any change to the Target Architecture or third-party
product/service provider is signed off by the business architects and
architecture sponsors in a revised Statement of Architecture Work

January 27, 2010 204

Phase E: Opportunities and Solutions - Step 6 -
Refine and Validate Dependencies (1)
• Assess Business Dependencies
− Business dependencies are matters outside of the IT domain that impact the successful delivery of
the IT service
− Professional development and training to implement, operate, and sustain the IT capability in both
a business and technical context
− Infrastructure that is to provide the physical building to house the new business capability
enhanced by IT
− Processes that enable the business use of the IT capability through the establishment of workflows,
processes, and governance arrangements to ensure that the IT resources can be appropriately
leveraged
− Policies, including legislation, that guide the development of and use of the IT resources
• Assess Information Dependencies
− Assess information dependencies to ensure that IT resources and systems that create the data
precede those that use the data
− Can be achieved through the development of an information sequence for the projects
• Assess Workflow Dependencies
− Business workflow dependencies include those that ensure that work processes are supported in a
logical manner so that the workflows can be implemented in an incremental manner
− Co-ordinate a series of projects and project increments to deliver business value on a continual
basis
− Fully implemented ideal workflow could well be preceded by an abbreviated one focusing on the
critical and/or high return on investment processes

January 27, 2010 205

Phase E: Opportunities and Solutions - Step 6 -
Refine and Validate Dependencies (2)
• Assess IT Dependencies
− IT dependencies include those activities outside of the IT portfolio where IT
resources/systems are critical to the achievement of their business capabilities
− Assess and validate dependencies
• Assess Foundation Dependencies and Interim Capabilities
− Foundation dependencies include the assessment of the required resources, deter
mining the optimal implementation path within the constraints of the organisation’s
capacity for creating and absorbing change
− Continuous provision of business capabilities may necessitate the creation of interim or
partial SBBs
− Enterprise architecture involves top-down design and bottom-up implementation
− Need to deliver business value in the short term will most likely necessitate
implementation compromises and creates planned rework
− Foundation dependencies will highlight the impact of decisions made and the extent of
the rework that should be factored into the final resource bill
• Rationalise and Consolidate Dependencies
− Integrate dependencies, many of which will have been repeated in the different areas
− Include in a Dependency Analysis Report that will be part of the documentation of the
Implementation and Migration Plan

January 27, 2010 206

Phase E: Opportunities and Solutions - Step 7 - Confirm
Readiness and Risk for Business Transformation
• Assess the readiness of the organisation to undergo the business transformation
changes necessary to leverage the enterprise architecture
• Assess the ability of the organisation to adapt to change and capture the
associated risks
• Business Transformation Readiness Assessment will have been conducted in
Phase A
• Review the findings and determine the impact of the findings on the Transition
Architecture
• Always risks associated with any transformation effort - important to identify,
classify, and mitigate them before starting so that they can be tracked throughout
any specific transformation effort
• In enterprise architecture, the shortest distance between two points (the Baseline
and Target Architectures) may not be a straight line, but rather a more indirect
path that the organisation can realistically negotiate
• Determine implementation approaches that will be culturally as well as technically
feasible for both tactical and strategic success

January 27, 2010 207

Phase E: Opportunities and Solutions - Step 8 - Formulate
High-Level Implementation and Migration Strategy
• Determine Overall Strategic Implementation Direction
− Determine what strategic approach will be taken to implement the Target Architecture
− Ensure that Target Architecture is not decomposed into a series of projects that proceed
independently with unfortunate results
− Stakeholders need to know how the strategic goals are to be achieved
− Three basic approaches:
• Greenfield - start from the beginning
• Revolutionary - radical change (switch on, switch off); need for major surge resourcing (double/shadow
system)
• Evolutionary - includes strategy of convergence; a phased approach is needed to introduce most capabilities
− Collaborate with enterprise stakeholders to select a transformation approach and then to ensure
that the resources will be provided to support its implementation
• Determine an Implementation Approach
− Implementation approach addresses how the strategic implementation direction is to be executed
to provide direction to both architects and portfolio/project managers alike
− Common implementation methodology recommendations include:
• Quick win (snapshots)
• Achievable targets
• Value chain method
− Get agreement on the Implementation and Migration Strategy for the organisation

January 27, 2010 208

Phase E: Opportunities and Solutions - Step 9 -
Identify and Group Major Work Packages (1)
• Analyse the Work Packages with Respect to Business Transformation
− Assess the business transformation-related activities and group them together
as potential projects
− Re-group work packages should be with respect to dependencies (including
workflow) and this final analysis used as the basis for project identification
− Once the projects are identified, then their project charter and scope
statements should be clearly written and initial (i.e., order of magnitude)
resource estimates completed
− Benefits can be framed in the context in an organisation-wide context using
the enterprise architecture
− High return on investment projects should be identified as potential
pathfinders to show early success
− Verify that the organisation-specific requirements will be met
− Check against the original business scenario(s) driving the scope of the projects

January 27, 2010 209

Phase E: Opportunities and Solutions - Step 9 -
Identify and Group Major Work Packages (2)
• Identify Major Work Packages
− Examine the Implementation Factor Assessment and Deduction matrix and
Consolidated Gaps, Solutions, and Dependencies matrix and add details on
proposed solution mechanism
− Hold a working session with the domain architects and operations
management personnel to determine what potentially the best solutions
would be
− Indicate for every gap/activity whether the solution should be oriented
towards
• New development
• Based upon a existing product and/or solution that can be purchased
− Update Consolidated Gaps, Solutions, and Dependencies matrix with details
addressing proposed solutions
− classify every current system as:
• Mainstream Systems - par t of the future information system
• Contain Systems - Expected to be replaced or modified in the planning horizon (next
three years)
• Replace Systems - To be replaced in the planning horizon
January 27, 2010 210
Phase E: Opportunities and Solutions - Step 10 -
Identify Transition Architectures
• Identify Transition Architecture and Capability Increments
− Re-assess the missing business capabilities identified in the Architecture Vision and
Target Architecture
− Break-down these targeted capabilities into capability increments each having clearly
identified and measurable business value
− Break-down supporting top-level projects into increments to deliver the capability
increments
− Determine where the most difficult activities are
− Do not attack the these first - focus on activities that most easily deliver missing
capability
− Most of the challenges in creating and absorbing change are challenges based upon an
organisation’s maturity and are expressed in organisation and cultural barriers to
change
− Creation of capability increments will identify what activities and outcomes can be
grouped together and roughly in what sequence they should be delivered
• Group Portfolios and Projects into Increments
− Take the sequence of activities and outcomes and groups the delivery vehicles (the
portfolios and projects) into increments, specifying what should be delivered in each
increment
− Projects should be broken down into increments based upon the deliverables required
in each one of the Transition Architectures

January 27, 2010 211

Phase E: Opportunities and Solutions - Step 11 - Create
Portfolio and Project Charters and Update the Architectures
• Create the Portfolio Charters
− Review and consolidate the portfolio and potentially major project charters
and ensure that their architectural outcomes are clearly defined
− Architectural outcomes will give the portfolios organisation context and
determine the fit and value of the deliverables for governance
• Create the Project Charters
− Review and consolidate the project charters
− Ensure that their architectural outcomes are clearly defined
• Create the Transition Architectures
− Transition Architectures will form the basis for Migration Planning in Phase F
− Transition Architectures should have a clear set of outcomes and a
specification of which delivery vehicle
− Transition Architecture will be expressed at a similar level of detail to the
Architecture Definition Document
• Conduct Overall Architecture Updates
− Update the Architecture Vision with interoperability policy decisions
− Identifies all of the business capabilities that are to be implemented

January 27, 2010 212

Phase E: Opportunities and Solutions - Outputs

• Refined and updated versions of the Architecture Vision, Business Architecture, Information
Systems Architecture, and Technology Architecture phase deliverables
− Statement of Architecture Work
− Architecture Vision including definition of types and degrees of interoperability
− Draft Architecture Definition Document
• Identification of increments
• Interoperability and co-existence requirements
• Inclusion of project list and project charters
− Draft Architecture Requirements Specification
• Consolidated and validated Architecture Roadmap
• Capability Assessment
• Enter rise Architecture Maturity Profile
• Transformation Readiness Report
• Transition Architecture
− Consolidated Gaps, Solutions, and Dependencies Assessment
− Risk Register
− Impact analysis
− Dependency Analysis Report
− Implementation Factor Assessment and Deduction Matrix
• Implementation and Migration Plan including the high-level Implementation and Migration
Strategy
January 27, 2010 213
Phase F: Migration Planning - Objectives

• To ensure that the Implementation and Migration Plan is co-

ordinated with the various management frameworks in use within
the organisation
• To prioritise all work packages, projects, and building blocks by
assigning business value to each and conducting a cost/business
analysis
• To finalise the Architecture Vision and Architecture Definition
Documents in line with the agreed implementation approach
• To confirm the Transition Architectures defined in Phase E with
relevant stakeholders
• To create, evolve, and monitor the detailed Implementation and
Migration Plan providing necessary resources to enable the
realisation of the Transition Architectures, as defined in Phase E
January 27, 2010 214
Phase F: Migration Planning - Approach

• Focus on the creation of a viable Implementation and Migration Plan

in cooperation with the portfolio and project managers
• Assess the dependencies, costs, and benefits of the various
migration projects
• Prioritised list of projects will form the basis of the detailed
Implementation and Migration Plan
• Supplement the architecture with portfolio and project-level detail
assigning tasks to specific resources
• Implementation and Migration Plan is part of a family of plans issued
by enterprise management frameworks that have to be closely co-
ordinated to ensure that business value is delivered and that the
resources are made available to complete the necessary work
• Establish architecture evolution cycle to ensure that the architecture
stays relevant and lessons learned should be documented to enable
continuous process improvement

January 27, 2010 215

Phase F: Migration Planning - Overview
Phase F: Migration Planning

Approach Inputs Steps Outputs

Confirm Management Framework

Reference Materials External to the
Interactions for Implementation and
Enterprise
Migration Plan

Assign a Business Value to Each

Non-Architectural Inputs
Project

Estimate Resource Requirements,

Architectural Inputs Project Timings, and Availability/
Delivery Vehicles

Prioritise the Migration Projects

Through the Conduct of a Cost/
Benefit Assessment and Risk
Validation

Confirm Transition Architecture

Increments/Phases and Update
Architecture Definition Document

Generate the Architecture

Implementation Roadmap (Time-
Lined) and Migration Plan

Establish the Architecture Evolution

Cycle and Document Lessons
Learned
January 27, 2010 216
Phase F: Migration Planning - Inputs
• Reference Materials External to the Enterprise − Draft Architecture Definition Document
− Architecture reference materials • Strategic Migration Plan
• Baseline Business Architecture
• Non-Architectural Inputs • Target Business Architecture
− Request for Architecture Work • Baseline Data Architecture
− Capability Assessment • Target Data Architecture
• Baseline Application Architecture
− Communications Plan • Target Application Architecture
• Architectural Inputs • Baseline Technology Architecture
• Target Technology Architecture
− Organisational Model for Enterprise Architecture • Impact analysis — project list and charters
• Scope of business units impacted
• Maturity assessment, gaps, and resolution approach − Draft Architecture Requirements Specification
• Roles and responsibilities for architecture team(s) • Architectural requirements
• Constraints on architecture work • Gap analysis results (from Business, Data, Application, and
Technology Architecture)
• Budget requirements • IT ser vice management integration requirements
• Governance and support strategy
− Change Requests for existing business programs and
− Governance models and frameworks projects
• Enterprise Architecture Management Framework
• Capability Management Framework
− Consolidated and validated Architecture Roadmap
• Portfolio Management Framework − Capability Assessment
• Project Management Framework • Enterprise Architecture Maturity Profile
• Operations Management FrameworkTechnology principles • Transformation Readiness Report
− Tailored Architecture Framework − Transition Architecture
• Tailored architecture method • Consolidated Gaps, Solutions, and Dependencies Assessment
• Tailored architecture content • Risk Register
• Configured and deployed tools • Impact analysis — project list
− Statement of Architecture Work • Dependency Analysis Report
• Implementation Factor Assessment and Deduction Matrix
− Architecture Vision − Implementation and Migration Plan including the high-
− Architecture Repository level Implementation and Migration Strategy
• Re-usable building blocks
• Publicly available reference models
• Organisation-specific reference models
• Organisation standards

January 27, 2010 217

 Phase F: Migration Planning - Steps
Phase F: Migration
Planning

Estimate Resource Prioritise the Migration Confirm Transition Generate the

Confirm Management Establish the
Requirements, Project Projects Through the Architecture Architecture
Framework Interactions Assign a Business Value Architecture Evolution
Timings, and Conduct of a Cost/ Increments/Phases and Implementation
for Implementation and to Each Project Cycle and Document
Availability/ Delivery Benefit Assessment and Update Architecture Roadmap (Time-Lined)
Migration Plan Lessons Learned
Vehicles Risk Validation Definition Document and Migration Plan

Confirm Organisational
Align Implementation Business Value, Return
Determine Personnel Derive Cost Benefit Confirm the Enterprise
and Migration Plan with on Investment, and Confirm Transition Confirm Enterprise
and Infrastructure Analysis for the Architecture Evolution
Business/ Capability Performance Architecture Time-Spans Architecture Evolution
(Capital) Costs Migration Projects Cycle
Planning Measurement
Parameters

Assign Risk to the Confirm Business Value Confirm the Enterprise

Examine Business Determine Operations Validate the Risk Enterprise Architecture
Projects and Project Delivered by the Architecture
Transformation Aspects and Maintenance Costs Assessment State Evolution
Increments Increments Management Processes

Assess the
Synchronisation of the Assign Business Value to Determine Transition Update Previously
Detailed Implementation Document Lessons
Enterprise Architecture the Projects and Project Architecture/Project Prioritise the Projects Created Architecture
and Migration Plan Learned
and Existing IT Planning Increments Increment Timings Deliverables
Framework

Align Implementation
Determine Continuous
and Migration Plan with Assess Best Delivery Incorporate Project
Business Value
the Project Management Vehicle Schedules
Assessment Technique
Framework

Align Implementation
and Migration Plan with
Plan the Migration
the Operations
Details
Management
Framework

Establish Plans for

Enterprise Architecture
Management

January 27, 2010 218

Phase F: Migration Planning - Steps (1)

• Confirm Management Framework Interactions for Implementation and Migration Plan

− Align Implementation and Migration Plan with Business/Capability Planning
− Examine Business Transformation Aspects
− Assess the Synchronisation of the Enterprise Architecture and Existing IT Planning Framework
− Align Implementation and Migration Plan with the Project Management Framework
− Align Implementation and Migration Plan with the Operations Management Framework
− Establish Plans for Enterprise Architecture Management
• Assign a Business Value to Each Project
− Confirm Organisational Business Value, Return on Investment, and Performance Measurement
Parameters
− Assign Risk to the Projects and Project Increments
− Assign Business Value to the Projects and Project Increments
− Determine Continuous Business Value Assessment Technique
• Estimate Resource Requirements, Project Timings, and Availability/Delivery Vehicles
− Determine Personnel and Infrastructure (Capital) Costs
− Determine Operations and Maintenance Costs
− Determine Transition Architecture/Project Increment Timings
− Assess Best Delivery Vehicle

January 27, 2010 219

Phase F: Migration Planning - Steps (2)

• Prioritise the Migration Projects through the Conduct of a Cost/Benefit Assessment and
Risk Validation
− Derive Cost Benefit Analysis for the Migration Projects
− Validate the Risk Assessment
− Prioritise the Projects
• Confirm Transition Architecture Increments/Phases and Update Architecture Definition
Document
− Confirm Transition Architecture Time-Spans
− Confirm Business Value Delivered by the Increments
− Update Previously Created Architecture Deliverables
• Generate the Architecture Implementation Roadmap (Time-Lined) and Migration Plan
− Confirm Enterprise Architecture Evolution
− Enterprise Architecture State Evolution
− Detailed Implementation and Migration Plan
− Incorporate Project Schedules
− Plan the Migration Details
• Establish the Architecture Evolution Cycle and Document Lessons Learned
− Confirm the Enterprise Architecture Evolution Cycle
− Confirm the Enterprise Architecture Management Processes
− Document Lessons Learned

January 27, 2010 220

Phase F: Migration Planning - Step 1 - Confirm Management
Framework Interactions for Implementation and Migration
Plan (1)
• Establish what the Implementation and Migration Plan should include and ensure
that it is coordinated with the other frameworks
• Four management frameworks that have to work closely together for the
Migration Plan to succeed
− Business Planning - conceives, directs, and provides the resources for all of the
activities required to achieve concrete business objectives/outcomes
− Enterprise Architecture - structures and gives context to all enterprise activities
delivering concrete business outcomes primarily but not exclusively in the IT domain -
currently IT governance addresses many of these requirements
− Portfolio/Project Management - co-ordinates, designs, and builds the business systems
that deliver the concrete business outcomes
− Operations Management - integrates, operates, and maintains the deliverables that
deliver the concrete business outcomes
• Implementation and Migration Plan will impact and consequently have to be
reflected in each one of these frameworks
• Understand the frameworks within the organisation and ensure that these plans
are co-ordinated and inserted within the plans of each one of these frameworks

January 27, 2010 221

Phase F: Migration Planning - Step 1 - Confirm Management
Framework Interactions for Implementation and Migration
Plan (2)
• Align Implementation and Migration Plan with Business/Capability Planning
− Implementation and Migration Plan has to be aligned with the business strategy and plans for all
aspects of the organisation
− View the strategic and business plans from an architecture perspective to determine fitness-for-
purpose
− Determine what can be leveraged from the strategic and business plans and what has to be
inserted as an addition to these plans in the upcoming release cycle
− Focus on the delivery of measurable, incremental business value at the end of each Transition
Architecture
• Examine Business Transformation Aspects
− Strategic business planning should address business transformation, as in virtually all cases of
enterprise architecture implementation there is a significant business transformation element
− Two main components, namely business transformation within and outside the IT lines of service
− Changes within the IT operational infrastructure impact the Implementation and Migration Plan
− Enterprise architecture redirection of effort from maintaining a highly complex and less co-
ordinated infrastructure to one where effort can spent on contributing directly to business value
− Human capital is paramount in a knowledge-based economy and their acceptance of the changes
cannot be taken for granted
− New processes, staff consultations, retraining are critical to the success of the enterprise
architecture

January 27, 2010 222

Phase F: Migration Planning - Step 1 - Confirm Management
Framework Interactions for Implementation and Migration
Plan (3)
• Assess the Synchronisation of the Enterprise Architecture and Existing IT Planning
Framework
− Implementation and Migration Plan is often a subset of the corporate IT strategic and business
plans
− Synchronisation is essential and the need for them to proceed in alignment will be a major change
in working approach for planners used to working without an enterprise architecture framework
− Enterprise architecture provide a context for their activities and provide the essential governance
fit criteria
− Ensure that the Implementation and Migration Plan is well-positioned within the IT business plan
• Align Implementation and Migration Plan with the Project Management Framework
− Every organisation has a deliver y methodology and most have some form of portfolio and project
management framework at differing levels of maturity
− Architecture Definition Document provides a Baseline Architecture, Target Architecture, gap
analysis, and dependencies between building blocks
− Implementation and Migration Plan adds further detail on how the Target Architecture is to be
realised through change activity
− Implementation and Migration Plan has to be embedded within the appropriate delivery vehicle
− Projects are transient delivery vehicles, whereas the enterprise architecture is permanent and
manages the enterprise architecture artifacts delivered by the projects throughout their lifecycle

January 27, 2010 223

Phase F: Migration Planning - Step 1 - Confirm Management
Framework Interactions for Implementation and Migration
Plan (4)
• Align Implementation and Migration Plan with the Operations
Management Framework
− Operations Management function runs the organisation infrastructure and the
minute that an artifact is handed to them it comes under their configuration
management and control
− Operations Management function will have been closely involved in the
establishment of the Baseline Architecture and have been solicited for
recommendations for the Target Architectures
− Implementation and Migration Plan has to cater for the hand-off to the
operations management group and arrange for the co-ordination of the
artifact configuration management
• Establish Plans for Enterprise Architecture Management
− Implementation and Migration Plan sits at the intersection of numerous
technical and management frameworks
− Enterprise architecture framework (established in the Preliminary phase)
should reflect the interactions
− Need to explicitly state how the architecture is to be implemented and
migrated

January 27, 2010 224

Phase F: Migration Planning - Step 2 - Assign a
Business Value to Each Project (1)
• Confirm Organisational Business Value, Return on Investment, and Performance
Measurement Parameters
− Ensure the business value parameters are well-understood and serve as the basis for
the creation and monitoring of the Implementation and Migration Plan
− Enable the generation of continuous business value, even accepting that this might
involve planned rework in subsequent sets of deliverables
− Establish a concrete set of criteria with which to assess the business value, return on
investment, and measures to ascertain how the project is meeting their objectives
• 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 executive stakeholders
• Business Value has to be defined
• Critical Success Factors (CSF) should be established to define success for a project and/or
project increment
• Measures of Effectiveness (MOE) are often performance criteria and many corporations
include them in the CSFs
• Strategic Fit based upon the overall enterprise architecture (all tiers) will be the critical factor
for allowing the approval of any new endeavor (project/initiative or whatever) or deter mining
the value of any deliverable
• Assign Risk to the Projects and Project Increments
− Aggregate the risks associated with each activity for the projects and their potential
increments in the Consolidated Gaps, Solutions, and Dependencies Assessment (from
Phase E)
January 27, 2010 225
Phase F: Migration Planning - Step 2 - Assign a
Business Value to Each Project (2)
• Assign Business Value to the Projects and Project
Increments
− Develop an estimated value to the business for each project
− Should be completed with business management input with the
enterprise architect ensuring that the value of the business
enabling IT infrastructure is well understood
• Determine Continuous Business Value Assessment
Technique
− Assessment could be developed through the use of a matrix
based on a value index dimension and a risk index dimension
− Should be conducted by both business clients and IT

January 27, 2010 226

Phase F: Migration Planning - Step 3 - Estimate Resource
Requirements, Project Timings, and Availability/Delivery
Vehicles (1)
• Determine Personnel and Infrastructure (Capital) Costs
− Determine what the costs will be in terms of personnel and infrastructure
− Ensure that all infrastructure costs are captured, including office space,
furniture, and so on, charging them against the activities or against the project
− Aggregate the SBB costs to come up with a total for capital costs for the project
and project increment and then add this project capital cost to the list of
projects
• Determine Operations and Maintenance Costs
− Costs are associated with the total cost of ownership for a SBB
− Triggered after the SBB has been handed over to operations management from
the project delivery organisation
− Ensure cost estimate will provide sufficient resources available to service the
SBB while in the field, so it should address the entire SBB lifecycle
− Operations and maintenance costs should be added to the SBB construction
cost to give a total cost of ownership
− Total cost of ownership should now be added to the list of projects

January 27, 2010 227

Phase F: Migration Planning - Step 3 - Estimate Resource
Requirements, Project Timings, and Availability/Delivery
Vehicles (2)
• Determine Transition Architecture/Project Increment
Timings
− Create an initial estimate of the time that the projects and project
increments will take
• Assess Best Delivery Vehicle
− Use this estimate to look at the resources available within the
organisation and determine whether the deliver y vehicle should
be internal, external or both

January 27, 2010 228

Phase F: Migration Planning - Step 4 - Prioritise the
Migration Projects through the Conduct of a Cost/Benefit
Assessment and Risk Validation (1)
• Derive Cost Benefit Analysis for the Migration Projects
− Initiate the cost/benefit analysis and drive the return on investment
− Return on investment has to be clear and take into account the stakeholders
for which it is being prepared
− Sensitivity to stakeholders’ concerns is important
− Discover all costs, and ensure that the business deals with the net benefit (cost
savings over time — cost of initiative over time)
• Validate the Risk Assessment
− Review the risks documented in the Gaps, Solutions, and Dependencies Report
− Ensure that the risks for the project artifacts have been mitigated as
− much as possible
− Update the project list with risk-related comments

January 27, 2010 229

Phase F: Migration Planning - Step 4 - Prioritise the
Migration Projects through the Conduct of a Cost/Benefit
Assessment and Risk Validation (2)
• Prioritise the Projects
− Using the previously calculated net benefits, and the Gaps, Solutions, and
Dependencies Analysis get consensus amongst the stakeholders to agree upon
a prioritisation of the projects
− Prioritisation criteria will include the key business drivers identified in Phase E
as well as those relating to individual stakeholders’ agendas
• Reduction of costs
• Consolidation of services
• Ability to handle change
• A goal to have a minimum of interim solutions (as they often become long-
term/strategic)
− Ensure that foundation projects are identified
• Often invisible to the end client but an essential intermediary be understood and
supported by senior management
− List of projects should clearly highlight dependencies
− Stakeholders have to review the risk assessment and revise it as necessary
ensuring that there is a full understanding of the residual risk associated with
the prioritisation and the projected funding line
− Update and reorder the list of projects with their priority

January 27, 2010 230

Phase F: Migration Planning - Step 5 - Confirm Transition
Architecture Increments/Phases and Update Architecture
Definition Document
• Confirm Transition Architecture Time-Spans
− Agree to a time-span of an increment
− Has to take into account the area where the architecture has to be implemented and
the results of the analysis of the organisation list of events and timings
− Affected by planning, budgetary, acqusitions cycles and pre-requisites
• Confirm Business Value Delivered by the Increments
− Review gap analyses, dependencies, and prioritised portfolios/projects
− Validate that discrete business outcomes can be delivered in increments
− Perform at the portfolio level as entire projects may be re-scheduled to allow others to
move forward more rapidly
− Important to align the architectures of the foundation projects to ensure that they
flexibly deliver the requisite support to achieving the business outcomes
• Update Previously Created Architecture Deliverables
− If the implementation approach has shifted as a result of confirming the
implementation increments, update the Transition Architectures to reflect the revised
direction
− Update the Architecture Definition, assigning project objectives and aligning projects
and their deliverables with the enterprise architecture increments
− The enterprise Architecture Definition is technology-aware but, as much as possible,
technology-independent

January 27, 2010 231

Phase F: Migration Planning - Step 6 - Generate the
Architecture Implementation Roadmap (Time-Lined) and
Migration Plan (1)
• Confirm Enter prise Architecture Evolution
− Confirm the actual evolution of the architecture to co-ordinate the development of
several concurrent instances of the various architectures
− Resources have to be assigned to move the architectures ahead in a coherent manner
− Take advantage of opportunities and innovations as well as coping with significant
business events
• Enterprise Architecture State Evolution
− Implementation and Migration Plan will show the proposed state of the architectures at
various levels of detail depending upon how far in the future the snapshot is
− Use the Technical Reference Model to shows how the capabilities in each area evolve
through the Transition Architectures
• Detailed Implementation and Migration Plan
− In Phase E and in previous steps within Phase F, most of the portfolio planning actions
will have been completed and this step brings all the detail together into an overall plan
− Formally integrate all of the projects, project increments, and activities as well as
dependencies into a project plan
− Ensure that all external dependencies are captured and included
− Conduct resource leveling to ascertain the overall availability of resources with
precedence being given to the priorities previously allocated
− Determine what can be done internally or externally with contract support

January 27, 2010 232

Phase F: Migration Planning - Step 6 - Generate the
Architecture Implementation Roadmap (Time-Lined) and
Migration Plan (2)
• Incorporate Project Schedules
− Roll-up plans (in part or in their entirety) into the Implementation and
Migration Plan
− Assess and adjust to ensure that the plan has the best chance for success
− Create finalised Implementation and Migration Plan
• Plan the Migration Details
− A building block is delivered when it becomes part of the corporate
infrastructure and handed over to the operations management function
− Migration Plan focuses on the actual handover of the constructed building
blocks and their integration into the infrastructure
− Migration Plan must cater for the ongoing operations and maintenance of the
delivered building block
− Ensure that either the project and/or operations management have the
resources to ensure that the building block is effectively sustained
− Important that deliverables are quickly but systematically placed into service
January 27, 2010 233
Phase F: Migration Planning - Step 7 - Establish the
Architecture Evolution Cycle and Document Lessons
Learned
• Confirm the Enterprise Architecture Evolution Cycle
− Ensure that the architecture remains relevant and provides the critical
guidance to the projects designing and delivering the SBBs
− No point in creating a family of architecture artifacts that are not being
maintained as they will become obsolete relatively quickly
− Has to be a regular update mechanism built into the architecture
transformation process
• Confirm the Enterprise Architecture Management Processes
− Release management is important so that all parties are able to contribute in a
timely manner
− Configuration management is also critical to ensure that the Enterprise
Continuum and architectures are co-ordinated and that the architectures
accurately reflect current and planned reality
• Document Lessons Learned
− Document lessons learned and treat as governance artifacts
− Action via change requests, or changes in processes, business units or
whatever is needed to improve the development and implementation of
enterprise architecture

January 27, 2010 234

Phase F: Migration Planning - Outputs

• Implementation and Migration Plan

• Finalised Architecture Definition Document
• Finalised Architecture Requirements Specification
• Finalised Architecture Roadmap
• Finalised Transition Architecture
• Re-Usable Architecture Building Blocks
• Requests for Architecture Work for the architecture aspects of
implementation projects
• Architecture Contracts for implementation projects
• Implementation Governance Model
• Change Requests arising from lessons learned
January 27, 2010 235
Phase G: Implementation Governance -
Objectives
• To formulate recommendations for each implementation project
• To govern and manage an Architecture Contract covering the overall
implementation and deployment process
• To perform appropriate governance functions while the solution is
being implemented and deployed
• To ensure conformance with the defined architecture by
implementation projects and other projects
• To ensure that the program of solutions is deployed successfully as a
planned program of work
• To ensure conformance of the deployed solution with the Target
Architecture
• To mobilise supporting operations that will underpin the future
working lifetime of the deployed solution

January 27, 2010 236

Phase G: Implementation Governance - Approach

• Bring together information for successful management of the various

implementation projects
• Deploy the Target Architecture as a series of transitions to enable early realisation
of business value and benefits, and to minimise the risk
• Overall approach
− 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 organisation’s standard for corporate, IT, and architecture governance
− Use the organisation’s established portfolio/program management approach, where
this exists
− Define an operations framework to ensure the effective long life of the deployed
solution
• Establish the connection between architecture and implementation organisation,
through the Architecture Contract
• Ensure compliance with the defined architecture(s), not only by the
implementation projects but also by other ongoing projects within the enterprise

January 27, 2010 237

Phase G: Implementation Governance - Overview
Phase G: Implementation
Governance

Approach Inputs Steps Outputs

Confirm Scope and Priorities for

Reference Materials External to
Deployment with Development
the Enterprise
Management

Identify Deployment Resources

Non-Architectural Inputs
and Skills

Guide Development of Solutions

Architectural Inputs
Deployment

Perform Enterprise Architecture

Compliance Reviews

Implement Business and IT

Operations

Perform Post-Implementation
Review and Close the
Implementation
January 27, 2010 238
Phase G: Implementation Governance - Inputs

• Reference Materials External to the Enterprise − Architecture Definition Document

− Architecture reference materials − Architecture Requirements Specification
• Architectural requirements
• Non-Architectural Inputs • Gap analysis results (from Business, Data,
− Request for Architecture Work Application, and Technology Architectures)
− Capability Assessment − Architecture Roadmap
• Architectural Inputs − Transition Architecture
− Implementation Governance Model
− Organisational Model for Enterprise Architecture
• Scope of business units impacted
− Architecture Contract
• Maturity assessment, gaps, and resolution approach − Request for Architecture Work
• Roles and responsibilities for architecture team(s) − Implementation and Migration Plan
• Constraints on architecture work
• Budget requirements
• Governance and support strategy
− Tailored Architecture Framework
• Tailored architecture method
• Tailored architecture content
• Configured and deployed tools
− Statement of Architecture Work
− Architecture Vision
− Architecture Repository
• Re-usable building blocks
• Publicly available reference models
• Organisation-specific reference models
• Organisation standards

January 27, 2010 239

Phase G: Implementation Governance - Steps

• Confirm Scope and Priorities for Deployment with

Development Management
• Identify Deployment Resources and Skills
• Guide Development of Solutions Deployment
• Perform Enterprise Architecture Compliance Reviews
• Implement Business and IT Operations
• Perform Post-Implementation Review and Close the
Implementation

January 27, 2010 240

Phase G: Implementation Governance - Step 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
− Identify the gaps in the existing enterprise solutions framework
− Identify the specific Solution Building Blocks (SBBs) required to fill these gaps
will be the identified by the solutions architects
• Produce a gap analysis report

January 27, 2010 241

Phase G: Implementation Governance - Step 2 -
Identify Deployment Resources and Skills
• Educate the development resources in the overall
enterprise architecture deliverables and expectations from
the specific development and implementation projects
• Identify system development methods required for
solutions development
• Ensure that the systems development method enables
feedback to the architecture team on designs

January 27, 2010 242

Phase G: Implementation Governance - Step 3 -
Guide Development of Solutions Deployment
• Formulate project recommendation
• For each separate implementation and deployment project
− 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 organisations and sponsoring organisation
• Update Enterprise Continuum directory and repository for solutions
• Guide development of business and IT operating models for services
• Provide service requirements derived from enterprise architecture
• Guide definition of business and IT operational requirements
• Carry out gap analysis between the Solution Architecture and operations
• Produce Implementation Plan

January 27, 2010 243

Phase G: Implementation Governance - Step 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

January 27, 2010 244

Phase G: Implementation Governance - Step 5 -
Implement Business and IT Operations
• Carry out the deployment projects including:
− IT services delivery implementation
− Business services delivery implementation
− Skills development and training implementation
− Communications documentation publication
• Publish new Baseline Architectures to the Architecture
Repository and update other impacted repositories, such
as operational configuration management stores

January 27, 2010 245

Phase G: Implementation Governance - Step 6 - Perform
Post-Implementation Review and Close the Implementation

• Conduct post-implementation reviews

• Publish reviews and close projects

January 27, 2010 246

Phase G: Implementation Governance - Outputs

• Architecture Contract
• Compliance Assessments
• Change Requests
• Architecture-compliant solutions deployed including:
− The architecture-compliant implemented system
− Populated Architecture Repository
− Architecture compliance recommendations and dispensations
− Recommendations on service delivery requirements
− Recommendations on performance metrics
− Ser vice Level Agreements (SLAs)
− Architecture Vision, updated post-implementation
− Architecture Definition Document, updated post-implementation
− Transition Architecture, updated post-implementation
− Business and IT operating models for the implemented solution

January 27, 2010 247

Phase H: Architecture Change Management -
Objectives
• To ensure that baseline architectures continue to be fit-for-purpose
• To assess the performance of the architecture and make
recommendations for change
• To assess changes to the framework and principles set up in previous
phases
• To establish an architecture change management process for the
new enterprise architecture baseline that is achieved with
completion of Phase G
• To maximise the business value from the architecture and ongoing
operations
• To operate the Governance Framework

January 27, 2010 248

Phase H: Architecture Change Management –
Approach (1)
• Ensure that the architecture achieves its original target business
value
• Manage changes to the architecture in a cohesive and architected
way
• Provide for the continual monitoring of such things as governance
requests, new developments in technology, and changes in the
business environment
• Establish and support the implemented enterprise architecture as a
dynamic architecture
• Monitor business growth and changes
• Implement capacity measurement and recommendations for
planning
• Establish a value and change management process

January 27, 2010 249

Phase H: Architecture Change Management –
Approach (2)
• Drivers for Change
− Enterprise architecture does not operate in a vacuum - there is usually an existing
infrastructure and business which is already providing value
− Approaches to change
• 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
− Enterprise architecture takes a strategic top-down approach to change
− A lessons learned process ensures that mistakes are made once and not repeated
− Many technology-related drivers for architecture change
• New technology reports
• Asset management cost reductions
• Technology withdrawal
• Standards initiatives
− Business drivers for architecture change
• Business-as-usual developments
• Business exceptions
• Business innovations
• Business technology innovations
• Strategic change

January 27, 2010 250

Phase H: Architecture Change Management –
Approach (3)
• Enterprise Architecture Change Management Process
− Enterprise architecture change management process needs to
determine how changes are to be managed, what techniques are
to be applied, and what methodologies used
− Process also needs a filtering function that determines which
phases of the architecture development process are impacted by
requirements
− Classify 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
• Re-architecting Change: A re-architecting change requires putting the
whole architecture through the architecture development cycle again

January 27, 2010 251

Phase H: Architecture Change Management –
Approach (4)
• Guidelines for Maintenance versus Architecture Redesign
− 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
− 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
January 27, 2010 252
Phase H: Architecture Change Management -
Overview Phase H: Architecture Change
Management

Approach Inputs Steps Outputs

Drivers for Change Reference Materials External to the

Establish Value Realisation Process
Enterprise

Enterprise Architecture Change

Management Process Non-Architectural Inputs Deploy Monitoring Tools

Guidelines for Maintenance

versus Architecture Redesign Architectural Inputs Manage Risks

Provide Analysis for Architecture

Change Management

Develop Change Requirements to

Meet Performance Targets

Manage Governance Process

Activate the Process to Implement

Change
January 27, 2010 253
Phase H: Architecture Change Management - Inputs

• Reference Materials External to the Enterprise − Architecture Definition Document

− Architecture reference materials − Architecture Requirements Specification
• Architectural requirements
• Non-Architectural Inputs • Gap analysis results (from Business, Data,
− Request for Architecture Work identified during Application, and Technology Architectures)
Phases E and F − Architecture Roadmap
• Architectural Inputs − Change Request - technology changes
• New technology reports
− Organisational Model for Enterprise Architecture • Asset management cost reduction initiatives
• Scope of business units impacted
• Technology withdrawal reports
• Maturity assessment, gaps, and resolution approach
• Standards initiatives
• Roles and responsibilities for architecture team(s)
• Constraints on architecture work − Change Request - business changes
• Budget requirements • Business developments
• Governance and support strategy • Business exceptions
• Business innovations
− Tailored Architecture Framework • Business technology innovations
• Tailored architecture method
• Strategic change developments
• Tailored architecture content
• Configured and deployed tools − Change Request
− Statement of Architecture Work − Transition Architecture
− Architecture Vision − Implementation Governance Model
− Architecture Repository − Architecture Contract
• Re-usable building blocks − Compliance Assessments
• Publicly available reference models − Implementation and Migration Plan
• Organisation-specific reference models
• Organisation standards

January 27, 2010 254

Phase H: Architecture Change Management - Steps

• Establish Value Realisation Process

• Deploy Monitoring Tools
• Manage Risks
• Provide Analysis for Architecture Change Management
• Develop Change Requirements to Meet Performance
Targets
• Manage Governance Process
• Activate the Process to Implement Change

January 27, 2010 255

Phase H: Architecture Change Management - Step 1
- Establish Value Realisation Process
• Influence business projects to exploit the enterprise
architecture for value realisation

January 27, 2010 256

Phase H: Architecture Change Management - Step 1
- Establish Value Realisation Process
• Influence business projects to exploit the enterprise
architecture for value realisation

January 27, 2010 257

Phase H: Architecture Change Management - Step 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 quality of service performance and usage
− Determine and track business continuity requirements

January 27, 2010 258

Phase H: Architecture Change Management - Step 3
- Manage Risks
• Manage enterprise architecture risks and provide
recommendations for IT strategy

January 27, 2010 259

Phase H: Architecture Change Management - Step 4 -
Provide Analysis for Architecture Change Management

• Provide analysis for architecture change management:

− Analyse performance
− Conduct enterprise architecture performance reviews with
service management
− Assess Change Requests and reporting to ensure that the
expected value realisation and Service Level Agreement (SLA)
expectations of the customers are met
− Under take a gap analysis of the performance of the enterprise
architecture
− Ensure change management requests adhere to the enterprise
architecture governance and framework

January 27, 2010 260

Phase H: Architecture Change Management - Step 5 -
Provide Analysis for Architecture Change Management

• Make recommendations on change requirements to meet

performance targets and development of position to act

January 27, 2010 261

Phase H: Architecture Change Management - Step 6
- Manage Governance Process
• Manage governance process and framework for
architecture:
− Arrange meetings of Architecture Board
− Hold meetings of the Architecture Board with the aim of the
meeting to decide on handling changes (technology and business
and dispensations)

January 27, 2010 262

Phase H: Architecture Change Management - Step 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

January 27, 2010 263

Phase H: Architecture Change Management -
Outputs
• Architecture updates (for maintenance changes)
• Changes to architecture framework and principles (for
maintenance changes)
• New Request for Architecture Work to move to another
cycle (for major changes)
• Statement of Architecture Work updated if necessary
• Architecture Contract updated if necessary
• Compliance Assessments updated if necessary

January 27, 2010 264

Using TOGAF Effectively

January 27, 2010 265

Using TOGAF

• Can use TOGAF at various levels to perform partial or

complete architecture exercises
− Define architecture practice
− Produce high-level strategic architecture
− Produce domain architectures
− Produce solution architectures
• Options and approaches discussed in Preliminary Phase of
this document

January 27, 2010 266

Four Dimensions that Define the Scope of the
Architecture
• Enterprise Scope and Focus
− How much should the full extent of the enterprise should the
architecting effort cover
• Architecture Domains
− Which of the four architecture domains - business, data,
application, technology - should be covered
• Vertical Scope or Level of Detail
− What level of detail should the architecting effort encompass
• Time Period
− What is the architecture needed and what time is available
• Very important to explicitly define and understand as
these dimensions affect all subsequent effort
January 27, 2010 267
Reasons for Limiting the Scope of the Architecture

• Reducing the scope of the architecture from a top-down,

all-inclusive architecture description encompassing all four
architecture domains
− Limiting the scope of the architectural activity
− 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

January 27, 2010 268

Dimension - Time Period

• Split Target Architecture into two (or more) stages

− Develop Target Architecture descriptions for the overall system,
demonstrating a response to stakeholder objectives and concerns
for a longer timeframe
− Develop one or more ‘Transition Architecture descriptions
incrementally converging on the Target Architecture
• Target Architecture requires periodic review and update
according to evolving business requirements and
developments in technology
• Transition Architectures are incremental and should not
evolve during the implementation phase of the increment

January 27, 2010 269

Using TOGAF Effectively

• Key Components • Phases

− Architecture Content – Preliminary − Preliminary Phase and Phase A
− Architecture Definition − Phases B – F
− Information Systems Definition – − Phases C, C1 and C2
Solutions/Applications and Data
− Transition Planning − Phases E and F
− Architecture Governance − Phases G and H

January 27, 2010 270

TOGAF Iterations

• Perform TOGAF components iteratively to produce

complete architecture
• Create Architecture Vision as a platform and justification
for moving forward
• Create Baseline and Target Architectures
• Create Transition Architecture(s)
• Incrementally move towards Target Architectures
• Establish Architecture Governance

January 27, 2010 271

 1
TOGAF Iterations Preliminary Architecture
Content 1
Iteration
Architecture
Definition 2
Iteration
5 A. Architecture 2
Architecture 5 Vision
Governance H. Architecture
Iteration B. Business
Change
Architecture
Management

3
G. C. Information
Requirements
Implementation Systems
Management Architecture
Governance

Information
Systems
F. Migration D. Technology Definition –
Planning Architecture Solutions/
E. Applications
Opportunities and Data
and Solutions Iteration
3
Transition 4
4 Planning
Iteration
January 27, 2010 272
 Baseline First Architecture Definition
Architecture Content Architecture Definition Transition Planning Architecture Governance
Iteration Iteration Iteration Iteration
Initial
TOGAF Phase Iteration 1 Iteration 2 Iteration n Iteration 1 Iteration n Iteration 1 Iteration n
Iteration
Preliminary Primary Other Other Other Secondary

A. Architecture Vision Primary Other Other Other Other Other Secondary

Business Baseline Other Primary Secondary Primary Other Other Secondary

Architecture Target Other Other Primary Primary Other Other Secondary

Application Baseline Other Primary Secondary Primary Other Other Secondary

Architecture Target Other Other Primary Primary Other Other Secondary

Data Baseline Other Primary Secondary Primary Other Other Secondary

Architecture Target Other Other Primary Primary Other Other Secondary

Technology Baseline Other Primary Secondary Primary Other Other Secondary

Architecture Target Other Other Primary Primary Other Other Secondary
Opportunities and
Other Secondary Secondary Secondary Primary Primary Other Other
Solutions
Migration Planning Other Secondary Secondary Secondary Primary Primary Other Other
Implementation
Other Other Primary Primary
Governance
Architecture Change
Other Other Other Other Other Primary Primary
Management
January 27, 2010 273
Baseline First Architecture Definition

• Activities
− Primary steps are the main focus for activity for the iteration
− Secondary steps are the subsidiary focus for activity for the
iteration
− Other steps are the potential activities for the iteration

January 27, 2010 274

 Target First Architecture Definition
Architecture Content Architecture Definition Transition Planning Architecture Governance
Iteration Iteration Iteration Iteration
Initial
TOGAF Phase Iteration 1 Iteration 2 Iteration n Iteration 1 Iteration n Iteration 1 Iteration n
Iteration
Preliminary Primary Other Other Other Secondary

A. Architecture Vision Primary Other Other Other Other Other Secondary

Business Baseline Other Other Primary Primary Other Other Secondary

Architecture Target Other Primary Secondary Primary Other Other Secondary

Application Baseline Other Other Primary Primary Other Other Secondary

Architecture Target Other Primary Secondary Primary Other Other Secondary

Baseline Other Other Primary Primary Other Other Secondary

Data
Architecture Target Other Primary Secondary Primary Other Other Secondary

Technology Baseline Other Other Primary Primary Other Other Secondary

Architecture Target Other Primary Secondary Primary Other Other Secondary
Opportunities and
Other Secondary Secondary Secondary Primary Primary Other Other
Solutions
Migration Planning Other Secondary Secondary Secondary Primary Primary Other Other
Implementation
Other Other Primary Primary
Governance
Architecture Change
Other Other Other Other Other Primary Primary
Management
January 27, 2010 275
Target First Architecture Definition

• Activities
− Primary steps are the main focus for activity for the iteration
− Secondary steps are the subsidiary focus for activity for the
iteration
− Other steps are the potential activities for the iteration

January 27, 2010 276

Establishment of an Enterprise Architecture
Function

January 27, 2010 277

Establish a Successful Enterprise Architecture
Program Office
• Staff the Program Office
− Typically a set of roles working closely with functional staff and system
developers
• Chief Architect
• Business Architect
• Systems Architect
• Data Architect
• EA Tool Expert
• Depending on the size of the organisation, roles can be shared
− Ensure staff are qualified and trained
• Identify other stakeholders
− Sponsor - Champion of the Enterprise Architecture program and ensures
resources
− Business Manager - Participates in Enterprise Architecture decisions and
promotes Enterprise Architecture solutions
− Business End-Users - Identifies requirement and provides feedback on results
of solutions
− CIO - Executive leader and primary Enterprise Architecture decision maker
− Other Chief Architects of related businesses
January 27, 2010 278
Determine the purpose of Enterprise Architecture

• Unique to each organisation

• Helps answer some other questions that will need to be
answered for future decisions
• Helps determines the depth and breadth of the Enterprise
Architecture effort
• Create an Enterprise Architecture charter
− Similar to one for projects
− Short, concise but informative
− Obtain signatures

January 27, 2010 279

Establish Enterprise Architecture Governance

• How will conflicts be resolved?

• How will changes be approved?
• Who will approve changes?
• How will versions be controlled?
• How will the Enterprise Architecture be enforced?
• How often will Enterprise Architecture documents be re-
published?

January 27, 2010 280

Develop an Enterprise Architecture Management Plan

• Document the organisation’s:

− Summary of the current and future architecture
− Performance gaps,
− Planned solutions
− Resource requirements,
− Enterprise Architecture management process
− Enterprise Architecture implementation methodology
− Enterprise Architecture framework
• Living document
• Updated at regular intervals (annually)
• Placed under version control
• Sequencing sub-plan section:
− Tasks
− Milestones
− Timeframes for implementing new Enterprise Architecture components and artifacts
− May have dependencies

January 27, 2010 281

Critical Steps

• Develop a Communications Plan

• Build templates and offer good examples
• Obtain buy-in from participants
• Manage stakeholders
• Use Enterprise Architecture for management decisions
− Analysis tools
− Decision support tools

January 27, 2010 282

Develop and Discuss the Architecture Vision

• The Architecture Vision phase of TOGAF includes

− Creating an initial description of the architecture
− Developing a Vision Statement to sell the architecture
• Discuss the initial description
− Be prepared for it to include changes to business processes or
even principles

January 27, 2010 283

Agree the Scope of the Architecture Work

• What systems/business units/geographical locations does

the architecture cover?
• Does the work include definition and supervision of
implementation projects?
• Does it include responsibility for detailed implementation
planning?
• Does it include definition of implementation governance
procedures?

January 27, 2010 284

Agree How You Will Accept the Architecture Work

• What are the deliverables?

• How will they be accepted?

January 27, 2010 285

Enterprise Architect

• The architect must address stakeholder concerns

• Talk to all stakeholders
− The architect needs to talk to everybody concerned with Enterprise
Architecture and any new systems
• Users
• Customers
• Developers
• Operations staff
• Management staff (including security)
• Build models to show the system from different viewpoints
− Cost
− Functionality
− Software design
• Crucial role
− Enterprise IT Architecture requires skill and judgement
− It can have a major impact on the business
− You should look for someone with professional standing
January 27, 2010 286
Enterprise Architecture Roles

Technology and Business and

Infrastructure Solution
Architecture Architecture
Skills Skills

Infrastructure Architecture Skills Business and Solution Architecture

Skills
Architectural frameworks, network
topology, directories, naming The Solutions Architect
infrastructure, operations, storage, Frameworks, methodologies, patterns,
backup and recovery, security SDLC, business processes, metadata,
integrated, business process
Work closely with operations management, modeling languages

Create architecture that requires

development to be viable

January 27, 2010 287

Business and Solution Architecture Skills

• Business and Solution Architecture role uses the specifications provided by Enterprise
Architecture to create a viable solution that considers and leverages existing infrastructure
and intellectual property to design a viable solution to support the corporate business
needs
• Awareness of business and solutions constraints
− Creates and manages a strategy, not based on a single technology or vendor. Specifies the
technology, builds consensus around the architectural solution, and works closely with the
technical developers/engineers to ensure proper implementation of the solution
− Knowledge of the physical and logical components:
− Demonstrates understanding of software and solutions patterns, data and metadata structures,
enterprise application integration solutions, business process management, modeling languages,
ISV and vertical software solutions, and SDLC
− Communication (written, verbal, and visual) of the business case:
− Participates in the creation and justification of a business case, defends why a solution is selected
and how it will be implemented using both formal and informal communication mechanisms
− Ownership of solutions architecture:
− Creates the architecture that meets and grows with the business needs and provides services for
the present and future
− Drives to completion the implementation of the architectural solution
− Demonstrates passion for solutions, processes, or technologies

January 27, 2010 288

Technology and Infrastructure Architecture Skills

• Technology Architecture role leverages the specifications provided by Enterprise

Architecture to create an infrastructure that supports the needs of the business
and provides input to the solutions architect with the constraints and tradeoffs
needed to create a viable solution
• Awareness of business and solutions constraints
− Creates and manages a strategy, not based on a single technology or vendor. Specifies
the technology, builds consensus around the architectural solution, and works closely
with the systems architects to ensure proper implementation of the infrastructure
− Knowledge of the physical and logical components:
− Demonstrates understanding of network topology, naming infrastructure, architectural
frameworks, storage, backup and recovery, directories, management frameworks,
repositories, monitoring, security, and ability to apply processes
− Communication (written, verbal, and visual) of the business case:
− Participates in the creation and justification of a business case, defends why an
infrastructure solution is selected and how it will be implemented using both formal
and informal communication mechanisms
− Ownership of infrastructure architecture:
− Creates the architecture that meets and grows with the business needs and provides
services for the present and future
− Drives to completion the implementation of the architecture
− Demonstrates passion for the solutions, processes, or technologies

January 27, 2010 289

Enterprise Architect Skills

• Technology - understanding of system components and their

characteristics, interfaces, and relationships when applied in specific
structures, as well as associated efforts and methods
• Strategy - ability to design a system to instantiate the enterprise
architecture and facilitate the building of a future technology vision
and providing forward thinking guidance
• Leadership - ability to influence an organization down a path of
change as well as be a catalyst for change
• Communication - ability to translate and sell the vision and applied
technology to the various stakeholders
• Organisational Dynamics - awareness of the stakeholders and
implications on them and the organisation of implementing the
vision
• Tactical/Process - shepherding the day-to-day implementation of
the architectural vision

January 27, 2010 290

Enterprise Architect Skills
Technology and Business and Solution
Infrastructure Architecture Skills
Architecture Skills

Technology Technology
Strategy Strategy
Leadership Leadership
Communication Communication
Organisational Dynamics Organisational Dynamics
Tactical / Process Tactical / Process

January 27, 2010 291

Technology and Infrastructure Architecture Skills -
Technology
− Technology: understanding of infrastructure system components
and their characteristics when applied in specific structures,
associated efforts and methods
• Technology in depth
− Understanding and application of core technologies in depth (e.g.
storage services, network services, infrastructure services, management
services, information worker services, etc.)
− Ability to quickly gain depth.
• Technology in breadth
− Ability to wisely employ architectural best practices
− Have a conceptual knowledge of multiple technologies
− Know what is coming in technology and how it could be managed
− Ability to rationalise and apply the relationship between the
infrastructure architecture and the enterprise architecture, in addition
to the enterprise architect framework used

January 27, 2010 292

Technology and Infrastructure Architecture Skills -
Strategy
• Strategy: ability to design the infrastructure to support the
enterprise architecture and facilitate the building of a future
technology vision and providing forward thinking guidance
− Synthesise industry-specific trends with respect to IT
− Align the architecture to the enterprise framework in use (e.g. TOGAF,
Zachman, IEEE 1471, BAIT)
− Operational excellence and operational frameworks (MOF, ITIL, etc.)
− IT Project portfolio management (project fits the business), balancing tactical
requirements against strategic needs
− Balance between users, management, operations, support, and finance that
meets the strategic needs of the business.
− Apply/integrate the value of project management frameworks and best
practices (MSF, PMBOK, etc.)

January 27, 2010 293

Technology and Infrastructure Architecture Skills -
Leadership
• Leadership: ability to influence an organisation down a
path of change as well as be a catalyst for change
− Able to ask thought-provoking questions that translate into
actionable technological patterns/solutions
− Actively mentor others
− Provide thought leadership by enabling others to see things from
a different and better perspective
− Influence decision makers
− Champion structure, process, best practices and standards
− Promote the capture and reuse of intellectual capital
− Effective in building mutual partnerships and networks with
parties or organizations

January 27, 2010 294

Technology and Infrastructure Architecture Skills -
Communication
• Communication: ability to translate the vision and applied
technology to the various stakeholders
− Effective listener and astute observer
− Communicate effectively and persuasively at the audience level
(executive, technical, etc.)
− Effective mediator/conflict management
− Able to document designs and specifications (adhering to
company practices)
− Communicate infrastructure constraints to solutions architects
− Able to effectively facilitate meetings

January 27, 2010 295

Technology and Infrastructure Architecture Skills -
Organisational Dynamics
• Organisational Dynamics: recognising the stakeholders and
understanding the implications on them and the
organization when implementing the vision
− Adeptly maneuver through politically-charged organisational
situations
− Effective in building mutual partnerships and networks with
parties or organisations
− Relationships with other architects and project stakeholders
− Have an awareness of the internal legal organisation and ensure
legal guidelines are met
− Be comfortable with compromise and conflict

January 27, 2010 296

Technology and Infrastructure Architecture Skills -
Tactical / Process
• Tactics: Shepherding the day-to-day implementation of the
architectural vision
− Gather and analyse requirements (technical, business)
− Envision and create an infrastructure that can be implemented, and that meets
requirements
− Model the pieces of the infrastructure and their relationships, communication
semantics, etc.
− Prototype and prove the feasibility of the design
− Create the design artifacts that are required to deliver and to maintain the
infrastructure
− See an infrastructure through to completion
• Audit compliance with the letter and intent of the architecture
• Review the ongoing implementation for opportunities for improvement
• Refine the model as requirements change, implementation choices play out, etc.
− Contribute to technical project management

January 27, 2010 297

Business and Solution Architecture Skills -
Technology
• Technical Skills: understanding of technologies and their
characteristics when applied to a specific business context
− Technology in Depth
• Understand the application of
− Current and future relevant vendor offerings and associated costs
• Implementation frameworks, blueprints, patterns, prescriptive
architectures
− Technology in Breadth
• Apply architectural and engineering concepts to create a solution that is
appropriately scalable, maintainable, securable, reliable, extensible,
flexible, available, manageable, etc.
• Able to think abstractly
• Understand the capabilities and constraints of the infrastructure
• Demonstrate broad development skills
• Able to quickly learn new concepts and gain expertise

January 27, 2010 298

Business and Solution Architecture Skills - Strategy

• Strategy: ability to design and support a future technology

vision for the business problem domain
− Understand business strategy
− Have industry knowledge of a specific industry
− Create solution road map
− Recognise industry trends
− Know the product roadmap for relevant vendors
− Determine vendor pricing impact on solutions

January 27, 2010 299

Business and Solution Architecture Skills -
Leadership
• Leadership: ability to influence an organization down a
path of change as well as be a catalyst for change
− Able to ask thought-provoking questions that translate into
actionable technological patterns/solutions
− Actively mentor others
− Provide thought leadership by enabling others to see things from
a different and better perspective
− Influence decision makers
− Champion structure, process, best practices and standards
− Promote the capture and reuse of intellectual capital
− Effective in building mutual partnerships and networks with
parties or organizations

January 27, 2010 300

Business and Solution Architecture Skills -
Communication
• Communication: ability to translate the vision and applied
technology to the various stakeholders
− Effective listener and astute observer
− Communicate effectively and persuasively at the audience level
(executive, technical, etc.)
− Effective mediator/conflict management
− Able to document designs and specifications (adhering to
company practices)
− Communicate infrastructure constraints to solutions architects
− Able to effectively facilitate meetings

January 27, 2010 301

Business and Solution Architecture Skills -
Organisational Dynamics
• Organisational Dynamics: recognizing the stakeholders and
understanding the implications on them and the
organization when implementing the vision
− Adeptly maneuver through politically-charged organizational
situations
− Effective in building mutual partnerships and networks with
parties or organizations
− Relationships with other architects and project stakeholders
− Have an awareness of the internal legal organization and ensure
legal guidelines are met
− Be comfortable with compromise and conflict

January 27, 2010 302

Business and Solution Architecture Skills - Tactical /
Process
• Tactical/ Process: Identify, select and implement the appropriate methodology for
delivering solutions
− Gather and analyse requirements (technical, business)
− Envision and create a solution that can be implemented, and that meets requirements
− Create the design artifacts that are required to deliver and to maintain the solution
− Model the pieces of the solution and their relationships, communication semantics, etc.
− See a solution through to completion
• Audit compliance with the letter and intent of the architecture
• Review the ongoing implementation for opportunities for improvement
• Refine the model as requirements change, implementation choices play out, etc.
• Learn from positives and negatives that result from the solution
− Contribute to technical project management
• Manage change
• Assess and mitigate risks
• Customize the process to the current environment/context
• Estimate development effort
• Identify and manage key technology constraints

January 27, 2010 303

More Information

Alan McSweeney
alan@alanmcsweeney.com

January 27, 2010 304