TOGAF 9 and Archi Mate 2 0 for

  • Slides: 36
Download presentation
TOGAF 9 and Archi. Mate 2. 0 for aligning SOA with Changing Strategies and

TOGAF 9 and Archi. Mate 2. 0 for aligning SOA with Changing Strategies and Capabilities using Sparx EA A presentation on a short Case Study using Sparx EA Enterprise Architect User Group – Nurnberg Oct 8, 2013 Birol Berkem (Ph. D) – TOGAF 9 Certified Enterprise Architect Goo. Biz. com This presentation aims at showing how to use the Archi. Mate ® 2. 0 notations throughout TOGAF® 9’ ADM phases in order to align SOA implementation components with changing business strategies and capabilities using Sparx EA Note : TOGAF (The Open Group Architecture Framework) and Archi. Mate are trademarks of the Open Group This work by Birol Berkem (Goo. Biz. com) is licensed under a Creative Commons Attribution-Noncommercial-Share Alike 3. 0 Unported License. Permissions beyond the scope of this license may be available by e-mail to info@goobiz. com

Structure of this Presentation • Business Agility – Definitions • Enterprise Architecture : Goals

Structure of this Presentation • Business Agility – Definitions • Enterprise Architecture : Goals and Roles • Balanced Score. Cards / Strategy Map techniques to specify Governance Aspects of the EA Operating Model • Business & IT Alignment using TOGAF 9. 1 and ADM 2. 0 – – – Phases in TOGAF’s ADM – A Summary TOGAF for SOA - Initial Content Meta-Model Why use Archi. Mate 2. 0 ? Basic Concepts, Layers and Viewpoints in Archi. Mate 2. 0 Modeling with Archi. Mate 2. 0 throughout TOGAF 9. 1’ ADM phases Structuring Capabilities to align SOA components Impacts of Capabilities upon the Application and Infrstructure layers Updating the Architecture Repository Modeling the Roadmap, Transition Architectures and Work Packages Modeling Implementation Projects Planning The SOA Architectural Backbone at the Implementation Governance Phase • Conclusion

Business Agility : Definitions • Business agility is the ability of a business to

Business Agility : Definitions • Business agility is the ability of a business to adapt rapidly and cost efficiently in response to changes in the business environment. • Business agility can be maintained by adapting goods and services to meet customer demands, adjusting to the changes in a business environment and taking advantage of human resources. • "On the Measurement of Enterprise Agility". Journal of Intelligent and Robotic Systems 33 (3): 329– 342. DOI: 10. 1023/A: 1015096909316 Nikos C. Tsourveloudi , Kimon P. Valavanis (2002)

Business Agility : Needs ! • The alignment of organisations with the changing needs

Business Agility : Needs ! • The alignment of organisations with the changing needs of their customer requires: – Communicating key requirements, principles and models of the futur state of the enterprise (vision, strategies, …) in order to ensure a coherent evolution, – Propagation of the changes to ensure a coherent reactivity • Such an alignment necessitates an architecture framework that includes : – process, users, information and technology, but also their internal and external relationships with their environment 4

What methodologies, architectures and specification languages to ensure a business agility ? How to

What methodologies, architectures and specification languages to ensure a business agility ? How to use them to capitalize on the business knowledge and align IT with the changing strategies ?

Enterprise Architectures : Goals and Roles ! • Enterprise Architecture is usualy done to

Enterprise Architectures : Goals and Roles ! • Enterprise Architecture is usualy done to identify gaps between current and target architecture state of an organisation. • Enterprise Architecture enables effective execution of the enterprise strategy to achieve change of an organization ! • It provides roadmap to achieve goals and deliver objectives to guide current and futur projects of the organisation. What sources to provide inputs data for the Governance Aspects of an EA ? 6

Use ‘Balanced Score. Cards’ / ‘Strategy Map’ techniques to specify Governance Aspects of the

Use ‘Balanced Score. Cards’ / ‘Strategy Map’ techniques to specify Governance Aspects of the EA Operating Model “What we do have to improve…" Shareholder requests Branding displayed to customers Tactical and process level KPIs to specify here… “What we have to do to enhance “value creation” How to implement such governance perspectives using Archi. Mate along the phases of TOGAF 9 ? © Birol Berkem Goo. Biz 2011/2012 7

