The Latest Open SOA Standards Heather Kreger SOA

The Latest Open SOA Standards Heather Kreger SOA, Policy, and Smarter Planet Standards Lead Architect, IBM Open Group SOA Work Group co-chair Ed Harrington Principal Consultant Architecting the Enterprise (C) The Open Group 2011

Copyright (c) 2009 -2011 The Open Group. All rights reserved. This material ("Material") may not be used, copied, distributed, modified, or shown, except under license from The Open Group member organizations are hereby granted a non-exclusive license to use, copy, distribute and show the unmodified material for any purpose, for so long as they are current, paid-up members of The Open Group. Others may use, copy, distribute and show the unmodified material free of charge for non-commercial use. That will usually mean using it inside the organization, and not for commercial exploitation. To use the material for commercial purposes, an organization must apply to The Open Group for a Commercial License. Any modification to the original Material, or any document that contains any portion of the Material shall constitute a derivative work. Anyone may create such derivative works and shall retain all right, title and interest in the changes or additions it makes to the Material, but nothing herein shall be deemed to transfer any right, title or interest in the Material. Furthermore, any derivative work shall always fully acknowledge the right, title and interest of The Open Group in the original Material (together with any contributor acknowledgements), and shall not claim or imply that any derivative work is the official Material. For the avoidance of doubt, creating a derivative work for commercial use shall constitute commercial use of the Material. 2 2 (C) The Open Group 2011

Agenda Introducing DDB Corporation Reusing the SOA tutorials scenario from Chris Greenslade, Clars, Heather Kreger, IBM, Ed Harrington, Architecting the Enterprise, Chris Harding, The Open Group, Don Kavanagh, Capita ITS UK Using the TOGAF-SOA “Practical Guide” Using the SOA Reference Architecture Governing SOA Solutions Creating a Service model using the SOA Ontology Applying SOA to Infrastructure - SOCCI Using a repository - S-RAMP 3 (C) The Open Group 2011

The Open Group SOA Work Group • Develops and fosters common understanding of SOA in order to facilitate alignment between the business and information technology communities. • Formed in October 2005 • By conducting producing definitions, analyses, recommendations, reference models, and standards • Open to all Open Group Supplier and Customer Council members (Platinum members, Forum Buyout members, and Silver members) • 400+ participants from 60+ member companies www. opengroup. org/projects/soa/ SLIDE 4 of 70

SOA Activities in The Open Group • Completed Projects – Definition of SOA – SOA Case Studies – Value That The Open Group Can Add to SOA – SOA Governance – Ontologies for SOA – SOA/TOGAF “Practical Guide” – Service-Oriented Cloud Computing Infrastructure – SOA Reference Architecture • Current Work Program – Security for the Cloud and SOA – Legacy Evolution to SOA • Other Open Group SOA Activities – SOA Maturity Model (Board project) – SOA Source Book SLIDE 5 of 70 – SOA Tutorials

SOA as an Architectural Style • IT is experiencing a shift – Away from efficiency and automation [of processes] – Towards business agility and management of complexity • SOA provides an architectural style intended to help – Simplify the business – Simplify the interoperation of different parts of that business – Quickly identify functional capabilities of an organization – Avoid duplicating similar capabilities across different areas of the organization – Limit the impacts of change – Understand in advance the likely chain of impacts SLIDE 6 of 70

Definition of SOA • Service-Oriented Architecture (SOA) is an architectural style that supports service orientation. – Service orientation is a way of thinking in terms of services and service-based development and the outcomes of services. – A service: Is a logical representation of a repeatable business activity that has a specified outcome (e. g. , check customer credit; provide weather data, consolidate drilling reports) • Is self-contained • May be composed of other services • Is a “black box” to consumers of the service • An architectural style is the combination of distinctive features in which architecture is performed or expressed. SLIDE 7 of 70

SOA Features • SOA is based on the design of the services – which mirror real-world business activities – comprising the enterprise (or inter-enterprise) business processes. • Service representation utilizes business descriptions to provide context (i. e. , business process, goal, rule, policy, service interface, and service component) and implements services using service orchestration. • SOA places unique requirements on the infrastructure – it is recommended that implementations use open standards to realize interoperability and location transparency. • Implementations are environment-specific – they are constrained or enabled by context and must be described within that context. • SOA requires strong governance of service representation and implementation. • SOA requires a “Litmus Test", which determines a “good service”. SLIDE 8 of 70

What does SOA Offer? Smaller Business-IT Gap Common semantics using “business process and business services” Smaller project cycles – more synch. opportunities Agility/Flexibility “React-Adapt-Adopt” cycle Business agility and IT flexibility Higher Productivity Through Re-use Becomes Mostly “assemble” Clearer software/app building process Re-use of services To get these benefits we have to have the right SOA services and solutions at the right time Better Operational Control Better management and visibility, better SLAs 9 (C) The Open Group 2011

