a practical approach to iterate togaf adm and deliver architecture

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

Upload: sriram-sabesan

Post on 22-Jan-2018

473 views

Category:

Business


4 download

TRANSCRIPT

Page 1: 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

25 April, 2017

Page 2: A Practical Approach to Iterate TOGAF ADM and deliver architecture

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

Page 3: A Practical Approach to Iterate TOGAF ADM and deliver architecture

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

Page 4: A Practical Approach to Iterate TOGAF ADM and deliver architecture

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

Page 5: A Practical Approach to Iterate TOGAF ADM and deliver architecture

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

Page 6: A Practical Approach to Iterate TOGAF ADM and deliver architecture

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

Page 7: A Practical Approach to Iterate TOGAF ADM and deliver architecture

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

Page 8: A Practical Approach to Iterate TOGAF ADM and deliver architecture

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

Page 9: A Practical Approach to Iterate TOGAF ADM and deliver architecture

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

Page 10: A Practical Approach to Iterate TOGAF ADM and deliver architecture

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

Page 11: A Practical Approach to Iterate TOGAF ADM and deliver architecture

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

Page 12: A Practical Approach to Iterate TOGAF ADM and deliver architecture

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

Page 13: A Practical Approach to Iterate TOGAF ADM and deliver architecture

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

Page 14: A Practical Approach to Iterate TOGAF ADM and deliver architecture

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

Page 15: A Practical Approach to Iterate TOGAF ADM and deliver architecture

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

Page 16: A Practical Approach to Iterate TOGAF ADM and deliver architecture

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.

Page 17: A Practical Approach to Iterate TOGAF ADM and deliver architecture

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.

Page 18: A Practical Approach to Iterate TOGAF ADM and deliver architecture

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

Page 19: A Practical Approach to Iterate TOGAF ADM and deliver architecture

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

Page 20: A Practical Approach to Iterate TOGAF ADM and deliver architecture

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

Page 21: A Practical Approach to Iterate TOGAF ADM and deliver architecture

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

Page 22: A Practical Approach to Iterate TOGAF ADM and deliver architecture

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)

Page 23: A Practical Approach to Iterate TOGAF ADM and deliver architecture

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

Page 24: A Practical Approach to Iterate TOGAF ADM and deliver architecture

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

Page 25: A Practical Approach to Iterate TOGAF ADM and deliver architecture

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

Page 26: A Practical Approach to Iterate TOGAF ADM and deliver architecture

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

Page 27: A Practical Approach to Iterate TOGAF ADM and deliver architecture

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

Page 28: A Practical Approach to Iterate TOGAF ADM and deliver architecture

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

Page 29: A Practical Approach to Iterate TOGAF ADM and deliver 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

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

Page 30: A Practical Approach to Iterate TOGAF ADM and deliver architecture

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

Page 31: A Practical Approach to Iterate TOGAF ADM and deliver architecture

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

Page 32: A Practical Approach to Iterate TOGAF ADM and deliver architecture

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

Page 33: A Practical Approach to Iterate TOGAF ADM and deliver architecture

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

Page 34: A Practical Approach to Iterate TOGAF ADM and deliver architecture

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

Page 35: A Practical Approach to Iterate TOGAF ADM and deliver architecture

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

Page 36: A Practical Approach to Iterate TOGAF ADM and deliver architecture

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

Page 37: A Practical Approach to Iterate TOGAF ADM and deliver architecture

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

Page 38: A Practical Approach to Iterate TOGAF ADM and deliver architecture

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

Page 39: A Practical Approach to Iterate TOGAF ADM and deliver architecture

Q and A

38© Conexiam, 2017Straightforward Answers to Complex Problems