Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

A Practical Approach to Iterate TOGAF ADM and deliver architecture

1,023 views

Published on

Benefits and Focus of the webinar:
Decision Maker: You will learn how to get the best out of your architecture team
Project / Portfolio Manager: Why architects can be your best friends and help you excel
Implementation Partner: What to demand from good architecture and gain the widest playing field to innovate
Architects: How to position yourself to be the "direction shaper"

Published in: Business
  • Hello! Get Your Professional Job-Winning Resume Here - Check our website! https://vk.cc/818RFv
       Reply 
    Are you sure you want to  Yes  No
    Your message goes here

A Practical Approach to Iterate TOGAF ADM and deliver architecture

  1. 1. A Practitioners’ Approach to Developing Enterprise Architecture Following the TOGAF® ADM Dave Hornford Sriram Sabesan Ken Street Conexiam
  2. 2. 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
  3. 3. 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
  4. 4. 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 – Partner, Conexiam – sriram.sabesan@conexiam.com – 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 – ken.street@conexiam.com – 20+ years in Consulting » Active improving architecture profession – IT4IT – Architecture Forum – Open Platform
  5. 5. 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 4© Conexiam, 2017Straightforward Answers to Complex Problems
  6. 6. 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
  7. 7. 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
  8. 8. 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
  9. 9. 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 8© Conexiam, 2017Straightforward Answers to Complex Problems
  10. 10. 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
  11. 11. 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
  12. 12. 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 11© Conexiam, 2017Straightforward Answers to Complex Problems
  13. 13. 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
  14. 14. 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
  15. 15. 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 14© Conexiam, 2017Straightforward Answers to Complex Problems
  16. 16. Method: Develop & Use Enterprise Architecture 15© Conexiam, 2017Straightforward Answers to Complex Problems 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.
  17. 17. Method: Develop & Use Enterprise Architecture 16© Conexiam, 2017Straightforward Answers to Complex Problems 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.
  18. 18. 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 17© Conexiam, 2017Straightforward Answers to Complex Problems
  19. 19. 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
  20. 20. 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
  21. 21. 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 Library Concern Stakeholders View Construction Information Required
  22. 22. 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)
  23. 23. 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 22© Conexiam, 2017Straightforward Answers to Complex Problems
  24. 24. 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
  25. 25. 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
  26. 26. 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
  27. 27. 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
  28. 28. 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 27© Conexiam, 2017Straightforward Answers to Complex Problems
  29. 29. 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
  30. 30. 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
  31. 31. 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
  32. 32. 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
  33. 33. 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
  34. 34. 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
  35. 35. 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
  36. 36. 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 35© Conexiam, 2017Straightforward Answers to Complex Problems 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
  37. 37. 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 36© Conexiam, 2017Straightforward Answers to Complex Problems 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
  38. 38. 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
  39. 39. Q and A 38© Conexiam, 2017Straightforward Answers to Complex Problems

×