How Enterprise Architecture Supports SOA EA discipline provides the following tools and techniques to assist organizations with SOAs ► Traceability that links IT assets to the business they support ■ These support impact assessment and portfolio management ► Principles, constraints, frameworks, patterns, and standards ■ The basis of design governance, ensuring interoperability, and re-use ► Linking of different perspectives to a single business problem (e. g. , business, data, application, technology, abstracted, concrete, etc. ) ■ providing a consistent model to address various domains and test for completeness ► Consistent abstractions of high-level strategies and project deliverables, ■ enabling both bottom-up and top-down outputs to be collated in a shared repository to support planning and analysis SLIDE 10 of 70

How Enterprise Architecture Supports SOA (2) EA becomes a foundation for service-orienting an organization, because it ► Links SOA stakeholders together, ■ Ensuring that the needs of each stakeholder community are met and that each stakeholder community is aware of appropriate context ► Links business to IT ■ Used to justify the cost of IT reengineering against business value ► Shows which services should be built and which should be re-used ► Shows how services should be designed and how platforms must interoperate ► Provides a repository to hold and maintain design-related information on an ongoing basis SLIDE 11 of 70

Pragmatically, why use EA for SOA? • Without you will have – Limited agility – Difficulty identifying and orchestrating SOA Service – Service sprawl – Exponentially growing governance challenges – Limited SOA Service interoperability – Limited SOA Service re-use – Multiple silo’ed SOAs – Difficulty evolving and changing your implementations SLIDE 12 of 70

SOA-TOGAF “Practical Guide”* • • TOGAF • The Open Group Architecture Framework (TOGAF): Worldwide Standard for the development and lifecycle management of Enterprise and other architectures • Currently Version 9 • Over 15, 000 Certified TOGAF Practitioners “Practical Guide • “Guide” describes how the various SOA Standards can be linked in support of a holistic SOA Solution using the TOGAF ADM * Officially: “Using TOGAF to Define and Govern Service Oriented Architectures” https: //www 2. opengroup. org/ogsys/jsp/publications/Public ation. Details. jsp? publicationid=12390 3 February 2011 (C) The Open Group 2006

SOA Meta-model – TOGAF Extended for SOA/TOGAF Practical Guide Team 14

Updated meta-model entities Extension Term (meta-model object) Information Entity Description Information Component An ideal grouping of Information Entities fulfilling one or more principles. These will be the base for the structure of the SOA Information Exchange Model (Canonical Information Model). An agreement between an IS service consumer and an IS service provider that establishes functional and non-functional parameters for interaction. The requirements and architecture (structure) of entire solution including process, information, service and infrastructure requirements. The Service Quality meta-model object is used as an attribute to services, components, and contracts The Service Qualities defines the non-functional requirements. The Location meta-model object is used as an attribute to a service or component. IS Service Contract SOA Solution Service Quality Location Information communicated about within the business SOA/TOGAF Practical Guide Team 15

SOA and the Preliminary Phase ØUnderstanding SOA – Input: SOA Ontology ØModify/Adjust Governance for SOA: Input – SOA Governance ØAdapt TOGAF to SOA specifics: Input – SOA Reference Architecture SLIDE 16 of 70

Preliminary Phase Enhancements • • • Objectives Ensure SOA supporting Principles in place • Ensure SOA Governance in place Inputs Existing SOA Reference Architectures Existing industry SOA Maturity models Existing SOA Governance Frameworks Existing Industry best practice SOA principles • • Steps Identify stakeholder concerns • SOA specific concerns Define scope • Ensure scope is appropriate for SOA • Tailor deliverables to level of architecture Evaluate Business Capabilities • SOA readiness Confirm Principles • SOA supporting Principles SOA/TOGAF Practical Guide Team • • • Outputs Statement of Architecture Work • with SOA as an approach Architecture principles • including SOA principles) Capability assessment • including SOA readiness Architecture Vision • with SOA thinking) Additional content populating the Architecture Repository • including SOA Reference Architecture) 17

Summary of The DDB Group Dursley Drill Bits History Formed in 1882 Success due to: • Quality of products • Patented Processes Global growth by acquisition of similar companies Semi-autonomous operation The Business Challenge United front to customer Establish global branding Reduce administrative overhead Preserve specialist production processes Rationalization of post production processes Current Status Produces hi-tech drill bits, cutters, routers, grinders and millers Customers are manufactures, users and spares wholesalers Preferred supplier to major machine tool manufacturers Products only manufactured against verified orders Rationalized order and production management Rationalized financial control 18 (C) The Open Group 2011

DDB Group (Migration step 1) Traditional Ordering Order Management Online Ordering Production Management Dispatch Management National (van fleets) 19 Financial Control Production Facility Group Dispatch Management International (logistics providers) (C) The Open Group 2011 Possible re-use Intercontinental (air freight agents)

For DDB Group - Initial Steps ü Understanding what SOA is (Definition of SOA, SOA Ontology) ü Understanding what our business goals for SOA are (Practical Guide) ü Understanding what SOA capabilities we have (OSIMM) ü 2 divisions have some SOA services already with Repositories ü Defining the roadmap to achieve our SOA goals (OSIMM) ü Business and IT principles and goals considerations ü Choosing Dispatch Management First ü Defining a reference architecture for our SOA solution (SOA RA) ü Service Model (SOA Ontology) ü Infrastructure services architecture (SOCCI) ü Defining a governance regimen for DDB Group (SOA Governance Framework) 20 (C) The Open Group 2011

