TOGAF Standard Architecture Design

Innovate Vancouver
The TOGAF® standard. The Open Group Website. (2022, December 3). Retrieved 2023, from
https://www.opengroup.org/togaf

Architecture
Dev Model
Requirements
Mapping
Templates
Reference
Models
Architecture
Maturity
Model
ADM Stages &
Steps
An Enterprise Architecture Design Build Roadmap
TABLE OF CONTENTS
The following
infographic provides a
high level overview of
an Enterprise
Architecture Design
Build Roadmap.
Reusable blocks,
templates, and
reference models are
explored. Each of these
can be used during the
Architecture
Development Model
(ADM) - lifecycle.
Reusing available building blocks within the
company's enterprise architecture simplifies
integration, configuration, and ongoing
maintenance of the architecture.
Reused building blocks also support cost management and
building 'boundaryless' architecture.
Innovate Vancouver

ARCHITECTURE DESIGN INPUTS AND
OUTPUTS
ARCHITECTURE CONTINUUM
OPEN ARCHITECTURE CONTENT FRAMEWORK
ARCHITECTURE DEVELOPMENT MODEL
ARCHITECTURE CAPABILITY
FRAMEWORK
An architecture design build approach
leverages existing assts, models, and best
practices with an emphasis on quality,
scalabil
The ADM highlights core value chains, resources, and models
that will be integrated with the new architecture models (as
appropriate)
This model provides an effective framework
approach designing, planning, implementing, and
governing an enterprise information technology
architecture.
This continuum includes a
series of architectur models
beginning with a foundation
model and ending with an
organization specific model
Enterprise Architecture Design Builds will often
follow an iterative waterfall approach that
emphasizes the following TOGAF Architecture
Development Model lifecycle. Work packages,
tasks, and service desk requests will follow an
agile approach with an emphasis on increasing
velocity and reducing wastes (LEAN).
TOGAF
ITIL
Waterfall
Scrum/
Agile
Prosci/ADKAR
SDLC Maturity Model
PMBOK
LEAN
Six Sigma
Reference Models
DevOps
Building Blocks
Innovate Vancouver
https://www.opengroup.org/toga
f
Release Planning
OSI

PHASE 1
Project Kickoff
Project Initiation
PHASE II
Architecture Vision
Business Architecture
Information Systems
Architecture
Technology Architecture
Architecture Design &
Development
Phase I & II
Product-Service Design/Build phases are
iterative and overlapping.
These phases will utilize Agile/Scrum and
SLDC ceremonies, emphasizing feedback
and user testing from business,
information, and technical groups. Preliminary Phase: To ensure users and
stakeholders impacted by the product or service
are included in the design, build, &
implementation process.
Architecture Vision: This includes identifying
project Scope, Stakeholders, Vision Statement,
and Approvals Roadmap for the Present State,
Future State, and Interim Architectures.
Business Architecture: Build the business
architecture and building blocks needed to
support the Architecture Vision.
Information Systems Architecture: This includes
the data and application architectures/ building
blocks.
Technical Architecture: This includes
development of the on prem and cloud technology
architecture
ADM
Phases
-
Definitions
Innovate Vancouver
Enterprise Architecture
Development Model (ADM)

PHASE III
Opportunities &
Solutions
Migration Planning
Transition Planning Iteration
PHASE IV
Implementation
Governance
Architecture Change
Management
Architecture Governance
Iteration
The ADM phases represents
overlapping and interdependent
workstreams that are refined and
updated throughout the
architecture design build lifecycle
Opportunities and Solutions: This includes selecting
products and service architectures based on existing
architecture models and yet to be acquired industry
best practices and assets.
Migration Planning: Migration planning will be
designed, implemented, and evaluated concurrent
with implementation governance, architecture change
management, release management, service desk
(ITIL), and capacity building (business, information,
technology).
Implementation Governance: Governance is
conducted throughout the lifecycle of the project.
Includes cutover to production.
Architecture Change Management: Change
management is conducted throughout the
lifecycle of the project.
ADM
Phases
-
Definitions
Phase III & IV
Innovate Vancouver
Enterprise Architecture
Development Model (ADM)