Business & IT Alignment using TOGAF 9 and ADM 2. 0 TOGAF 9 ®

Business & IT Alignment using TOGAF 9 and ADM 2. 0 TOGAF 9 ® : An Enterprise Architecture Framework proposed by the Open Group to align Enterprise Ressources, IT Systems and Technologies with the changing Business Strategies and Business Capabilities. Archi. Mate 2. 0 ® : Brings you a specification language and viewpoints that allows formalization of the artifacts used within this Alignment Process. The TOGAF ® 9 ADM (Architecture Development Method) for developing an Enterprise Architecture 8

Phases in TOGAF’s ADM – A Summary Governance of implementation and Architecture Change Management

Phases in TOGAF’s ADM – A Summary Governance of implementation and Architecture Change Management Architecture Planning : Business Drivers and Goals Concerns of the Stakeholders Principles, Requirements, Capability Assesment, Readiness Factors, … Development of the Enterprise Architecture, Views of the Architecture across domains, Risk Mitigation , … Detailed Implementation and Migration Plan Work Packages and Transition Architectures Consolidating architecture descriptions Definition of the Roadmap Identifying opportunities for re-use and potential solution components 9

TOGAF ® 9 / SOA Initial Content Meta. Model Elements Q : So, how

TOGAF ® 9 / SOA Initial Content Meta. Model Elements Q : So, how to link such concepts to increase business agility ? A : Need a language that ensures coherence, traceability, completeness ! From the Open Group’s TOGAF ® 9. 1 Specifications 10

Archi. Mate 2. 0 adds value to TOGAF 9. 1 Artifacts bringing consistency, traceability,

Archi. Mate 2. 0 adds value to TOGAF 9. 1 Artifacts bringing consistency, traceability, completeness ! 11 From the Open Group’s TOGAF ® 9. 1 Specifications

What is Archi. Mate 2. 0 ? Why use Archi. Mate 2. 0 ?

What is Archi. Mate 2. 0 ? Why use Archi. Mate 2. 0 ? – Archi. Mate is a modeling language for describing enterprise architectures – Broader scope than UML (essentially designed for software engineering) – Supports EA frameworks like TOGAF 9 & Zachman – Archi. Mate 2. 0 adds valueto TOGAF 9. 1 by bringing consistency, traceability, completeness ! – Archi. Mate viewpoints are more detailed than TOGAF’s architecture artifacts – TOGAF does not provide a specification language for descriptions and examples

Archi. Mate 2. 0 Layers to support TOGAF 9’s « Capability-Based Planning of the

Archi. Mate 2. 0 Layers to support TOGAF 9’s « Capability-Based Planning of the Enterprise Architecture » 13 From the Open Group’s TOGAF ® 9. 1 and Archi. Mate ® 2. 0 Specifications

Basic Archi. Mate Concepts (Very Simplified !) BIZ. FUNCTION 14 Simplified Archi. Mate Elements

Basic Archi. Mate Concepts (Very Simplified !) BIZ. FUNCTION 14 Simplified Archi. Mate Elements adapted from « EA Modeling with Archi. Mate & Sparx » - A. Sikandar Cap Gemini Canada

Archi. Mate 2. 0 – Some Important Viewpoints useful for the Concern of IT

Archi. Mate 2. 0 – Some Important Viewpoints useful for the Concern of IT / Business Alignment Introductory Viewpoint Application Usage Viewpoint Organization Viewpoint Infrastructure Viewpoint Actor Co-Operation Viewpoint Infrastructure Usage Viewpoint Stakeholder Viewpoint Implementation and Deployment Viewpoint Goal Realization Viewpoint Information Structure Viewpoint Goal-Contribution Viewpoint Project Viewpoint Principle Viewpoint Service Realization Viewpoint Requirement Realization Viewpoint Layered Viewpoint Motivation Viewpoint Landscape Map Viewpoint Business Function Viewpoint Migration Viewpoint Business Process Viewpoint Implementation and Migration Business Process Co-operation Viewpoint Product Viewpoint Application Behavior Viewpoint A viewpoint in Archi. Mate is a selection of a relevant subset of the Archi. Mate concepts and the representation of that part Application Co-operation Viewpoint of an architecture Application Structure Viewpoint Application Usage Viewpoint On the basis of the previous Balanced Score Card example input data, let us use some of these viewpoints within Sparx EA

