A Practical Approach to Iterate TOGAF ADM and deliver architecture

A Practitioners’ Approach to
Developing Enterprise Architecture
Following the TOGAF® ADM
Dave Hornford
Sriram Sabesan
Ken Street
Conexiam

Agenda
» Who We Are
» Why this Whitepaper
» Guiding an Enterprise – information before decision
» Architecture Landscape – filling by purpose
» Iterating and the Crop Circle
» Work Products
» Jumping to Phase G
» Architecting & Evolving
» Leading the Architecture Practice
» Q&A
1© Conexiam, 2017Straightforward Answers to Complex Problems

Conexiam
» Management consulting company
– Employ enterprise architecture as a tool of trade
– Operates in North America, Europe & the Middle East
– Uses a sprint based engagement model
– Provides strategic architecture to implementation
guidance and governance services
» Use open standards & public best practices
– IT4IT, TOGAF, SABSA, APQC, BMC, BMD, Strategy
Map
» Extend & integrate with in-house method
– Navigate & Pilot
» Contributing thought leaders
– Open Group
– The SABSA Institute
» Key work is demonstrating how they are used
– More documents under publication review
2
© Conexiam, 2017
(v170424)
Straightforward Answers to Complex Problems

Your Presenters
» Dave Hornford
– Partner, Conexiam
– dave.hornford@conexiam.com
– 20+ years in Consulting
» Active improving
architecture profession
– Open Group
– Digital Transformation
– The SABSA Institute
» Sriram Sabesan
– sriram.sabesan@conexiam.com
» Active improving
architecture profession
– IEEE
– Digital Transformation
– IASA
– Open CA
» Ken Street
– ken.street@conexiam.com
» Active improving
architecture
profession
– IT4IT
– Architecture Forum
– Open Platform

Why This Whitepaper
» Conexiam’s Philosophy
– Vanguard EA consultants
– Conexiam only does EA development &
EA Capability improvement
– Use open standards as base of service
offering
We don’t reinvent the basics of the wheel
– Share our practice
» Acceleration
– Highlight TOGAF’s framework in action
– Transition from theory to high-functioning
EA toolkit
» Bluntly:
– Continued poor practice
hurts our Industry
– Continued poor practice
has never-ending loop
• re-boot
• fail
• shutdown
• reboot

Why bother with EA?
» One very simple reason:
– to guide effective change
» Effective change starts with a strategy and realizes value
via appropriate solution implementation
» Enable Stakeholders
– to understand the implications of their preferences
– enforce their decisions

High functioning Architect
» Characteristics are straight-forward
– Support decision-makers with information ahead of decision
– Focused on time-to-market of their work product
– Own the decision-maker’s decision
– Work at the level of detail required for right now
– Do not do other people’s jobs
» Enable effective decision-making against complex cross-
cutting preferences
» Enable implementation to be guided and constrained

Starting Point: TOGAF
» TOGAF framework contains three parts:
1. Method
2. Content Framework
3. EA Capability Framework
» TOGAF by design
– scalable
– configurable
» TOGAF standard provides a Framework
– essential universal scaffolding

Overcome Mythology
» TOGAF is read as a cookbook
– Just STOP
» TOGAF is a Framework
– Look for the concept
– Always use the concept
» Foundation
– Use the same concept
Not the same technique, template, process, etc.
– Past the concept everything in TOGAF is an example or a starter

There is not ONE WAY
» No one right EA deliverable, model, view, work product,
or technique
» Want to succeed
– Align to purpose
– Align to successful approach
– Align to the problem
– Solve for your Stakeholders
» Want to fail
– Deliver after decision
– Be dogmatic in approach
– Address parochial problems
– Solve for your preference

