Goo Biz Governing Scrum using TOGAFs ADM Governing

Goo. Biz Governing Scrum using TOGAF’s ADM Governing Scrum using TOGAF ADM & The Goal-Driven Capability Based Development Birol Berkem, Ph. D – Enterprise Architect (Master Data Quality Manager, TOGAF 9, Archi. Mate 3) Goo. Biz. com This webinar does not have to be considered as a TOGAF or Archi. Mate 2 training class. It only aims at showing how to make connections between TOGAF® ADM and SCRUM in order to : • establish the project vision on the basis of business values, • synchronize features of the product backlog / sprints with functions of the capability increments, • provide ‘walking skeletons’ with consolidated architecture gaps, • while maintaining governance with changing strategies and supporting business agility… Note : TOGAF 9 (The Open Group Architecture Framework) and Archi. Mate 3 are trademarks of the Open Group

Goo. Biz Business Agility requires an Enterprise Architecture • Business agility [1] is the ability of a business to adapt rapidly and cost efficiently in response to changes in the business environment. • It includes : – maintaining & adapting goods and services to meet customer demands, – adjusting them coherently to changes in a business environment – taking advantage of assets at all production dimensions of an enterprise architecture : business, data, application, technology • The alignment of organizations with such changing needs requires an enterprise architecture [2] to enable effective execution of the enterprise strategy to achieve change (until the IT level) – EA [2] is defined as : A conceptual blueprint that defines the structure and operation of an organization. The intent of an enterprise architecture is to determine how an organization can most effectively achieve its current and future objectives. • • [1] Adapted from "On the Measurement of Enterprise Agility” - Nikos C. Tsourveloudi , Kimon P. Valavanis (2002) [2] Search. CIO. com 2

Goo. Biz Enterprise Architecture needs to be Governed • TOGAF : An Enterprise Architecture Framework to align Enterprise Ressources, IT Systems and Technologies with the changing Business Strategies by : • Identifying gaps between current and target architectures, • Providing roadmap to achieve goals and ‘coordinate’ current and future projects of the organisation 3 How can ADM realize Business Strategies on a « Capability » basis ?

Goo. Biz Governance of implementation and Architecture Change Management Phases in TOGAF’s ADM – A Summary Drivers, Goals, Principles, Business Values Capabilities, Concerns of Stakeholders, Requirements, Business Transformation Readiness Assessments, Risks… Development of the Enterprise Architecture, Views of the Architecture across domains, Gaps, Risk Mitigation , … Detailed Implementation, Migration Plan, Work Packaged Actions to Coordinate Projects Consolidating architecture descriptions Risks Assessments, Definition of the Roadmap Identifying opportunities for re-use and potential solution components How « Governance » applies on the ADM to realize Business Strategies ? © Birol Berkem Goo. Biz. com Paris, 2014 4

Goo. Biz Main Parts of the Governance Process Governance is the practice by which enterprise architectures are managed and controlled at an enterprise-wide level This includes: • controls on the creation and monitoring of activities and components – ensuring introduction, implementation, and evolution of architectures, • ensuring compliance with internal and external standards and regulatory obligations • supporting management of the above (components and activities, their compliance, …) • ensuring accountability to external and internal stakeholders What are current needs about GOVERNANCE on Agile Development ? 5 © Birol Berkem Goo. Biz. com Paris, 2014

Goo. Biz Needs about Governance on Agile Development • Important tension between team’s desire to be “agile”, the workgroup’s narrow business objectives and the organizational interest in standards, structure, visibility and security ! • Companies that use Agile Software Development Methodologies are currently searching ways to : – Align “agile development” to best practices, – Gain centralized control and visibility of the progress across the company, – While adhering to governance and regulatory requirements, – Leveraging any internal/ external solutions with any process and methodology for development • And despite the fact that they may be geographically dispersed… How such Governance needs may « frame » elements of Scrum life cycle ? 7 © Birol Berkem Goo. Biz. com Paris, 2014