Understanding the gaps between the present
and targeted future state for the company's
enterprise architecture is critical. Decisions
need to be made whether to move from
present to future directly or if transitional
states are needed. Additional considerations
include reuse, simplify, build, or procure
components
GAPS
The transitional architecture
states can be compared to a
release roadmap. The transitional
state add OR substract
architecture components bringing
the company ccloser to the final
state
TRANSITION
STATE
FUTURE STATE
Identify the targeted future state
for the company's enterprise
architecture. This takes into
consideration the integrated
business, data, application, and
technology architectures.
Identify the current state
components of the business,
data, application, and technology
architectures
CURRENT
STATE
ARCHITECTURE VISION
CROSSING THE CHASM
1 2 3 4
Innovate Vancouver

Devices
Hardware,
Networks &
Application
Templates
Reference Models
Inputs & Outputs in Architecture Design
Reinforces and
strengthens business
processes and
workflows
Business Processes
Aligns with the
organizational structure
and key performance/
strategic goals
Org Chart
Integrates and supports
device access, updates,
and use metrics
Design build process
leverages available templates
to strengthen efficiency,
scalability, and reuse of
building blocks
Reinforces and
strengthens
organization and
regulatory
requirements
Policies & Procedures
Supports ongoing data
integration, management,
and analytics reporting
Data Models
Integrates, reuses, and
builds upon existing
assets and resources
Leverages industry best practices to
strengthen integration, quality, and
continuous improvement: Examples,
ITIL, TOGAF, PROSCI, ADM, OSI
f
Innovate Vancouver
Examples

FEATURES PRODUCT D PRODUCT C PRODUCT B PRODUCT A
Features
Applications
Integration
Requirements COTS
Devices
Unlimited Storage
Live Meeting
PRODUCT FEATURES &
SERVICES COMPARISON
CHART
Innovate
Vancouver
f
This generic matrix is recommended
in The Open Group Architecture
Guide (TOGAF) to map features
against existing OR new products &
services suggested by the
organization's information
technology team.
Requirements are solicited from stakeholders which include an evaluating of existing products and services
used by the enterprise. Products are often selected from a review of industry best practices.
Once the comparison
chart is completed it can
be used to facilitate
future discussions with
primary users and
decision makers.
The resulting enterprise
architecture will be
driven by an evaluation
of key constraints,
options, pros & cons,
performance
considerations, and cost
(to name a few).
The chart cells can also
be used to note
additional information

FEATURES STEP 1 STEP 2 STEP 3 STEP 4
Decision A
Decision B
Decision C
Deciion D
Decision E
Decision F
BUSINESS PROCESS MAP
Innovate
Vancouver
Innovate
Vancouver
f
This generic business process map
is recommended in The Open Group
Architecture Guide (TOGAF) to map
features, rols, and steps throughout
a business process.
Universal Markup Language (UML)
can also be used to draft visual
flowcharts that follow the matrix
below
Requirements are solicited from stakeholders which include an
evaluating of existing products and services used by the enterprise.
Products are often selected from a review of industry best
practices.
Once the business process
map is completed it can be
used to facilitate future
discussions with primary
users and decision makers.
The resulting enterprise
architecture will be selected
based on an evaluation of
supported key business
decisions, process, and value
drivers targeted to be
enabled by each architecture
component.
The chart cells can also be
used to note additional
information

NAME OF FACTOR DESCRIPTION IMPACT
Factor-A
Factor-B
Factor-C
Factor-D
Factor-E
Factor-F
Innovate
Vancouver
IMPLEMENTATION FACTOR
ASSESSMENT & REDUCTION
Innovate
Vancouver
f
a
c
b
This matrix is used to
evaluate the impact of
introducing new
components within a
existing architecture
environment

NUMBER (ID)
ARCHITECTURE
LEVEL
GAP
POTENTIAL
SOLUTIONS
DEPENDENCIES
ID-A
ID-B
ID-C
IC-D
ID-E
ID-F
Innovate
Vancouver
CONSOLIDATED GAPS
SOLUTIONS &
DEPENDENCIES
Innovate
Vancouver
f
a
c
b
This matrix is used to identify and
evaluate existing gaps within the
architecture model proposed.
Solutions and dependencies are
identified.
Business
Data
Application
Technology
Business
Data

