TOGAF v9.1 Foundation and Certified - QA · TOGAF Foundation and Certified ... introduce delegates to The Open Group Architecture Framework ... Enterprise Architecture purpose is

TOGAF9FC v1.8

TOGAF® v9.1

Foundation and Certified Level 1 and 2

TOGAF Foundation and Certified TOGAF9FC v1.8

Contents Introduction 1

Basic Concepts 4

Core Concepts 13

Introduction to the ADM 21

The Enterprise Continuum 27

Architecture Repository 32

Architecture Content Framework 37

Content Metamodel 40

Preliminary Phase 43

Governance 54

Business Scenarios and Business Goals 64

Architecture Views and Viewpoints 68

Stakeholder Management 72

Building Blocks 75

Phase A – Architecture Vision 78

Phase B – Business Architecture 88

Phase C – Information Systems Architecture 98

Phase C – Data Architecture 100

Phase C – Application Architecture 105

Phase D – Technology Architecture (and TRM/III-RM) 110

Technical Reference Model – TRM 115

Integrated Information Infrastructure Reference Model – III-RM 117

Phase E – Opportunities and Solutions 120

Phase F – Migration Planning 125

Phase G – Implementation Governance 132

Phase H – Change Management 137

Requirements Management 141

Architecture Partitioning 143

Adapting the ADM 145

Architecture Maturity Models 153

Architecture Skills Framework 156

Copyright Notice

Includes extracts from the TOGAF® 9.1 Framework

Copyright © 2011 The Open Group


1

Introduction

General Information

Safety

Security

Course Times

Breaks

Rooms

About You

Name

Company

Role and Responsibilities

Architecture experience

Objectives for attending course

Other Courses attended

Objectives

The key objective of this course is to introduce delegates to The Open Group Architecture Framework – TOGAF, and to provide sufficient information for them to gain Foundation and Certified status, by taking the necessary exams

Note: Exams can be taken at the convenience of the delegate via Prometric


2

Timetable

Day 1

Course Introduction

Basic Concepts

Core Concepts and Reference Models

An Introduction to the ADM

The Enterprise Continuum

The Architecture Repository

The Architecture Content Framework

The Architecture Metamodel

Day 2

The Preliminary Phase

Architecture Governance

Business Scenarios

Architecture View and Viewpoints

Stakeholder Management

Building Blocks and the ADM

Day 3

Phase A: Architecture Vision

Phase B: Business Architecture

Phase C: Information System Architecture

Phase C – Data Architecture

Phase C – Application Architecture

Phase D: Technology Architecture

Phase E: Opportunities and Solutions

Phase F: Migration Planning

Day 4

Phase G: Implementation Governance

Phase H: Architecture Change Management

Requirements Management

Architecture Partitioning

Adapting the ADM

Maturity Models

Skills Framework

Exam Preparation


3

Course Material

The content of the course has been guided by a syllabus published by The Open Group

The material has been through, and passed, a formal accreditation process undertaken by The Open Group

It consists of:

o Course Manual

o Reference Cards

o Selected Extracts from Framework

o Sample Foundation and Certified Exams

o Additional sample questions

o Case Study for use during course

o Sample answer to case study

Exam Process

The Combined Exam is included as part of the course fee

The exams are managed by an external organisation

The exam consists of two parts – Foundation (Part 1) and Certified (Part 2)

Part 1 duration 60 minutes consisting of 40 multiple choice questions (closed book). One point is awarded for a correct answer, zero points for all other answers. Pass mark is 22

Part 2 duration 90 minutes consisting of 8 complex scenario-based multiple choice questions (open book). Each question has four possible answers. Five points are awarded for the correct answer; three points for the next best answer; one point a barely correct answer; and zero points for the remaining answer. Pass mark is 24

The trainer will provide full details on how to arrange your exam.


4

Basic Concepts

Session Objectives

We will look at the following:

The Open Group and its evolution

What an Enterprise is

The Purpose of Enterprise Architecture

The Business Benefits of an Enterprise Architecture

What an Architecture Framework is, and why TOGAF is so suitable

What an “architecture” is, and finally

The main types of architecture covered by TOGAF

The Certification Programme

The Open Group

Vendor and Technology Neutral, not-for-profit consortium started in 1996

They own the UNIX and TOGAF trade marks

500+ Organisations are members, including QA

60,000+ Individual Foundation or Certified Architects

200,000+ downloads / purchases of TOGAF PDF/Book

Certification started in 2003

Vision : “Boundaryless Information Flow™”

TOGAF Evolution


5

What is an Enterprise?

An Enterprise is a collection of Organisations that share a common set of goals

Enterprises come in many shapes and forms:

An entire enterprise or even specific domain within it

An entire Government or a department within it

An entire Corporation or division within it

Chain of dispersed organisations linked by common ownership

And there is the Extended Enterprise that encompasses other organisations who do business with you.

Enterprise Architecture – What is its purpose?

Complex organisations (enterprises) have complex systems

Enterprise Architecture is about co-ordinating and evolving those systems... Why?

o To support the Enterprise strategy

o And the Extended Enterprise strategy

EA provides a strategic context for system evolution, in response to the constantly changing business

environment

It creates an environment where IT efficiency is balanced against business need

What are the Business Benefits?

Other traditional benefits of an Enterprise Architecture are:

A more efficient business operation:

o Lower business operation costs

o More agile organization

o Business capabilities shared across the organization

o Lower change management costs

o More flexible workforce

o Improved business productivity

A more efficient IT operation:

o Lower software development, support and maintenance costs

o Increased portability of applications

o Improved interoperability and easier system and network management

o Improved ability to address critical enterprise-wide issues like security

o Easier upgrade and exchange of system components

Better return on existing investment, reduced risk for future investment:

o Reduced complexity in the business and IT

o Maximum return on investment in existing business and IT infrastructure

o The flexibility to make, buy, or out-source business and IT solutions

o Reduced risk overall in new investments and their cost of ownership

Faster, simpler, and cheaper procurement:


6

o Buying decisions are simpler, because the information governing procurement is readily available

in a coherent plan

o The procurement process is faster - maximizing procurement speed and flexibility without

sacrificing architectural coherence

o The ability to procure heterogeneous, multi-vendor open systems

o The ability to secure more economic capabilities


7

What is an Architecture Framework?

The answer is many things, such as...

like any framework, it is a lot of good advice that’s been developed over years

guidance on designing the “building blocks” of an architecture

a set of tools (vocabulary, techniques) to help in this process

the standardisation necessary to attract vendor-based tools to help architects in their work

You need TOGAF to give you a “kick-start” in any architecting activities undertaken.

So why is TOGAF so suitable?

Because it has evolved over many years to deliver this toolset

It is “best practice” used by and supported by many architects

TOGAF really comes to the fore when considering more complex systems in complex organisations, by addressing the problems often encountered in these situations.

It has a process and toolset that is...

o Focussed on aligning IT and business

o Based on “codified common-sense” and best practices

o The product of many experienced architects

o An open standard, therefore free

o Supported by tool vendors and others

o Widely adopted

o Usable in a wide variety of circumstances


8

TOGAF Parts

Part II – The Architecture Development Method: a process for undertaking Enterprise Architecture.

Part III – ADM Guidelines and Techniques: this contains many established techniques. It is the most valuable toolkit, addressing topics such as Governance (principles), Stakeholder Management, Business Scenarios, Gap Analysis, Migration Planning Techniques, Risk Management, and more.

Part IV – Architecture Content Framework: puts structure into the sort of documents architects deal with, and more importantly perhaps, a Metamodel that describes architectural entities and their relationships.

Part V – The Enterprise Continuum: despite its rather enigmatic title this area provides some fundamental and substantial help on how to both visualise and organise both Architecture definitions (building blocks), and the associated processes.

Part VI – Reference Models: The Technical Reference Model (TRM) and the Integrated Information Infrastructure Model.

Part VII – Architecture Capability Framework: this final section has some important aspects, not least guidance on Architecture Governance, and a Skills Framework.

1st Part – Introduction

Where is this in the previous graphic? No room!

It is important – it contains the Executive overview and basic definitions that are covered in this section.


9

TOGAF Capabilities


10

What is a [System] Architecture?

TOGAF Definitions

1. A formal description of a system, or a detailed plan of the system at component level to guide its

implementation.

2. The structure of components, their inter-relationships and the principles and guidelines governing their

design and evolution over time.

A comparative definition…

“The fundamental concepts or properties of a system in its environment embodied in its elements, relationships and in the principles of its design and evolution.”

Source: ANSI/IEEE 1471 – 2000, now superseded by ISO/IEC/IEEE 42010:2011, called “Systems and software engineering — Architecture description”

The Different Types of Architecture


11

Certification Program

Exam Paths


12

Summary

We have learnt that:

The Open Group is a well-established vendor-neutral consortium

An Enterprise is a collection of organisations that share the same goal

Enterprise Architecture purpose is to integrate and simplify corporate systems to better support long term business strategy

Enterprise Architecture Business Benefits are quicker, cheaper, more efficient systems

An Architecture Framework is best architecture practice

TOGAF is so suitable because it provides advice on governing, doing, designing and generally evolving systems

The structure of TOGAF is in Seven parts

An “architecture” is a collection of related components (BBs) whose design and evolution needs governing

The main types of architecture covered by TOGAF are Business, Application, Data and Technology – but don’t forget “Enterprise Architecture”


13

Core Concepts

Session Objectives


The Architecture Development Method




Architecture Capability

Using TOGAF with other frameworks

The TRM and III-RM

The purpose of this module is to explain the core concepts of TOGAF.

This module covers Key Learning Points that are part of the Level 1 (Foundation) certification.


14

The Architecture Development Method


15


What we’re getting here is some solid advice on the type of documents to produce and the information that goes in them. All that is needed now is some idea of how people want this data to be represented – this is where Views and Viewpoints come in. We’ll look at this later.


16


This term may be slightly arcane, but this whole concept is critical to describe how IS/IT “Architectures” are composed. We will look at this in more detail later.

On its Y-axis, it addresses the need to initially describe architecture in a high-level way, which is then used to guide and / or support the final detailed specification.

On its X-axis it plots the continuum itself which starts (if you look at the right-hand side first) with the very specific architectures that are an intrinsic part of your organisation, and moves out eventually to a very general area that is populated by Frameworks (TOGAF etc.), Languages (ECMA-script, Java etc.), Basic Patterns of Architecture (MVC, Point-to-point etc.).


17



18

Architecture Capabilities

Using TOGAF with other Frameworks

MSP: Managing Successful Programmes

PRINCE2: Projects in Controlled Environments

ITIL: The Information Technology Infrastructure Library

COBIT: Controlled Objectives for Information and Related Technology


19

Technical Reference Model

Integrated Information Infrastructure RM


20

Summary

We have seen that:

The Architecture Development Method is a set of architecture processes

The Architecture Content Framework suggests documents and entities that describe architecture

The Enterprise Continuum explores how to conceptualise and categorise architecture

The Architecture Repository is a place to store architecture assets

Architecture Capability describes relationships with others and core competencies of the Architecture Practice

Using TOGAF with other frameworks is vital, to co-ordinate with PMO, PO and Governance

The TRM and III-RM are two Reference Models


21

Introduction to the ADM

Session Objectives


What is the ADM, and its key Points?

Phases A – D, typical steps and Document Versioning

Relationships between the ADM and other parts of TOGAF

Guidelines and techniques for use

Adapting the ADM

ADM Governance and Information

Scope, its limitations and dimensions

Architecture Integration


22

The ADM and Key Points

Definition process – Phases A to D


23

ADM Relationships

Guidelines and Techniques


24

Adapting the ADM

ADM Governance and Information


25

Architecture Scope

Architecture Integration

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


26

Summary

We looked at the following:

What is the ADM, and its key Points intuitive, generic, use alongside...

Phases A – D, typical steps they contain and Document Versioning models, baseline, target, gaps, timeframe, impact, checkpoint, finalisation, documentation

Relationships between the ADM and other parts of TOGAF highly integrated

Guidelines and techniques for use the architects toolbox

Adapting the ADM to suit large and small, internal and external development, nature of the business

ADM Governance and Information is important, to control and audit documentation and processes

Scope, its limitations and dimensions many different influences on architectural activity

Architecture Integration in order to harmonise architectures to standards and reference architectures


27


Session Objectives

We will look at the following

The Enterprise Continuum – what is it and how is it used?

The constituent parts of the Enterprise Continuum

Explain how the Enterprise Continuum relates to other parts of TOGAF

The purpose of this module is to understand the concept of the Enterprise Continuum, its purpose and constituent parts.

This module covers Key Learning Points that are part of the Level 1 (Foundation) certification.

Definitions

Continuum: “a continuous sequence in which adjacent elements are not perceptibly different from each other, but the extremes are quite distinct”

Imperceptible: “so slight, gradual, or subtle as not to be perceived”

Source: Oxford Dictionary

What is the Enterprise Continuum?

A CLASSIFICATION SYSTEM...

...which can therefore assist in identifying reusable assets

A way of “idealising” (considering the design / architecture) and “realising” (considering the solution)

A communications aid, for use internally and externally (extended enterprise)

An aid to (software) engineering and / or making effective use of COTS packages

Reuse

Reference Models

Patterns

Building Blocks

Frameworks

Specifications

Existing architecture Assets

BUT YOU NEED SOMEWHERE TO STORE AND ACCESS THIS INFORMATION – A “REPOSITORY”


28

Main Constituents


29

Main Graphic


30

Architecture Continuum

When you “idealise” about architecture you should:

Use reference models where-ever possible

Reuse existing logical (architectural) building blocks

Think right to left

Solutions Continuum

When you “realise” an architecture you should:

Derive from existing Architectural assets

Implement a physical solution

Control that solution using SLAs


31

Relationship with the ADM

Summary

We have looked at

The Enterprise Continuum – a classification system

The constituent parts of the Enterprise Continuum –

Architecture and Solution Continuums

Explain how the Enterprise Continuum relates to other parts of TOGAF – particularly during definition phases


32

Architecture Repository

Session Objectives

We will look at the following

What is the Architecture Repository

How it relates to the Enterprise IT Repository

Describe the purpose of the main repository areas

The purpose of this module is to help understand the purpose of the Architecture Repository, its constituent parts, and its relationship to other parts of TOGAF.

Overview

An effective Architecture Practice will generate a large output of documents, diagrams etc.

A structured framework for classifying this output

It should be regarded as part of an overall Enterprise IT Repository, consisting of

o Detailed Design

o Deployment

o Service Management areas

Observation – the Enterprise Repository is seen by many newcomers to the TOGAF framework, as an “entry point”


33

Repositories


34

Classes of Repository Information

The Architecture Metamodel

The Architecture Capability

The Architecture Landscape

The Standards Information Base

The Reference Library

The Governance Log

The Architecture Metamodel applies the Content Framework, in particular the architectural entities to the information stored in the repository.

The Architecture Capability encompasses the governance aspects, such as processes, roles, and decisions.

The Architecture Landscape is the heart of the repository. It contains all baseline architecture descriptions as well as ongoing work.

The Standards Information Base encapsulates the standards to which architectures must comply of conform.

The Reference Library is the “goldmine” of guidelines and guidance material, patterns and reference models, from both external and internal sources. It is here that reusable Architecture Building Blocks are stored.