The Open Group SOA Ontology: Explicit formal specifications of the terms in the domain and relations among them (Gruber 1993) Define the concepts, terminology and semantics in both business and technical terms, to: Enhance the understanding of concepts Enable communications between business and technical people, State problems and opportunities clearly and unambiguously Create a semantic model and foundation for domain-specific areas For formalizing and understanding Core SOA concepts Serve as a semantic foundation for other SOA related standards Formalizes, refines, and extends OASIS SOA RM (Vocabulary and common understanding and ‘essence’ of SOA) OWL and UML representation to facilitate tools and automation Potentially use with model-driven approaches and tools, increasing adoption of SOA http: //www. opengroup. org/soa/standards/ontology. htm 21 (C) The Open Group 2011

Making this easier 22 Semantic Foundation for other standards Stabilizing terminology and relationships Reducing mapping terms Consistency among standards Reuse investment going forward Formalized ontology can be used by machines Enabling modeling tools Automating on standardized terms and relationships, Clarifying assumptions Enabling interoperability Architects from different domains have problems communicating because Have different architecture concepts bridge architectural disciplines and methods (C) The Open Group 2011

SOA Reference Architecture Consumer Interfaces Operational Systems 3/16/2018 23 (C) The Open Group 2011 Governance Service Components Information Services Quality of Service Operational Systems Integration Business Processes Information Service Components Governance Services Quality of Service Integration Business Processes

Layers of the SOA Reference Architecture (1) • • Operational Systems Layer – Programs and data of the operational systems of the enterprise – The new and existing infrastructure needed to support the SOA solution. Service Components Layer – Software components, each of which provides the implementation or “realization” for a service, or operation on a service, and binds the service contract to the implementation of the service in the operational systems layer. Services Layer – Services, with their descriptions, contracts, and policies, and the containers that contain the service components. Business Processes Layer – Business processes , and compositions in which business processes are composed of other business processes and of services. • Consumer Interfaces Layer – The programs by which the users interface to the services SLIDE 24 of 70

Layers of the SOA Reference Architecture (2) • Integration Layer – Integration of and communication between other building blocks, including messaging, message transformation, complex event processing, service composition and service discovery. • Quality of Service Layer – Monitoring and management of the quality of service of the architected system, including its performance, reliability, availability, scalability, security, and manageability. • Information Layer – Management, analysis, interpretation and transformation of data • Governance Layer – Governance rules and procedures; and – Services and programs that support the application of the rules and the operation of the procedures. SLIDE 25 of 70

SOA Governance • Governance is a means for establishing and enforcing how people and solutions work together to achieve organizational objectives • SOA Governance provides the framework for planning, developing, deploying and managing the SOA environment • Benefits: – – SLIDE 26 of 70 Ensure alignment Establish controls Reduce cost over time Mitigate risks

SOA Governance in the Enterprise Business Governance Supports Aligns IT Governance EA Governance Extends SOA Governance SLIDE 27 of 70

SOA Governance Aspects People Roles & Responsibilities Organizational structure Processes Governing processes Governed processes Technology Infrastructure Tools SLIDE 28 of 70

SOA and the ADM – Phase A: Vision ØDevelop Perform Maturity and Readiness Assessments: Input - OSIMM SLIDE 29 of 55

Phase A Vision Enhancements Objectives • No additional objective material • • • Inputs Organizational Model • SOA Centre of Excellence • SOA Maturity Assessment • SOA Readiness Assessment • SOA Governance Tailored Architecture Framework • SOA meta-model extensions • SAO Reference Architecture Available higher-level (Strategic/ Segment) architecture • • Steps Identify stakeholder concerns • SOA specific concerns Define scope • Ensure scope is appropriate for SOA • Tailor deliverables to level of architecture Evaluate Business Capabilities • SOA readiness Confirm Principles • SOA supporting Principles • • • Outputs Statement of Architecture Work • with SOA as an approach Architecture principles • including SOA principles Capability assessment • including SOA readiness Architecture Vision • with SOA thinking Additional content populating the Architecture Repository • including SOA Reference Architecture 30 SOA/TOGAF Practical Guide Team

Open Group SOA Integration Maturity Model Assessment (OSIMM) • Market/Practitioner Need: – SOA becoming relatively mature – Like other Maturity Assessment Models in TOGAF and the Industry SOA benefits from a maturity assessment • Seven Categories of Assessment • Seven Levels of Maturity: From “Silo” to “Dynamically Re. Configurable Services” • Extensible • Assess current capabilities and understand RIGHT target capabilities for your business • OSIMM V 2 ISO International Standard http: //www. opengroup. org/soa/standards/osimm. htm SLIDE 31 of 70