SUB-DOMAIN SERVICE
TRANSITION
ARCHITECTURE
DATE
TRANSITION
ARCHITECTURE
DATE
Domain-A
Domain-B
Domain-C
Domain-D
Domain-E
Domain-F
Innovate
Vancouver
TRANSITION
ARCHITECTURES
Innovate
Vancouver
f
a
c
b
This matrix is used to identify transition
architectures incorporated into the roadmap.
The roadmap moves the architecture from the
present state to the future state. Transition
architecture are scheduled along a release
roadmap, introducing new architecture
components that drive value for stakeholders
within each iteration/ delivery.

PROJECT/ASSET VALUE (1-10) RISK (1-10) SCORE DECISION
Project-A
Project-B
Project-C
Project-D
Project-E
Project-F
Innovate
Vancouver
BUSINESS VALUE
ASSESSMENT
Innovate
Vancouver
f
a
c
b
This matrix helps to evaluate the business value
gained through the introduction of each
feature/component/ building block into the
architecture solution. This value is evaluated with
consideration of risk involved in both incorporating
the new component and realizing the value expected
through its implementation.
The matrix includes
a cell to identify the
decision made
whether to accept
the risk and
incorporate the new
architecture
component.
The matrix can also
be used to evaluate
the value x risk of a
proposed project.

DATA ARCHITECTURE
APPLICATION
ARCHITECTURE
TECHNOLOGY
ARCHITECTURE
Innovate Vancouver
Integrated Information
Technology Components
The design of the business, data,
application, and technology architectures
are interdependent and iterative.
Updates to one architecture area will often
impact the architecture of another area.
Phase C in the Architecture
Development Method emphasizes the
design-build of the data and
applications architecture.
Which architecture is built first will
depend on the needs of the
corporation, but many start with the
data architecture.
Architecture design can follow a top-
down or bottom-up approach.
Technology Architecture is designed to
support the delivery of the data and
application architectures.

Preliminary: Architecture Principles
Architecture Requirements: Business Strategy,
Technology Strategy, Business Principles-Objectives-
& Drivers, Architecture Vision, Stakeholders
1
ARCHITECTURE VISION
2
3
4
Motivation: Drivers, Goals, Objectives, Measures
Organization: Organization Units, Locations, Actor,
Roles
Function: Business Services, Contracts, Service
Qualities, Processes, Events, Controls, Products
Data: Data Entities, Logical Data Components,
Physical Data Components
Applications: Information System Services, Logical
Application Components, Physical Application
Components
Platform Services
Logical Technology Components
Physical Technology Components
BUSINESS ARCHITECTURE
INFORMATION ARCHITECTURE
TECHNOLOGY ARCHITECTURE
Open
Architecture
Content
Framework
ARCHITECTURE
REALIZATION
Opportunities, Solutions, & Migration
Planning: Capabilities, Work
Packages, Architecture Contracts
Implementation Governance:
Standards, Guidelines, Specifications
The content framework represents a
template of objects, assets, and
processes that need to be identified
during architecture design build efforts.
The template list helps make sure all
requirements that will serve as inputs
and outputs to the architec.ture model
are considered.
Innovate
Vancouver
f
5

Technical Reference Model &
Standards information Base
Foundation
Architectures (TRM)
integrated information
infrastructure reference model
Common Systems
Architectures (III- RM)
The team should create a
visual representation.
Industry
Architectures
The team should monitor
the process efficiency.
Organization Specific
Architecturess
Architecture Continuum
Innovate Vancouver
An overview of the TRM and II RM are included in the
following slides

Communications
Infrastructure
Interface
Communications
Infrastrucure
Open Group's Technical Reference Model
(TRM)
T H E A R C H I T E C T U R E D E V E L O P M E N T
M O D E L ( A D M ) C Y C L E W I L L E M P H A S I Z E
T H E O P E N G R O U P ’ S T E C H N I C A L
R E F E R E N C E M O D E L ( T R M ) T O E N S U R E
T H E F O L L O W I N G A R E C A P T U R E D I N T H E
A R C H I T E C T U R E D E S I G N R E Q U I R E M E N T S
INFRASTRUCTURE &
BUSINESS
APPLICATIONS LAYER
APPLICATION
PROGRAMMING
INTERFACE
OPERATING
SYSTEMS AND
NETWORK
SERVICES
Software Engineering
Security
System & Network Management
Transaction Processing
Location & Directory
International Operations
Data Interchange
Data Management
Graphics & Images
Innovate Vancouver