The Governance Log provides a record of governance activity across the enterprise.

Enterprise Continuum and the Repository


35

Architecture Landscape

Strategic Architectures: provide a longer term (high-level) roadmap towards achieving strategic business goals.

Segment Architectures: are the next level down, represent major business domains or even systems / capabilities (the classification is up to the organisation), but still at the higher level.

Capability Architectures: represent the “ground level” of architecting. They represent packages or projects that are part of transitionary or incremental plans. This is where the Solution Building Blocks live.


36

Standards Information Base

Summary

We have looked at the following

What is the Architecture Repository a framework for classifying architecture output

How it relates to the Enterprise IT Repository it fits alongside other repositories for development, deployment and support

Describe the purpose of the main repository areas:

o The Architecture Metamodel organises an architectural framework and models content

o The Architecture Capability supports governance of the repository

o The Architecture Landscape contains live architecture

o The Standards Information Base captures standards

o The Reference Library provide guidelines

o The Governance Log records enterprise governance activity


37

Architecture Content Framework

Session Objectives

This chapter will:

Explain the purpose of the Architecture Content Framework

Describe the main components of the Content Metamodel

Describe the relationship between the Content Metamodel and the ADM

The purpose of this module is to help understand the TOGAF Architecture Content Framework.

Overview

A significant new feature to Version 9

Like any classification system

o aids consistency of terminology

o mapping items to other frameworks, such as Zachman

Key parts are:

o Architecture Deliverables

o Architectural Artifacts

o Building Blocks

o Content Metamodel

Content Framework Items

Deliverable

o Contractually specified work product, formally reviewed, agreed and signed-off by the stakeholders

Artifact

o A more granular work product describing architecture from a specific view and viewpoint. Classified as:

Catalogues (lists)

Matrices (relationships between lists) and

Diagrams

Building Block

o A potentially reusable component of business, IT or architectural capability. Combined with other BBs, delivers:

o Architecture BBs describe capability

o Solutions BBs implement that capability

Deliverable

Contractually specified, formally reviewed, agreed and signed-off by the stakeholders. At end of project will be either archived, or transitioned into the Architecture Repository as a Reference Model, Standard or snapshot of the Architecture Landscape at a point in time.


38

Key Relationships

Example Deliverable


39

The Content Metamodel

Definition of all Building Blocks that may exist within an architecture

Combined with the Work Products, provides a comprehensive way to describe Architecture

Its classification is closely mapped to the ADM, and will be used extensively within the Inputs and Outputs particularly during the “definition” phases (A – E)

Summary

In this chapter we have:

Explained the purpose of the Content Framework which provides a consistent platform for describing architecture

Described the main components of the Content Metamodel which are the work products and the metamodel

Described the relationship between the Content Metamodel and the ADM where the metamodel is closely mapped to main ADM phases


40

Content Metamodel

Session Objectives

This chapter will:

Describe the core Metamodel concepts

Describe the key concepts related to the Core Part

Explain why the Metamodel is divided into Core and Extension parts

Describe briefly the Extension Parts

The purpose of this module is to help understand the TOGAF Content Metamodel.

Overview

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

[Source: TOGAFTM 9 Part I, Chapter 3 (Definitions)]

"Metamodeling" is the construction of a collection of "concepts" (things, terms, etc.) within a certain domain.

[Source: Wikipedia]

A Metamodel is a formalised set of entities showing the relationships between them.

[Source: Unknown]

Core Concepts

Core and Extension Content

o Basic version with

o A set of extensions covering additional considerations

Core Metamodel Entities

o showing the purpose of each entity

o key relationships that support architectural traceability

Catalog(ue), Matrix and Diagram Concept

Core and Extension Content provides an introduction to the way in which TOGAF employs a basic core metamodel and then applies a number of extension modules to address specific architectural issues in more detail.

Core Metamodel Entities introduces the core TOGAF metamodel entities, showing the purpose of each entity and the key relationships that support architectural traceability.

Catalog(ue), Matrix, and Diagram Concept describes the concept of catalogues, matrices, and diagrams.


41

Core Entity Diagram


42

Core and Extension Parts

Full Diagram with Extensions

See Reference Card

Associated Artifacts

See Reference Card

Summary

In this chapter we have:

Described the core Metamodel concepts to provide a formal and consistent set of terms for use in ADM

Described the key concepts related to the Core Part Actor, Application Component , Business Service, Data Entity, Function, Organisation, Platform Service, Process, Role, Technology Component

Explained why the Metamodel is divided into Core and Extension parts core provides key basic definitions, and the extension looks at specific aspects in more detail

Described briefly the Extension Part which addresses Governance, Services, Process Modelling, Data, Infrastructure Consolidation, Motivation


43

Preliminary Phase

Session Objectives

This module focuses on the Preliminary Phase’s

Objectives

Approach

Main inputs

Steps

Outputs

The purpose of this module is to help understand how the Preliminary Phase contributes to the success of enterprise architecture.

Phase Objectives

1. Determine the Architecture Capability desired by the organisation:

o Review the organisational context for conducting enterprise architecture

o Identify and scope the elements of the enterprise organisations affected by the Architecture Capability

o Identify the established frameworks, methods, and processes that intersect with the Architecture Capability

o Establish Capability Maturity target

2. Establish the Architecture Capability

o Define and establish the Organisational Model for Enterprise Architecture

o Define and establish the detailed process and resources for architecture governance

o Define the Architecture Principles

o Select and implement tools that support the Architecture Capability

Approach

Define the Enterprise inc. scope, stakeholders, extent

Identify key drivers and elements in the Organisational Context inc. commercial models / budgets,

stakeholders, intentions, management processes, baseline, skills, capabilities and corporate culture

Define the requirements for architecture work inc. business need, cultural aspiration, organisation intents, strategic intent, financial forecasts

Define the architecture principles that guide the development of architecture, and cross-ref to business

principles, goals and drivers

Define the framework to be used inc. business capability, project and programme management, operations and solution development

Define the relationships between management frameworks see next slide

Evaluate the enterprise architecture maturity by means of capability maturity models such as NASCIO

and ACMM


44

Relationship between Frameworks

Inputs

TOGAF

Other architecture framework(s)

Board strategies, business plans, business strategy, IT Strategy, business principles, business goals and business drivers

Governance and legal frameworks

Architecture capability

Partnership and contract agreements

Existing organisational model for enterprise architecture

Existing architecture framework, if any including method, content, principles, repository and tools


45

Further Input Considerations

Other Architecture Frameworks may be required or mandated

o such as PRINCE2, ITIL, or industry specific i.e. MoDAF

Business principles, business goals, and business drivers

o all part of the Business Motivation, or Organisational Context

Other Architecture Frameworks may be required or mandated, such as xGEAF, MoDAF, FEAF, DoDAF. In these cases TOGAF can be used alongside.

Business principles, business goals, and business drivers – all part of the Business Motivation, or Organisational Context.

Influence of Pre-existing Inputs

Existing architectural / organisational aspects to take into account:

The Organisational Model for Enterprise Architecture, including:

o Scope of organisations impacted

o Maturity assessment, gaps, and resolution approach

o Roles and responsibilities for architecture team(s)

o Budget requirements

o Governance and support strategy

Existing Architecture Framework (if any) including:

o Architecture method, and content (deliverables and artifacts)

o Configured and deployed tools

Existing architecture principles

Existing Architecture Repository

o Framework description

o Architectural descriptions

o Existing target descriptions, etc.

Steps

1. Scope the enterprise organisations impacted

2. Confirm governance and support frameworks

3. Define and establish enterprise architecture team and organisation

4. Identify and establish architecture principles

5. Tailor TOGAF and, if any, other selected Architecture Frameworks

6. Implement architecture tools


46

Summary

1. Scope the Enterprise

Identify Core parts of the enterprise, those indirectly affected, the extended enterprise, stakeholders involved and any associated governance.

2. Confirm Governance

Often Enterprise architecture activity can have a profound effect on governance – and this should be ascertained and acted upon when dealing with governance processes and documents.

3. Establish Team and Organisation

See future slide.

4. Establish Principles

See future slide.

5. Tailor Architecture frameworks

See future slide.

6. Implement Architecture Tools

The formality of the Architecture is influenced by the uptake of Architecture Tools.

Establish EA Team and Organisation

Determine existing enterprise and business capability

Conduct an enterprise architecture / business change maturity assessment

Identify gaps in existing work areas

Allocate key roles and responsibilities

Define change requests:

o Inform existing enterprise architecture and IT architecture work of stakeholder requirements

o Request assessment of impact on their plans and work

o Identify common areas of interest

o Identify any critical differences and conflicts of interest

o Produce requests for change to stakeholder activities

Determine constraints on enterprise architecture work

Review and agree with sponsors and board

Assess budget requirements


47

Identify Principles

Principles are enduring rules

They enable decision-making (management)

Enterprise Principles inform and help the organisation to fulfil its

mission

Architecture principles...

o govern the evolution of systems

o govern the implementation of architecture

Defining Principles

An important process that should be handled by the Chief, or most senior [enterprise] architect

Other senior stakeholders should be closely involved:

o Architecture Board Members, that may well include

o Other key stakeholders (business, operations, commercial, legal etc.)

o CIO, if applicable

Each principle must be related to some form of goal, or driver


48

List of Principles

Business Primacy of Principles

Maximise Benefit to the Enterprise

Information Management is Everybody’s Business

Business Continuity

Common Use Applications

Service Orientation

Compliance with Law

IT Responsibility

Protection of Intellectual Property

Data Data is an Asset

Data is Shared

Data is Accessible

Data Trustee

Common Vocabulary and Data Definitions

Data Security

Application Technology Independence

Ease-of-Use

Technology Requirements-based Change

Responsive Change Management

Control Technical Diversity

Interoperability


49

Principle Template

Name Should both represent the essence of the rule as well as be easy to remember. Specific technology platforms should not be mentioned in the name or statement of a principle.

Statement Should succinctly and unambiguously communicate the fundamental rule. For the most part, the principles statements for managing information are similar from one organisation to the next. It is vital that the principles statement be unambiguous.

Rationale Should highlight the business benefits of adhering to the principle, using business terminology. Point to the similarity of IS and IT principles to the principles governing business operations. Also describe the relationship to other principles and intentions regarding a balanced interpretation. Describe situations where one principle would be given precedence or carry more weight than another for making a decision.

Implications Should highlight the requirements, both for the business and IT, for carrying out the principle – in terms of resources, costs and activities/tasks. It will often be apparent that current systems, standards, or practices would be incongruent with the principle upon adoption. The impact to the business and consequences of adopting a principle should be clearly stated. The reader should readily discern the answer to: ‘‘How does this affect me?’’ It is important not to oversimplify, trivialise, or judge the merit of the impact. Some of the implications will be identified as potential impacts only and may be speculative rather than fully analysed.


50