Open Group Service Integration Maturity Matrix (OSIMM) Service Foundation Levels Dynamically Composite Silo Business View Isolated Business Line Driven Governance & Organization Ad hoc LOB IT Strategy and Governance Integrated Componentized Services Composed Outsourced Services Business Services BPM & BAM Services Business capabilities via context aware services Componentized Business Functions Business provides & consumes services Object Oriented Modeling Common Governance Processes Emerging SOA governance SOA and IT Governance Alignment Service Oriented Modeling for Infrastructure Applications comprised of composite services Process Integration via Service Dynamic Application Assembly SOA Grid Enabled SOA Dynamically Re. Configurable Architecture Virtualized Data Services Semantic Data Vocabularies Virtual SOA Environment: Context-aware Sense and Respond Sense & Respond Level 7 Structured Analysis & Design Object Oriented Modeling Component Based Development Applications Modules Objects Components Services Architecture Monolithic Architecture Layered Architecture Information Application Specific Data Solution Infrastructure & LOB Platform Management Specific SLIDE 32 of 70 Services Re-Configurable Business Process Integration Methods Level 1 Virtualized LOB Specific (Data subject areas established) Enterprise Standards Level 2 Component Emerging Architecture SOA Canonical Models. Information as a Service Enterprise Business Data Dictionary & Repository Common Reusable Infrastructure Project Based SOA Environment Common SOA Environment Level 3 Level 4 Level 5 SOA and IT Infrastructure Governance alignment Service Oriented Level 6 Governance via Policy Business Process Modeling Event-based:

DDB SOA Maturity Roadmap – Using OSIMM Service Foundation Levels Dynamically Composite Silo Business View Isolated Business Line Driven Governance & Organization Ad hoc LOB IT Strategy and Governance Integrated Componentized Services Virtualized Re-Configurable Services Composed Outsourced Services Business Services BPM & BAM Business Process Integration Componentized Business Functions Business provides & consumes services Object Oriented Modeling Common Governance Processes Emerging SOA governance SOA and IT Governance Alignment SOA and IT Infrastructure Governance alignment Service Oriented Business capabilities via context aware services Governance via Policy Methods Structured Analysis & Design Object Oriented Component Based Development Service Oriented Modeling for Infrastructure Applications Modules Objects Components Services Applications comprised of composite services Process Integration via Service Dynamic Application Assembly Architecture Monolithic Architecture Layered Architecture SOA Grid Enabled SOA Dynamically Re. Configurable Architecture Information Application Specific Data Solution Virtualized Data Services Semantic Data Vocabularies Infrastructure & LOB Platform Virtual SOA Environment: Context-aware Sense and Respond Sense & Respond Management Specific Level 1 33 LOB Specific (Data subject areas established) Enterprise Standards Level 2 Component Emerging Architecture SOA Canonical Models. Information as a Service Enterprise Business Data Dictionary & Repository Common Reusable Infrastructure Project Based SOA Environment Common SOA Environment Level 3 Level 4 (C) The Open Group 2011 Level 5 Level 6 Business Process Modeling Event-based: Level 7

Phase B Enhancements Objectives • No additional objective material • • • Inputs Organizational Model • SOA Centre of Excellence • SOA Maturity Assessment • SOA Readiness Assessment • SOA Governance Tailored Architecture Framework • SOA meta-model extensions • SOA Reference Architecture Available higher-level (Strategic/ Segment) architecture SOA/TOGAF Practical Guide Team • Steps Select Reference models, viewpoints & tools • SOA metamodel & content extensions • Information Entity & Information Component • • Outputs Validated business Principles • SOA supporting Principles Target Business Architecture • Business Service (with contract) • Business Process • Information Entity • Information Component Draft Architecture Requirements • Technical requirements for SOA Outputs may include • Business Service Interaction Diagram • Business Process Diagram • Business Vocabulary Catalog • Business Services Catalog • Business Service/Location catalog • Event/Process catalog 34 • Contract/Service Quality Catalog • Business Service Interaction Matrix • Business Service/Information matrix • Information component model

Phase B Artifacts Artifact Purpose Meta-model entities Business Service Interaction Diagram This diagram shows all the business services in scope and their relations and the information flowing between the business services This is a set of diagrams that show the business processes and their decomposition, their interactions, and the information with which they are concerned. Business services, Contracts, Information Entity Business Process Diagram Subset of business service model showing the Business services and Contracts involved in the processes and the Business information passed between the Business services. This is a list of Information entities and descriptions of those elements. Business Vocabulary Catalog List of the key terms used in describing the business processes and information. Business Services Catalog This is a list of the enterprise's business services and their functional and nonfunctional requirements. To understand where the business services needs to be executed. List of Business services and their Service Qualities To understand which process is run in relation to an event To understand the non-functional properties of a contract To show relations between Business Services To show information entities are used by business services and to find faults in that model To define the logical structure of the information in the organization. Lists Event and their effected Business process Lists Contracts and their relevant Service Qualities Business services on both axis and contracts in the cross point Business services and Information entities Business Service/Location Catalog Event/Process Catalog Contract/Service Quality Catalog Business Service Interaction Matrix Business Service/Information Matrix Information Component Model SOA/TOGAF Practical Guide Team Business Service, Location Information Components and their relations. 35

Phase C Enhancements Objectives • Extend Applications section to include ‘Applications & Services' • • • Inputs Organizational Model • SOA Centre of Excellence • SOA Maturity Assessment • SOA Readiness Assessment • SOA Governance Tailored Architecture Framework • SOA meta-model extensions • SOA Reference Architecture Available higher-level (Strategic/ Segment) architecture • • Steps Select Reference models, viewpoints & tools SOA meta-model & content extensions IS Service Contract Relationship between IS Service & Data Entity • • Outputs Validated business Principles • SOA supporting Principles Target Information Systems Architecture • IS Service (with contract) • Service Portfolio Draft Architecture Requirements • Technical requirements for SOA Outputs may include • Service Interaction Diagram • Business Process/Service Matrix • Service Contract Catalog • IS Service/Application (existing) catalog • IS Service/Data entity matrix • Logical SOA Component Matrix • Logical SOA Solution Diagram • Service Distribution Matrix 36 SOA/TOGAF Practical Guide Team