Integrated Information Infrastructure
Reference Model (III-RM)
Information Consumer Applications
Information Provider Applications
Application Platform
Dev
Tools
Brokering
Applications
Management
Utilities
Security Qualities Mobility
Performance SLA's Qualities Mnagement Policies
Innovate
Vancouver
f
The III-RM is a subset of the TRM
reference model shown in the
previous slide. It is "fundamentally an
applications architecture reference
model." (opengroup.org)
This model shows the "major
component categories for
developing, managing, and operating
an integrated information
infrastructure."
Brokering applications are
responsible for requesting
information, breaking it down, and
sending to their destinations. This is
done continuously until the intended
action is completed. The model
initiates from the Information
Provider Application and ends its
circuit(s) with delivery to the
Information Consumer Applications.

ARCHITECTURE BOARD
Governance and Oversight
1
COMPLIANT
Meeting Product & Performance
Specifications Definitions
2
CONTRACTS
Partner and Support Level Agreements
3
MATURITY MODELS
Evaluate current processes and strengthening
continuous improvement
4
SKILLS FRAMEWORK
High level list of competencies and skills needed to
manage the architecture lifecycle
5
Architecture
Capability
Framework
Innovate Vancouver
Architecture capability
frameworks strengthen the
development of business
capability, planning, and
management of architecture
within the organization
The architecture
maturity model is
graphically depicted in
the following slide

INFORMATION
GOVERNANCE
OPPORTUNITIES
& SOLUTIONS
INFORMATION
ARCHITECTURE
1. Security Services Catalogue
2. Security Classification
3. Data Quality
BUSINESS
ARCHITECTURE
1. Security Policy/Architecture
2. Security Domain Model
3. Trust Framework
4. Risk Assessment
5. Business Risk Model/ Risk
Register
6. Applicable Law & Regulation
Register
PRELIMINARY
1. Business Drivers & Objecties
2. Security Principles
3. Risk Appetite
4. Key Risk Areas/ Business
Impact
5. Security Resource Plan
1. Security Audit
2. Security Training &
Awareness
1. Business Attribute Profile
2. Control Objectives /
Security Objectives
TECHNOLOGY
ARCHITECTURE
1. Security Standars
Enterprise Security Architecture Framework
REQUIREMENTS
MANAGEMENT
1. Business Atribute Profile
2. Control Objectives/ Security
Objectives
Innovate Vancouver
Leverage the enterprise security architecture as a reference
model to target, configure, and secure your information
technology assets
Each green circle on the graphic represents a phase
on the architecture development lifecycle (ADM)

LEVEL 1:
INFORMAL
LEVEL 2:
UNDER REVIEW
LEVEL 3:
STANDARDIZED
LEVEL 4:
MANAGED
LEVEL 5:
CONTINUOUS
IMPROVEMENT
Architecture Maturity
Model
Developed by the US Department of Defense (DOD),
the Architecture Maturity Models defines an
organizations architecture design, build, and
management process along the 5 level maturity
continuum depicted below.
The nine areas evaluated:
1. Architecture process
2. Architecture
development
3. Business linkage
4. Senior management
involvement
5. Operating unit
participation
6. Architecture
communication
7. IT security
8. Architecture
Governance
9. IT investment and
acquisition strategy
Innovate Vancouver /
Click on the link at the bottom of this slide to further explore the
criterion for each maturity level

Prepare Architecture
Review Report
3
1
4 6
7
8
9
11
12
Determine Scope
of Review
(Discovery)
Schedule
Architecture
Review Meeting
Accept, Review,
and Sign Off
Assessment
Report/Summary
Delivered
Analyze Completed
Checklist - Results
Interview Project
Principals
Identify Lead
Architect
Architecture
Review Request
Identify
Responsible
Organization
2
5
Tailor Checklists
10
Present Review
Findings
Architecture
Compliance
Review
Process
Innovate Vancouver
The compliance review process is used to audit and evaluate ongoing architecture development, changes, and
configuration against the target architecture approved by the stakeholders. The review process is activated per agreed
schedule, and in particular during change processes to help evaluate the change's impact on other architecture
components