Purpose
» EA to Support Strategy
– Deliver EA to provide an end-to-end Target Architecture, and develop roadmaps of change over a three to
ten-year period. An architecture for this purpose will typically span many change programs or portfolios. In
this context, architecture is used to identify change initiatives and supporting portfolio and programs. Set
terms of reference, identify synergies, and govern the execution of strategy via portfolio and programs.
» EA to Support Portfolio:
– Deliver EA to support cross-functional, multi-phase, and multi-project change initiatives. An architecture for
this purpose will typically span a single portfolio. In this context, architecture is used to identify projects,
and set their terms of reference, align their approaches, identify synergies, and govern their execution of
projects.
» EA to Support Project:
– Deliver EA to support the Enterprise’s project delivery method. An architecture for this purpose will typically
span a single project. In this context, the architecture is used to clarify the purpose and value of the
project, identify requirements to address synergy and future dependency, assure compliance with
architectural governance, and to support integration and alignment between projects.
» EA to Support Solution Delivery
– Deliver EA that is used to support the solution deployment. An architecture for this purpose will typically be
a single project or a significant part of it. In this context, the architecture is used to define how the change
will be designed and delivered, identify constraints, controls and

Think about Support
» Support is always before decision
» Guide & Constrain is before action
» Key is always before
– If you architect to support Strategy the strategy is not decided
– If you architect to support Portfolio the roadmap is not decided
– If you architect to support Project the project value and scope are
not decided
– If you architect to support Solution Delivery the solution is not
decided
» Architecting after is just documenting
– Very little value generation in documentation

EA Repository
» Breadth: subject matter covered
– Consider domain, organization, and initiative as
examples
– Breadth is one of the most important scoping
dimensions. Provides context of analysis.
» Level of Detail: self-explanatory
– Minimum necessary
» Time: the planning horizon
– Point in time reaching the is expected
– Care must be taken where one or more transition
architectures exist before reaching the planning
horizon
– Typically, the longer the planning horizon, the
less detailed the architecture
» Recency: fresh or stale
– a hint that prior EA may need to be reviewed and
either reaffirmed or replaced.

Purpose Breadth Level of Detail Time Recency
Architecture to
Support Strategy
No pattern.
Some Strategy will have a broad impact
while other Strategy will cover a narrow
subject.
Not very detailed.
May contain point constraints that are
very detailed when the value is
dependent upon tight control.
Typically, more guidance than
constraint.
Typically, looking ahead for a 3 to 10-
year period when Target.
Current Architecture to Support
Strategy tends to have a short
timeframe of validity.
Typically, the need to update and
keeping current this architecture is
highly variable.
Architecture to
Support Portfolio
Will cover single subjects (the
Portfolio).
Typically, not very detailed.
May contain discrete constraints that
are very detailed when the value is
dependent upon tight control.
Typically, valid for 2 to 5-year period
when Target.
Current Architecture to Support
Portfolio should be considered past its
best-before date. A portfolio without a
view to the future is pointless.
Typically, the need to update and
keeping current this architecture is
highly variable.
Architecture to
Support Project
Narrow breadth, typically discrete
Projects within a Portfolio.
Typically detailed.
Will contain detailed constraints, that
may not be fully supported by detailed
architecture descriptions.
Typically, more constraint than
guidance is developed.
Typically, valid as a target for <2 years.
Will have very long-lived timeframes as
current (post realization).
Typically, will be retained in the EA
Landscape for an extended period after
transition from Target to Current.
In the absence of an Architecture
Project, the architecture and associated
constraints and guidance will continue
indefinitely.
Architecture to
Support Solution
Delivery
Typically, very narrow breadth. Most detailed EA.
Will contain the most detailed
constraint.
Typically, only constraints will be
developed, as guidance will be carried
forward from superior architecture.
Typically, valid as a target for <2 years.
Will have very long-lived timeframes as
current (post realization).
Typically, will be retained in the EA
Landscape for an extended period after
transition from Target to Current.
In the absence of an Architecture
Project, the architecture and associated
constraints and guidance will continue
indefinitely.