Example Principle (#1)

Name Primacy of Principles

Statement Principles of information management apply to all organizations within the enterprise.

Rationale The only way we can provide a consistent and measurable level of quality information to decision-makers is if all organizations abide by the principles.

Implications • Without this principle, exclusions, favouritism and inconsistency would rapidly undermine the management of information.

• Information management initiatives will not begin until they are examined for compliance with the principles.

• A conflict with a principle will be resolved by changing the framework of the initiative.

Example Principle (#2)

Name Service Orientation

Statement The architecture is based on a design of services which mirror real-world business activities comprising the enterprise (or inter-enterprise) business processes.

Rationale Service orientation delivers enterprise agility and Boundaryless Information Flow.

Implications • Service representation utilizes business descriptions to provide context (i.e. business process, goal, rule, policy, service interface and service component) and implements services using service orchestration.

• Service orientation places unique requirements on the infrastructure, and implementations should use open standards to realize interoperability and location transparency.

• Implementations are environment-specific; they are constrained or enabled by context and must be described within that context.

• Strong governance of service representation and implementation is required.

• A ‘‘Litmus Test’’, which determines a ‘‘good service’’, is required.


51

Qualities of Principles

Understandable The underlying tenets can be quickly grasped and understood by individuals throughout the organisation. The intention of the principle is clear and unambiguous, so that violations, whether intentional or not, are minimised.

Robust Enable good quality decisions about architectures and plans to be made, and enforceable policies and standards to be created. Each principle should be sufficiently definitive and precise to support consistent decision-making in complex, potentially controversial situations.

Complete Every potentially important principle governing the management of information and technology for the organisation is defined. The principles cover every situation perceived.

Consistent Strict adherence to one principle may require a loose interpretation of another principle. The set of principles must be expressed in a way that allows a balance of interpretations. Principles should not be contradictory to the point where adhering to one principle would violate the spirit of another. Every word in a principle statement should be carefully chosen to allow consistent yet flexible interpretation.

Stable Principles should be enduring, yet able to accommodate changes. An amendment process should be established for adding, removing, or altering principles after they are ratified initially.


52

Tailoring the Framework

Terminology Tailoring

Process Tailoring – TOGAF is likely to have to integrate with:

o Project and Service portfolio management processes

o Project lifecycle

o Operations handover processes

o Operational management processes (including configuration management, change management and service management)

o Procurement processes

Content Tailoring – aligning architecture description to align with the

Content Framework or other content frameworks (Zachman, Metis)

Outputs

Organisational model for enterprise architecture

Tailored Architecture Framework, including architecture principles

o The final architecture processes and list of principles

Initial Architecture Repository

Restatement of, or reference to, business principles, business goals and business drivers

Request for [enterprise] Architecture Work

Architecture Governance Framework

o Established after taking into account the organisation and integration with other frameworks

Request for Architecture Work

Organisation sponsors

Organisation's mission statement

Business goals (and changes)

Strategic plans of the business

Time limits

Changes in the business environment

Organisational constraints

Budget information, financial constraints

External constraints, business constraints

Current business system description

Current architecture / IT system description

Description of the organisation developing the architecture

Description of resources available to the organisation developing the architecture


53

Security

Scope impacted enterprise organisations:

o Identify core enterprise (units)

o Identify soft enterprise (units) those units that may see changes because of the above

o Identify extended enterprise (units)

o Identify communities involved (enterprises)

o Identify security governance involved, including legal framework and geographies

Define and document applicable regulatory and security policy requirements

Define required security capability

Implement security architecture tools

Summary

The Preliminary phase prepares an organisation to undertake successful enterprise architecture projects.


54

Governance

Session Objectives

Explain the nature and concepts of Architecture Governance, and a Governance Framework

Describe the Architecture Board

Explain the need for and meaning of Architecture Compliance

Explain the purpose and describe Compliance Reviews

Explain the benefits and list Key Success Factors

Discuss the role, setting up and operating an Architecture Board

The purpose of this module is to help understand how to apply Architecture Governance in development of an enterprise architecture.

Overview

Architecture Governance is the practice and orientation by which enterprise architectures and other architectures are managed and controlled at an enterprise-wide level.

TOGAF provides guidance on aspects of Architecture Governance in the Architecture Capability Framework.

Architecture governance is concerned with governing the ADM as a whole – Phase G Implementation Governance is an essential part of this, focusing on ensuring architectures are implemented to specification.

Nature of Governance

Focus on rights, roles and equitable treatment of shareholders

Disclosure, transparency and responsibility

Ensures:

o Sound strategic guidance of the organisation

o Effective monitoring of management by the board

o Board accountability for the company and to the shareholders

Board’s responsibilities:

o Reviewing and guiding corporate strategy

o Setting and monitoring achievement of management’s performance objectives

Characteristics

Discipline all involved parties will have a commitment to adhere to procedures, processes and authority

structures established by the organisation

Transparency all actions implemented and their decision support will be available for inspection by authorised organisation and provider parties

Independence all processes, decision-making, and mechanisms used will be established so as to minimise or avoid potential conflicts of interest

Accountability identifiable groups within the organisation, e.g., governance boards who take actions or

make decisions — are authorised and accountable for their actions

Responsibility each contracted party is required to act responsibly to the organisation and its stakeholders

Fairness all decisions taken, processes used and their implementation will not be allowed to create unfair

advantage to any one particular party


55


...is specifically control over:

Creation and monitoring of all architectural components and associated activities

Ensuring compliance with internal and external standards

Establishing those processes necessary to achieve the above

Developing good practice, particularly by ensuring accountability to stakeholders inside and outside the organisation

Benefits of Architecture Governance is to achieve effective IT / Business linkage, and control architecture activity using the above.

Key Success Factors

Best practices

Organisational responsibilities and structures

Integration of tools and processes

Criteria for control

Internal and external requirements

Best practices for the submission, adoption, re-use, reporting and retirement of architecture policies, procedures, roles, skills, organisational structures and support services.

Organisational responsibilities and structures to support the architecture governance processes and reporting requirements.

Integration of tools and processes to facilitate the take-up of the processes, both procedurally and culturally.

Criteria for control of the architecture governance processes, dispensations, compliance assessments, SLAs, and OLAs.

Internal and external requirements for the effectiveness, efficiency, confidentiality, integrity, availability, compliance, and reliability of all architecture governance-related information, services and processes.

Governance Hierarchy / Organisation

Corporate governance of the organisation as a whole, its compliance with the law and how the overall

governance activities are structured

Technology R&D, production of Goods and Services

IT governance of IT Function in general, including planning, acquiring, implementing and monitoring IT

performance and services. COBIT is a useful resource for ensuring compliance.

Architecture in some cases an Executive Board-level responsibility.


56

Architecture Governance Framework (conceptual)

Governance Processes

Policy Management and Take-On ensures all amendments, contracts and other documentation are

controlled

Compliance against SLAs and OLAs

Dispensation whereby alternative SLAs and or OLAs can be allowed, for a fixed time

Monitoring and Reporting, performance management is required to ensure that both the operational and

service elements are managed against an agreed set of criteria. This will include monitoring against service

and operational-level agreements, feedback for adjustment, and reporting. Internal Management

information will be considered in Environment Management.

Business Control ensuring compliance with Business policies

Environment Management ensuring Repository is controlled and updated properly, as well as controlling

access and training.


57

Organisation Structure


58

Setting up an Architecture Board

Likely triggers are:

New CIO

Merger or acquisition

Consideration of a move to newer forms of computing

Recognition that IT is poorly aligned to business

Desire to achieve competitive advantage via technology

Creation of an enterprise architecture program

Significant business change or rapid growth

Requirement for complex, cross-functional solutions

Likely size:

4 – 10 depending on size and complexity of organisation

Other related bodies include Design Authorities and Working Parties

AB Responsibilities

Consistency between sub-architectures

Identifying re-usable components

Flexibility of enterprise architecture:

o To meet changing business needs

o To capitalise on new technologies

Enforcement of Architecture Compliance

Improving the maturity level of architecture discipline within the organisation

Ensuring that the discipline of architecture-based development is adopted

Providing the basis for all decision-making with regard to changes to the architectures

Supporting a visible escalation capability for out-of-bounds decisions

AB Justification and Composition

What exists all too often without an AB is one-off solutions that lead to:

High costs of development

High costs of operation and support:

o Numerous run-time environments

o Numerous implementation languages

o Numerous interfaces and protocols ...

Lower quality

Higher risk

Difficulty in replicating and re-using solutions

Board comprised of:

Local (domain experts, line responsibility)

Global (organisation-wide responsibility)


59

Operation of the AB – Board Meetings

Supporting the production of quality governance material and activities

Providing a mechanism for formal acceptance through consensus and authorised publication

Providing a fundamental control mechanism for ensuring effective implementation of the architectures

Establishing and maintaining the link between architecture and strategy of the business

Identifying divergence from the contract and planning activities to realign with the contract through dispensations or policy upgrades

Typical Board Meeting Agenda

Minutes of Previous Meeting

Requests for Change

Dispensations

Compliance Assessments

Dispute Resolution

Architecture Strategy and Direction Documentation

Actions Assigned

Contract Documentation Management

Any Other Business (AOB)

AB Operational Responsibilities

All aspects of monitoring and control

Meeting on a regular basis

Ensuring effective and consistent management and implementation

Resolving ambiguities, issues, or conflicts

Providing advice, guidance, and information

Ensuring compliance

Considering policy (schedule, Service Level Agreements (SLAs), etc.) changes

Ensuring that all information relevant to the implementation of the Architecture Contract

Validation of reported service levels, cost savings, etc.

Architecture Contracts

Are formal agreements between

o Architecture Design and Development Partners (who could be internal or external)

o Architecting Function and Business Users

A contract is a governance Control that can be used to establish responsibility and test compliance

Can be used to ensure:

o A system of continuous monitoring

o Adherence to the principles, standards, and requirements

o Identification of risks

o A set of processes and practices that ensure accountability, responsibility and discipline related to architecture artifacts

o A formal understanding of the governance organisation, its authority and scope of architecture


60

Architecture Compliance Definitions


61

Need for Architecture Compliance

To ensure compliance of individual projects with the Enterprise Architecture:

The Architecture function prepares the project architectures

The IT Governance Function will define a formal Compliance Review process

Purpose of Compliance Reviews

There are additional, more politically-oriented motivations for conducting Architecture Compliance

reviews, which may be relevant in particular cases:

The Architecture Compliance review can be a good way of deciding between architectural alternatives

The output of the Architecture Compliance review is one of the few measurable deliverables to the CIO to

assist in decision-making.

Architecture reviews can serve as a way for the architecture organization to engage with development

projects that might otherwise proceed without involvement of the architecture function.

Architecture reviews can demonstrate rapid and positive support to the enterprise business community

While compliance to architecture is required for development and implementation, non-compliance also

provides a mechanism for highlighting:

Areas to be addressed for realignment

Areas for consideration for integration into the architectures as they are uncovered by the compliance

processes


62

Compliance Review Process


63

Architecture Governance and Capability

Governance is part of the Architecture Practice that can be represented as a “system” with the following architectures:

Business Architecture (processes, organisation etc.)

Data Architecture (repository / continuum)

Application Architecture (functionality)

Technology Architecture (platform support)

Business Architecture of the architecture practice that will highlight the architecture governance, architecture processes, architecture organisational structure, architecture information requirements, architecture products, etc.

Data Architecture that would define the structure of the organisation’s Enterprise Continuum and Architecture Repository.

Application Architecture specifying the functionality and / or applications services required to enable the architecture practice.

Technology Architecture that depicts the architecture practice’s infrastructure requirements and deployment in support of the architecture applications and Enterprise Continuum.

Summary

Architecture Governance is the practice and orientation by which enterprise architectures and other architectures are managed and controlled at an enterprise-wide level.

TOGAF provides guidance on aspects of Architecture Governance in the Architecture Capability Framework.

The Governance Board plays a critical role, especially at the operational level.


64

Business Scenarios and Business Goals

Session Objectives


Defining and describing the Business Scenario technique

Developing and validating Business Scenarios

Overview

Referred to as a “method-within-a-method”, the Business Scenario technique is vital in order to understand the business context that lies behind a system.

It is a complete description (SMART) of a business problem, especially useful when enlisting the help of external vendor-based solutions.

Primarily describes:

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

Initiated in Phase A, developed in Phase B, used throughout definition phases.

The Business Scenario Process

A business scenario is essentially a complete description of a business problem, both in business and in architectural terms, which enables individual requirements to be viewed in relation to one another in the context of the overall problem. Without such a complete description to serve as context:

There is a danger of the architecture being based on an incomplete set of requirements that do not add up to a whole problem description, and that can therefore misguide architecture work.

The business value of solving the problem is unclear.

The relevance of potential solutions is unclear.

Also, because the technique requires the involvement of business line management and other stakeholders at an early stage in the architecture project, it also plays an important role in gaining the buy-in of these key personnel to the overall project and its end-product - the enterprise architecture.


65

The Business Scenario Process


66

Contents

Development Guidelines

You will need to investigate by:

Taking time, observing and recording how they work

Structure information in such a way that it can be used later

Uncover critical business rules from domain experts

Stay focused on what needs to be accomplished and how it is to be accomplished

Validation

Business Scenarios must be S.M.A.R.T

Specific

Measurable

Actionable

Realistic

Time-bound

These apply to the Business Goals and Objectives, although it tends to be the Objectives that provide greatest opportunity to be SMART, i.e.

Goal: Decrease Costs

Objectives: Reduce peoplepower by 10% within 12 months; reduce maintenance costs by 20% within 6 months


67

Summary

Referred to as a “method-within-a-method”. It is a complete description (SMART) of a business problem. Primarily describes:

A business process, application, or set of applications enabled by the architecture

The business and technology environment

The people and computing components (called ‘‘actors’’)

The desired outcome


68

Architecture Views and Viewpoints

Session Objectives

Define and explain the terms Stakeholder, Concern, View and Viewpoint

Creating Views and their benefits

The purpose of this module is to help understand the concepts of views and viewpoints, and their role in communicating with stakeholders as well as applying them to the Architecture Development Cycle. Also how to apply the Stakeholder Management technique using Stakeholder Maps.

Overview

Views and Viewpoints are the crucial elements that determine how you represent Architecture.

Definitions

System is a collection of components organised to accomplish a specific function or set of functions

Stakeholders are individuals, teams, or organisations who have key roles in, or concerns about, the system; for example, as users, developers, or managers. Different stakeholders with different roles in the system will have different concerns

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

View is a representation of a whole system from the perspective of a related set of concerns – “what you actually see”

Viewpoint defines the perspective from which a view is taken – “what you want to see” – a template lists

interested Stakeholders, their concerns, and an indication of how the view can be represented


69

ISO 42010


70

Example Viewpoint and View


71

Creating Views

Excellent guidance available in ISO/IEC 42010: 2007, formerly ANSI/IEEE 1471 – 2000 (although neither is mandated)

Views are the key to representing Architectures

Create a library of Viewpoints – a Stakeholder Map is useful for this. Viewpoints are reusable

Develop new Viewpoints only when necessary

OR develop new views, then retro-fit it to a Viewpoint!

A View MUST have a Viewpoint

Viewpoint / Artifact Summary

Preliminary Phase

Principles catalogue

Phase A

Stakeholder Map matrix

Value Chain diagram

Solution Concept diagram

Phase B

Organisation/Actor catalogue

Driver / Goal / Objective catalogue

Role catalogue

Business Service/Function catalogue

Location catalogue

Process / Event / Control / Product catalogue

Contract / Measure catalogue

Business Interaction matrix

Actor / Role matrix

Business Footprint diagram

Business Service/Information diagram

Functional Decomposition diagram

Product Lifecycle diagram

Goal/Objective/Service diagram

Business Use-Case diagram

Organisation Decomposition diagram

Process Flow diagram

Event diagram

Phase C – Data

Data Entity / Data Component catalogue

Data Entity / Business Function matrix

Application / Data matrix

Conceptual Data diagram

Logical Data Diagram

Data Dissemination diagram

Data Security diagram

Class Hierarchy diagram

Data Migration diagram

Data Lifecycle diagram

Phase C – Application

Application Portfolio catalogue

Interface catalogue

Application / Organisation matrix

Role / Application matrix

Application/Function matrix

Application Interaction matrix

Application Communication diagram

Application and User Location diagram

Application Use-Case diagram

Enterprise Manageability diagram

Process / Application Realisation diagram

Software Engineering diagram

Application Migration diagram

Software Distribution diagram

Phase D

Technology Standards catalogue

Technology Portfolio catalogue

Application / Technology matrix

Environments and Locations diagram

Platform Decomposition diagram

Processing diagram

Networked Computing / Hardware diagram

Communications Engineering diagram

Phase E

Project Context diagram

Benefits diagram


Requirements catalogue

Summary

Views and Viewpoints are the crucial elements that determine how you represent Architecture.


72


Session Objectives

Define and explain the terms Stakeholder and Concerns

Creating Views and their benefits

Stakeholder Maps

The purpose of this module is to help understand the concepts of views and viewpoints, and their role in communicating with stakeholders as well as applying them to the Architecture Development Cycle. Also how to apply the Stakeholder Management technique using Stakeholder Maps.

Overview

Stakeholders have concerns about architecture that can be addressed by these views and viewpoints.


A critical part of being an Architect is to manage Stakeholders:

Early identification of the most powerful stakeholders means their input can help shape the architecture, and attract their support

Support from powerful stakeholders can help win more resource thus increasing the chance of success

Early and frequent communication with stakeholders ensures full understanding of the benefits, and can lead to greater support

Full awareness of stakeholders can help architects anticipate their reaction to the architecture. Action can then be taken to capitalise on positive reaction, and avoid negative reaction

Stakeholders are initially identified in Phase A; however others will become apparent as the ADM process continues.

Tailoring the views of the architecture to address the concerns of these stakeholders, is what it’s all about!

Identifying Stakeholders

Investigate who will become a stakeholder and once identified consider:

Who gains and who loses from this change?

Who controls change management of processes?

Who designs new systems?

Who will make the decisions?

Who procures IT systems and who decides what to buy?

Who controls resources?

Who has specialist skills the project needs?

Who has influence?


73

Stakeholder Categories

Stakeholder Power Grid


74

Creating Views

Excellent guidance available in ISO/IEC 42010: 2007, formerly ANSI/IEEE 1471 – 2000 (although neither is mandated)

Views are the key to representing Architectures

Create a library of Viewpoints – a Stakeholder Map is useful for this. Viewpoints are reusable

Develop new Viewpoints only when necessary

OR develop new views, then retro-fit it to a Viewpoint!

A View MUST have a Viewpoint

Stakeholder Map

Summary

Stakeholders have concerns about architecture that can be addressed by these views and viewpoints.


75

Building Blocks

Session Objectives


What is a Building Block and what makes a good one?

Architecture and Solution Building Blocks

Using Building Blocks with the ADM

Architecture Patterns

The purpose of this module is to help understand the concept of building blocks within TOGAF.

Overview

The concept of Building Blocks is central to the approach recommended for designing a system architecture.

A building block is a package of functionality.

Comparing Baseline and Target building blocks allows identification of the gaps in architecture.

Architecture BBs are used to describe concepts and logic. Solution BBs describe physical solutions.

The way in which Building Blocks are assembled will vary widely between individual architectures. Every organisation must decide for itself what arrangement of building blocks works best for it.

A Building Block

Is a package of functionality defined to meet the business needs across an organisation

Has a type that corresponds to the TOGAF content metamodel (such as actor, business service, application, or data entity)

Has a defined boundary and is generally recognisable as ‘‘a thing’’ by domain experts

May interoperate with other, inter-dependent BBs

If properly designed, has the following characteristics:

o It considers implementation and usage, and evolves to exploit technology and standards

o It may be assembled from other building blocks

o It may be a subassembly of other building blocks

o Ideally a building block is re-usable and replaceable, and well specified

Architecture Building Blocks

Characteristics

Capture architecture requirements; e.g., business, data, application and technology requirements

Direct and guide the development of SBBs

Specification Content

Fundamental functionality and attributes: semantic, unambiguous, including security capability and manageability

Interfaces: chosen set, supplied

Interoperability and relationship with other building blocks

Dependent building blocks with required functionality and named user interfaces

Map to business / organisational entities and policies


76

Solution Building Blocks

Characteristics

Define what products and components will implement the functionality

Define the implementation

Fulfil business requirements

Are product or vendor-aware

Specification Content

Specific functionality and attributes

Interfaces

Required SBBs used with required functionality and names of the interfaces used

Mapping from the SBBs to the IT topology and operational policies

Specifications of attributes shared across the environment (not to be confused with functionality) such as security, manageability, localisability, scalability

Performance, configurability

Design drivers and constraints, including the physical architecture

Relationships between SBBs and ABBs

Design Issues

Some general principles are:

An architecture need only contain building blocks that are relevant to the business problem that the

architecture is attempting to address.

Building blocks may have complex relationships to one another. One building block may support multiple

building blocks or may partially support a single building block.

Building blocks should conform to standards relevant to their type, the principles of the enterprise, and the

standards of the enterprise.

Generally, BBs fall into three main classes

1. Re-usable, such as Legacy items

2. Bespoke BBs, developed internally

3. Packaged BBs (i.e. COTS) purchased from vendors


77

Building Blocks and the ADM

Patterns

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

A pattern is ‘‘an idea that has been useful in one practical context and will probably be useful in others’’ [Analysis Patterns—Re-usable Object Models]

Used to describe the context of how BBs could be used, i.e. “an e-commerce system”

Architecture Pattern: fundamental organisation of a software system

Design Pattern: describes the commonly recurring structure of communicating components

Idiom: low level pattern specific to programming language

An excellent reference source on this…

http://www.ibm.com/Search/?q=patterns&v=16&en=utf&lang=en&cc=zz&Search=Search

Summary

We have discovered that:

The concept of Building Blocks is central to the approach recommended for designing a system architecture

A building block is a package of functionality

Comparing Baseline and Target building blocks allows identification of the gaps in architecture

Architecture BBs are used to describe concepts and logic. Solution BBs describe physical solutions

The way in which Building Blocks are assembled will vary widely between individual architectures. Every organisation must decide for itself what arrangement of building blocks works best for it


78

Phase A – Architecture Vision

Session Objectives

This module focuses on the Architecture Vision Phase’s

Objectives

Approach

Main inputs

Steps

Outputs

The purpose of this module is to help understand how the Architecture Vision Phase contributes to the success of enterprise architecture.

Phase Objectives

Develop a high-level aspirational vision of the capabilities and business value to be delivered as a result of the proposed enterprise architecture

Obtain approval for a Statement of Architecture Work that defines a program of works to develop and deploy the architecture outlined in the Architecture Vision.


79

Approach

Creating the Architecture Vision

Business Scenarios

Creating an Architecture Vision

Provides a first-cut, high-level description of the Baseline and Target Architectures

Covers the business, data, application and technology domains

Includes key parts of the business context, such as business goals, strategy and environment

If this information is not available, then more research is needed to understand the context

The Business Scenario technique is useful, because it involves gathering the information above

Business Scenarios

The business scenario technique is a TOGAF equivalent to a combination of Business Analysis and

Requirements Engineering

Covered in a separate section

Inputs


Business principles, business goals and business drivers

Organisation model for Enterprise Architecture

Tailored Architecture Framework, including tailored method, content, principles, tools

Populated Architecture Repository; that is, existing architecture documentation (framework description, architecture descriptions, existing baseline descriptions, etc.)


Consists of existing architectural documentation:

Framework description

Architectural descriptions

Baseline descriptions

Architectural Building Blocks

Solution Building Blocks


80

Steps

1. Establish the architecture project

2. Identify stakeholders concerns, and requirements

3. Confirm and elaborate business goals, business drivers, and constraints

4. Evaluate business capabilities

5. Assess readiness for business transformation

6. Define scope

7. Confirm and elaborate architecture principles, including business

principles

8. Develop Architecture Vision

9. Define the Target Architecture KPIs

10. Identify Business Transformation Risks and mitigation activities

11. Develop enterprise architecture plans and Statement of Architecture

Work; secure approval

Step Summary

1. Establish the project

Depends on scope of project (i.e. Enterprise-level, Solution-level, and Standalone). Get endorsement, and link with other frameworks (i.e. MSP, PRINCE).

2. Identify Stakeholders concerns, and business requirements

See future slide.

3. Confirm and Elaborate Business Goals

Identify Goals, Drivers. If none exist go back to stakeholder and get them. Also gather information on constraints.

4. Evaluate Business Capabilities

Think of this as a synonym for a “Macro-level Business Function”. Is it provided internally or outsourced? Does it use a formal package? Value Chain diagram can be used to describe capability.

5. Assess readiness

See future slide.

6. Define Scope

Breadth or coverage; level of detail; partitioning characteristics; specific domains to be covered; time period; existing architecture assets.

7. Confirm and elaborate principles

A process started in the preliminary phase.

8. Develop Architecture Vision

Create high-level view of baseline and target architecture. Business scenario useful for doing this. Should establish scope.

9. Define the Target Architecture Value Propositions and KPIs

Develop a business case; produce review and agree value proposition for each stakeholder; define procurement requirements; assess business risk.

10. Identify Business Transformation Risks

See future slide.


81

11. Develop Enterprise Architecture Plans and SOW

Established performance metrics for required work. Then identify new work products; provide direction; identify

impact; determine level of detail; consider resources and build roadmap; build a communications plan; review and

get agreement for plan.

Stakeholders – Concerns and Requirements

Here we need to identify:

1. Candidate vision components and requirements

2. Candidate scope boundaries

3. Stakeholder concerns, issues and cultural factors

4. *The concerns and viewpoints that are relevant to this project

5. *The stakeholders that are involved with the project

6. *The key roles and responsibilities within the project

* These items can be identified in a Stakeholder Matrix, see “Stakeholder Management.

Business Transformation Readiness

Is the business (especially the people) ready for the new system? This assessment is based on understanding a series of readiness factors.

Initiated in Phase A, kept under review during Definition Phases and then used in Phases E/F.

The process involves:

Determining the readiness factors

Presenting them using Maturity Models

Rating those readiness factors

Relating them to risk, and consider mitigation

Blending these in during Phases E/F


82

Suggested Readiness Factors

Vision

Desire, Willingness, and Resolve

Need

Business Case

Funding

Sponsorship and Leadership

Governance

Accountability

Workable Approach and Execution Model

IT Capacity to Execute

Enterprise Capacity to Execute

Enterprise Ability to Implement and Operate

Risk Management

Initiated in Phase A, reviewed during definition and critical to the Planning phases E/F

Full Process involves:

Identifying risk

Assessing Initial Risk, considering

o Effects – Catastrophic, Critical, Marginal, Negligible

o Frequency – Frequent, Likely, Occasional, Seldom, Unlikely

o End risk – Extremely High (E), High (H), Moderate (M), Low (L)

Risk Mitigation and Residual Risk Assessment

Risk Monitoring

Risk Impact Classification Scheme


83

Outputs

Approved Statement of Architecture Work

Refined statements of business principles, business goals, and business drivers

Architecture principles

Capability assessment

Tailored Architecture Framework

Architecture Vision and high-level requirements

Draft Architecture Definition Document including:

o Baseline Business Architecture (vision)

o Baseline Data Architecture (vision)

o Baseline Application Architecture (vision)

o Baseline Technology Architecture (vision)

o Target Business Architecture (vision)

o Target Data Architecture (vision)

o Target Application Architecture (vision)

o Target Technology Architecture (vision)

Communications Plan

Additional content populating the Architecture Repository

Statement of Architecture Work

Typical contents of a Statement of Architecture Work are:

Statement of Architecture Work title

Project request and background

Project description and scope

Over view or outline of Architecture Vision

Managerial approach

Change of scope procedures

Roles, responsibilities and deliverables

Acceptance criteria and procedures

Project plan and schedule

Support of the Enterprise Continuum

Signature approvals


84

Capability Assessment

Investigate existing capabilities as well as those needed for the target system:

Business Capability Assessment

o Current and future performance and how these capabilities are realised

IT Capability Assessment

o Change and Operational processes; likely impact of the target system

Architecture maturity assessment

o Governance capability; skills; quality and depth of Repository material

Business Transformation Readiness Assessment

o Readiness Factors and risk

Capability-based Planning

Capability-based Planning focuses on Business Outcomes and the delivery of strategic business capabilities to the Enterprise

Increase focus on shared capabilities

Capabilities are concerned with:

o Skills

o Resources

o Training and

o Maturity-measured capability / processes

The Business Scenario can be used to discover and refine these capabilities

Capabilities


85

Capability-based Planning

Relationship Between Capabilities, Enterprise Architecture, and Projects

Architecture Vision

Problem description

o Stakeholders and their concerns

o List of issues / scenarios to be addressed

Objective of Statement of Architecture Work

Summary views necessary for the Request for Architecture Work and the Version 0.1 Business, Application, Data, and Technology Architectures created; typically including:

o Value Chain Diagram

o Solution Concept Diagram

Mapped Requirements

Reference to Draft Architecture Definition document

Interoperability

The ability to share information and services:

Phase A: the nature and security considerations of the information and service exchanges are first

revealed within the business scenarios

Phase B: the information and service exchanges are further defined in business terms

Phase C – Data: the content of the information exchanges are detailed using the corporate data and/or information exchange model

Phase C – Applications: the way that the various applications are to share the information and services is

specified

Phase D: the appropriate technical mechanisms to permit the information and service exchanges are specified

Phase E: the actual solutions (e.g. Commercial Off-The-Shelf (COTS) packages) are selected

Phase F: the interoperability is logically implemented


86

Interoperability Matrices

Phase B: Inter-stakeholder Information Interoperability Requirements (Using degrees of information interoperability)

Phase C: Inter-system Interoperability Requirements

Degrees of Interoperability

Degree 1: Unstructured Data Exchange involves the exchange of human-interpretable unstructured data, such as the free text.

Degree 2: Structured Data Exchange involves the exchange of human-interpretable.

Structured data intended for manual and/or automated handling,

Degree 3: Seamless Sharing of Data involves the automated sharing of data amongst systems based on a common exchange model.

Degree 4: Seamless Sharing of Information is an extension of Degree 3 to the universal interpretation of information through data processing based on co-operating applications.

These degrees should be further refined and made technically meaningful for each of the degrees. An example refinement of degree 3 with four sub classifications follows:

3A: Formal Message Exchange

3B: Common Data Exchange

3C: Complete Data Exchange

3D: Real-time Data Exchange

Operability from an IT (or EAI) Perspective

Presentation Integration/Interoperability

Common look-and-feel with guidance on how to use the underlying system

Information Integration/Interoperability

Information seamlessly shared between applications

Application Integration/Interoperability

Corporate functionality seamlessly integrated between applications through workflows, with no application duplication

Technical Integration/Interoperability

Includes common methods and services for accessing the Application Platform and Communications Infrastructure


87

Business Interoperability and BB

Business Building Blocks are concerned with Business Processes

Therefore interoperability of Processes must be considered

Significant gaps or differences in processes can be much more difficult to deal with than gaps in the data, applications or technology

We’re talking here of

”Business Process Re-engineering”

Communications Plan

Identification of stakeholders and grouping by communication requirements.

Identification of communication needs, key messages in relation to the Architecture Vision, communication risks and Critical Success Factors (CSFs).

Identification of mechanisms that will be used to communicate with stakeholders and allow access to architecture information, such as meetings, newsletters, repositories, etc.

Identification of a communications timetable, showing which communications will occur with which stakeholder groups at what time and in what location.

Security

Security considerations have an impact on Phases A to H of the TOGAF ADM. The following security specifics appropriate to the security architecture must be addressed within each phase in addition to the generic phase activities.

The steps of the Architecture Vision phase are applicable to ensuring that security requirements are addressed in subsequent phases of the ADM. Security considerations will have an effect on the enterprise such that all enterprise architecture development needs to be informed and utilize the security policy, constraints, governance, artifacts, and building blocks.

Obtain management support for security measures

Define necessary security-related management sign-off milestones of this architecture development cycle

Determine and document applicable disaster recovery or business continuity plans/requirements

Identify and document the anticipated physical/ business/regulatory environment(s) in which the system(s) will be deployed

Determine and document the criticality of the system: safety-critical/mission-critical/noncritical

Summary

The Architecture Vision phase is about project establishment and initiates an iteration of the architecture development cycle, setting the scope, constraints, and expectations for the iteration. It is required in order to validate the business context and to create the approved Statement of Architecture Work.


88

Phase B – Business Architecture

Session Objectives

This module focuses on the Business Architecture Phase’s

Objectives

Approach

Main inputs

Steps

Outputs

The purpose of this module is to help understand how the Business Architecture Phase contributes to the success of enterprise architecture.

Phase Objectives

Develop the Target Business Architecture that describes how the enterprise needs to operate to achieve the business goals, and respond to the strategic drivers set out in the Architecture Vision, in a way that addresses the Request for Architecture Work and stakeholder concerns

Identify candidate Architecture Roadmap components based upon gaps between the Baseline and

Target Business Architectures

Approach

Developing the Baseline Description

Understand existing business architecture. Document working assumptions about high-level architectures.

Business Modelling

Traditional modelling includes Activity Models (or Business Process Models), Use Case Models and Class Models.

Using the Architecture Repository

Examples of assets in this repository are:

Industry Business Models (OMG, TMF, Government agencies)

Business Domain Models (Accounts, Supply Chain, B2B)

Enterprise Building Blocks

Applicable standards


89

Inputs


Business principles, business goals, and business drivers


Communications Plan

Organisation model for enterprise architecture



Architecture principles, including business principles, when pre-existing

Enterprise Continuum


Architecture Vision, including:

o Refined key high-level stakeholder requirements

Draft Architecture Definition Document:

o Baseline Business Architecture (high-level)

o Baseline Data Architecture (high-level)

o Baseline Application Architecture (high-level)

o Baseline Technology Architecture (high-level)

o Target Business Architecture (high-level)

o Target Data Architecture (high-level)

o Target Application Architecture (high-level)

o Target Technology Architecture (high-level)

Business Principles, Goals, Drivers

Contextual Business Information – goals, strategy, drivers

Business Principles:

Primacy of Principles

Maximise Benefit to the Enterprise

Information Management is Everybody's Business

Business Continuity

Common Use Applications

Service-orientation

Compliance with Law

IT Responsibility

Protection of Intellectual Property


90

Steps

1. Select reference models, viewpoints, and tools

2. Develop Baseline Business Architecture Description

3. Develop Target Business Architecture Description

4. Perform gap analysis

5. Define Candidate Roadmap Components

6. Resolve impacts across the Architecture Landscape

7. Conduct formal stakeholder review

8. Finalise the Business Architecture

9. Create Architecture Definition Document

Note: technically speaking, the Architecture Definition Document is created in Phase A (as per this most recent version).

Step Summary


See future slides.

2. Develop Baseline Architecture Description

See future slide.

3. Develop Target Architecture Description

Repeat step 2, this time focussing on the Target Architecture.


See future slides.


This is built up during the definition period. It is initially a general estimate on timing, but which can be used later when formulating detailed implementation plans during Phase E (and then F).


Impacts could be on pre-existing architecture and/or other projects.


Critical to keep stakeholders fully up-to-speed.

8. Finalise the Architecture

This includes selecting standards; documenting Building Blocks; cross-checking architecture against business goals, and requirement (traceability), map with the Architecture Repository; finalise all work products.


See future slides.


91

Modelling Techniques and Views

Modelling techniques

Structured Analysis: identify key functions and map to organisational units

Use-case Analysis: associate functions with actors

Process Modelling: breakdown of functions to enable activities within the process to be identified

Artifacts


92

Business Modelling

BPMN

UML

ArchiMate®


93

Gap Analysis

Technique compares Baseline and Target Building Blocks. Suggested gap types are:

Business domain gaps:

o People gaps (e.g. cross-training requirements)

o Process gaps (e.g. process inefficiencies)

o Tools gaps (e.g. duplicate or missing tool functionality)

o Information gaps

o Measurement gaps

o Financial gaps

o Facilities gaps (buildings, office space, etc.)

Data domain gaps:

o Data not of sufficient currency

o Data not located where it is needed

o Not the data that is needed

o Data not available when needed

o Data not created

o Data not consumed

o Data relationship gaps

Applications impacted, eliminated or created


94

Gap Analysis Matrix

The matrix diagram is a slight adaptation of the TOGAF example. The Building blocks used here are based on the TRM Network Services definitions.


95

Building Blocks

Building blocks are packages of functionality

Suggested Building Blocks at the Business level (based on Content Metamodel) are:

Organisations

Actors

Drivers, Goals and Objectives

Roles

Business Services

Business Functions

Locations

Processes / Events / Controls / Products

Contracts and measures

Outputs

Statement of Architecture Work, updated if necessary

Validated business principles, business goals, and business drivers

Elaborated Business Architecture principles

Draft Architecture Definition Document (qualitative view) comprising

o Baseline Business Architecture (detailed), if appropriate

o Target Business Architecture (detailed)

o Views corresponding to selected viewpoints that address stakeholder concerns

Draft Architecture Requirements Specification (quantitative view)

o Gap analysis results

o Technical requirements

o Updated business requirements

Business Architecture components of an Architecture

Architecture Roadmap


96

Architecture Definition Document

1. Scope

2. Goals, objectives, and constraints

3. Architecture principles

4. Baseline Architecture

5. Architecture models (for each state to be modelled):

o Business Architecture models

o Data Architecture models

o Application Architecture models

o Technology Architecture models

6. Rationale and justification for architectural approach

7. Mapping to Architecture Repository:

o Mapping to Architecture Landscape

o Mapping to reference models

o Mapping to standards

o Re-use assessment

8. Gap analysis

9. Impact assessment

10. Transition Architecture

Business Architecture Models

Organisation structure – identifying business locations and relating them to organisational units

Business goals and objectives for the enterprise and each organisational 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 skills requirement development and modification

Business data model

Correlation of organisation and functions — relate business functions to organisational units in the form of a matrix report

Architecture Requirements Specification

Typical contents of an Architecture Requirements Specification are:

Success measures

Architecture requirements

Business service contracts

Application service contracts

Implementation guidelines

Implementation specifications

Implementation standards

Interoperability requirements

Constraints


97

Assumptions

Business Requirements

Gap analysis results

Technical requirements — identifying, categorising, and prioritising the implications for work in the

remaining architecture domains, for example...

o by a dependency / priority matrix (the could guide trade-off between speed of transaction processing and security);

o list the specific models that are expected to be produced (for example, expressed as primitives of the Zachman Framework)

Updated business requirements

Security

Determine who are the legitimate actors who will interact with the product / service / process

Assess and baseline current security-specific business processes (enhancement of existing objective)

Determine whom/how much it is acceptable to inconvenience in utilising security measures

Identify and document interconnecting systems beyond project control

Determine the assets at risk if something goes wrong — ‘‘what are we trying to protect?’’

Determine the cost (both qualitative and quantitative) of asset loss / impact in failure cases

Identify and document the ownership of assets

Determine and document appropriate security forensic processes

Identify the criticality of the availability and correct operation of the overall service

Determine and document how much security (cost) is justified by the threats and the value of the assets at risk

Reassess and confirm Architecture Vision decisions

Assess alignment or conflict of identified security policies with business goals

Determine ‘‘what can go wrong?’’

Summary

Business Architecture documents the fundamental organisation of a business, embodied in its business processes and people, their relationships to each other and the environment, and the principles governing its design and evolution.

It should show how the organisation meets its business goals.


98

Phase C – Information Systems Architecture

Session Objectives

This module focuses on the Information Systems Architecture Phase’s

Objectives

Approach

Steps

Inputs

Outputs

The purpose of this module is to help understand how the Information Systems Architecture Phase contributes to the success of enterprise architecture.

Phase Objectives

The purpose of this composite phase is to:

Develop the Target Information Systems (Data and Application) Architecture, describing how the enterprise’s Information Systems Architecture will enable the Business Architecture and the Architecture Vision, in a way that addresses the Request for Architecture Work and stakeholder concerns

Identify candidate Architecture Roadmap components based upon gaps between the Baseline and Target Information Systems (Data and Application) Architectures

Approach

To develop the Data and / or Applications Architectures in either order.

Although advocates exist for a:

Data-driven approach, such as Steven Spewak’s Enterprise Architecture Planning

Application-driven approach, when introducing a new Package (particularly one of major importance such as an ERP Application), it is sometimes preferred to focus on the implementation and integration issues first


Assets residing in the repository should be considered:

Data

ARTS (retail)

Energistics (energy industry)

Application

TeleManagement Forum (telecomms)

OMG software models, and MDA (Model-driven Architecture)


99

Inputs, Outputs and Steps

Inputs / Outputs will be dealt with in the detailed sections that follow.

Steps are:

Develop the Data Architecture

Develop the Application Architecture

Security considerations

Assess and baseline current security-specific architecture elements

Identify safe default actions and failure states

Identify and evaluate applicable guidelines and standards

Revisit assumptions regarding interconnecting systems beyond project control

Determine and document sensitivity or classification level of information

Identify and document custody of assets

Identify the criticality of availability and correct operation of each function

Determine the relationship of system with existing business disaster / continuity plans

Identify what aspects of the system must be configurable to reflect changes in policy / business environment

Identify lifespan of information as required by the business or regulation

Determine approaches to address identified risks

Identify actions / events that warrant logging for later review or triggering forensic processes

Identify and document requirements for rigor in proving accuracy of logged events (non-repudiation)

Identify potential / likely avenues of attack


Summary

The purpose of this composite phase is to:

Define the types and sources of data needed to support the business, and do so in a way that can be understood by stakeholders

Define the kinds of application systems necessary to process the data, and what they do to support the business


100

Phase C – Data Architecture

Session Objectives

This module focuses on the Data Architecture Phase’s

Objectives

Approach

Inputs

Steps

Outputs

The purpose of this module is to help understand how the Data Architecture Phase contributes to the success of enterprise architecture.

Phase Objectives

Develop the Target Data Architecture that enables the Business Architecture and the Architecture Vision, while addressing the Request for Architecture Work and stakeholder concerns


Target Data Architectures

Approach

Key considerations are:

Data Management

Data Migration

Data Governance

Data Management

Definition of which application components in the landscape will serve as the system of record / reference for enterprise master data

Will there be an enterprise-wide standard that all application components, including software packages, need to adopt (in the main packages can be prescriptive about the data models and may not

be flexible)?

Understand how data entities are utilised by business functions, processes and services – data dissemination

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 the enterprise’s customers and suppliers (e.g. use of ETL tools during the data migration, data profiling tools to evaluate data quality, etc.)?

Data Migration

When migrating data:

Identify affected data items

Consider how much transformation, weeding and cleansing may be required

Ensure an enterprise-wide common data definition is established


101

Data Governance

The key areas are:

Structure and standards within the organisation to manage data

Management Systems and data-related programmes that govern data throughout its lifecycle

People, in the form of appropriately skilled Data Architects and formal data roles

Inputs



Communications Plan



Data principles


Architecture Vision


Draft Architecture Definition Document, containing:

o Baseline Business Architecture (detailed)


o Baseline Data Architecture (high-level)

o Target Data Architecture (high-level)

o Baseline Application Architecture (detailed or vision)

o Target Application Architecture (detailed or vision)

o Baseline Technology Architecture (vision)

o Target Technology Architecture (vision)

Draft Architecture Requirements Specification, including:


o Relevant technical requirements

Business Architecture components of an Architecture Roadmap

Data Principles

Data is an Asset

Data is Shared

Data is Accessible

Data Trustee

Common Vocabulary and Data Definitions

Data Security


102

Steps


2. Develop Baseline Data Architecture Description

3. Develop Target Data Architecture Description


5. Define candidate roadmap components



8. Finalise the Data Architecture


Note: technically speaking, the Architecture Definition Document is created in Phase A (as per this most recent

version).

Step Summary


See future slides.


Bearing in mind the scope and level or detail, identify baseline Data Building Blocks.


Repeat Step 2 focusing on the Target Architecture Building Blocks.


Using the Gap Analysis technique, identify gaps between Baseline and Target.










See future slides.


103

Selecting Reference Models

Modelling techniques: Entity Relationship Diagrams, Class Diagrams.

Data Models: ARTS (retail) model, Energistics Data Model.

Modelling process includes:

Collect data-related models from existing Business Architecture and Application Architecture materials

Rationalise data requirements and align with any existing enterprise data catalogs and models; this allows the development of a data inventory and entity relationship

Update and develop matrices across the architecture by relating data to business service, business function, access rights, and application

Elaborate Data Architecture views by examining how data is created, distributed, migrated, secured, and archived

Data Artifacts


104

Outputs


Validated principles, or new data principles


o Baseline Data Architecture

o Target Data Architecture

o Data Architecture views of key stakeholder concerns



o Data interoperability requirements


o Constraints on the Technology Architecture

o Updated business (and application) requirements

Data Architecture components of an Architecture Roadmap

Data Architecture in the ADD

Baseline Data Architecture, Version 1.0, if appropriate

Target Data Architecture, Version 1.0

o Business data model

o Logical data model

o Data management process models

o Data Entity / Business Function matrix

o Views corresponding to the selected viewpoints addressing key stakeholder concerns

Data Architecture in the ARS


Data interoperability requirements

Relevant technical requirements that will apply to this evolution of the architecture development cycle

Constraints on the Technology Architecture about to be designed

Updated business requirements, if appropriate

Updated application requirements, if appropriate

Summary

The Data Architecture phase defines the types and sources of data needed to support the business, and does so in a way that can be understood by stakeholders.


105

Phase C – Application Architecture

Session Objectives

This module focuses on the Application Architecture Phase’s

Objectives

Approach

Inputs

Steps

Outputs

The purpose of this module is to help understand how the Application Architecture Phase contributes to the success of enterprise architecture.

Phase Objectives

Develop the Target Application Architecture that enables the Business Architecture and the Architecture Vision, while addressing the Request for Architecture Work and stakeholder concerns


Target Application Architectures

Approach

Application Repository

TeleManagement Forum (telecomms), which includes:

o TeleManagement Forum – a set of application models in Telecomms sector (TAM)

OMG software models, and MDA (Model-driven Architecture)

Integrated Information Infrastructure Reference Model (III-RM)


106

Inputs



Communications Plan



Application principles


Architecture Vision





o Baseline Data Architecture (detailed or high-level)

o Target Data Architecture (detailed or high-level)

o Baseline Application Architecture (high-level)

o Target Application Architecture (high-level)






Business and Data Architecture components of an Architecture Roadmap

Application Principles

Technology Independence

Ease-of-Use


107

Steps

1. Select reference models, viewpoints, and tools.

2. Develop Baseline Application Architecture Description.

3. Develop Target Application Architecture Description.

4. Perform gap analysis.

5. Define candidate roadmap components.

6. Resolve impacts across the Architecture Landscape.

7. Conduct formal stakeholder review.

8. Finalise the Application Architecture.

9. Create Architecture Definition Document.


version).

Step Summary


See future slides.


Bearing in mind the scope and level or detail, identify baseline Application Building Blocks.














See future slides.


108

Selecting Reference Models, Viewpoints and Tools

Check external sources such as TmF, OMG, Application Vendors

Consider the following process:

o 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

o Identify logical applications and the most appropriate physical applications

o Develop matrices across the architecture by relating applications to business service, business function, data, process, etc.

o Elaborate a set of Application Architecture views by examining how the application will function, capturing integration, migration, development, and operational concerns

Application Artifacts


109

Outputs


Validated principles, or new principles (application)


o Baseline Application Architecture

o Target Application Architecture

o Application Architecture views of key stakeholder concerns



o Application interoperability requirements

o Relevant technical requirements Constraints on the Technology Architecture

o Updated business and data requirements

Application Architecture components of an Architecture Roadmap

Application Architecture in the ADD

Baseline Application Architecture, Version 1.0, if appropriate

Target Application Architecture, Version 1.0

o Process systems model

o Place systems model

o Time systems model

o People systems model

Application Architecture in the ARS


Applications interoperability requirements

Relevant technical requirements that will apply to this evolution of the architecture development cycle

Constraints on the Technology Architecture about to be designed

Updated business requirements, if appropriate

Updated data requirements, if appropriate

Summary

In this section we have looked at how to develop a Target Application Architecture that enables the Business Architecture and the Architecture Vision, while addressing the Request for Architecture Work and stakeholder concerns.


110

Phase D – Technology Architecture (and TRM/III-RM)

Session Objectives

This module focuses on the Technology Architecture Phase’s

Objectives

Approach

Inputs

Steps

Outputs

This module also includes an examination of the TRM and III-RM

Phase Objectives

Develop the Target Technology Architecture that enables the logical and physical application and data components and the Architecture Vision, addressing the Request for Architecture Work and stakeholder concerns

Identify candidate Architecture Roadmap components based upon gaps between the Baseline and Target Technology Architectures

Approach

Using the Architecture Repository consider:

Existing IT services as documented in the IT repository or IT service catalogue

TOGAF Technical Reference Model (TRM)

Generic technology models relevant to the organisation’s industry ‘‘vertical’’ sector

Technology models relevant to Common Systems Architectures


111

Inputs


Business principles, business goals and business drivers


Communications Plan




Architecture principles, including business principles, when pre-existing

Enterprise Continuum





o Baseline Data Architecture (detailed)

o Target Data Architecture (detailed)

o Baseline Application Architecture (detailed)

o Target Application Architecture (detailed)






Business, Data and Application Architecture components of an Architecture Roadmap

Technology Principles

Requirements-based Change

Responsive Change Management

Control Technical Diversity

Interoperability


112

Steps

1. Select reference models, viewpoints, and tools.

2. Develop Baseline Technology Architecture Description.

3. Develop Target Technology Architecture Description.

4. Perform gap analysis.

5. Define candidate roadmap components.

6. Resolve impacts across the Architecture Landscape.

7. Conduct formal stakeholder review.

8. Finalise the Technology Architecture.

9. Create Architecture Definition Document.


version).