Innovate Vancouver
Statement of
Architecture
Request
Document Outline
1. Request for Architecture
2. Define the enterprise
3. Identify key drivers and elements in the
organizational context
4. Define the requirements for the architecture
work
5. Define the architecture principles that will
inform any architecture work
6. Define the framework to be used
7. Define the relationships between management
framework
8. Evaluate the enterprise architecture maturity
Content
This initiation document is produced by the product and/or
architecture owner. Integration of feedback from primary
stakeholders is necessary to make sure the architecture team
understands the capabilities required to manage the solution
once delivered.
The architecture request is evaluated to insure it
aligns with key business drives, resources, and
capabilities within the organization.

Innovate Vancouver
Business
Architecture
Steps in the Architecture Development Method
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 &
timeline
6. Resolve impacts across the architecture
landscape
7. Conduct formal stakeholder review
8. Finalize the business architecture
9. Create architecture definition document
Steps
The business architecture includes the people,
processes, policies, culture, regulatory environment,
products & services, and business model of the
company.
The purpose of the data architecture, application
architecture, and technology architecture is to
support the workloads, processes, and goals of the
business and people.
The Open Group Architecture Framework incorporates the
Architecture Development Method (ADM) to help evaluate,
update, and manage the company's enterprise architecture. To
improve alignment, increase productivity, strengthen
performance, and increase efficiencies. The business
architecture drives everything across the architecture
development lifecycle.

Innovate Vancouver
Stakeholder
Management
1. Identify stakeholders
2. Classify stakeholder positions
3. Determine stakeholder management approach
4. Tailor engagement deliverables
Steps
Effective stakeholder management begins with
understanding the organizational context in which the
solution will be managed, accessed, and implemented.
This begins with drafting the stakeholder catalogue, which is
updated throughout the architecture development lifecycle.
This catalogue takes into consideration the development
team, users, and specialists that will manage the architecture
solution once delivered into the production environment.
It is crucial that the stakeholder catalogue is more
than a normative document that spells out the ideal
resources, roles, and specializations available to the
project. The catalogue also serves as a foundation
for discussing gaps and resources that still need to
be sourced.

Innovate Vancouver
Business
Scenarios
Document Outline
1. Problem description
2. Detailed objectives
3. View of environments and processes
4. Actors-their roles and responsibilities
5. Principles and constraints Requirements
Content
Business Scenarios help the architecture team understand how to
structure, configure, and deploy data, application, and technology
components across relevant environments.
These scenarios also help understand how the architecure
solutions are likely to be used, adopted, and implement. Which
barriers are likely to be encountered. These scenarios are also
leveraged to identify priorities, pain points, and release roadmaps.
Many business scenario mapping and
documentation tools are available. How these
scenarios are presented to stakeholders will depend
on their roles and responsibilities. Understanding
these views is critical towards building an effective
communications and onboarding roadmap.

Innovate Vancouver
Statement of
Architecture
Work
Document Outline
1. Title
2. Architecture project request background
3. Architecture project description and scope
4. Overview of architecture vision
5. Change of scope procedures
6. Roles, responsibilities, and deliverables
7. Acceptance criteria and procedures
8. Architecture project plan and schedule
9. Approval process
10. Establish the architecture project
11. Identify stakeholders, concerns, and business
requirements
12. Confirm business goals, drivers, and constraints
13. Evaluate capabilities
14. Assess readiness for business transformation
15. Define scope
16. Confirm and elaborate architecture principles,
including business principles
17. Develop architecture vision
18. Define the target architecture value propositions and
KPI's
19. Identify the business transofrmation and mitigation
activities
20. Develop statement of architecture work, secure
approval
Content
This document is drafted by the
architecture team with input from the
statement of architecture request (form).
This document goes into more detail and
sets the technical vision for the architecture
teams. Updated throughout the ADM
lifecycle.

Innovate Vancouver
Data Architecture
2. Develop baseline data architecture description
3. Develop target data architecture description
5. Define candidate roadmap components
6. Resolve impacts across architecture
landscape
8. Finalize the data architecture
Steps
Data is central to a business' competitive advantage. It gives
stakeholders information into the performance and drivers
across the enterprise. The business model is dependent on
data to make decisions.
Customers use information to inform their decisions. How
data is stored, structured, accessed, and viewed has a direct
impact on the company's competitive advantage and
stakeholder satisfaction metrics.
In the business architecture phase the team has
assessed the business requirements for the data
architecture. Phase B provides direct input and
direction into phase C, the data and application
architecture phase.