What is Good Architecture?
» Planning horizon is key
1. Define a target (time in future) & current in same terms
2. Articulate the Gap – change, effort, and benefit
3. Articulate Controls against Risks and Assets
4. Articulate Constraints against choices implementing Target
» Without these four, there is no architecture
may include transition state
– It is not just about needing to do more
– Target aligned to stakeholder concerns

Method: Develop & Use Enterprise Architecture
Process Flow Information Flow
Undertaking any activity to produce the outputs of a Phase you are exercising the Phase
You consume the mandatory inputs and produce the mandatory outputs
This applies to all ADM phases.

Architecture States
» Current
– No architecture is same as deliberate architecture
» Candidate (Work-in-Progress)
– Unapproved version of target or transition state
– A version to inspect and assess a “What-if” scenario
What-if key in Trade-off
» Target
– Approved version of what better looks like at the end of planning horizon
» Transition State
– Interim, value realization state; Potential resting point & change in specification
– be very nervous about transition states – real transitions add governance overhead

Communicating Architecture – Ease of Use
» Preserve the stakeholder concern
– Trade-off is not about solving for one or the other
• it’s solving for all
• almost always means compromise for best fit
– Use views to communicate – anything that simplifies the message
• Views (Stakeholder + Concern + Representation of Concern)
» Architect is rarely present at time of decision
– Communication should support third party interpretation
– Decision and direction stays the same, even with second hand
information

Communicating Is Key
» Stakeholder(s)
– Enable assessment of the
implementation in support
of the target
– Need viewpoints to
address all concerns
(Do not confuse a viewpoint
with a communication)
– Govern implementation to
protect value
» Implementer(s)
– How the project fits within
the big picture?
– What is the value to be
protected & what
dependencies to watch-out
for?
– What does conformance
mean?

Viewpoint, Visualization & Communication
» Viewpoint
– Is your check-box
– Addresses Concern-Stakeholder Pair
– Enables confidence in your architecture
• Stakeholder/Concern addressed
• Analysis performed
• Information gathered
– Information required drives your EA
Repository & meta-model
• Gather & analyze only what is needed
• Gather & analyze all that is needed
» Visualization /
Communication
– In a happy place these are
Viewpoints
– In a real-place they are
different than Viewpoints
Viewpoint Library
Concern Stakeholders View Construction Information Required

ADM Outputs, Outcomes and Required Knowledge
21Straightforward Answers to Complex Problems © Conexiam, 2017
Phase Output & Outcome Essential Knowledge
Phase E:
Opportunities &
Solutions
A set of work packages that address
the set of gaps, with an indication of
value produced and effort required,
and dependencies between the work
packages to reach the adjusted target.
 Dependency between the set of
changes. (Work Package & Gap
dependency)
 Value, effort, and risk associated
with each change and work
package.
 How stakeholder priority and
preference adjust in response to
value, effort, and risk of change.
Phase F:
Implementation
and Migration
Plan
An approved set of projects, containing
the objective and any necessary
constraints, resources required, and
start and finish dates.
 Resources available to undertake
the change.
value, effort, and risk of change.
(Stakeholder Requirements)
Phase G:
Implementation
Governance
Completion of the projects to
implement the changes necessary to
reach the adjusted target state.
 Purpose and constraints on the
implementation team. (Gap,
Architecture Requirement
Specification, Control)
success, value, effort, and risk of
change. (Stakeholder
Requirements)
Phase H:
Architecture
Change
Management
Direction to proceed and start
developing a Target Architecture that
addresses perceived, real, or
anticipated shortfalls in the Enterprise
relative to stakeholder preferences.
 Gaps between approved target, or
preference, and realization from
prior work. (Value Realization)
 Changes in preference or priority.
(Stakeholder Requirements)
Phase Output & Outcome Essential Knowledge
Phase A:
Architecture
Vision
Sufficient documentation to get
permission to proceed.
Permission to proceed to
develop a Target Architecture to
prove out a summary target.
 The scope of the problem being