Goo. Biz Scrum Life Cycle (Summary) The development is based on a series of capabilities : From the vision statement until the final product 1: Craft a Product Vision & Identify Users and their Needs 2: Identify User Goals and the Activities to meet them 3: Identify the Important Tasks for performing the Most Important Activities 4: Build a Walking Skeleton for the Highest Needs as part of the First Iteration 5: Allow other Detailed Architecture and Additional Features to Emerge Over time Sprint Retrospective Inspect and adapt in an effort to improve… Vision Statement How the previous Governance needs may be used as inputs for Scrum touch-points ? 6

Goo. Biz Governance Inputs on the Touch-Points of Scrum Life Cycle How to carry on Business Values on the basis of Risks and Capability Increments ? How to create & update Features based on Consolidated Gaps & Dependencies ? How to Monitor Risks How to provide Consolidated INPUTS for the Walking Skeleton & Ensure Conformance to the Architecture Constraints ? (end-to-end architecture structures) on the basis of architecture gaps ? Vision Statement 9 This necessitates to Govern Value Streams (from Features to Deployment) using TOGAF ADM & Capability Based Planning

Goo. Biz Governing Scrum using TOGAF’s ADM Business Values carried by Capability Increments Risk Monitoring & Conformance Review Potentially Shippable Product Increment Inputs for ‘Walking Skeletons’ based on Consolidated Architecture Gaps Daily Scrum 1 -4 Week Sprints Features based on Consolidated Gaps & Dependencies Sprint Planning How to support such connections – what artifacts might be used as a Sprint Backlog Retrospective vehicle to establish the bridge ? Product Backlog Adaptation Vision Statement 10 © Birol Berkem Goo. Biz. com Paris, 2014

Goo. Biz Governing Scrum using TOGAF’s ADM Business Values carried by Capability Increments Risk Monitoring & Conformance Review Potentially Shippable Product Increment Inputs for ‘Walking Features based on Consolidated Skeletons’ based on Gaps & Dependencies Consolidated Architecture Gaps Tasks (To Do) EPIC Name : Visitor Registration Process ‘Phases : B to D’ : Daily User Story 1: Enter Visitor Create Bonus DB Table & link to Visitor Tb Scrum Create UI 1 and link it to the UC Ctrl… Implement User / System interact. Activities… 1 -4 Week User Story 2 : ‘Fill Poll’ to capture Prod. of Interest. Sprints Create Poll DB Table &link it to Visitor Tb Create UI 2 and link it to the UC Ctrl… Implement User / System Sprint interact. Activities… Sprint User Story 3 : Notify Related Units & Marketing DB Tb Retrospective - Link Poll DB Table to Sales. Backlog Sprint Planning Product Backlog Adaptation Vision Statement 11 © Birol Berkem Goo. Biz. com Paris, 2014

Goo. Biz Steps of the « Capability Based Development » TOGAF offers the Capability-Based Planning that focuses on the planning, engineering and delivery of Drivers, Goals, strategic business capabilities to the enterprise Objectives and Capabilities are initialy confirmed in the Preliminary and Architecture Vision Phases Capabilities are structured to mitigate Risks using business functions, and to make impact analysis of their evolution throughout IT layers • Incremental Road. Map to reach the Target Architecture by reusing existing capabilities • Work Packaged Actions to implement these Increments and ‘coordinate’ Implementation Projects on capability increment basis Capability Based Planning from the Open Group’s TOGAF ® 9. 1 Capability-Based SOA Backbone where solution components plugged into the architecture are orchestrated to realize related functions… Capabilities are abilities of an Organization, People, Processes and Technology … (From TOGAF 9. 1 Definition) How to enable this Goal-Driven & Capability-Based Development to Govern Scrum from Vision Statement until the Architecture ‘Walking Skeleton’ ? 11 © Birol Berkem Goo. Biz. com Paris, 2014

Goo. Biz Archi. Mate Layers for the « Architecture Gap Analysis » Archi. Mate 2 is a Modelling Language that brings : BIZ. FUNCTION consistency (well established notation with unambiguous relationship types), completeness (explicit modelling notations for requirements, principles, constraints, work packages, transition architectures), traceability (relationships to architecture components using viewpoints across multiple-domains). Example of the Archi. Mate Layered Viewpoint –will be used to serve as a support from the Vision Statement until the Architecture ‘Walking Skeleton’ 12 Simplified Archi. Mate Elements adapted from « EA Modeling with Archi. Mate & Sparx » - A. Sikandar Cap Gemini Canada