Innovate Vancouver
Application
Architecture
2. Develop baseline application architecture
description
3. Develop target application architecture
description
5. Define candidate roadmap components
6. Resolve impacts across architecture
landscape
8. Finalize the application architecture
Steps
Applications includes infrastructure and busines software that
stakeholder use everyday. From office applications to more
complex enterprise resource planning applications (ERP),
stakeholders depend on these tools to manage their workloads.
These applications are hosted in the company's technology
architecture and infrastructure. Wheter on premises or in the
cloud, these servers, networks, devices, and protocols help
protect the information assets stakeholders access through
applications.
The first step in the application architecture phases
is taking inventory of the applications already being
used. Further design at this phase includes
integration and interoperability considerations.
Determing what tools can be simplified, reused,
replaced, or rebuilt.
Simplicity supports both security but also
performance and ongoing management of business,
data, application, and technology assets.

Innovate Vancouver
Technology
Architecture
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 architecture
landscape
7, Conduct formal stakeholder review
8. Finalize the technology architecture
9, Create architecture definition document
Steps
Architecture partitioning is suggested when focusing on a
complex enterprise architecture. Designing the architecture and
the department or functional unit level. Integrating across each
iteration. Assessing compliance with the architecture standards
and statement of work throughout the project lifecycle.
Technology infrastructure underlies each partition. Efficiency,
performance, and cost controls scale as architectural
components are shared across the enterprise.
Building out a technology (and other phases)
architecture often involves a release schedule. With
different technology components delivered at
different times. A time based roadmap that focuses
on delivering measurable value to stakeholders
during each iteration.
The steps on this graphic provide a high level
roadmap for designing, upgrading, and
standardizing your company's technology
architecture.

Innovate Vancouver
1. Determine change attributes: Business, Data/App,
Technology. Includes transition and capability
assessment, and building out the matrix's from the
migrations phase
2. Determine business constraints for implementation.
Includes architecture maturity assessment and review
of strategic/business plans. Review the gaps and
dependencies matrix.
3. Review and consolidate gap analysis results from
Business, Data/App, and Technology phases. Review
matrix's.
4. Review consolidated requirements across related
business functions. Review matrix's.
5. Consolidate and reconcile interoperability
requirements. Review matrix's.
6. Refine and validate dependencies. Review matrix
and the business transformation readiness assessment
7. Confirm readiness and risk for business
transformation
8. Formulate implementation & migration strategy.
Review matrix and identify work packages. Other
considerations: resuse, procure, develop. In house.
Contract-outsource.
Opportunities &
Solutions
Steps
9. Identify and group major work packages
10. Identify transition architectures. Based on
organizational capability. Review matrix's.
Deliver clear business value with each
increment
11. Create architecture roadmap and
implementation and migration plan.
Consolidate interoperability requirements,
work packages, and transition architectures
into roadmap. Update architecture (ADM)
planning & requirement documents as
necessary

Innovate Vancouver
Migrations
Planning
1. Confirm management framework interactions
for the implementation and migration plan
2. Assign business value to each work package.
Reference organizational capability assessment
if available.
3. Estimate resource requirements, project
timings, and availability/ delivery vehicle
(priorities, value, resources, etc.)
4. Prioritize migration projects through the
conduct of a cost/ benefit assessment and risk
validation (prioritization, value, cost, risks, etc.)
5. Confirm architecture roadmap and
architecture definition document
6. Complete the implementation and migration
plan
7. Complete the architecture development cycle
and document lessons learned (architecture
development governance to implementation
lifecycle). Lessons learned further inform the
capability assessment and roadmap for building
the capabilities to manage the architecture.
Steps
Migration planning emphasizing delivering value
with each iteration. Prioritizing functionality and
business units that need migrated first.
Consolidating, cleaning, and migrating duplicated
assets to new architected environments.
The following migration steps are high level and
generic, to be tailored to the asset type.