Phase C Artifacts Artifact Purpose Meta-model entity usage IS Service This shows potential SOA services (IS Services) and Interaction Diagram the interactions between them, and their use of information. Business This matrix shows the relation between each Business Process/IS Service Process and the IS Services supporting the process Matrix IS Service Contract The catalog lists all IS Services, their Contracts and the Catalog related Service Qualities to enable analysis of the nonfunctional requirements for potential SOA Services. IS Services and the Contracts between them. Preferably the Service Quality entity for both IS Services and Contracts Business Process and its relation to IS Service(s). IS Service/Application (existing) catalog IS Service/Data entity matrix Logical SOA Component Matrix IS Service(s), related Contracts and Service Qualities connected with as-is Physical Application Components. Logical SOA Solution Diagram IS Service Distribution Matrix This catalog connects IS Services (potential SOA Services), Contracts and Service Qualities with existing applications (baseline Physical Application Components) This matrix shows what data is handled by potential SOA Services (IS Services). This matrix shows the relationship between the logical SOA Components (Logical Application Components) and the potential SOA Services (IS Services) This diagram shows the relations between the logical SOA components (Logical Application Components) and other logical solutions (Logical Application Components). This matrix shows the services distributed on physical locations to fulfill legal or other requirement SOA/TOGAF Practical Guide Team List of IS Services and their related Service Qualities. Additionally IS Service Contracts for each IS Service is included. IS Services and its related Data Entities IS Services, Logical Application Components and Principles & Business Drivers (used to find criteria to do grouping). Logical Application Components and Contracts and their Service Qualities. Logical Technology components and their mapping to Contracts are used for the interface mechanisms. IS Service, Logical Application Component, Physical Application Component and 37 Location.

Phase D Enhancements Objectives • No additional objective material • • • Inputs Organizational Model • SOA Centre of Excellence • SOA Maturity Assessment • SOA Readiness Assessment • SOA Governance Tailored Architecture Framework • SOA meta-model extensions • SAO Reference Architecture Available higher-level (Strategic/ Segment) architecture • Steps Select Reference models, viewpoints & tools • SOI Reference Model • Relationship between Logical Technology Component & Logical Application Component • • SOA/TOGAF Practical Guide Team Outputs Validated business Principles • SOA supporting Principles Target Technology Architecture • Expected processing load & distribution of load across technology Draft Architecture Requirements • Technical requirements for SOA Outputs may include • Logical Technology Architecture Diagram • Logical Application and Technology Matrix 38

Phase D Artifacts Artifact Purpose Meta-model entity usage Logical Technology Architecture Diagram This diagram is used to show and analyze the instance of the Open Group SOA Reference Architecture. This matrix is used to show and analyze the relations between the Logical Application Components and the Logical Technology Components Platform Service (Capability), Logical Technology Component (ABB) Logical Application and Technology Matrix SOA/TOGAF Practical Guide Team Logical Application Components and their relations to Logical Technology Components including derivations of the Service Qualities. 39

Example interactions among the Layers of SOA Reference Architecture Consumer Layer Integration Layer Business Process Layer Services Layer Component Layer Operational Systems Layer 3/16/2018 40 (C) The Open Group 2011

Dispatch Management Solution Architecture Using the Open Group SOA RA Dispatch Portals Order Management Dispatch Processes Select Carrier Production Dispatch Place Delivery Manage Delivery Inter. Dispatch Inter. Track Services National nationalcontinental Delivery Cancel Track Delivery Confirm Dispatch Components Best-of-breed Existing Operational Systems Carriers Orders Deliveries http: //www. opengroup. org/soa/drafts/refarch. htm#_SOA_Reference_Architecture 41 (C) The Open Group 2011

SOA Infrastructure Portals Information presentation Composition engine Performance monitor SOA Governance Repository Service Registry ESB Access control Data conversion CEP Existing Infrastructure 42 EJB (C) The Open Group 2011

Service Oriented Cloud Computing Infrastructure (SOCCI) • • SLIDE 43 of 70 Joint project between SOA and Cloud Work Groups, because accessing infrastructure services is needed and common for both Provides definitions, architecture, components, recommendations and guidelines that help enable the provisioning of infrastructure as a service in the cloud computing and SOA environments SOCCI results from applying the principles of service-orientation to the infrastructure architectural pillar. – Infrastructure architecture is regarded by many as one of the three pillars of information technology (IT), together with business architecture and application architecture. socci is related to SOA, which is most commonly used to refer to the use of this principle in application architecture. In contrast to other infrastructure architectures, an SOCCI has the following differentiating characteristics: – The infrastructure is defined as a set of technology-agnostic, standardized services. – The applications are decoupled from the infrastructure. – The infrastructure services are delivered from a pool of resources governed by a centralized management system that balances supply and demand. https: //wiki. opengroup. org/councilswiki/doku. php? id=workgroups: cloud: service_oriented_cloud_computing_infrast ructure_project_page