addressed.
 Those who have interests that are
fundamental to the problem being
addressed. (Stakeholders & Concerns)
 What summary answer to the problem is
acceptable to the stakeholders?
(Architecture Vision)
 Stakeholder priority and preference.
 What value does the summary answer
provide?
Phase B,
Phase C, &
Phase D
A set of domain architectures
approved by the stakeholders
for the problem being
addressed, with a set of gaps,
and work to clear the gaps
understood by the stakeholders.
 How does the current Enterprise fail to
meet the preferences of the
stakeholders?
 What must change to enable the
Enterprise to meet the preferences of the
stakeholders? (Gaps)
 What work is necessary to realize the
changes, that is consistent with the
additional value being created? (Work
Package)
 How stakeholder priority and preference
adjust in response to value, effort, and
risk of change. (Stakeholder
Requirements)

Key Work Product: Hot & Cold
Practice
Supports
Architecture to
Support Strategy
Architecture to
Support Portfolio
Architecture to
Support Project
Architecture to
Support Solution
Delivery
Phase A Work
Product:
Vision
Key deliverable
Before framing of a
strategic planning
session
Refresh before
initiation of
program budgeting
Key deliverable
Before start of
budget planning
Often not used
Activity to produce
a vision overlaps
with
portfolio/program
candidate
architecture and
roadmap
May be used at
business case
Limited use
Primary use is early in
implementation cycle
(via internal providers
or execution partners)
Phase E Work
Product:
Candidate
Architecture
During strategic
planning session
Refresh as required
in program
budgeting
Key deliverable
Before start of
budget planning
Primary use is
stakeholder
acceptance of
target and gap
Before project
initiation and
finalization of
business case
Primary use is
creation of
Architecture
Specification
Before engagement of
execution partners
(including internal
providers)
Primary use is creation
of Architecture
Specification
Roadmap During strategic
planning session
Refresh as required
in program
budgeting
Before start of
budget planning
Refresh as required
to support
budgeting and
program
management
Limited use
Can be used as an
input to projects
with multiple
interactive changes
Before engagement of
execution partners
(including internal)
ID required change
and execution
preference. Manage
change & delivery
partner selection
Practice Supports
Architecture to
Support Strategy
Architecture to
Support Portfolio
Architecture to
Support Project
Architecture to
Support Solution
Delivery
Phase F :
Architecture
Contract &
Architecture
Specification
Likely not used Limited use Key deliverable
Before completion
of project initiation
Key deliverable
Before engagement
and contracting
Implementation
& Migration Plan
Likely not used During portfolio
budgeting
Refresh as required
to support
budgeting and
program
management
Key deliverable
Before project start
Key deliverable
Before engagement
and contracting
Phase G Work
Product:
Conformance
Assessment
Likely not used Likely not used Key deliverable
At key points in
project that allow
reporting to
stakeholders and
decisions for non-
conformance
Key deliverable
At key points in project
that allow reporting to
stakeholders and
obtaining decisions for
non-conformance
Phase H Work
Product:
Value
Assessment
Before governance
review, framing a
strategic planning
session and program
budget
Key deliverable
Before governance
review and program
budgeting
Refresh as required
to support program
management
Limited use
Scope of significant
architecture change
and value often
does not cleanly
align to projects
Limited use
Scope of significant
architecture change
and value often does
not cleanly align to
solution deployment

Use of Solution Delivery Notebook (SDN)
» Living Document
» Possible output of
– Architecture to support Strategy
– Architecture to support Portfolio
» Mandatory output of
– Architecture to support Project
– Architecture to support Solution
Delivery
» Is example of TOGAF’s Architecture
Contract concept
» Ensures building a “complete
bridge”

ADM Plan for each Purpose Based Architectures
» Support Strategy
– Understand context
– Perform assessment and
analysis
– Define approach to target
state
– Finalize Architecture
Vision/target state

