Please enable JavaScript.
Coggle requires JavaScript to display documents.
1 Architecture Development Method - Coggle Diagram
1 Architecture Development Method
Phases
Preliminary Phase
Objectives
Selection of Tools
Prep & initiation activities for Architecture Capability
Define Architecture Principles
Prep Org for TOGAF Arch Project
Customization of the TOGAF framework
Requirement Management
Every stage of a TOGAF project is
based on
validates
business requirements.
identified, stored, and fed into and out
of the relevant ADM phases
of the relevant ADM phases, which dispose of, address,
and prioritize requirements.
Requirements are
Phase A
Architecture Vision
Set
the scope
constraints,
for a
TOGAF project
expectations
Create the Architecture Vision
Identify stakeholders
Validate the business context
create the Statement of Architecture Work
Obtain approvals
Phase B
Business Architecture
Develops Business Architecture
Phase D
Technology Architecture
Phase C
Information
Systems Architectures
Application & Data
Phase E
Opportunities & Solutions
Perform initial implementation planning
identification of delivery vehicles for the building blocks identified in the previous phases.
Determine whether
an incremental approach is required
if so identify Transition Architectures
Phase F
Migration Planning
Develop detailed
Implementation Plan
Migration Plan
addresses
how to move from the Baseline to the Target
Architecture.
Phase G
Implementation Governance
Provide architectural
oversight
for the implementation
Prepare and issue Architecture Contracts
Ensure that the
implementation project conforms to the architecture
Phase H
Architecture
Change Management
Provide
continual monitoring
change management
process
ensure
maximizes the value of the
architecture to the business.
architecture responds to the needs of the enterprise
Phases and Steps are covered in Certified Course
ADM outputs and Versioning 0.1 and 1.0
ADM
iterative process
Cycling around the ADM
Iterating between phases
Cycling around a single phase
validation of results against the original requirements
reconsider - scope detail, schedules and milestones
consider assets from
previous iterations
external assets from marketplace
Relationship ADM
- Other parts of TOGAF
there are reminders to consider
which
architecture assets from the Architecture Repository the architect should use
development of a Technology Architecture
Similarly, in the development of a
Business Architecture
, it may be a
reference model for e-Commerce
taken from the industry at large
Each iteration
populate an organization-specific landscape
ADM is on the development of the enterprise-specific
ADM can also be viewed
process of populating the enterprise’s own Architecture
Repository with relevant re-usable building blocks
all the architecture assets identified and leveraged through the process
ADM repeatedly over time,
Other parts of TOGAF
Architecture Repository
Includes
reference architectures
models
patterns
that have been accepted for use within the enterprise
actual architectural work done previously within the enterprise
Enterprise continuum
Practical implementation of
the architect gradually adds more and more content to the organization’s Architecture Repository
Foundation Architecture
Business requirement
s of an enterprise may be used to identify the necessary definitions and
selections
set of re-usable common models
policy and governance definitions
even as specific as overriding technology selections
Supporting Guidelines and Techniques
The guidelines provided with the TOGAF standard describe
how the ADM process can be adapted
to deal with a number of
different usage scenarios
The
techniques
described within TOGAF 9 Part III support
specific tasks within the ADM
(e.g., the
gap analysis
technique, principles, etc.)
Enterprise Continuum
An Approach to
categorize
the
architecture
source
material
set of relevant, available
reference models in the industry
contents of the organization’s
own Architecture
Repository
How to
Adapt the ADM
to your Enterprise
Reasons for Adabpting
order of phases
- business and architecture
principles
of an enterprise
order
of the phases - the
maturity
of the
architecture discipline
ADM in
conjunction with
another enterprise architecture framework
ADM to reflect the relationships with, and
dependencies
on, the
other management processes
small-to-medium enterprise - to the
reduced level
of
resources
and
system complexity
enterprise is very large and complex - interlinked “enterprises” within an
overall collaborative business framework
need for the
ADM process to be governed
is a key process to be managed and governed
Architecture Board should be satisfied
- applied
correctly across all phases
ensure that all
considerations are made
all
required deliverables are produced
management
architectural artifacts
one or more repositories
supporting versioned object
process control and status
governance
related processes
governance repository
Reference Data
for
guidance and instruction
during project implementation
description of the governance procedures
Process Status
A record of
state of any governance processes
ex:
outstanding compliance requests
dispensation requests
compliance assessment investigations
Audit Information:
Key decisions and responsible personnel
A reference for future
architectural
and
supporting process developments, guidance, and precedence
reasons for
scoping an architecture activity
Reasons
objectives and stakeholder concerns
availability of people, finance, and other resources
organizational authority
possible dimensions for limiting
Breadth
Depth
Time period
Architecture domains
need for an integration framework
different types of architecture need to co-exist
consistent frame of reference
architecture integration - lower end of the integration spectrum
granularity and level of detail in each artifact
maturity of standards
for the interchange of architectural descriptions