SOA ABBs for Cloud - SOCCI Presentation Layer Consumer Interfaces APIs Business-Process-as-a-Service (BPaa. S) Platform-as-a-Service (Paa. S) Infrastructure-as-a-Service (Iaa. S) Service Components Operational Systems SOI Framework Compute Network Infrastructure Storage Facilities Information Software-as-a-Service (Saa. S) Quality of Service Integration Services Governance Business Processes

SOCCI – Management of Cloud Elements Services Business-Process-as-a-Service (BPaa. S) Software-as-a-Service (Saa. S) Platform-as-a-Service (Paa. S) Business Infrastructure-as-a-Service (Iaa. S) Service Components Service Oriented Infrastructure Compute Network Storage Infrastructure Operational Systems Facilities Operational Governance SOCCI Information Quality of Service Business Processes Integration API Interfaces Consumer Interfaces

SOCCI ABBs SOCCI Architectural Building Blocks SOCCI Management Building Blocks Business Billing Manager Metering Elements of SOCCI Billing Manager Location Manager Compute Storage Operational Virtualization Manager Monitoring & Event Manager Monitor Network Facilities Configuration Manager Configuration manager Provisioning Manager Resource manager Capacity & Performance Manager 46

SOA Reference Architecture for DDB Group • We have defined SOA Reference Architecture for SOA Solution • Functional concerns: Infrastructure, Services, Business processes, Consumers • Cross cutting concerns: Integration, Information, Quality of Service, Governance • We have discovered that: – Since there are 4 semi-autonomous divisions, 2 of them have already started their SOA journey, have some services available and have put Repositories into place – The SOA solution governance need to handle ensuring that services are unique and reused across ALL the divisions – New Services must be approved by a Governance board (marked in repository) 47 (C) The Open Group 2011

SOA Governance Framework Standard SOA Governance Reference Model Technolog y Guiding Principles Roles and Responsibilities Governing Processes SOA Governance Vitality Method • Ongoing and iterative over time • Keeps business and IT solutions aligned • Guiding Principles Governed Artifacts SOA • Artifacts Processes People: • Roles and Responsibilities • Organizational Structure Processes: • Governing Processes • Governed Processes Technology: • Infrastructure • Tools http: //www. opengroup. org/soa/standards/gov. htm 48 (C) The Open Group 2011

SOA Governing Processes Compliance - provides the mechanism for review and approval/rejects against the criteria established Dispensation - allows for appeals of noncompliance to established processes Dispensation Communication - educates, supports and communicates SOA governance across the organization SLIDE 49 of 70 Compliance Communication

SOA Governance Regimen for DDB Group – Governance regimen targets: • People – Corporate changes (adding a Gov Board, creating a central dispatch position, …) • Process – SOA Solution Lifecycle and Portfolio processes – SOA Service Lifecycle and Portfolio processes • Technology – Registries, Repositories – Infrastructure – Management and Monitoring • Governance Transition Plans • These targets need to be included in the SOA transition plan 50 (C) The Open Group 2011

SOA Processes – DDB Group Enterprise SOA Solution Dispatch Solution SOLUTION PLANNING Solution Portfolio Management DESIGN & OPERATIONAL Solution Lifecycle Dispatch Solution development and deployment 51 Service Identification Process – Dispatch Service decomposition SERVICE Service Portfolio Management Service Lifecycle Service Development, deployment for Dispatch Service (C) The Open Group 2011

SOA Governance Artifacts and Technology for DDB Group • Process Artifacts – Appeal record – Exception record – Dispensation record – Compliance indicator – Communication Plan 52 • SOA Governance Technology – Storage and access capability – Policy enforcement – Monitoring – Management – Workflow (C) The Open Group 2011

SOA Governing Processes – DDB Enforce Reduction In Duplication Process Compliance • Keep a registry of available services • Developers to check for existing services that meet requirements • If a new service is identified, submit ‘new service request’ to registry • Governance board works funding out for service owners • Signoff from Governance Board before new services are developed • Registry record for new services has Board Signoff in Unique. Service property Dispensation Communication 53 • Petition Governance Board for exception to redevelop service • Inform developers of new services and Requirement for signoff for new services (C) The Open Group 2011

Phase E Enhancements Objectives • No additional objective material • • • Inputs Organizational Model • SOA Centre of Excellence • SOA Maturity Assessment • SOA Readiness Assessment • SOA Governance Tailored Architecture Framework • SOA meta-model extensions • SOA Reference Architecture Available higher-level (Strategic/ Segment) architecture • Steps Select Reference models, viewpoints & tools • Physical Data Component • Physical Application Component • Technology Application Component • SOA Solution SOA/TOGAF Practical Guide Team • • • Outputs Architecture Roadmap • SOA & SOI Roadmap Draft Architecture Requirements • Technical requirements for SOA Outputs may include • Physical SOA Solution Matrix • Physical SOA Solution Diagram • Physical Service Solution Matrix • Application Guidelines • Physical Technology Architecture diagram • Physical Application and Technology Matrix • Technology Portfolio Catalog • Technology Guidelines 54