Innovate Vancouver
Implementation
Governance
1. Confirm scope and priorities for deployment
with the development management
2. Identify deployment resources and skills
3.Guide development of solutions deployment
4. Perform Enterprise Architecture Reviews
5. Implement business and IT operations
6. Do post-implementation review, close the
implementation
Steps
The governance framework includes the processes, roles, and
responsibilities necessary to keep the architecture development
project on schedule, budget, and to approved specifications.
Many tools are available to help in this endeavor. This includes
quality management systems, a formal change control process,
formal change management and delivery roadmaps, and project
team structures and reporting relationships.
Implementation governance is supported with a
structured approach. Architectural partitioning
supports assigning the right architecture to the right
teams. Engaging the right subject matter experts
and leaders that own the solution.
SME's and leaders that are involved in making
decisions relevant to the targeted architecture.
Assigning resources. Evaluating progress.
Identifying how to overcome obstacles and
leveraging synergies.

Innovate Vancouver
Architecture
Change
Management
1. Establish value realization process (priority,
impact, constraints). Focus on alignment with
business strategy and goals.
2. Deploy monitoring tools (dashboards,
analytics, reports, governance). Monitor impact
of changes to business, data/applications,
technology architecture.
3. Manage risks (probability, impact, strategies).
Register all events that may impact the
architecture
4. Provide analysis for architecture change
management. Confirm expectations of
stakeholders are met. Performance. Impact.
SLA's. Standards. Gap analysis.
5. Develop change requirements to meet
performance targets
6. Manage governance process. Update
documents as necessary.
7. Activate the process to implement change.
Allocate resources and management for the
architecture tasks. Produce request for
architecture work (if needed).
Steps
Architecture change management is more than just
delivery schedules and training. It involves evaluating
the impact of changes. Managing risks. Re-architecting
solutions when needed. All focusing on the delivery of
value with each decision and/ or change.
The larger the change, the more impact it will have. The
more disruption caused the more important a formal
change management process becomes. This requires a
governance framework to evaluate and guide the
process.

Innovate Vancouver
Architecture
Change Request
The architecture change request is invovles a formal
process to implement a change. It involves
completing a thorough assessment of the change's
impact.
Evaluating options. Suggesting a solution based on
best practices and optimal performance. Then
acting on the decision made by the change control
board (or governance team, etc.)
1. Description of proposed change
2. Rationale for proposed change
3. Impact assessment of the proposed change
including a. Reference to specific requirements
b. Stakeholder priority of the requirements to
date
c. Phases to be revisited
d. Phase to lead on requiremnets prioritization
e. Results of phase investigations and revised
priorities
f. Recommendations on management of
requirements
4. Repository reference number
Content
The governance team reviews the change request. Evaluates
the impacts and risks identified, and considers the options and
suggestions made.
Their decision serves as a direct imput into the change
management process, migration mechanisms, and informs
updates to all architecture documents and artifacts (diagrams,
matrix's, process maps, architecture views, etc).

9. IMPLEMENT CHANGE
8. UPDATE THE ARCHITECTURE
REQUIREMENTS REPOSITORY
WITH INFORMATION RELATING
TO CHANGES REQUESTED
7. IMPLEMENT CHANGES
ARISING (ADM)
6. ASSESS IMPACT OF
CHANGE (ADM)
3. MONITOR BASELINE
REQUIREMENTS
2. BASELINE
REQUIREMENTS
1. IDENTIFY/DOCUMENT
REQUIREMENTS (ADM)
4. IDENTIFY CHANGED
REQUIREMENT (ADM)
5. IDENTIFY CHANGED
REQUIREMENT AND
RECORD PRIORITIES
Innovate Vancouver
Requirements
Management
Process
The requirements management process runs throughout the architecture development lifecycle. Requirements are scoped at a
high level during the architecture work request process. This is further clarified during the architecture vision phase, which
provides a high level vision for the architecture team to plan out their work. The subsequent phases (business, data/
applications, technical) involve further investigation and stakeholder consultation to confirm the architecture requirements. The
design for the architecture is updated as the development team builds out the architecture products, services, and assets.

Innovate
Vancouver
f

TOGAF Standard Architecture Design

Recommended

Recommended

More Related Content

What's hot

What's hot (20)

Similar to TOGAF Standard Architecture Design

Similar to TOGAF Standard Architecture Design (20)

More from Innovate Vancouver

More from Innovate Vancouver (20)

Recently uploaded

Recently uploaded (20)

TOGAF Standard Architecture Design