Step Summary


See future slides.


Bearing in mind the scope and level or detail, identify baseline Technology Building Blocks.














See future slides.


113

Technology Artifacts and ABBs

Use the Technology viewpoints to provide the necessary modelling

Existing ABBs could be found in the Foundation Architecture, as described by the TRM

Outputs


Validated business principles, business goals, and business drivers

Elaborated Business Architecture principles

Draft Architecture Definition Document containing content updates:

o Baseline Technology Architecture (detailed), if appropriate

o Target Technology Architecture (detailed)

o Views corresponding to selected viewpoints addressing key stakeholder concerns

Draft Architecture Requirements Specification including content updates:


o Requirements output from Phases B and C

o Updated technology requirements

Technology Architecture components of an Architecture Roadmap


114

Technology Architecture in the ADD

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

Technology Architecture in the ARS


Requirements output from Phases B and C

Updated technology requirements

Security

Assess and baseline current security-specific technologies

Revisit assumptions on interconnecting systems beyond system control

Identify and evaluate applicable recognised guidelines and standards

Identify methods to regulate consumption of resources

Engineer a method by which the efficacy of security measures will be measured and communicated

Identify the trust (clearance) level of users, administrators, interconnecting systems beyond system control

Identify minimal privileges required for any entity to achieve a technical or business objective