Goo. Biz Web. Sale Company – « Extending its Digital Transformation to « Turn Internet Visitors into Buyers and Incite clients to buy complementary products » A Web. Sale Company offers on-line products to its internet visitors and customers. • Faced to a crucial competition in its sector, the CEO decided to gain loyalty of their visitors and customers by turning visitors into buyers also inciting them to buy complementary products related to their particular interest and previous transactions (attractive products, …) • bbonus. . . ) To suggest such complementary products, a comparative analysis should be done between products that are consulted or purchased over the web and products that might potentially be purchased as complementary items to them (eventually using tools for Predictive Analytics) • However, information provided by the products portfolio is not always accurate to ensure a full compatibility due to ambiguous links. To mitigate risks of high volume returned products due to such an issue, the CFO with the Principal EA decide to"Refine the Product Portfolio" by maintaining there only “precisely linked complementary products” then integrate other products after receiving from their providers "trusty data for conformance”. In the Preliminary Phase, we look at the current and target states of the organisation : to enable its Architecture Practice… 13 © Birol Berkem Goo. Biz. com Paris, 2014

Goo. Biz In the Vision Phase : We start by looking at the existing Baseline Capabilities What are Target Values & Capabilities and how these current capabilities should evolve to reach them ? 14 © Birol Berkem Goo. Biz. com Paris, 2014

Goo. Biz Target Capabilities will be outlined with Business Values to be delivered • The High level Business Values must be assigned to Capabilities of the Target Architecture • Values need to be ‘decomposed’ in order to be supported by Sub-Capabilities and Functions… 15 How to configure these target capabilities to deliver targeted business values ? © Birol Berkem Goo. Biz. com Paris, 2014

Goo. Biz Use the « Capability Based Planning » of TOGAF Let’s start by considering Drivers, Goals and Objectives within the ADM Preliminary & Architecture Vision Phases 16 © Birol Berkem From the Open Group’s TOGAF ® 9. 1 Specifications Goo. Biz. com Paris, 2014

Goo. Biz In the Preliminary & Vision Phases : We know about Drivers, Goals and Baselines Capabilities upon which we have to apply changing Strategies How to make impact analysis of changing strategies assigned to each capability over the organization to ensure coherent deployment of its Target Architecture ? How to manage the performance level of target capabilities and adapt them to changes ? How to dynamically adapt the enterprise to changes by focusing on design and delivery of its targeted capabilities using TOGAF & Scrum ? 17 © Birol Berkem Goo. Biz. com Paris, 2014

Goo. Biz In Phase A: Functions and Requirements can be more precisely determined using Archi. Mate Viewpoints like the ‘Goal Realization’ Let’s populate these sub-capabilities using internal functions on the basis of risks to mitigate & © Birol Berkem and prepare ‘initial features’ of the Scrum’s Vision & ‘Product backlog’ Goo. Biz. com Paris, 2014 18

Goo. Biz I Risk Factors per Sub. D Capability Phase A: Excerpt from the Risk Identification and Mitigation Assessment Work. Sheet (summarized) IMPACT Severity Risk of Suggesting wrong products to Visitors (Initiated Major MANAGE VISITOR REGISTRATION BY MINIMIZING ABANDON 4 5 Unable to accurately identify products that correspond to particular interest of Visitors Phase A) reassessed Phase E & H Uncontrolled abandon Risk of non Major rate during Registration Attained Objectives of visitors for the Visitor Registration process (Initiated Phase A) reassessed Phase E & H L MITIGATION ACTIONS ik el ih o o d Owner Capture the target product profile of the visitor using a Poll Marketing Questionnaire via Visitor Profiling function - Fill Questionnaire Process (the Poll Questionnaire should be configured dynamically on the basis of products consulted by visitors in order to suggest them online complementary products as well as for future mailings once registered). Motivate Visitor to complete his registration by suggesting appropriate Bonus Assignment on future purchase, Marketing Review the questionnaire -dynamically configured to include potential emerging products of interest for visitors, … Make them measurable functions ! 6 Untargeted Mailing to Visitors Risk to lose potential Major customers by non targeted mailing(Initiated Develop Targeted mailing : Determine the correct family of Marketing existing and emerging products that could be interesting for the visitor on the basis of his/her product profile. 19 On the basis of these risk mitigation actions, we will have to configure related functions Phase A) reassessed © Birol Berkem Phase E & H in phase B and execute their impact analysis in phases C and D Goo. Biz. com Paris, 2014