Phase E Artifacts Artifact Physical SOA Solution Matrix Purpose Meta-model entity usage This matrix shows all the components of a SOA IS Services, Physical Application Components, Solution Platform Services, Physical Technology Components Physical SOA Solution This diagram shows the relations between the Physical Application Components and Contracts Diagram physical SOA solution (Physical Application and their Service Qualities. Physical Technology Components) and other solutions (Physical components and their mapping to Contracts are Application Components). used for the interface mechanisms. Physical Service This matrix shows which existing services are IS Services, Physical Application Components Solution Matrix re-used, which services could be provided by (as-is SOA services for re-use), other Physical external services (Saa. S) and which services Application Components (new and existing needs to be developed as wrappings of applications to be wrapped) and new Physical new/existing applications and which needs to Application Components (new services to be be developed or purchased externally) Application Guidelines This document provides the guidelines on how to develop the SOA Solution and Services. Physical Technology This diagram is used to show and analyze the Platform Service, Logical Technology Architecture diagram physical technical solution for the SOA Component, Physical Technology Component infrastructure. Physical Application and This matrix is used to show and analyze the Physical Application Components and their Technology Matrix physical infrastructure used to run the physical relations to Physical Technology Components application including derivations of the Service Qualities. Technology Portfolio This is a list of products and kinds of product Physical Application Components and their Catalog that will be used in the implementation, relation with Service Qualities including SOA run-time infrastructure, Technology Guidelines This document provides the guidelines on how to use SOA infrastructure 55 SOA/TOGAF Practical Guide Team

What services are in the Group Dispatch solution? • Dispatch Management Online Ordering Traditional Ordering Order Management – Select Carrier process Production Management Financial Control Production Facility Group Dispatch Management – Place Delivery process – Manage Delivery process – services: • Delivery Confirmation • Delivery Track Dispatch Management • Delivery Cancel • Delivery Feedback • National (van fleets) International (logistics providers) Intercontinental (air freight agents) Carrier Services: – National Service Identification step – International – Intercontinental 56 (C) The Open Group 2011 Some will be decomposed into compositions and processes

DDB Group Dispatch Management Decomposition and planning For the DDB dispatch service there are multiple dependencies Dispatch Management Service Ship Date Destination Group Dispatch Data Service Group Dispatch Data Access Service 57 Group Dispatch Business Processes Service Group Dispatch Access Rules Service Group Dispatch Business Rule Service Choose Carrier Place Delivery Manage Delivery Service Identification step: Important for identifying ‘utility’ services that are highly reusable (C) The Open Group 2011

DDB Group Manage Dispatch Service Decomposition and planning For the DDB dispatch service there are multiple dependencies Manage Delivery Process Ship Date Customer Ship Date Delivery Cancel Delivery Confirmation Service Delivery Tracking Delivery Feedback Service Identification step: These services will use The business access services 58 (C) The Open Group 2011

SOA Ontology – Core concepts 59 Element System Human Actor Task Service Contract Effect Service Interface Information Type Policy Composition Process Service Composition Orchestration Choreography Collaboration (C) The Open Group 2011

Developing Service: Elements of SOA Human Actor Task System has. Member Element performs Performs Service Subclasses 60 (C) The Open Group 2011

Developing Service: Adding Service Contract… Human Actor Does Task is. Party. To Service Contract Element Service performed by elements Of SOA environment Performs has. Contract 61 Service (C) The Open Group 2011

Developing Service: Adding System and Composition Human Actor System Task has. Member Element Composition Orchestrates *Composition. Pattern Performs Service 62 Service Composition (C) The Open Group 2011 Process

Dispatch solution Human Actor Chief Dispatcher Customer Production Mgr has. Member is. Party. To Service Contract System Group Dispatch Task Place. Order/Customer Place. Delivery/Dispatcher Send. Order/Prod. Mgr Element Orchestrates Composition *Composition. Pattern Delivery. Contract has. Contract Performs Service Place. Delivery. Confirm National Delivery. Track International (C) The Open Group 2006 Delivery. Cancel Intercontinental Delivery. Feedback Group 2011 (C) The Open Service 63 Service Composition Process Select. Carrier Place Delivery Manage. Delivery

Using the Ontology in Standards S-RAMP – SOA Repository Artifact Model and Protocol OASIS Technical Committee formed December 2010 http: //www. oasis-open. org/committees/tc_home. php? wg_abbrev=s-ramp. Co-submitted: HP, IBM, Software AG, Tibco Proposed Standard for Repositories and their use in SOA environments to publish, search for and retrieve a wide variety of technical documents which describe a customer's SOA environment. Used during Design time, Runtime, and for Monitoring Includes support for describing available Artifacts, Services, Classification (OWL), Protocol for Create, Read, Update, Delete (Atom binding) SOA Ontology adopted as the foundational “business model” for the SRAMP standard on registry/repository integration the S-RAMP meta model is semantically consistent with the SOA ontology 64 (C) The Open Group 2011

Using the Ontology and S-RAMP 65 Define your service model as a set of extensions to the SOA Ontology Save the model and artifacts in Repository using S-RAMP Look up services and get information for invoking and governing services using SRAMP Vendor neutral Federation between vendors now possible (C) The Open Group 2011