Identify mitigating security measures, where justified by risk assessment


Summary

Develop the Target Technology Architecture that enables the logical and physical application and data components and the Architecture Vision, addressing the Request for Architecture Work and stakeholder concerns.


115

Technical Reference Model – TRM

Overview

Describes a Foundation Architecture – an architecture of generic services and functions on which more specific architectures or components can be built. Consists of

A taxonomy

The TRM Graphic

At its highest level, two qualities are emphasised (that in combination enable better integration within and between enterprises):

Application Portability, via the Application Platform Interface - identifying the set of services that are to be made available in a standard way to applications via the platform

Interoperability, via the Communications Infrastructure Interface - identifying the set of Communications Infrastructure services that are to be leveraged in a standard way by the platform

Both of these goals are essential to enable integration within the enterprise and trusted interoperability on a global scale between enterprises.

TRM Views

Main Categories

Application Software

o Business Applications (customer facing, “front office”)

o Infrastructure Applications (utilities, usually COTS-based, i.e. transfers services, mail clients, groupware, “office packages”, software engineering

Application Platform a single generic concept of a platform providing all possible services to the software. Particularly provide support to Infrastructure Software

Application Platform Interface promotes application portability especially for those sharing a programmatic interface, protocol and data structure

Communications Infrastructure Interface of which the Internet is a prime example

Qualities such as manageability, security and general non-functional based performance


116

Application Platform Service Categories

Graphics and Imaging

Data Management

Data Interchange

User Interface

International Operation

Location and Directory

Transaction Processing

Security

Software Engineering

System and Network Management

Application Platform Service Qualities

Availability

o Manageability

o Serviceability

o Performance

o Reliability

o Recoverability

o Locatability

Assurance

o Security

o Integrity

o Credibility

Usability

o International Operation

Adaptability

o Interoperability

o Scalability

o Portability

o Extensibility

Tailoring the TRM

TRM based on TAFIM (Technical Architecture Framework for Information Management, which originated in the 80s), but updated to emphasise interoperability and portability

However other models could be used:

o Legacy models

o Alternative models derived from the TRM but with suitable variations in categories

The TRM graphic could also be adjusted

Each “box” within the TRM could be regarded as representing [foundation] “Building Blocks”. Each

BB should comply / conform with standards


117

Integrated Information Infrastructure Reference Model – III-RM

Boundaryless Information Flow

“Getting information to the right people at the right time in a secure, reliable manner”. Those people could be inside or outside the organisation (extended enterprise)

Boundaryless doesn’t necessarily mean “no boundaries” – more that any boundaries should be

“permeable”

“Permeability” is achieved by

o Integrated Information

o Integrated access to information

Solution – an “Integrated Information Infrastructure”

III-RM High Level Structure

The III-RM is a subset of the TOGAF TRM in terms of its overall scope, but it also expands certain parts of the TRM - in particular, the business applications and infrastructure applications parts - in order to provide help in addressing one of the key challenges facing the enterprise architect today: the need to design an integrated information infrastructure to enable Boundaryless Information Flow.


118

III-RM High-level Structure

Components

Business Applications

o Information Provider Applications – that are connected to the data or servers

o Information Consumer Applications – that deliver content to the user

o Brokering Applications – that manage link between requestor (consumer) and responder (provider)

Infrastructure Applications

o Development Tools to model, design and construct the apps above

o Management Utilities to understand, operate, tune and manage run-time systems

Application Platform supply supporting services (see TRM)

Interfaces: api’s, formats, protocols

Qualities: see TRM


119

III-RM Detailed Structure

Summary

We have also looked at the TRM and III-RM. Together they look at the concept of a Foundation Architecture, and the way Applications communicate with each other.


120

Phase E – Opportunities and Solutions

Session Objectives

This module focuses on the Opportunity and Solutions Phase’s

Objectives

Approach

Inputs

Steps

Outputs

Phase Objectives

Generate the initial complete version of the Architecture Roadmap, based upon the gap analysis and

candidate Architecture Roadmap components from Phases B, C, and D

Determine whether an incremental approach is required, and if so identify Transition Architectures that will deliver continuous business value

Approach

Based on the gaps identified in previous phases, and a review of requirements, readiness and constraints, consider how to develop the target architecture by documenting:

An architecture listing individual work packages in a timeline that will realize the Target Architecture.

Work packages identifying logical groups of changes necessary to realize the Target Architecture.

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

An Implementation and Migration Plan providing a schedule of the projects that will realize the Target Architecture.

The Architecture Roadmap will also refer to all stakeholders that have contributed requirements.

Inputs

Product Information



Communications Plan

Planning Methodologies



Architecture Vision


Draft Architecture Definition Document

Draft Architecture Requirements Specification

Change Requests for existing programs and projects

Candidate Architecture Roadmap components from Phases B, C, D


121

Steps

1. Determine / confirm key corporate change attributes.

2. Determine business constraints for implementation.

3. Review and consolidate gap analysis (from Phases B-D).

4. Review consolidated requirements across functions.

5. Consolidate and reconcile interoperability requirements.

6. Refine and validate dependencies.

7. Confirm readiness and risk for business transformation.

8. Formulate high-level Implementation and Migration Strategy.

9. Identify and group major work packages.

10. Identify Transition Architectures.

11. Create Architecture Roadmap and Implementation / Migration Plan.

Step Summary

1. Determine/confirm key corporate change attributes

Use Implementation Factor Assessment and Deduction matrix to assess change.

2. Determine business constraints for implementation

Constraints include drivers, plans, and a review of Enterprise Architecture Maturity.

3. Review and consolidate gap analysis results from Phases B to D

See future slide.

4. Review IT requirements from a functional perspective

Look to rationalise and simplify Functional Requirements with a view to providing shared services.

5. Consolidate and reconcile interoperability requirements

Interoperability considerations are initiated in Phase A. Pay particular attention to Business Process interoperability, where differences in process can sometimes run counter to principles such as reuse.

6. Refine and validate dependencies

This includes Business, Information, Workflow, IT and Foundation dependencies.

7. Confirm readiness and risk for business transformation

Return to the Business Transformation Readiness and Risk Assessment techniques initiated in Phase A.

8. Formulate high-level Implementation and Migration Strategy

See future slide.

9. Identify and group major work packages

See future slide.

10. Identify Transition Architectures

See future slide.


122

11. Create Architecture Roadmap and Implementation/Migration Plan

A project/portfolio charter consists of capabilities delivered, included work packages, business value, RAID (risk, assumptions, issues, dependencies) – i.e. outcomes delivered, their value and risk. From this create the transition architecture and update overall architecture. The narrower the scope, the more definitive should be the list of targeted capabilities.

Determine and Confirm Key Corporate Change Attributes

How the EA can best be implemented to take advantage of business culture

Use the Implementation Factor Assessment and Deduction Matrix:

Review and Consolidate Gap Analysis

Using the Consolidated Gaps, Solutions and Dependencies Matrix:


123

Implementation and Migration Strategy

Overall strategic approach could be:

o Greenfield start from the beginning

o Revolutionary radical, big-bang, re-engineer

o Evolutionary convergence strategy needed, phased, process improvement

Implementation Approach could include:

o Quick Win

o Achievable Target

o Value Chain Method (Nascio method)

(NASCIO: North American Association of Chief Information Officers)

Identify and Group Work Packages

The need is to organise the Work Packages to account for:

o strategic implementation direction and approach, as outlined in the Implementation Factor Assessment and Deduction matrix

o Dependencies, as outlined in the Consolidated Gaps, Solutions and Dependencies matrix. Consider each gap, decide on moving towards:

o New Development

o Reuse or purchase

The resulting work packages could be grouped as

o Mainstream Systems

o Contain Systems (replaceable within 3 years)

o Replace Systems (replaceable shortly)


124

Transition Architectures

Use the Architecture Definition Increments Table:

Outputs


Architecture Vision, updated if necessary

Draft Architecture Definition Document, including content updates for:

o Transition Architecture, number and scope, if any

Draft Architecture Requirements Specification, updated if necessary

Capability Assessment, including content updates for:

o Business and IT Capability

Architecture Roadmap, including

o Work Package Portfolio

o Identification of Transition Architectures, if any

o Implementation recommendations

Outline Implementation and Migration Plan and strategy

Security

Identify existing security services available for re-use

Engineer mitigation measures addressing identified risks

Evaluate tested and re-usable security software and security system resources

Identify new code / resources / assets that are appropriate for re-use


Summary

Generate the initial complete version of the Architecture Roadmap, based upon the gap analysis and candidate Architecture Roadmap components from Phases B, C, and D.


125

Phase F – Migration Planning

Session Objectives

This module focuses on the Migration Planning Phase’s

Objectives

Approach

Inputs

Steps

Outputs

Phase Objectives

Finalise the Architecture Roadmap and the supporting Implementation and Migration Plan

Ensure that the Implementation and Migration Plan is coordinated with the enterprise's approach to managing and implementing change in the enterprise's overall change portfolio

Ensure that the business value and cost of work packages and Transition Architectures is understood by key stakeholders

Approach

This is the place where detailed planning is needed, particularly focussing on:

o Dependencies

o Costs and Benefits

o Risks

This will inevitable require co-ordination with management activities such as:

o Project

o Programme


126

Inputs


Communications Plan


Governance Models and Frameworks



Architecture Vision


Draft Architecture Definition Document, including:

o Transition Architectures if necessary

Draft Architecture Requirements Specification

Change Requests for existing programs and projects


Capability Assessment, including Business and IT Capability

Transition Architectures

Implementation and Migration Plan (outline) including high-level Implementation and Migration Strategy

Steps

1. Confirm management framework interactions for the Implementation and Migration Plan

2. Assign a business value to each work package

3. Estimate resource requirements, project timings, and availability/delivery vehicle

4. Prioritise the migration projects through the conduct of a cost/benefit assessment and risk validation

5. Confirm Architecture Roadmap and update Architecture Definition Document

6. Complete Implementation and Migration Plan

7. Complete development cycle and document lessons learned


127

Step Summary

1. Confirm management framework interactions for Implementation and Migration Plan

See future slide.

2. Assign a business value to each project

See future slide.

3. Estimate resource requirements, project timings, and availability/delivery vehicle

Resources/costs include people, office/IT infrastructure, training, operations, and maintenance. Project timings should take account of each SBB timing (set in step 5 of phases B-D). Delivery vehicle could be provided internally, externally by contract, or a mixture.

4. Prioritise the migration projects through the conduct of a cost/benefit assessment and risk validation

See future slide.

5. Confirm Architecture Roadmap and update Architecture Definition Document

See future slide.

6. Complete Implementation and Migration Plan

Confirm Enterprise Architecture evolution and state; create the detailed Implementation and Migration plan.

7. Complete development cycle and document lessons learned

Lesson learned will be used in connection with influencing Architecture Capability.

Management Framework Interaction

The key frameworks where interaction may be required are:

Business Planning (including Business Transformation)

Enterprise Architecture (and IT planning)

Portfolio / Project Management

Operations Management


128

Business Value

Consider criteria for establishing business value:

o Performance Evaluation Criteria used to approve and monitor progress of architecture transformation

o Return on Investment

o Business Value (see NASCIO EA Value Chain)

o Critical Success Factors

o Measures of effectiveness which can be expressed as performance criteria

o Strategic Fit based on overall enterprise architecture

Create a value-index (compliance to principles, value as above) and a risk index (size, complexity, technology, organisational capacity and impact of failure). Then perform a Business Value and Risk Assessment...

Business Value Assessment Technique


129

Prioritise Migration Projects

1. Derive Cost Benefit Analysis for the Migration Projects

2. Validate the Risk Assessment (the Consolidated Gaps, Solutions and

Dependencies Report can be used here)

3. Prioritise the Projects. Examples that could affect priorities are:

o Reduction of costs

o Consolidation of services

o Ability to handle change

o A goal to have a minimum of ‘‘interim’’ solutions (they often become long-term / strategic!)

Confirm Architecture Roadmap

1. Confirm Transition Architecture Time-Spans

2. Take into account Business Value; Capability; Risk

3. Then consolidate deliverables, to create a revised Architecture Roadmap

State Evolution Table

This technique looks at the evolution of the Solution Building Blocks, mapped to the TRM

Use in conjunction with Architecture Definition Increments Table


130

Outputs

Implementation and Migration Plan (detailed) including

o Implementation and Migration Strategy

o Project and Portfolio Breakdown

o Project Charters (optional)

Finalised Architecture Definition Document and Transition Architectures if any (see Deliverables for detailed headings of document)

Finalised Architecture Requirements Specification

Finalised Architecture Roadmap

Re-Usable Architecture Building Blocks

Requests for Architecture Work for the architecture aspects of implementation projects (if any)

Implementation Governance Model

Change Requests for Architecture Capability arising from lessons learned

Implementation and Migration Plan

Typical contents are...

Implementation and Migration Strategy

Project and Portfolio breakdown:

o Capabilities delivered by projects

o Included work packages

o Business value

o Risk, issues, assumptions, dependencies

Project charters:

Related work packages

Business value

Risk, issues, assumptions, dependencies

Resource requirements and costs

Benefits of migration

Estimated costs of migration options

Security

Assess the impact of new security measures upon other new components or existing leveraged systems

Implement assurance methods by which the efficiency of security measures will be measured and communicated on an ongoing basis

Identify correct secure installation parameters, initial conditions, and configurations

Implement disaster recovery and business continuity plans or modifications



131

Summary

The Migration Planning Phase addresses migration planning; that is, how to move from the Baseline to the Target Architectures. It includes creating the finalised Architecture Definition Document and the detailed Implementation and Migration Plan. After completion of this phase the preparation for implementation has been completed.


132

Phase G – Implementation Governance

Session Objectives

This module focuses on the Implementation Governance Phase’s

Objectives

Approach

Inputs

Steps

Outputs

Phase Objectives

Ensure conformance with the Target Architecture by implementation projects

Perform appropriate Architecture Governance functions for the solution and any implementation-driven architecture Change Requests

Approach

This is where the plans have to be put into action – an Implementation Programme that properly reflects:

Business priorities

Organisational standards

Existing Programme or Project management approach

Operational considerations

A vital link between the implementing organisation and architecture is established through an overall Architecture Contract. Project details are recorded:

Name, description, and objectives

Scope, deliverables, and constraints

Measures of effectiveness

Acceptance criteria

Risks and issues

Ensuring compliance with defined architecture(s) by both implementation projects and other ongoing projects.


133

Inputs






Architecture Vision


Architecture Definition Document




Architecture Contract

Request for Architecture Work identified in Phases E and F


Steps

1. Confirm scope and priorities for deployment with development management

2. Identify deployment resources and skills

3. Guide development of solutions deployment

4. Perform enterprise architecture compliance reviews

5. Implement business and IT operations

6. Perform post-implementation review and close the implementation and Migration Plan


134

Step Summary

1. Confirm scope and priorities for deployment with development management

Review migration planning outputs and produce deployment recommendations; identify enterprise architecture priorities; recommend on deployment issues; identify BBs for replacement / update etc.; identify gaps in Enterprise Solution Framework (current enterprise SBBs) and specific BBs that fill those gaps; produce Gap Analysis report.

2. Identify deployment resources and skills

Consider system development methods (i.e. developers, languages used); ensure development feedback can be given to the architects.

3. Guide development of solutions deployment

Formulate project recommendations; document Architecture Contract; update repository; guide development of business and IT Operating models; derive service requirements; guide definitions of business and IT operational requirements; do Gap Analysis between Solution Architecture and operations; produce implementation plan.

4. Perform enterprise architecture compliance reviews

See Governance chapter.

5. Implement business and IT operations

Carry out deployment projects such as IT or Business Service Delivery implementation; communications document publication.

6. Perform post-implementation review and close the implementation

Closure takes place when solutions are fully deployed once.

Outputs

Architecture Contract (signed)


Change Requests

Impact Analysis – Implementation

Recommendations

Architecture-compliant solutions deployed, including:

o The architecture-compliant implemented system

o Populated Architecture Repository

o Architecture compliance recommendations and dispensations

o Recommendations on service delivery requirements

o Recommendations on performance metrics

o Service Level Agreements (SLAs)

o Architecture Vision, updated post-implementation

o Architecture Definition Document, updated post implementation

o Business and IT operating models for the implemented solution


135

Architecture Contract Contents


Contract between Architecture Design and Development Partners

o Introduction and background

o The nature of the agreement

o Scope of the architecture

o Architecture and strategic principles and requirements

o Conformance requirements

o Architecture development and management process and roles

o Target architecture measures

o Defined phases of deliverables

o Prioritised joint work plan

o Time window(s)

o Architecture delivery and business metrics

Contract between Architecting Function and Business Users

o Introduction and background

o The nature of the agreement

o Scope

o Strategic requirements

o Architecture deliverables that meet the business requirements

o Conformance requirements

o Architecture adopters

o Time window

o Architecture business metrics

o Service architecture (includes Service Level Agreement (SLA))

Relationship of AC to Architecture Governance

To ensure effectiveness of these contracts, the following governance aspects may need to be introduced:

Simple processes

People-centred authority

Strong communication

Timely responses and an effective escalation process

Supporting organisational structures

Status tracking of architecture implementation

Security

Establish architecture artifact, design, and code reviews and define acceptance criteria for the successful implementation of the findings

Implement methods and procedures to review evidence produced by the system that reflects operational stability and adherence to security policies

Implement necessary training to ensure correct deployment, configuration, and operations of security-relevant subsystems and components; ensure awareness training of all users and non-privileged operators of the system and / or its components

Determine ‘‘what has gone wrong?’’


136

Risk Monitoring

The residual risk has to be accepted and approved

Mitigation measures need to be monitored

Sometimes risks can be identified in this phase that require another partial or full circuit of the ADM

Sample Risk Identification and Mitigation Worksheet

Summary

The Implementation Governance Phase defines architecture constraints on the implementation projects and obtains signatures on an Architecture Contract. The contract, along with all the documentation, is then delivered to the implementation team. This phase includes governing the architecture through implementation by conducting compliance reviews, and by risk monitoring as well as post-implementation reviews.


137

Phase H – Change Management

Session Objectives

This module focuses on the Change Management Phase’s

Objectives

Approach

Inputs

Steps

Outputs

Phase Objectives

Ensure that the architecture lifecycle is maintained

Ensure that the Architecture Governance Framework is executed

Ensure that the enterprise Architecture Capability meets current requirements

Change Management Approach (1)

Consider drivers for change that can be:

Strategic (top-down) architecture to enhance or create new capability

Bottom-up to correct or enhance current infrastructure

Changes to previously delivered projects (now operational) that are related to ongoing projects

Requests for Change (RFCs) handled by Architecture Board. RFCs could be:

o Technology-based: new technology, asset management cost reductions, technology withdrawal, change in standards

o Business-based: “BaU” developments, exceptions, innovations, business technology innovations, strategic change


Consider Enterprise Architecture Change Management Process, often handled by existing frameworks such as ITIL, PRINCE2. Change can be about:

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


138


Consider Guidelines for Maintenance versus Re-Design. A good rule-of-thumb is:

If the change impacts two stakeholders or more, then it is likely to require an architecture redesign and

re-entry to the ADM.

If the change impacts only one stakeholder, then it is more likely to be a candidate for change

management.

If the change can be allowed under a dispensation, then it is more likely to be a candidate for change

management.

For example:

Re-architecting - If the impact is significant for the business strategy, then there may be a need to redo

the whole enterprise.

Incremental Change - If a new technology or standards emerge, then there may be a need to refresh the

Technology Architecture, but not the whole enterprise architecture.

Change management techniques - If the change is at an infrastructure level - for example, ten systems

reduced or changed to one system - this may not change the architecture above the physical layer, but it

will change the Baseline Description of the Technology Architecture. This would be a simplification change

handled via change management techniques

Inputs

Request for Architecture Work identified in Phases E and F




Architecture Vision


Architecture Definition document



Change Requests due to technology changes

Change Requests due to business changes

Change Requests from lessons learned


Architecture Contract (signed)




139

Change Requests

Changes can arise because:

o During implementation circumstances may give rise to deviation from plan, or a change the

scope

o At any time, changes (i.e. business, technology) may require revision of architecture

A Change Request would typically contain:

o Description of the proposed change

o Rationale for the proposed change

o Impact assessment of the proposed change, including:

Reference to specific requirements

Stakeholder priority of the requirements to date

Phases to be revisited

Phase to lead on requirements prioritisation

Results of phase investigations and revised priorities

Recommendations on management of requirements

o Repository reference number

Steps

1. Establish Value Realisation process

2. Deploy Monitoring Tools

3. Manage Risks

4. Provide Analysis for Architecture Change Management

5. Develop Change Requirements to meet Performance Targets

6. Manage Governance Process

7. Activate the process to implement Change


140

Step Summary

1. Establish value realisation process

Exploit enterprise architecture in order to realise value (benefit/outcome) to the business.

2. Deploy monitoring tools

Monitor business, technology, on-going business value, architecture capability maturity, asset management programs, QoS, business continuity.

3. Manage risks

Use risk assessment to provide recommendations for IT strategy.

4. Provide analysis for architecture change management

Analyse and review performance – especially with Service Management; assess change requests to ensure value is realised and service level expectation met; identify gaps in performance of enterprise architecture; ensure change management requests adhere to architecture governance.

5. Develop change requirements to meet performance targets

From the above, make recommendations on change requirements.

6. Manage governance process

Arrange and then hold Governance Board meetings to discuss changes and dispensations, and make decisions.

7. Activate the process to implement change

Produce a new Request for Architecture Work; capture implemented changes and document in architecture repository.

Outputs

Architecture updates

Changes to architecture framework and principles

New Request for Architecture Work, to initiate another cycle of the ADM in response to change


Architecture Contract, updated if necessary

Compliance Assessments, updated if necessary

Security

Determine ‘‘what has gone wrong?’’

Incorporate security-relevant changes to the environment into the requirements for future enhancement (enhancement of existing objective)

Summary

The Change Management Phase ensures that changes to the architecture are managed in a cohesive and controlled manner in line with the Architecture Governance processes.

It also establishes and supports the enterprise architecture to provide flexibility to evolve the architecture rapidly in response to changes in the technology or business environment.


141


Session Objectives

This module focuses on Requirements Management

Objectives

Approach

Inputs

Steps

Outputs

Phase Objectives

Ensure that the Requirements Management process is sustained and operates for all relevant ADM phases. Crucial to this process is the recording of all requirements, impact analysis of changed requirements, and adjustment of any gaps

Manage architecture requirements identified during any execution of the ADM cycle or a phase

Ensure that relevant architecture requirements are available for use by each phase as the phase is executed

Approach

Generally, the ADM must be able to respond to the dynamic environment

At all phases of architecture requirements must be considered, as well as constraints, principles, policies and standards

Useful resources

o Business Scenarios

o Requirements tools (see volere.co.uk/tools.htm)

Inputs

The inputs to the Requirements Management process are the requirements-related outputs from each ADM phase

The first high-level requirements are produced as part of the Architecture Vision

Each architecture domain then generates detailed requirements. Deliverables in later ADM phases contain mappings to new types of requirements (for example, conformance requirements)


142

Steps – Phase / Requirements Management Related

1. Identify / document requirements.

2. Baseline requirements – determine priorities; confirm stakeholder buy-in; record priorities.

3. Monitor baseline requirements.

4. Identify changed requirements – remove; add; modify; and re-assess priorities.

5. Identify changed requirements and record priorities – identify and resolve conflicts; generate requirements impact statements.

6. Assess impact of changed requirements on current and previous ADM phases; decide whether to do something now or later; issue requirements impact statement.

7. Implement requirements arising from Phase H (catches changes from Phase H and ensures proper consideration.

8. Update the requirements repository.

9. Implement change in the current phase.

10. Assess and revise gap analysis for past phases, using Gap Analysis technique.

N.B. Phase-related steps shown in bold.

Outputs

Changed requirements

Requirements Impact Assessment, which identifies the phases of the ADM that need to be revisited to address any changes. The final version must include the full implications of the requirements (e.g. costs, timescales, and business metrics)

Security

New Security Requirements arise from:

1. A new statutory or regulatory mandate.

2. A new threat realised or experienced.

3. A new IT architecture initiative discovers new stakeholders and / or new requirements.

Other considerations:

Is our security good?

Nothing useful can be said about a security measure outside the context of an application, or a system and its environment

Summary

Requirements Management is an ongoing activity of the ADM. The requirements repository contains the current requirements for the Target Architecture.


143

Architecture Partitioning

Objectives


Describe the purpose of Partitioning

Consider Architecture and Solutions in the context of partitioning

Employing Architecture Partitioning

Overview

In a complex enterprise there can be many architectures, at different stages and describing different levels of detail (architectures and solutions). Partitioning is a way dealing with this complexity because...

Architecture is complex

Different architectures conflict with one another

Different teams need to work on different elements of architecture at the same time

Effective architecture re-use requires modular architecture segments

Characteristics of Solutions

Characteristics of Architectures


144

Applying Partitioning in Preliminary Phase

Determine the organisation structure for architecture within the enterprise establish standing teams for each main partition:

o Governance bodies applicable to the team

o Team Membership

o Team reporting lines

Determine the responsibilities for each standing architecture team further partitioning may be needed for each team defining:

o Subject Matter

o Level of Detail

o Time periods the architecture should cover

o Stakeholders

Determine the relationships between architectures consider:

o Architecture overlap / dovetail / drill-down

o Compliance requirements between architectures

Integrating Architecture Partitions

Creation of partitioned architectures runs the risk of producing a fragmented and disjointed collection of architectures that cannot be integrated to form an overall big picture

For large complex enterprises, federated architectures - independently developed, maintained, and managed architectures that are subsequently integrated within an integration framework - are typical. Such a framework should specify the principles for interoperability, migration and conformance. This allows specific business units to have architectures developed and governed as stand-alone architecture projects

In order to mitigate against this risk, standards for content integration should be defined and architecture governance should address content integration as a condition of architectural compliance

Summary

In a complex enterprise there can be many architectures, at different stages and describing different levels of detail (architectures and solutions). Partitioning is a way dealing with this complexity.


145

Adapting the ADM

Objectives

We will be looking at...

Iterations

o The concept of iteration and how it applies to TOGAF

o Factors influencing the use of iteration

o Suggested iteration cycles, and their application to the ADM

Levels

o Identifying and applying different ADM levels within an Enterprise

o Architecture engagement

o Combining levels and iterations

Security (which has mainly been covered in previous chapters)

SOA

o SOA as an Architectural Style

o How the TOGAF Metamodel supports SOA

o How Enterprise Architecture supports SOA

Iterations

The ADM is not a sequential process – it can take many iterations, and cycles through the phases.

Iteration can be used:

Each cycle through the ADM is bound to a Request for Architecture Work, intended to either extend or change the Architecture Landscape

Separate projects may give rise to concurrent operation of ADM cycles

One project may trigger another, causing the instantiation of a further ADM cycles. This is particularly so where strategy architectures give rise to segment architecture, which eventually give rise to capability architectures

Examples of Iterations between phases

Architecture Capability-related:

Projects may need to iterate between Preliminary and Phase A to (re-)establish aspects of Architecture Capability

Projects may need to revisit the Preliminary Phase as a result of new Capability requirements

Architecture Development-related

Project teams may operate their own ADM cycles concurrently

Project teams may cycle between ADM phases in planned phases

Project teams may return to previous phases

Other Iteration Cycles

Transition Planning iterations

Architecture Governance iterations


146

Iteration Cycles applied to the ADM

Approaches to Architecture Development

Two approaches can be adopted within the ADM for the development of architectures:

Baseline First: In this style, an assessment of the baseline landscape is used to identify problem areas and improvement opportunities. This process is most suitable when the baseline is complex, not clearly understood, or agreed upon. This approach is common where organizational units have had a high degree of autonomy

Target First: In this style, the target solution is elaborated in detail and then mapped back to the baseline, in order to identify change activity. This process is suitable when a target state is agreed at a high level and where the enterprise wishes to effectively transition to the target model

Typically, if the baseline is broadly understood a higher value will be obtained focusing on the target first then baseline to the extent necessary to identify changes.

In practical terms, an architecture team will always give informal consideration to the baseline when analysing the target (and vice versa).

In situations where baseline and target are expected to be considered in parallel by stakeholders, it is recommended that the architecture team focuses priority on one state in order to maintain focus and consistency of execution.


147

Mapping TOGAF Phases to Iteration Cycles

Baseline First

Target First


148

Classes of Architecture Engagement

ADM Levels and Iteration Cycles


149

Levels of Architecture

Levels of the Architecture Landscape


150

Security

Security is both an architectural area in its own right, and at the same time must be integrated with existing architectures

Security Architecture has the following general features:

o It has its own methods. These methods might be the basis for a discreet security methodology

o It composes its own discrete view and viewpoints

o It addresses non-normative flows through systems and among applications

o It introduces its own normative flows through systems and among applications

o It introduces unique, single-purpose components in the design.

o It calls for its own unique set of skills and competencies of the enterprise and IT architects.

We have already looked at security on a phase-by-phase basis

Security Concerns

SOA

SOA as an Architectural Style

SOA is an Architectural style that promotes the creation of (functional) capabilities that behave and interoperate in a standard way

There is an emphasis on reusing these capabilities, thus promoting greater flexibility and agility

SOA replaces the traditional silo with granular services, as well as an infrastructure platform of utility services

How Architecture Supports SOA

Provides a set of tools linking top-down business-led SOA to developer-led bottom-up SOA:

Consistent abstractions of high-level strategies and deliverables to support planning and analysis

Linkage of different perspectives to a single business problem (e.g., business, information systems, technology, breadth, depth, level of detail, etc.) providing a consistent model to address various domains and tests for completeness


151

Identification of clear roadmaps to achieve future state

Traceability that links IT and other assets to the business they support

Support for impact assessment, risk/value analysis, and portfolio management

Identified and documented principles, constraints, frameworks, patterns, and standards

Governance frameworks and processes that ensure appropriate authority for decision-making

SOA Adaptions to the ADM

Preliminary Phase: Architecture Capability is adapted to support SOA

Phase A – Architecture Vision: focus is on services, policy, tasks and composition (an SOA Ontology is published by the Open Group). Stakeholders need to be made aware of the implications of SOA

Architecture Development:

o Phase B: focus on business services, contracts and information

o Phase C: focus on how Information System Services address business need

o Phase D: focus on IT implementation and delivery of services

ArchiMate is suited to the SOA style


152

SOA Reference Architecture

Summary

Iterations and Levels of Architecture are both ways of organising how/what the ADM processes are dealt with

Security is a distinct but integrated part of architecture

The good practice of dealing with stakeholders, and designing taking account of both the business and applications, makes TOGAF an excellent environment to develop SOA styles of architecture


153

Architecture Maturity Models

Objectives

In this chapter we will cover the following:

The role of Maturity Models

The CMMI Approach

The ACMM

Maturity Assessments

The Role of Maturity Models

Capability Maturity Models help to improve processes. Developed by CMU/SEI in late 80s/early 90s

They are templates describing “best process”, in a variety of areas, along with a maturity scale (i.e. 0 to

5, 1 to 5)

An organisation can assess its current maturity against this scale, and then aim to improve their “score” by improving/introducing processes

They are used to:

o Implement and audit processes

o Measure Quality

o Measure people’s competency

o Judge maturity of out-sourced partners

Many models exist, for activities such as:

o People (P-CMM, improving management and development of HR)

o Systems Engineering (SE-CMM)

o Software Acquisition (SA-CMM)

The CMMI Approach

Capability Maturity Model Integration (CMMI) was introduced to integrate different models, and to help...

o Link management and engineering activities to business objectives, and ensure outputs (products/services) meet customer expectations

o Implement robust high-maturity practices, based on lessons learned

o Address additional organisational functions critical to its outputs

o Assist compliance/conformance with ISO standards

CMMI used to rate overall Maturity (“staged representation”) AND/OR process-by-process Capability (“continuous representation”)


154

Architecture Maturity Model

The Architecture Capability Maturity Model (ACMM) developed by US Dept. of Commerce.

Defines 6 maturity levels and 9 elements (processes)

Levels:

0. – None

1. – Initial

2. – Under Development

3. – Defined

4. – Managed

5. – Measured

Elements:

Architecture Process

Architecture Development

Business Linkage

Management Team Participation

Operating Unit Participation

Architecture communication

IT Security


IT Investment and Acquisition Strategy

Full details of the ACMM available on:

http://ocio.os.doc.gov/ITPolicyandPrograms/Enterprise_Architecture/PROD01_004935

Business Transformation Readiness Assessment – Maturity Model

Please note the following example Maturity Model scorecard relates to Business Transformation Readiness

Assessment, which itself is also a kind of Maturity Model. This example does not appear in the Framework

document and has been obtained from online resources, but is included below just to provide a real example of

Maturity Model templates.

http://ocio.os.doc.gov/ITPolicyandPrograms/Enterprise_Architecture/PROD01_004935


155

Maturity Assessments

If desired an organisation can go through a formal assessment called SCAMPI (Standard CMMI Appraisal Method for Process Improvement)

Used to measure Capability and Maturity

Three types of assessment

o Class A: Formal and Official

o Class B: Interim assessment (semi-informal)

o Class C: Self-assessments (totally informal)

Summary

In this chapter we looked at:

The role of Maturity Models to describe best practice and define how to assess your maturity level

The CMMI Approach integrates a variety of models

The ACMM is a model that focuses on Enterprise Architecture

Maturity Assessments are performed using the SCAMPI system


156

Architecture Skills Framework

Objectives

In this chapter we will look at:

The purpose of the Architecture Skills Framework

Why it is needed

Benefits of using the framework

Structure of the Skills Framework

Purpose and Need

The purpose of Skills Frameworks is typically to define:

o Roles

o Competencies or skills

o Proficiency or depth of knowledge

An Architecture Skills Framework refines these characteristics to fit the context

Successful EA is characterised by establishing:

o A uniform definition of the architecture roles, which is understood both internally and externally

o A proper practice that recognises the skills required AND encourages certification where possible

Benefits of Use

Reduced time, cost, and risk in training, hiring and managing architecture pro’s, both internal and external

Reduced time and cost to set up an internal architecture practice

Solution Development time, cost and risk is also reduced

Structure of the Skills Framework

Roles

Architecture Board Members

Architecture Sponsor

Architecture Manager

Architects

o Enterprise

o Business

o Data

o Application

o Technology

Programme/Project Managers

IT Designers

And many others...

Skills

Generic leadership, team-player

etc.

Business business cases, processes, strategic planning

EA modelling, building blocks, applications, system integration

Programme/Project management change mgmt., PM methods

IT General knowledge broking apps, asset mgmt., SLAs, migration planning

Technical IT software engineering, security, data interchange

Legal Environment DP law, contract law, procurement law, fraud

Proficiency Levels

1. Background not a

required skill

2. Awareness understands background, issues and implications

3. Knowledge detailed knowledge, can provide professional advice and guidance

4. Expert substantial and extensive knowledge and practical experience on the subject


157

Summary

In this chapter we looked at:

The purpose and need for an Architecture Skills Framework to provide a consistent and uniform structure

Benefits of using the framework reduced cost, time and risk because the right people are being used in the right way

Structure of the Skills Framework consists of Roles, Skills and Proficiencies


158

Adapting the ADM ArchiMate and SOA, 151 Classes and Architecture Engagement, 148 Iterations, 145

Applied to ADM, 146 Between Phases, 145 Other Cycles, 145

Levels and Iteration Cycles, 148 Levels of Architecture

Architecture Landscape, 149 Objectives, 145 Phases Mapped to Cycles

Baseline First, 147 Target First, 147

Security, 150 Security Concerns, 150 SOA

ADM Adaptations, 151 Architecture Support, 150 As an Architectural Style, 150 OG Reference Model, 152

Architecture Content Framework Artifact, 37 Building Block, 37 Content Metamodel

Main Graphic, 39 Deliverable, 37 Example Deliverable, 38 Key Relationships, 38 Overview, 37 Work Products, 37

Architecture Development Method Key Points, 22 Request for Architecture Work, 52

Architecture Maturity Models ACMM, 154 CMMI Approach, 153 Maturity Assessments, 155 Objectives, 153 Role, 153

Architecture Partitioning Applying, 144 Architecture Characteristics, 143 Objectives, 143 Overview, 143 Solution Characteristics, 143

Architecture Repository Architecture Landscape, 35 Classes of Information, 34 Link with Enterprise Continuum, 34 Overview, 32 Repositories, 33 Standards Information Base, 36

Architecture Skills Framework Benefits of Use, 156 Objectives, 156 Purpose and Need, 156 Structure, 156

Basic Concepts 1st Part – Introduction, 8 Certification Program, 11 Definitions of System Architecture, 10 Enterprise Architecture

Business Benefits, 5 Definition, 5 Purpose, 5

Evolution of Framework, 4 Exam Paths, 11 Structure of TOGAF, 8 Suitability of TOGAF, 7 The Open Group, 4 TOGAF Capabilities, 9 Types of Architecture, 10 What is an Architecture Framework, 7

Building Blocks Architecture Building Blocks, 75 Design Issues, 76 Link with ADM, 77 Overview, 75 Patterns, 77 Qualities, 75 Solution Building Blocks, 76

Business Scenarios Contents, 66 Development Guidelines, 66 Overview, 64 Process, 65 Validation, 66

Content Metamodel Artifacts, 42 Core and Extension Parts, 42 Core Concepts, 40 Core Diagram, 41 Full Diagram with Extensions, 42 Overview, 40

Core Concepts Architecture Content Framework

Introduction, 15 Architecture Development Method

Main Graphic, 14 Architecture Repository, 17 Enterprise Continuum

Main Graphic, 16 Integrated Information Infrastructure RM, 19 Technical Reference Model, 19 Using TOGAF with other Frameworks, 18

Enterprise Continuum Architecture Continuum, 30 Definition of Continuum, 27 Main Constituents, 28 Main Graphic, 29 Relationship with ADM, 31 Reuse, 27 Solutions Continuum, 30 What is it?, 27

Governance


159

Architecture Board Board Meetings, 59 Justification and Composition, 58 Meeting Agenda, 59 Operational Responsibilities, 59 Responsibilities, 58 Setting up, 58

Architecture Compliance Definitions, 60 Architecture Contracts, 59 Capabilities, 63 Compliance Review

Processes, 62 Purpose, 61

Conceptual Framework, 56 Hierarchy/Organisation, 55 Key Success Factors, 55 Main Characteristics, 54 Nature of, 54 Need for Architecture Compliance, 61 Organisation Structure, 57 Overview, 54 Processes, 56 Specifics, 55

Integrated Information Infrastructure RM Boundaryless Information Flow, 117 Components, 118 Detailed Structure, 119 High-level Structure, 118

Introduction to the ADM Adapting the ADM, 24 Architecture Integration, 25 Architecture Scope, 25 Governance and Information, 24 Guidelines and Techniques

Introduction, 23 Phases A-D, 22 Relationships, 23

Phase A Approach, 79 Architecture Repository, 79 Architecture Vision, 85 Business Scenarios, 79 Business Transformation Readiness, 81 Capabilities Example, 84 Capability Assessment, 84 Capability-based Planning, 84, 85 Communications Plan, 87 Creating an Architecture Vision, 79 Inputs, 79 Interoperability

Business, 87 Degrees, 86 IT Perspective, 86 Matrices, 86 Phase level, 85

Objectives, 78 Outputs, 83 Risk Impact Classification Scheme, 82 Risk Management, 82 Security, 87 Stakeholders Concerns and Requirements, 81

Statement of Architecture Work, 83 Step Summary, 80 Steps, 80 Suggested Readiness Factors, 82

Phase B Approach, 88 Architecture Definition Document, 96 Architecture Requirements Specification, 96 Building Blocks, 95 Business Modelling, 92 Business Requirements, 97 Gap Analysis, 93 Gap Analysis Matrix, 94 Inputs, 89 Model Types, 96 Modelling Techniques and Views, 91 Objectives, 88 Outputs, 95 Principles, Goals, Drivers, 89 Security, 97 Step Summary, 90 Steps, 90

Phase C Approach, 98 Inputs, Outputs and Steps, 99 Objectives, 98 Repository Items, 98 Security, 99

Phase C - Applications Approach, 105 Architecture Definition Doc, 109 Architecture Requirements Spec, 109 Inputs, 106 Objectives, 105 Outputs, 109 Principles, 106 Selecting Ref.Models/Viewpoints/Tools, 108 Step Summary, 107 Steps, 107 Viewpoints, 108

Phase C - Data Achitecture Requirements Spec, 104 Approach, 100 Architecture Definition Doc, 104 Governance, 101 Inputs, 101 Management, 100 Migration, 100 Objectives, 100 Outputs, 104 Principles, 101 Reference Models, 103 Step Summary, 102 Steps, 102 Viewpoints, 103

Phase D - Technology Approach, 110 Architecture Definition Doc, 114 Architecture Requirements Spec, 114 Inputs, 111


160

Outputs, 113 Phase Objectives, 110 Principles, 111 Security, 114 Step Summary, 112 Steps, 112 Viewpoints and ABBs, 113

Phase E – Opportunities and Solutions Approach, 120 Confirm Change, 122 Identify Work Packages, 123 Illustrate, 120 Implementation and Migration Strategy, 123 Objectives, 120 Outputs, 124 Review Gaps, 122 Security, 124 Step Summary, 121 Steps, 121 Transition Architectures, 124

Phase F – Migration Planning Approach, 125 Business Value, 128 Business Value Assessment Technique, 128 Confirm Architecture Roadmap, 129 Framework Interaction, 127 Implementation and Migration Plan, 130 Inputs, 126 Outputs, 130 Phase Objectives, 125 Prioritise Migration Projects, 129 Security, 130 State Evolution Table, 129 Step Summary, 127 Steps, 126

Phase G – Implementation Governance Approach, 132 Architecture Contract Contents, 135 Inputs, 133 Objectives, 132 Outputs, 134 Risk Monitoring, 136 Security, 135 Step Summary, 134 Steps, 133

Phase H – Change Management Approach, 137 Change Requests, 139 Inputs, 138 Objectives, 137 Outputs, 140 Security, 140

Step Summary, 140 Steps, 139

Preliminary Phase Approach, 43 Establish EA Team and Organisation, 46 Further Considerations, 45 Influence of Existing Inputs, 45 Inputs, 44 Outputs, 52 Phase Objectives, 43 Principles

Defining, 47 Example One, 50 Example Two, 50 Identifying, 47 Qualities, 51 Template, 49 TOGAF List, 48

Relationship between Frameworks, 44 Security, 53 Steps, 45 Tailoring the Framework, 52

Requirements Management Approach, 141 Inputs, 141 Objectives, 141 Outputs, 142 Security, 142 Steps, 142

Stakeholder Management Creating Views, 74 Critical Aspects, 72 Identifying Stakeholders, 72 Overview, 72 Stakeholder Categories, 73 Stakeholder Map, 74 Stakeholder Power Grid, 73

Technical Reference Model Application Platform Service Categories, 116 Main Categories, 115 Overview, 115 Platform Service Categories, 116 Tailoring, 116 Views, 115

Views and Viewpoints Creating Views, 71 Definitions, 68 Example, 70 ISO 42010

2007 Model, 69 Overview, 68 Viewpoint/Artifact Summary, 71

Contact us:0845 757 [email protected]

TOGAF v9.1 Foundation and Certified - QA · TOGAF Foundation and Certified ... introduce delegates to The Open Group Architecture Framework ... Enterprise Architecture purpose is

Documents