Goo. Biz Structure capabilities & align until the Technology – carry out Business Values by function & prepare the Working Skeleton Let’s Structure Capabilities in order to: • Mitigate risks upon functions that compose them , • adapt them to changing strategies, • Also Analyze Impacts throughout Application and Technology layers 20 © Birol Berkem Goo. Biz. com Paris, 2014

Goo. Biz In Phase B : Capabilities are structured to mitigate risks and easily adapted to changes… «BUSINESS CAPABILITY ORCHESTRATOR » [Abandon rate > 50 %] SLAs should also be provided for these functions in order to align SOA backbone and guide implementation projects for conformance with these architecture constraints 21 © Birol Berkem Goo. Biz. com Paris, 2014

Goo. Biz Governing Scrum using TOGAF’s ADM • Part 2 – Governing Scrum using TOGAF’s Capability Based Planning • • Establishing the project vision on the basis of business values, Synchronizing features of the product backlog / sprints with functions of the capability increments, Providing ‘walking skeletons’ with consolidated architecture gaps, Maintaining governance with changing strategies…

Goo. Biz s on cti un s F nes Vision Statement si Bu s va lues So we have to proceed with the ‘value decomposition’ process through the Architecture Layers Business : : IS etc. . to discover Epics, User Stories, other features… Bus ines • In Phase B : Business Values carried out by Capabilities and their Business Functions will help to clarify the Vision Statement & populate Product Backlog…

Goo. Biz Phases C, D : We have to perform Impact Analysis to Realize ‘Capabilities’… The resulting architecture will be used as part of the Walking Skeleton Let’s Structure Capabilities in order to: • Mitigate risks upon functions that compose them , • adapt them to changing strategies, • Also Analyze Impacts throughout Application and Technology layers 24 © Birol Berkem Goo. Biz. com Paris, 2014

Goo. Biz In Phases B and C : The ‘Layered’ Viewpoint supports the Impact Analysis for Implementing the « Managing Visitor Registration » Sub-Capability TARGET CAPABILITY SERVICES TARGET CAPABILITY PROCESS and ROLES Development of the Architecture Views across Business and IS domains… BASELINE CAPABILITY APPLICATION SERVICES AND COMPONENTS This impact analysis must be performed until the Technical Infrastructure layer (phase D) to describe complete implementation of the new capability -cf. next slide 25

Goo. Biz In Phases C, D : The Archi. Mate ‘Layered’ Viewpoint supports the Impact Analysis for Implementing « Visitor Registration » Sub-Capability TARGET CAPABILITY PROCESS and ROLES BASELINE CAPABILITY APPLICATION SERVICES AND COMPONENTS Development of the Architecture Views across IS and Technical domains… We will consolidate this B, C, D layers gap analysis in phase E then design the roadmap and provide a ‘Walking Skeleton to enable realization of User Stories 2626 © Birol Berkem Goo. Biz 2014

Goo. Biz In Phase D : A High-level view of the SOA Backbone may be « OUTLINED » according to functions, requirements and expected service levels to deliver ‘Capabilities’ « BUSINESS CAPABILITY ORCHESTRATOR » USE CASE (UC) Business Sub-Capability Component Service Point (User Story) Sub-Capability and Functions previously described «BUSINESS CAPABILITY ORCHESTRATOR » Service Point (User Story) «BUSINESS CAPABILITY ORCHESTRATOR » « B. C. O » 27