S-RAMP’s extensions to the SOA Ontology SOA Model Type Group. Dispatch Task Place. Delivery/Dispatcher defined. By Derived Artifact Type Organization DDB Group Policy Business. Policy sets. Policy Human Actor Chief Dispatcher defined. By Information Type Customer, Ship Date is. Output. At is. Input. At is. Party. To Service Contract Delivery. Contract has. Contract Service Instance Place. Delivery 66 defined. By Service Interface Delivery Service Operation Request. Delivery Has. Operation Is. Interface. Of Service Place Delivery Element Performs Has. Instance (C) The Open Group 2011

Magic happens here • Implement the solution using the service model • Use a service registry to implement the governance processes 3 February 2011 (C) The Open Group 2006

Implementation Governance and the ADM ØRun/modify/adjust Governance for SOA: SLIDE 68 of 70

SOA Governing Processes – DDB Enforce Reduction In Duplication Process Compliance • Keep a registry of available services • Developers to check for existing services that meet requirements • If a new service is identified, submit ‘new service request’ to registry • Governance board works funding out for service owners • Signoff from Governance Board before new services are developed • Registry record for new services has Board Signoff in Unique. Service property Dispensation Communication 69 • Petition Governance Board for exception to redevelop service • Inform developers of new services and Requirement for signoff for new services (C) The Open Group 2011

SOA Governance Vitality Method If there are more than 10% Policy Exceptions the policy should be reexamined (uniqueness) DDB Group monitors that all service records in registry have Unique. Service Properties 70 (C) The Open Group 2011

DDB Group – 2 Years Later • The DDB Group SOA governance regimen has been implemented based upon the adoption of the outsourced logistics services • New organization-wide SOA governance board interacts with the business, IT, EA Governance Boards • DDB’s Service Portfolio Management includes the business services for the outsourced dispatch management processes • DDB Group is engaging successfully internationally, expanding business opportunities • Tracking, reporting and analysis methods have been developed for SOA governance metrics 71 (C) The Open Group 2011

Conclusions • TOGAF can help you develop your SOA solution and the Practical Guide shows you how • OSIMM helps you understand the right SOA goals for your enterprise. • The SOA Governance Framework helps you customize the processes, structures and technologies for your enterprise – and update them over time to keep them relevant • Good governance is crucial if SOA is to realize its business potential • The Open Group SOA Reference Architecture helps you understand technical aspects of your solution • Service Oriented Cloud Computing Infrastructure architectures applies to both SOA and Cloud • Build your service models using an existing standard foundation like the Open Group SOA Ontology 72 (C) The Open Group 2011

Where to learn more about Open Group Standards • • • The Open Group SOA project page: http: //www. opengroup. org/soa The Open Group Cloud Computing project page: http: //www. opengroup. org/cloudcomputing/ TOGAF-SOA “Practical Guide”: https: //www 2. opengroup. org/ogsys/jsp/publications/Publication. Details. jsp? publicationid=12390 Open Group’s SOA Source Book: http: //www. opengroup. org/projects/soa-book/ Navigating the Open Standards Landscape Around Architecture paper published jointly with OMG and OASIS: http: //www. opengroup. org/pubs/catalog/w 096. htm, OSIMM Standard: http: //www. opengroup. org/soa/standards/osimm. htm – Webinar: https: //opengroupevents. webex. com/ec 0605 lb/eventcenter/recording/record. Action. do ? siteurl=opengroupevents&the. Action=poprecord&ec. Flag=true&record. ID=2679992 SOA Governance Framework Standard: http: //www. opengroup. org/soa/standards/gov. htm – Webinarhttp: //www. opengroup. org/projects/soa/doc. tpl? CALLER=documents. tpl&dcat=35&gdi d=22510 • • • SOA Ontology: https: //www 2. opengroup. org/ogsys/jsp/publications/Publication. Details. jsp? catalogno=c 104 • SOCCI: https: //wiki. opengroup. org/councilswiki/doku. php? id=workgroups: cloud: service_oriented_cloud_computing_infrastructure_project_page 73 (C) The Open Group 2011

Thank You! 74 (C) The Open Group 2011

Where to learn more about S-RAMP SRAMP – SOA Repository Artifact Model and Protocol OASIS Technical Committee formed December 2010 http: //www. oasis-open. org/committees/tc_home. php? wg_abbrev=s-ramp S-RAMP client you can access and experiment with • http: //s-ramp. soaphub. org: 5901/SRAMPClient ATOM Publishing Protocol • http: //atompub. org/ • http: //datatracker. ietf. org/wg/atompub/ 75 (C) The Open Group 2011

How SOA Standards Relate Semantic model for Reference Model Language for Modeling Languages Ontology Used By Guides Reference Architecture Foundation Architecture Abstract Assesses Reference Architecture Industry Architecture Reference Architecture Common Systems Architecture Maturity Models Organization Solution Architecture Influence and Refine 76 Navigating the SOA Open Standards Landscape The Open Group. Architecture June 2009 76 (C) Around 2011 http: //www. opengroup. org/pubs/catalog/w 096. htm Concrete