» Support Portfolio
– Group work packages to
themes
– Balance opportunity and
viability
– Run up to budget
– Drive confidence of
delivery

» Support Project
– Ascertain dependencies
– Balance options and
suppliers
– Finalize scope and budget
– Prepare for Solution
Delivery Governance
» Support Solution Delivery
– Align implementers
– Guide delivery
– Realizing the solution

Jumping to G
» Not a bad thing!
– Often a good thing
» Be aware:
– sooner the enterprise jumps to G the more complex the compliance
– sooner the enterprise jumps to G, higher the number of constraints to future architecture
work!
– sooner the enterprise jumps to G the sooner it can achieve business value
» Distinguish Jumping to G from Un-architected action
» Jumping to action nothing but pitfall traps
This classic approach is why EA exists
– Missing the purpose
– Missing the business cycle
– Not doing architecture

Agile Enterprise
» Agile EA Concepts
– EA Landscape defines the backlog
– Business Cycle drives backlog
priority
– Good meta-model defines the
contents of the EA Landscape
» Approach
– Think “purpose-based”
Architectures
– Iteration is key to time-to-market
– Superior Architecture is key to
architecture development
– Normally one iteration to create
“architecture to support
strategy” results in several
iterations of other architectures
If you use TOGAF ADM iteratively
you are directly supporting an Agile
approach to EA development
Use Agile approach to develop EA
Use EA to guide
Backlog & Sprint
Planning
Use EA to constrain
change in a Sprint
Developing EA that enables an Agile enterprise

Architecture as a “Product”
» EA work produces information
– to guide decision making
– to drive effective change
» Product = “a binder’
= the “SDN”
= the “Direction Governance Binder”
= the “Portfolio Binder (Sprint Team Binder)”
» Agile Enterprise requires its EA team to be Agile (Agile EA)
» To deliver Agile EA, the EA team needs to follow an agile method
» Agile method = Creating “purpose-based” architectures

Evolving Architectures
» What we do all day long
» Re-use existing work
– Superior Architecture
every decision previously made that passes recency
» Iteration in Action
» Requires high-quality EA Repository
• able to manage & compare multiple states
» Think of the paths
– Current >> Target >> New Target >> Current >>…
– Current >> New Current >> New Current >> Target
» Do you have a Target or just a current action plan?

Comparing Architectures
» If you do not compare architecture you do not do architecture
– You have no Gap
– You have no common understanding of current
– You have no approved Target
• Approved Target requires Stakeholder understanding of work to fill Gap
– Cannot see how you are doing Trade-off
» Comparing requires like description
– EA Repository / Metamodel Key for Comparing
» We constantly compare
– Candidate (typically multiple) with Current & Target

Governance
» Creation (Target)
– Do you have the right Stakeholder(s)?
– Did a Stakeholder(s) Approve?
– Did it address their concerns?
– Really?
» Consumption (Implementation of Target)
– Without an approved target implementation
governance is not possible
– Report non-conformance to Stakeholders
and step back (governance reporting)
• Is the implementation delivering the
intended benefits and value
Govern Creation
Govern
Consumption

Governance Roles
» Stakeholder:
– Owner of the architecture. Provides priority, preference, and direction.
– All decision rights about the Target Architecture, and any relief from and enforcement of the target, are vested in the
stakeholders.
» Stakeholder Agent:
– Representative of the stakeholder.
» Subject Matter Expert:
– Possesses specialized knowledge about some aspect of the Enterprise or the environment in which it operates.
Provides knowledge, advice, and validation of interpretation.
» Implementer:
– Responsible for performing all change activity. Scope of change is not relevant.
– All decision rights about proposed implementation choices, such as design, product selection, and change sequence,
are vested with the implementer.
» Architect:
– Developer of the Target Architecture.
– Provides recommendations when non-compliance with the target is determined.
» Auditor:
– Performs systematic reviews of both the target creation and implementation of the target.
– Best performed at multiple stages to capture errors before the cost of correction exceeds potential value realization.
– Auditing can be performed within a formal structure such as an architecture governing board or by a peer reviewer.

