togaf v9.1 foundation and certified - qa · togaf foundation and certified ... introduce delegates...
Post on 30-Apr-2018
220 Views
Preview:
TRANSCRIPT
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
TOGAF Foundation and Certified TOGAF9FC v1.8
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
TOGAF Foundation and Certified TOGAF9FC v1.8
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
TOGAF Foundation and Certified TOGAF9FC v1.8
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.
TOGAF Foundation and Certified TOGAF9FC v1.8
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
TOGAF Foundation and Certified TOGAF9FC v1.8
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:
TOGAF Foundation and Certified TOGAF9FC v1.8
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
TOGAF Foundation and Certified TOGAF9FC v1.8
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
TOGAF Foundation and Certified TOGAF9FC v1.8
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.
TOGAF Foundation and Certified TOGAF9FC v1.8
9
TOGAF Capabilities
TOGAF Foundation and Certified TOGAF9FC v1.8
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
TOGAF Foundation and Certified TOGAF9FC v1.8
11
Certification Program
Exam Paths
TOGAF Foundation and Certified TOGAF9FC v1.8
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”
TOGAF Foundation and Certified TOGAF9FC v1.8
13
Core Concepts
Session Objectives
We will look at the following:
The Architecture Development Method
The Architecture Content Framework
The Enterprise Continuum
The Architecture Repository
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.
TOGAF Foundation and Certified TOGAF9FC v1.8
14
The Architecture Development Method
TOGAF Foundation and Certified TOGAF9FC v1.8
15
The Architecture Content Framework
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.
TOGAF Foundation and Certified TOGAF9FC v1.8
16
The Enterprise Continuum
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.).
TOGAF Foundation and Certified TOGAF9FC v1.8
17
The Architecture Repository
TOGAF Foundation and Certified TOGAF9FC v1.8
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
TOGAF Foundation and Certified TOGAF9FC v1.8
19
Technical Reference Model
Integrated Information Infrastructure RM
TOGAF Foundation and Certified TOGAF9FC v1.8
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
TOGAF Foundation and Certified TOGAF9FC v1.8
21
Introduction to the ADM
Session Objectives
We will look at the following:
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
TOGAF Foundation and Certified TOGAF9FC v1.8
22
The ADM and Key Points
Definition process – Phases A to D
TOGAF Foundation and Certified TOGAF9FC v1.8
23
ADM Relationships
Guidelines and Techniques
TOGAF Foundation and Certified TOGAF9FC v1.8
24
Adapting the ADM
ADM Governance and Information
TOGAF Foundation and Certified TOGAF9FC v1.8
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.
TOGAF Foundation and Certified TOGAF9FC v1.8
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
TOGAF Foundation and Certified TOGAF9FC v1.8
27
The Enterprise Continuum
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”
TOGAF Foundation and Certified TOGAF9FC v1.8
28
Main Constituents
TOGAF Foundation and Certified TOGAF9FC v1.8
29
Main Graphic
TOGAF Foundation and Certified TOGAF9FC v1.8
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
TOGAF Foundation and Certified TOGAF9FC v1.8
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
TOGAF Foundation and Certified TOGAF9FC v1.8
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”
TOGAF Foundation and Certified TOGAF9FC v1.8
33
Repositories
TOGAF Foundation and Certified TOGAF9FC v1.8
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
TOGAF Foundation and Certified TOGAF9FC v1.8
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.
TOGAF Foundation and Certified TOGAF9FC v1.8
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
TOGAF Foundation and Certified TOGAF9FC v1.8
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.
TOGAF Foundation and Certified TOGAF9FC v1.8
38
Key Relationships
Example Deliverable
TOGAF Foundation and Certified TOGAF9FC v1.8
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
TOGAF Foundation and Certified TOGAF9FC v1.8
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.
TOGAF Foundation and Certified TOGAF9FC v1.8
41
Core Entity Diagram
TOGAF Foundation and Certified TOGAF9FC v1.8
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
TOGAF Foundation and Certified TOGAF9FC v1.8
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
TOGAF Foundation and Certified TOGAF9FC v1.8
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
TOGAF Foundation and Certified TOGAF9FC v1.8
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
TOGAF Foundation and Certified TOGAF9FC v1.8
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
TOGAF Foundation and Certified TOGAF9FC v1.8
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
TOGAF Foundation and Certified TOGAF9FC v1.8
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
TOGAF Foundation and Certified TOGAF9FC v1.8
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.
TOGAF Foundation and Certified TOGAF9FC v1.8
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.
TOGAF Foundation and Certified TOGAF9FC v1.8
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.
TOGAF Foundation and Certified TOGAF9FC v1.8
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
TOGAF Foundation and Certified TOGAF9FC v1.8
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.
TOGAF Foundation and Certified TOGAF9FC v1.8
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
TOGAF Foundation and Certified TOGAF9FC v1.8
55
Architecture Governance
...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.
TOGAF Foundation and Certified TOGAF9FC v1.8
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.
TOGAF Foundation and Certified TOGAF9FC v1.8
57
Organisation Structure
TOGAF Foundation and Certified TOGAF9FC v1.8
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)
TOGAF Foundation and Certified TOGAF9FC v1.8
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
TOGAF Foundation and Certified TOGAF9FC v1.8
60
Architecture Compliance Definitions
TOGAF Foundation and Certified TOGAF9FC v1.8
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
TOGAF Foundation and Certified TOGAF9FC v1.8
62
Compliance Review Process
TOGAF Foundation and Certified TOGAF9FC v1.8
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.
TOGAF Foundation and Certified TOGAF9FC v1.8
64
Business Scenarios and Business Goals
Session Objectives
We will look at the following:
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.
TOGAF Foundation and Certified TOGAF9FC v1.8
65
The Business Scenario Process
TOGAF Foundation and Certified TOGAF9FC v1.8
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
TOGAF Foundation and Certified TOGAF9FC v1.8
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
TOGAF Foundation and Certified TOGAF9FC v1.8
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
TOGAF Foundation and Certified TOGAF9FC v1.8
69
ISO 42010
TOGAF Foundation and Certified TOGAF9FC v1.8
70
Example Viewpoint and View
TOGAF Foundation and Certified TOGAF9FC v1.8
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 Management
Requirements catalogue
Summary
Views and Viewpoints are the crucial elements that determine how you represent Architecture.
TOGAF Foundation and Certified TOGAF9FC v1.8
72
Stakeholder Management
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.
Stakeholder Management
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?
TOGAF Foundation and Certified TOGAF9FC v1.8
73
Stakeholder Categories
Stakeholder Power Grid
TOGAF Foundation and Certified TOGAF9FC v1.8
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.
TOGAF Foundation and Certified TOGAF9FC v1.8
75
Building Blocks
Session Objectives
We will look at the following:
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
TOGAF Foundation and Certified TOGAF9FC v1.8
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
TOGAF Foundation and Certified TOGAF9FC v1.8
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
TOGAF Foundation and Certified TOGAF9FC v1.8
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.
TOGAF Foundation and Certified TOGAF9FC v1.8
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
Request for Architecture Work
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.)
Architecture Repository
Consists of existing architectural documentation:
Framework description
Architectural descriptions
Baseline descriptions
Architectural Building Blocks
Solution Building Blocks
TOGAF Foundation and Certified TOGAF9FC v1.8
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.
TOGAF Foundation and Certified TOGAF9FC v1.8
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
TOGAF Foundation and Certified TOGAF9FC v1.8
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
TOGAF Foundation and Certified TOGAF9FC v1.8
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
TOGAF Foundation and Certified TOGAF9FC v1.8
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
TOGAF Foundation and Certified TOGAF9FC v1.8
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
TOGAF Foundation and Certified TOGAF9FC v1.8
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
TOGAF Foundation and Certified TOGAF9FC v1.8
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.
TOGAF Foundation and Certified TOGAF9FC v1.8
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
TOGAF Foundation and Certified TOGAF9FC v1.8
89
Inputs
Request for Architecture Work
Business principles, business goals, and business drivers
Capability Assessment
Communications Plan
Organisation model for enterprise architecture
Tailored Architecture Framework
Approved Statement of Architecture Work
Architecture principles, including business principles, when pre-existing
Enterprise Continuum
Architecture Repository
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
TOGAF Foundation and Certified TOGAF9FC v1.8
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
1. Select reference models, viewpoints, and tools
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.
4. Perform gap analysis
See future slides.
5. Define Candidate Roadmap Components
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).
6. Resolve impacts across the Architecture Landscape
Impacts could be on pre-existing architecture and/or other projects.
7. Conduct formal stakeholder review
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.
9. Create Architecture Definition Document
See future slides.
TOGAF Foundation and Certified TOGAF9FC v1.8
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
TOGAF Foundation and Certified TOGAF9FC v1.8
92
Business Modelling
BPMN
UML
ArchiMate®
TOGAF Foundation and Certified TOGAF9FC v1.8
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
TOGAF Foundation and Certified TOGAF9FC v1.8
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.
TOGAF Foundation and Certified TOGAF9FC v1.8
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
TOGAF Foundation and Certified TOGAF9FC v1.8
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
TOGAF Foundation and Certified TOGAF9FC v1.8
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.
TOGAF Foundation and Certified TOGAF9FC v1.8
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
Architecture Repository
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)
TOGAF Foundation and Certified TOGAF9FC v1.8
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
Determine ‘‘what can go wrong?’’
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
TOGAF Foundation and Certified TOGAF9FC v1.8
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
Identify candidate Architecture Roadmap components based upon gaps between the Baseline and
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
TOGAF Foundation and Certified TOGAF9FC v1.8
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
Request for Architecture Work
Capability Assessment
Communications Plan
Organisation model for enterprise architecture
Tailored Architecture Framework
Data principles
Statement of Architecture Work
Architecture Vision
Architecture Repository
Draft Architecture Definition Document, containing:
o Baseline Business Architecture (detailed)
o Target 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 Gap analysis results
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
TOGAF Foundation and Certified TOGAF9FC v1.8
102
Steps
1. Select reference models, viewpoints, and tools
2. Develop Baseline Data Architecture Description
3. Develop Target Data 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 Data 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
1. Select reference models, viewpoints, and tools
See future slides.
2. Develop Baseline Architecture Description
Bearing in mind the scope and level or detail, identify baseline Data Building Blocks.
3. Develop Target Architecture Description
Repeat Step 2 focusing on the Target Architecture Building Blocks.
4. Perform gap analysis
Using the Gap Analysis technique, identify gaps between Baseline and Target.
5. Define Candidate Roadmap Components
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).
6. Resolve impacts across the Architecture Landscape
Impacts could be on pre-existing architecture and/or other projects.
7. Conduct formal stakeholder review
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.
9. Create Architecture Definition Document
See future slides.
TOGAF Foundation and Certified TOGAF9FC v1.8
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
TOGAF Foundation and Certified TOGAF9FC v1.8
104
Outputs
Statement of Architecture Work
Validated principles, or new data principles
Draft Architecture Definition Document, containing:
o Baseline Data Architecture
o Target Data Architecture
o Data Architecture views of key stakeholder concerns
Draft Architecture Requirements Specification, including:
o Gap analysis results
o Data interoperability requirements
o Relevant technical 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
Gap analysis results
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.
TOGAF Foundation and Certified TOGAF9FC v1.8
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
Identify candidate Architecture Roadmap components based upon gaps between the Baseline and
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)
TOGAF Foundation and Certified TOGAF9FC v1.8
106
Inputs
Request for Architecture Work
Capability Assessment
Communications Plan
Organisation model for enterprise architecture
Tailored Architecture Framework
Application principles
Statement of Architecture Work
Architecture Vision
Architecture Repository
Draft Architecture Definition Document, containing:
o Baseline Business Architecture (detailed)
o Target Business Architecture (detailed)
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)
o Baseline Technology Architecture (high-level)
o Target Technology Architecture (high-level)
Draft Architecture Requirements Specification, including:
o Gap analysis results
o Relevant technical requirements
Business and Data Architecture components of an Architecture Roadmap
Application Principles
Technology Independence
Ease-of-Use
TOGAF Foundation and Certified TOGAF9FC v1.8
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.
Note: technically speaking, the Architecture Definition Document is created in Phase A (as per this most recent
version).
Step Summary
1. Select reference models, viewpoints, and tools
See future slides.
2. Develop Baseline Architecture Description
Bearing in mind the scope and level or detail, identify baseline Application Building Blocks.
3. Develop Target Architecture Description
Repeat Step 2 focusing on the Target Architecture Building Blocks.
4. Perform gap analysis
Using the Gap Analysis technique, identify gaps between Baseline and Target.
5. Define Candidate Roadmap Components
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).
6. Resolve impacts across the Architecture Landscape
Impacts could be on pre-existing architecture and/or other projects.
7. Conduct formal stakeholder review
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.
9. Create Architecture Definition Document
See future slides.
TOGAF Foundation and Certified TOGAF9FC v1.8
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
TOGAF Foundation and Certified TOGAF9FC v1.8
109
Outputs
Statement of Architecture Work
Validated principles, or new principles (application)
Draft Architecture Definition Document, containing:
o Baseline Application Architecture
o Target Application Architecture
o Application Architecture views of key stakeholder concerns
Draft Architecture Requirements Specification, including:
o Gap analysis results
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
Gap analysis results
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.
TOGAF Foundation and Certified TOGAF9FC v1.8
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
TOGAF Foundation and Certified TOGAF9FC v1.8
111
Inputs
Request for Architecture Work
Business principles, business goals and business drivers
Capability Assessment
Communications Plan
Organisation model for enterprise architecture
Tailored Architecture Framework
Approved Statement of Architecture Work
Architecture principles, including business principles, when pre-existing
Enterprise Continuum
Architecture Repository
Draft Architecture Definition Document, containing:
o Baseline Business Architecture (detailed)
o Target Business Architecture (detailed)
o Baseline Data Architecture (detailed)
o Target Data Architecture (detailed)
o Baseline Application Architecture (detailed)
o Target Application Architecture (detailed)
o Baseline Technology Architecture (high-level)
o Target Technology Architecture (high-level)
Draft Architecture Requirements Specification, including:
o Gap analysis results
o Relevant technical requirements
Business, Data and Application Architecture components of an Architecture Roadmap
Technology Principles
Requirements-based Change
Responsive Change Management
Control Technical Diversity
Interoperability
TOGAF Foundation and Certified TOGAF9FC v1.8
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.
Note: technically speaking, the Architecture Definition Document is created in Phase A (as per this most recent
version).
Step Summary
1. Select reference models, viewpoints, and tools
See future slides.
2. Develop Baseline Architecture Description
Bearing in mind the scope and level or detail, identify baseline Technology Building Blocks.
3. Develop Target Architecture Description
Repeat Step 2 focusing on the Target Architecture Building Blocks.
4. Perform gap analysis
Using the Gap Analysis technique, identify gaps between Baseline and Target.
5. Define Candidate Roadmap Components
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).
6. Resolve impacts across the Architecture Landscape
Impacts could be on pre-existing architecture and/or other projects.
7. Conduct formal stakeholder review
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.
9. Create Architecture Definition Document
See future slides.
TOGAF Foundation and Certified TOGAF9FC v1.8
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
Statement of Architecture Work, updated if necessary
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 Gap analysis results
o Requirements output from Phases B and C
o Updated technology requirements
Technology Architecture components of an Architecture Roadmap
TOGAF Foundation and Certified TOGAF9FC v1.8
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
Gap analysis results
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
Determine ‘‘what can go wrong?’’
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.
TOGAF Foundation and Certified TOGAF9FC v1.8
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
TOGAF Foundation and Certified TOGAF9FC v1.8
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
TOGAF Foundation and Certified TOGAF9FC v1.8
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.
TOGAF Foundation and Certified TOGAF9FC v1.8
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
TOGAF Foundation and Certified TOGAF9FC v1.8
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.
TOGAF Foundation and Certified TOGAF9FC v1.8
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
Request for Architecture Work
Capability Assessment
Communications Plan
Planning Methodologies
Tailored Architecture Framework
Statement of Architecture Work
Architecture Vision
Architecture Repository
Draft Architecture Definition Document
Draft Architecture Requirements Specification
Change Requests for existing programs and projects
Candidate Architecture Roadmap components from Phases B, C, D
TOGAF Foundation and Certified TOGAF9FC v1.8
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.
TOGAF Foundation and Certified TOGAF9FC v1.8
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:
TOGAF Foundation and Certified TOGAF9FC v1.8
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)
TOGAF Foundation and Certified TOGAF9FC v1.8
124
Transition Architectures
Use the Architecture Definition Increments Table:
Outputs
Statement of Architecture Work, updated if necessary
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
Determine ‘‘what can go wrong?’’
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.
TOGAF Foundation and Certified TOGAF9FC v1.8
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
TOGAF Foundation and Certified TOGAF9FC v1.8
126
Inputs
Request for Architecture Work
Communications Plan
Organisation model for enterprise architecture
Governance Models and Frameworks
Tailored Architecture Framework
Statement of Architecture Work
Architecture Vision
Architecture Repository
Draft Architecture Definition Document, including:
o Transition Architectures if necessary
Draft Architecture Requirements Specification
Change Requests for existing programs and projects
Architecture Roadmap
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
TOGAF Foundation and Certified TOGAF9FC v1.8
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
TOGAF Foundation and Certified TOGAF9FC v1.8
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
TOGAF Foundation and Certified TOGAF9FC v1.8
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
TOGAF Foundation and Certified TOGAF9FC v1.8
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
Determine ‘‘what can go wrong?’’
TOGAF Foundation and Certified TOGAF9FC v1.8
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.
TOGAF Foundation and Certified TOGAF9FC v1.8
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.
TOGAF Foundation and Certified TOGAF9FC v1.8
133
Inputs
Request for Architecture Work
Capability Assessment
Organisation model for enterprise architecture
Tailored Architecture Framework
Statement of Architecture Work
Architecture Vision
Architecture Repository
Architecture Definition Document
Architecture Requirements Specification
Architecture Roadmap
Implementation Governance Model
Architecture Contract
Request for Architecture Work identified in Phases E and F
Implementation and Migration Plan
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
TOGAF Foundation and Certified TOGAF9FC v1.8
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)
Compliance Assessments
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
TOGAF Foundation and Certified TOGAF9FC v1.8
135
Architecture Contract Contents
Statement of Architecture Work
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?’’
TOGAF Foundation and Certified TOGAF9FC v1.8
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.
TOGAF Foundation and Certified TOGAF9FC v1.8
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
Change Management Approach (2)
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
TOGAF Foundation and Certified TOGAF9FC v1.8
138
Change Management Approach (3)
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
Organisation model for enterprise architecture
Tailored Architecture Framework
Statement of Architecture Work
Architecture Vision
Architecture Repository
Architecture Definition document
Architecture Requirements Specification
Architecture Roadmap
Change Requests due to technology changes
Change Requests due to business changes
Change Requests from lessons learned
Implementation Governance Model
Architecture Contract (signed)
Compliance Assessments
Implementation and Migration Plan
TOGAF Foundation and Certified TOGAF9FC v1.8
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
TOGAF Foundation and Certified TOGAF9FC v1.8
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
Statement of Architecture Work, updated if necessary
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.
TOGAF Foundation and Certified TOGAF9FC v1.8
141
Requirements Management
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)
TOGAF Foundation and Certified TOGAF9FC v1.8
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.
TOGAF Foundation and Certified TOGAF9FC v1.8
143
Architecture Partitioning
Objectives
We will look at the following:
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
TOGAF Foundation and Certified TOGAF9FC v1.8
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.
TOGAF Foundation and Certified TOGAF9FC v1.8
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
TOGAF Foundation and Certified TOGAF9FC v1.8
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.
TOGAF Foundation and Certified TOGAF9FC v1.8
147
Mapping TOGAF Phases to Iteration Cycles
Baseline First
Target First
TOGAF Foundation and Certified TOGAF9FC v1.8
148
Classes of Architecture Engagement
ADM Levels and Iteration Cycles
TOGAF Foundation and Certified TOGAF9FC v1.8
149
Levels of Architecture
Levels of the Architecture Landscape
TOGAF Foundation and Certified TOGAF9FC v1.8
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
TOGAF Foundation and Certified TOGAF9FC v1.8
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
TOGAF Foundation and Certified TOGAF9FC v1.8
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
TOGAF Foundation and Certified TOGAF9FC v1.8
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”)
TOGAF Foundation and Certified TOGAF9FC v1.8
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
Architecture Governance
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.
TOGAF Foundation and Certified TOGAF9FC v1.8
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
TOGAF Foundation and Certified TOGAF9FC v1.8
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
TOGAF Foundation and Certified TOGAF9FC v1.8
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
TOGAF Foundation and Certified TOGAF9FC v1.8
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
TOGAF Foundation and Certified TOGAF9FC v1.8
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
TOGAF Foundation and Certified TOGAF9FC v1.8
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 3888info@qa.comwww.qa.com
top related