a practical approach to iterate togaf adm and deliver architecture
TRANSCRIPT
A Practitioners’ Approach to
Developing Enterprise Architecture
Following the TOGAF® ADM
Dave Hornford
Sriram Sabesan
Ken Street
Conexiam
25 April, 2017
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– [email protected]
– 20+ years in Consulting
» Active improving
architecture profession
– Open Group
– Digital Transformation
– The SABSA Institute
» Sriram Sabesan– Partner, Conexiam– [email protected]
– 20+ years in Consulting
» Active improving
architecture profession
– IEEE
– Digital Transformation
– IASA
– Open CA
3© Conexiam, 2017Straightforward Answers to Complex Problems
» Ken Street– Partner, Conexiam– [email protected]
– 20+ years in Consulting
» 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 offeringWe 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
4© Conexiam, 2017Straightforward Answers to Complex Problems
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
5© Conexiam, 2017Straightforward Answers to Complex Problems
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
6© Conexiam, 2017Straightforward Answers to Complex Problems
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
7© Conexiam, 2017Straightforward Answers to Complex Problems
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 conceptNot the same technique, template, process, etc.
– Past the concept everything in TOGAF is an example or a starter
8© Conexiam, 2017Straightforward Answers to Complex Problems
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
9© Conexiam, 2017Straightforward Answers to Complex Problems
» 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
10© Conexiam, 2017Straightforward Answers to Complex Problems
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 arenot decided
– If you architect to support Solution Delivery the solution is not decided
» Architecting after is just documenting– Very little value generation in documentation
11© Conexiam, 2017Straightforward Answers to Complex Problems
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.
12© Conexiam, 2017Straightforward Answers to Complex Problems
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.
13© Conexiam, 2017Straightforward Answers to Complex Problems
What is Good Architecture?
» Planning horizon is key1. 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 architecturemay include transition state
– It is not just about needing to do more
– Target aligned to stakeholder concerns
14© Conexiam, 2017Straightforward Answers to Complex Problems
Method: Develop & Use Enterprise Architecture
15© Conexiam, 2017Straightforward Answers to Complex Problems
Process Flow Information FlowUndertaking any activity to produce the outputs of a Phase you are exercising the Phase
You consume the mandatory inputs and produce the mandatory outputsThis applies to all ADM phases.
Method: Develop & Use Enterprise Architecture
16© Conexiam, 2017Straightforward Answers to Complex Problems
Process Flow Information FlowUndertaking any activity to produce the outputs of a Phase you are exercising the Phase
You consume the mandatory inputs and produce the mandatory outputsThis 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” scenarioWhat-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
17© Conexiam, 2017Straightforward Answers to Complex Problems
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
18© Conexiam, 2017Straightforward Answers to Complex Problems
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?
19© Conexiam, 2017Straightforward Answers to Complex Problems
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
20© Conexiam, 2017Straightforward Answers to Complex Problems
Viewpoint LibraryConcern 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.
How stakeholder priority and preference adjust in response to 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)
How stakeholder priority and preference adjust in response to 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 & ColdPractice 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 changeand execution preference. Manage change & delivery partner selection
Practice SupportsArchitecture 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
22© Conexiam, 2017Straightforward Answers to Complex Problems
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”
23© Conexiam, 2017Straightforward Answers to Complex Problems
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
24© Conexiam, 2017Straightforward Answers to Complex Problems
ADM Plan for each Purpose Based Architectures
» Support Portfolio
– Group work packages to
themes
– Balance opportunity and
viability
– Run up to budget
– Drive confidence of
delivery
25© Conexiam, 2017Straightforward Answers to Complex Problems
ADM Plan for each Purpose Based Architectures
» 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
26© Conexiam, 2017Straightforward Answers to Complex Problems
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 trapsThis classic approach is why EA exists
– Missing the purpose
– Missing the business cycle
– Not doing architecture
27© Conexiam, 2017Straightforward Answers to Complex Problems
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
28© Conexiam, 2017Straightforward Answers to Complex Problems
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
29© Conexiam, 2017Straightforward Answers to Complex Problems
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?
30© Conexiam, 2017Straightforward Answers to Complex Problems
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
31© Conexiam, 2017Straightforward Answers to Complex Problems
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
32© Conexiam, 2017Straightforward Answers to Complex Problems
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.
33© Conexiam, 2017Straightforward Answers to Complex Problems
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
34© Conexiam, 2017Straightforward Answers to Complex Problems
Stakeholder Concerns Matrix (example)
Agi
lity
Effi
cie
ncy
Val
ue
Val
ue
P
rop
osi
tio
n
Ch
ange
Co
st
Ch
ange
Im
pac
t
Ali
gnm
en
t
Feas
ibili
ty
De
pe
nd
abili
ty
Co
ntr
ol
Spe
cifi
cati
on
Secu
rity
Co
nfi
de
nce
Cu
sto
me
r In
tim
acy
Scal
abili
ty
Bu
sin
ess
Co
nti
nu
ity
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 XBusiness Partner
X X X X X X X X X
Customer X X X X X X X
35© Conexiam, 2017Straightforward Answers to Complex Problems
Remember: Real approval is complexIf 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)
Agi
lity
Effi
cien
cy
Val
ue
Val
ue
P
rop
osi
tio
n
Ch
ange
Co
st
Ch
ange
Im
pac
t
Ali
gnm
en
t
Feas
ibili
ty
De
pe
nd
abili
ty
Co
ntr
ol
Spe
cifi
cati
on
Secu
rity
Co
nfi
de
nce
Cu
sto
me
r In
tim
acy
Scal
abili
ty
Bu
sin
ess
C
on
tin
uit
y
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 XBusiness Partner
X X X X X X X X X
Customer X X X X X X
36© Conexiam, 2017Straightforward Answers to Complex Problems
Remember: Tradeoff discussions can be difficultThe 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
Trad
eo
ff P
oss
ible
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
37© Conexiam, 2017Straightforward Answers to Complex Problems
Q and A
38© Conexiam, 2017Straightforward Answers to Complex Problems