Reminder : Contents of the ‘Balanced Score Cards to guide the Governance Aspects of

Reminder : Contents of the ‘Balanced Score Cards to guide the Governance Aspects of the Web. Sale EA Operating Model “What we do have to improve…" Shareholder requests Branding displayed to customers Tactical and process level KPIs to specify here… “What we have to do to enhance “value creation” How to handle such governance perspectives using TOGAF and Archi. Mate ? © Birol Berkem Goo. Biz 2011/2012 1 6

In the Preliminary Phase of TOGAF 9 : We start by modeling Baseline Architecture

In the Preliminary Phase of TOGAF 9 : We start by modeling Baseline Architecture Capabilities of the Web. Sale Company

In the Preliminary Phase : Drivers, Assessments and Initial Goals of the EA may

In the Preliminary Phase : Drivers, Assessments and Initial Goals of the EA may be modeled using the ‘Stakeholder Viewpoint’ Business Drivers and Goals Principles, initial Requirements … 18

In the Architecture Vision (Phase A) : Requirements can be discovered by decomposing Goals

In the Architecture Vision (Phase A) : Requirements can be discovered by decomposing Goals using the ‘Goal Realization’ and ‘Motivation ‘Viewpoints (1/2) 19

In the Architecture Vision (Phase A) : Business Functions are discovered by applying the

In the Architecture Vision (Phase A) : Business Functions are discovered by applying the ‘Goal Realization’ and ‘Motivation ‘Viewpoints (2/2) 20 How to better structure Capabilities to adapt them to changing requirements and align SOA components ? 20

In the Business Architecture Phase (Phase B) : Business Capabilities can be structured to

In the Business Architecture Phase (Phase B) : Business Capabilities can be structured to be easily adapted to changes and align SOA «BUSINESS CAPABILITY ORCHESTRATOR » 21 How to describe process activities and guide SOA service level specifications on the basis of such a Capability Configuration ?

On the basis of the previous capability structure, requirements are assigned to ‘Service Points’

On the basis of the previous capability structure, requirements are assigned to ‘Service Points’ that are controled by the Capability Orchestrator « CAPABILITY ORCHESTRATOR » Service points allow capabilities to interact with their environment (cf. Phase G - Implementation Governance slide) 22

The Orchestration of Service Points activities may be precisely described using UML or BPMN

The Orchestration of Service Points activities may be precisely described using UML or BPMN Process Descriptions Changes may be expressed using {constraints} applied to Business Capabilities «BUSINESS CAPABILITY ORCHESTRATOR » Process Actions are to be reconfigured by considering new contraints to apply Actions of the orchestrator service « makes call » to its service point behaviors to realize the « Register Visitor » Capability 23

The Sparx EA Architecture Repository is continously enriched since definition of the Goals, Strategies,

The Sparx EA Architecture Repository is continously enriched since definition of the Goals, Strategies, etc… (from OMG’s BMM) … through Process Descriptions BUSINESS GOAL STRATEGY Tactic level KPIs TACTIC BUSINESS PROCESS SYSTEM REQUIREMENTS (based on process level KPIs) 24 © Birol Berkem Goo. Biz 2013

Reminder : New Requirements were assigned to capitalize on the Business Capabilities « Managing

Reminder : New Requirements were assigned to capitalize on the Business Capabilities « Managing Visitor Registration… » and « Targeted Mailing… » Baseline Biz. Capabilities Target Biz. Capabilities As Capabilities require a combination of organization, people, processes and technology, we need to look for impacts of these target capabilities upon the Application and Infrastructure layers…

In Phases B and C : The ‘Layered’ Viewpoint supports the Impact Analysis for

In Phases B and C : The ‘Layered’ Viewpoint supports the Impact Analysis for Implementing the « Managing Visitor Registration » Capability Development of the Architecture Views across domains… 26

In Phases C, D : The ‘Layered’ Viewpoint supports the Technical Impact Analysis for