Governance Reporting
» Concerns
– THESE ARE NOT STATEMENTS OF REQUIREMENT
– Think of them as topic areas
Constraint
(Architecture Principle,
Architecture Requirements
Specification, or Control)
Value
(Best done in terms of the
Enterprise’s mandatory
concerns) Gap
Current state: assess what the Enterprise has Conforms Fails to Deliver Not Applicable
Implementation Project: assess project, design, and
implementation
Violates Not Applicable Filling
Roadmap, portfolio, or program: assess plans and
directions
Not Applicable Delivers Leaving Open

Stakeholder Concerns Matrix (example)
Agility
Efficiency
Value
Value
Proposition
ChangeCost
Change
Impact
Alignment
Feasibility
Dependability
Control
Specification
Security
Confidence
Customer
Intimacy
Scalability
Business
Continuity
Senior Leaders X X X X X X X X X X
Portfolio
Managers
X X X X X X X X X X X
Business
Requirements
Owners
X X X X X X X
Implementers X X X X X X X
Risk Owners X X X X X X X X X
Business
Partner
X X X X X X X X X
Customer X X X X X X X
Remember: Real approval is complex
If you don’t resolve X, you will be surprised in G when unaddressed Concerns demonstrate you do not have an approved architecture
 Need one for each
Architecture Purpose
 Used to validate
Completeness and
Confidence
 Stakeholders and
Concerns will vary –
Public vs Private
 Every X needs to be
resolved

Stakeholder Concerns Matrix (example)
Agility
Efficiency
Value
Value
Proposition
ChangeCost
Change
Impact
Alignment
Feasibility
Dependability
Control
Specification
Security
Confidence
Customer
Intimacy
Scalability
Business
Continuity
Senior Leaders X X X X X X X X X
Portfolio
Managers
X X X X X X X X X X X
Business
Requirements
Owners
X X X X X X X
Implementers X X X X X X X
Risk Owners X X X X X X X X X
Business
Partner
X X X X X X X X X
Customer X X X X X X
Remember: Tradeoff discussions can be difficult
The Practitioner is assisting their organization select the best possible path against a set of competing preferences over time –
governance ensures the best path is delivered
TradeoffPossible
 Need one for each
Architecture Purpose
 Have all conflicts in
the Target been
identified
 Have the conflicts
been resolved

Building the EA Capability
» Start with TOGAF
– Universal essential scaffolding
– Not a cookbook
» Look to your purpose & where in the business cycle you are
» Look at who your Stakeholders are
» Look at Superior Architecture (even if it isn’t documented)
» Use tools at hand to accelerate your work
– World-Class EA: A Practitioners’ Approach to Developing Enterprise Architecture Following the
TOGAF® ADM
– Digital Transformation Strategy to Implementation using The Open Group Standards
– The TOGAF® Leader’s Guide to Establishing and Evolving an EA Capability
– TOGAF® 9 and DoDAF 2.0
– Information Security Management (O-ISM3, TOGAF®, and SABSA®)
– The Open Group IT4IT™ Reference Architecture, Version 2.1
» Watch-out: deliver something useful for senior decision-makers and you don’t get to stop

Q and A

A Practical Approach to Iterate TOGAF ADM and deliver architecture

Recommended

Recommended

More Related Content

What's hot

What's hot (20)

Similar to A Practical Approach to Iterate TOGAF ADM and deliver architecture

Similar to A Practical Approach to Iterate TOGAF ADM and deliver architecture (20)

More from Sriram Sabesan

More from Sriram Sabesan (11)

Recently uploaded

Recently uploaded (20)

A Practical Approach to Iterate TOGAF ADM and deliver architecture

Editor's Notes