Goo. Biz Consolidate the Roadmap, Transition Architectures and Work Packages to ‘coordinate’ Implementation Projects • In this third step, we consider the consolidated Road. Map to reach the Target Architecture. • Capability Increments for Transition Architectures will extend the existing business capabilities (starting by the Baseline Architecture) • Work Packages of Actions will implement these Increments by ‘coordinating’ Implementation Projects Let’s start by drawing the Roadmap and its underlying capability components for 28 © Birol Berkem

Goo. Biz In Phase E : For the ‘Vision Statement ‘of Scrum The Roadmap and Transition Architecture capabilities are finalized on a Risk basis & Business Values of underlying capabilities are determined ! Consolidating architecture descriptions Definition of the Roadmap Identifying opportunities for re-use and potential solution components Now how to deliver these « transition architecture capabilities » with their business values using Capability Increments – and implementation projects ? 29 © Birol Berkem Goo. Biz 2014

Goo. Biz Architecture Definition Increments Table sets “target states” for implementation projects as part of the “Releases” TRANSITION ARCHITECTURE 1 TRANSITION PREPARATION PHASE ARCHITECTURES Websale System {VISITOR REGISTRATION [MANAGED] ; CATALOG [REFINED] } PROJECTS Visitor Marketing Management Project Catalog Refinement Project Integration Project Visitor. Registration [MANAGED] TRANSITION ARCHITECTURE 2 TRANSITION ARCH ITECTURE 3 COMMENTS As part of each « Architecture Release » [TURNING VISITORS INTO BUYER] {Registrant Rate > 200 per week & Buyer Rate > 20 % « Implementation Projects » of Registered Visitors} ; {TARGETED MAILING USING PRODUCT TRACKING ; REPORTED are constrained Unsubsciption Request Rate < 5 % per month; SUCCESS MEASURES} {Purchase Rate > 20 % of Recommended Products} by « Target States » (themes) Rate of Linked new Complementary Products > 10% per month ; according to « Strategic Visitor. Registration Visitor. Mailing Objectives » INITIAL OPERATIONAL CAPABILITY “BENEFITS” Websale System [MANAGED] KPIs {Registrant Rate > 200 per week } [TARGETED] KPIs {Rate of Browsed Products > 60 % of Recommended Products} Catalog Visitor. Mailing [TARGETED] KPIs : {Unsubsciption Request Rate < 5 % each month} Catalog [REFINED] {Unprecisely linked products cleaned} > 10 % each month} - KPIs : {Rate of Linked Complementary Products Visitor [Turning into Buyer] KPIs : {Purchase Rate > 20 % of Recommended Products} In Phase F : These constraints will be used to determine sequences of the Implementation Projects using the Archi. Mate Project Viewpoint … Visitor [Turning into Buyer ] KPIs : { Purchase Rate > 60 % of Recommended Products} © Birol Berkem Goo. Biz. com Paris, 2014

Goo. Biz In Phase F : Coordinate Implementation Projects using Work Packages • In this third step, we consider the consolidated Road. Map to reach the Target Architecture. • Capability Increments for Transition Architectures will extend the existing business capabilities (starting by the Baseline Architecture) • Work Packages of Actions will implement these Increments by ‘coordinating’ Implementation Projects How the Consolidated Gaps & Dependencies Matrix may help for the Product Backlog ? 31 © Birol Berkem

Goo. Biz In Phase E : Deliverables and Work Package Actions are determined for the Transition Architecture Consolidating architecture descriptions Definition of the Roadmap Identifying opportunities for re-use and potential solution components And they are finally determined for the target architecture… (next slide) 32 © Birol Berkem Goo. Biz 2014

Goo. Biz Phase F : ‘Coordinate’ the Implementation Projects B. C. MODEL FRAGMENT «BUSINESS CAPABILITY ORCHESTRATOR » Implementation Projects will be coordinated in Phase G on the basis of business, IS and technology constraints imposed to the Architecture from phases B to E 33 © Birol Berkem Goo. Biz 2014

Goo. Biz Consolidate the Roadmap, Transition Architectures and Work Packages to ‘coordinate’ Implementation Projects • In this third step, we consider the consolidated Road. Map to reach the Target Architecture. • Capability Increments for Transition Architectures will extend the existing business capabilities (starting by the Baseline Architecture) • Work Packages of Actions will implement these Increments by ‘coordinating’ Implementation Projects How the Consolidated Gaps & Dependencies Matrix may help for the Product Backlog ? 34 © Birol Berkem

Goo. Biz Governing Scrum using TOGAF’s ADM Capability Radar Diagram Business Values carried by Capability Increments Risk Monitoring & Conformance Review Potentially Shippable Product Increment Inputs for ‘Walking Features based on Consolidated Skeletons’ based on Gaps & Dependencies Consolidated Architecture Gaps Tasks (To Do) EPIC Name : Visitor Registration Process ‘Phases : B to D’ : Daily User Story 1: Enter Visitor Create Bonus DB Table & link to Visitor Tb Scrum Create UI 1 and link it to the UC Ctrl… Implement User / System interact. Activities… 1 -4 Week User Story 2 : ‘Fill Poll’ to capture Prod. of Interest. Sprints Create Poll DB Table &link it to Visitor Tb Create UI 2 and link it to the UC Ctrl… Implement User / System Sprint interact. Activities… Sprint User Story 3 : Notify Related Units & Marketing DB Tb Retrospective - Link Poll DB Table to Sales. Backlog Sprint Planning Product Backlog Adaptation Vision Statement 11 © Birol Berkem Goo. Biz. com Paris, 2014

Goo. Biz Example of a Consolidated Gaps, Solutions and Dependencies Matrix Excerpt from TOGAF 9. 1 Consolidated Gaps, Solutions and Dependencies Matrix of the Open Group This Dependency Matrix can provide more precisely the basis for understanding what parts of processes should be automated and how – so it may help to discover : 1 - Application Level « Epics » and « user stories » of the Product Backlog 2 - Tasks of the appropriate ‘Walking Skeleton’ to realize ‘activities’ of these user stories

Goo. Biz EPICS Structure the « Product Backlog » on the basis of Business Functions to ‘automate’ from Phases B&C Parts of automated processes TRIGGERED BY users provide USER STORIES (steps of Epic) For each business function an end-to-end traceability helps to understand its AUTOMATED activities at the IS layer FOR EACH USER STORY WHAT ACTIVITIES ? How to determine the ‘Working Skeleton’ and tasks to realize each user story ?

Goo. Biz Governing Scrum using TOGAF’s ADM Capability Radar Diagram Business Values carried by Capability Increments Risk Monitoring & Conformance Review Potentially Shippable Product Increment Tasks (To Do) EPIC Name : Visitor Registration Process ‘Phases : B to D’ : User Story 1: Enter Visitor Create Bonus DB Table & link to Visitor Tb Create UI 1 and link it to the UC Ctrl… Implement User / System interact. Activities… User Story 2 : ‘Fill Poll’ to capture Prod. of Interest Create Poll DB Table &link it to Visitor Tb Create UI 2 and link it to the UC Ctrl… Implement User / System interact. Activities… User Story 3 : Notify Related Units Link Poll DB Table to Sales & Marketing DB Tb Send Visitor Info. to Sales and Marketing Mail boxes… Inputs for ‘Walking Skeletons’ based on Consolidated Architecture Gaps Daily Scrum 1 -4 Week Sprints Sprint Planning Features based on Consolidated Gaps & Dependencies Product Sprint Backlog How can we establish such connections on a « Capability basis » ? Backlog Retrospective Adaptation Vision Statement 10 © Birol Berkem Goo. Biz. com Paris, 2014

Goo. Biz In Phase E: Consolidated Gaps from Phases B, C and D help to discover « tasks » to enable the « Walking Skeleton » of User Stories Business GAP : Visitor Registration Process Activity 1 : Enter Visitor Activity 2 : Profile Visitor Interest Activity 3 : Notify Related Units « I » Customer « I » Bonus [Registration] [Assignment] « I » Customer « I » Poll [Data Mgmt] [Processing] « I » Customer « I » Poll [ Poll Data to Review] [Notification] Appli GAP : Visitor Registration Process Activity 1 : Enter Visitor - Create Bonus Assignment Appli Service Interface & Implementation Activity 2 : Profile Visitor Interest-Cr. Poll Process Appli Service Intf& Imp. Activity 3 : Notify Related Units -Cr. Poll to Review Appli Service Intf&Imp Information (Data) GAP : Visitor Registration Application & Techno Activity 1 : Enter Visitor - Create Bonus DB Table & link it to Visitor DB Tb Activity 2 : Profile Visitor Interest- Poll DB Table linked to Visitor Tb Activity 3 : Notify Related Units -Poll DB Table linked to Sales & Marketing DB Tb -Visitor Info. sent to Sales and Marketing « I » Visitor Bonus [DB Assignmt] « I » Visitor Poll [DB Assignmt] « I » Poll [DB Notification] Precise Consolidation of BCD Layer Gaps for elaborating the Consolidated Gap, Solution & Dependency Matrix Dependencies discovered for each layer will identify deliverables & work packages 3939 © Birol Berkem Goo. Biz 2014

Goo. Biz Phase G Objectives • Phase G defines architecture constraints on the implementation projects and ensures their conformance through the Architecture Contract – It includes governing the architecture through implementation by compliance reviews and by risk monitoring – Perform appropriate functions of the Architecture Governance for the solution – The development happens in parallel with Phase G

Goo. Biz Monitor Risks and Conformance of Implementation Projects Structuring the Capability Based SOA Backbone In this last step (Phase G), we focus on how to realize Constraints imposed to « Business Functions » by « Implementation Projects » Upon the Capability-Based SOA Backbone 41 © Birol Berkem Goo. Biz 2014

Goo. Biz Reminder from Phase B : Capabilities were structured to mitigate risks and being easily adapted to changes… «BUSINESS CAPABILITY ORCHESTRATOR » Also seen that in Phase D : SOA Backbone has to be designed according to these functions, requirements and expected service levels 42 © Birol Berkem Goo. Biz. com Paris, 2014

Goo. Biz In Phase D : A High-level view of the SOA Backbone has been « outlined » according to functions, requirements and expected service levels to deliver ‘Capabilities’ « BUSINESS CAPABILITY ORCHESTRATOR » USE CASE (UC) Business Capability Component Service Point (User Story) Sub-Capability and Functions previously described «BUSINESS CAPABILITY ORCHESTRATOR » Service Point (User Story) «BUSINESS CAPABILITY ORCHESTRATOR » « B. C. O » 43

Goo. Biz Architecture Definition Increments Table sets “target states” requested from implementation projects on the basis of Strategic Objectives TRANSITION ARCHITECTURE 1 TRANSITION ARCHITECTURE 2 TRANSITION ARCH ITECTURE 3 INITIAL OPERATIONAL CAPABILITY “BENEFITS” Websale System {VISITOR REGISTRATION [MANAGED] ; CATALOG [REFINED] } [TURNING VISITORS INTO BUYER] TRANSITION PREPARATION PHASE ARCHITECTURES PROJECTS Visitor Marketing Management Project COMMENTS {Rate of Linked new Complementary Products > 10% per month ; Registrant Rate > 200 per week & Buyer Rate > 20 {TARGETED MAILING USING % of Registered Visitors} ; Unsubsciption Request Rate < 5 PRODUCT TRACKING ; REPORTED % per month; {Purchase Rate > 20 % of Recommended SUCCESS MEASURES} Products} Constraints imposed to « Business Functions » are to be realized Visitor. Mailing by « Implementation Projects » [TARGETED] Visitor. Registration [MANAGED] KPIs {Questionnaire to recustomize if Abandon Rate > 50 %} KPIs : {Registrant Rate > 200 per week & Registrant Buyer Rate > 20 % of Registered Visitors} KPIs {Rate of Browsed Products > 60 % of Recommended Products} Visitor [Entry] : If abandon & abandon rate > 50% then send to Mktg. Suggested Products [to adapt] Questionnaire [Filling] : If abandon & abandon rate > 50% then Questionnaire [to review] Catalog Refinement Project Catalog [REFINED] {Unprecisely linked products cleaned} Visitor. Mailing [TARGETED] KPIs : {Unsubsciption Request Rate < 5 % each month} Catalog [REFINED] KPIs : {Rate of Linked Complementary Products > 10 % each month} Visitor [Turning into Buyer] Integration KPIs : {Purchase Rate > 20 % of Project Recommended Products} In Phase F : Coordinated Implementation Projects on the basis of Target States using Archi. Mate Project Viewpoint Visitor [Turning into Buyer ] KPIs : { Purchase Rate > 60 % © Birol Berkem of Recommended Products} Goo. Biz. com Paris, 2014

Goo. Biz Support Constraints of the Architecture Backbone by the Implementation Projects BUSINESS LAYER I_Entry FUNCTIONAL LAYER UI <<SRV-P>> « GOAL-DRIVEN « B. C. O » SERVICE » Visitor [Entry] Visitor [Registration] <<UC-Comp>> Visitor [Entry] <<REALIZE>> <<SRV-P>> Visitor [Notification] VISITOR [REGISTRATION] BUSINESS & DATA LAYER <<REALIZE>> <<ENTITY>> Visitor <<ENTITY>> Form <<ENTITY>> Question naire DATA SERVICES FUNCTIONAL LAYER Example : Specification of the Implementation of Architecture Constraints Example for supporting the Architecture Backbone ‘s expected constraints by the implementation 45 © Birol Berkem Goo. Biz 2014

In Phase G : Solution Components (SBBs) are plugged into the ABBs of the Architecture backbone to implement business functions Goo. Biz « BUSINESS CAPABILITY ORCHESTRATOR » Service/Request Point (UC Comp) Service/Request Point (SRV Comp) Business Capability Component «BUSINESS CAPABILITY ORCHESTRATOR » <<Trace>> SRV-Cmp UC-Cmp «Gd. S_Comp» Visitor_Registration: : Visitor_Entry «UC_Comp» Visitor_Registration: : Visitor_Entry complete_fields: boolean form_incomplete: boolean visitor_entered: boolean + enter_visitor() : void complete_fields() : void fill_form() : void {pre : form_found} thanks_for_entry() : void 46 - - entry_processed: boolean entry_requested: boolean form_registered: boolean form_validated: boolean + enter_visitor() : void - process_entry() : void {pre: entry_requested} - register_form() : void - validate_form() : void « B. C. O » 46

Goo. Biz Governing Scrum using TOGAF’s ADM Compliance Review Architecture Related Compliance Issues • Architecture functions Insufficiently aligned with objectives • Granularity mismatch between Baseline/T arget functions for Gap Analysis • Compliance issues for implementation projects : some appli. system functions that do not respect Archi. Constraints … • Not respected BADT standards - (Ex events processing do not use Publish/Subscribe or Listener patterns ) • … Capability Radar Diagram Business Values carried by Capability Increments Risk Monitoring Implementation Related Compliance Issues & Conformance (Sprint Retrospective ) Review • • • Inputs for ‘Walking Features based on Consolidated Skeletons’ based on Gaps & Dependencies Consolidated Architecture Gaps Tests Insufficiently defined for design & development Missing Tasks in the Scrum Task board Incorrect task estimates… … Potentially Shippable Product Increment Daily Scrum 1 -4 Week Sprints Sprint Retrospective Sprint Backlog Sprint Planning Product Backlog Adaptation Vision Statement 10 © Birol Berkem Goo. Biz. com Paris, 2014

Goo. Biz TOGAF’s ADM Phases and Archi. Mate to Connect with Scrum In Phases G & H : Capability Driven SOA Backbone Components are Implemented to realize expected functions and Changes are Managed In Phases Prelim. & A : Capabilities are assessed on the basis of Goals, Principles, Requirements, … In Phase B : Capabilities are first structured depending on the risks and requirement basis In Phases E & F : Implementation Projects are planned to realize Capabilities In Phase B, C, D : Impact Analysis of new Capabilities is performed across Architecture Layers In Phase E : The Roadmap and capabilities are consolidated to drive Epics & User Stories © Birol Berkem Goo. Biz 2014 48