In Phases C, D : The ‘Layered’ Viewpoint supports the Technical Impact Analysis for Implementing the « Managing Visitor Registration… » Capability Development of the Architecture Views across domains… 27

In Phase E : The Roadmap and underlying capabilities for Transition and Target Architectures

In Phase E : The Roadmap and underlying capabilities for Transition and Target Architectures are consolidated from phases B, C, D Consolidating architecture descriptions Definition of the Roadmap Identifying opportunities for re-use and potential solution components 28

Deliverables and Work Package Actions are determined for the Transition Architecture (1/2) Consolidating architecture

Deliverables and Work Package Actions are determined for the Transition Architecture (1/2) Consolidating architecture descriptions Definition of the Roadmap Identifying opportunities for re-use and potential solution components 29

Deliverables and Work Package Actions are finally determined for the Target Architecture (2/2) Traceability

Deliverables and Work Package Actions are finally determined for the Target Architecture (2/2) Traceability links that are automatically displayed for the selected deliverable are useful for Consolidating architecture descriptions How to use these deliverables to discover Organizational and IT Projects ? 30

Phase F : Planning Implementation Projects 31 How to guide and align Projects by

Phase F : Planning Implementation Projects 31 How to guide and align Projects by Architectural Constraints on the basis of Business Capabilities ?

Phase G – IMPLEMENTATION GOVERNANCE q In Phases B and C : We have

Phase G – IMPLEMENTATION GOVERNANCE q In Phases B and C : We have seen how to structure Business Capabilities to establish the bridge toward SOA and assigned functional service expectations to related service points q In Phase G : We transform them into SOA Architectural Backbone elements (components, ports with required and provided interfaces) Let’s apply this step on our case study… 32 32

In Phase G : The Architectural Backbone of the system may be detailed on

In Phase G : The Architectural Backbone of the system may be detailed on the basis of previous specifications of the ‘Capabilities’ « BUSINESS CAPABILITY ORCHESTRATOR » USE CASE (UC) Service/Request Point (UC Comp) Service/Request Point (SRV Comp) BUSINESS CAPABILITY «BUSINESS CAPABILITY ORCHESTRATOR » « B. C. O »

UC and Service Behaviours may be specified using a choreography BUSINESS LAYER I_Entry <<SRV-P>>

UC and Service Behaviours may be specified using a choreography BUSINESS LAYER I_Entry <<SRV-P>> « GOAL-DRIVEN Visitor [Entry] <<UC-Comp>> Enter Visitor <<REALIZE>> Visitor <<SRV-P>> Visitor [Notification] [Registration] FUNCTIONAL LAYER UI « B. C. O » SERVICE » VISITOR [REGISTRATION] BUSINESS & DATA LAYER <<REALIZE>> <<ENTITY>> Visitor <<ENTITY>> Question naire DATA SERVICES Form UNCTIONAL LAYER « Service » and « UC-Comp » interactions may be implemented by a couple of (web service and its client) port components 34 We transform Actions of Service and Use Case partitions into methods of the corresponding components (cf. next)

In Phase G : Behaviors of the Components are plugged into the Architecture backbone

In Phase G : Behaviors of the Components are plugged into the Architecture backbone to implement capabilities « BUSINESS CAPABILITY ORCHESTRATOR » Service/Request Point (UC Comp) Service/Request Point (SRV Comp) BUSINESS CAPABILITY «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} 35 thanks_for_entry() : void - - 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 »

Conclusion • The alignment of organisations with the changing needs of their customer requires:

Conclusion • The alignment of organisations with the changing needs of their customer requires: – Communicating key requirements, principles and models of the futur state of the enterprise (vision, strategies, principles, …) in order to ensure a coherent evolution, – Propagation of the changes to ensure a coherent reactivity until SOA Components • Sparx EA ensures this alignment supporting the Business Motivation Model (BMM), Balanced Score Cards, Strategy Map, TOGAF 9, Archi. Mate 2. 0 and Soa. ML • It also permits organizations to capitalize on their business knowledge by the means of Business Capabilities • Complementary information to this presentation about the Agile Enterprise Modeling, IT and System Specifications can be found on our website : www. goobiz. com 36