1. The Latest Open SOA Standards
3 February 2011
3 February 2011
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
(C) The Open Group 2003
(C) The Open Group 2003 1

2. 14 April 2018
Copyright
Copyright (c) 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. 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
(C) The Open Group 2011
(C) The Open Group 2009 2

3. Agenda Introducing DDB Corporation
3 February 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
(C) The Open Group 2003

4. 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
SLIDE 4 of 70

5. 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
SOA Tutorials
SLIDE 5 of 70

6. SOA as an Architectural Style
ATE010 - Introduction to the Course
ATE-eLT81-CP /04
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
TOGAF 8 Certification for Practitioners

7. 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

8. 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

9. What does SOA Offer? Smaller Business-IT Gap Agility/Flexibility
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
Better Operational Control
Better management and visibility, better SLAs
To get these benefits we have to have the right SOA services and solutions at the right time 9
(C) The Open Group 2011

10. How Enterprise Architecture Supports SOA
ATE010 - Introduction to the Course
ATE-eLT81-CP /04
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
TOGAF 8 Certification for Practitioners

11. How Enterprise Architecture Supports SOA (2)
ATE010 - Introduction to the Course
ATE-eLT81-CP /04
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
TOGAF 8 Certification for Practitioners

12. 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

13. SOA-TOGAF “Practical Guide”*
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”
3 February 2011
(C) The Open Group 2006

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

15. Updated meta-model entities
Extension Term (meta-model object)
Description
Information Entity
Information communicated about within the business
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).
IS Service Contract
An agreement between an IS service consumer and an IS service provider that establishes functional and non-functional parameters for interaction.
SOA Solution
The requirements and architecture (structure) of entire solution including process, information, service and infrastructure requirements.
Service Quality
The Service Quality meta-model object is used as an attribute to services, components, and contracts
The Service Qualities defines the non-functional requirements.
Location
The Location meta-model object is used as an attribute to a service or component.
SOA/TOGAF Practical Guide Team

16. 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

17. 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
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)
SOA/TOGAF Practical Guide Team

18. 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

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

20. 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

21. The Open Group SOA Ontology
3 February 2011
The Open Group SOA Ontology
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 21
(C) The Open Group 2011
(C) The Open Group 2003 21

22. Making this easier Semantic Foundation for other standards
3 February 2011
Making this easier
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 22
(C) The Open Group 2011
(C) The Open Group 2003

23. SOA Reference Architecture
14 April, 2018
SOA Reference Architecture
Consumer Interfaces
Business Processes
Services
Service Components
Operational Systems
Integration
Quality of Service
Information
Governance
Consumer Interfaces
Business Processes
Services
Service Components
Operational Systems
Integration
Quality of Service
Information
Governance
This high-level perspective shows the conceptual building blocks of an SOA solution, and how they relate to each other. It can be used as a basis for specific solution models, and also for models of larger SOA systems, including those of enterprise SOA.
14 April, 2018
(C) The Open Group 2011
(C) The Open Group 2008

24. 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

25. 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

26. 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:
Ensure alignment
Establish controls
Reduce cost over time
Mitigate risks
SLIDE 26 of 70

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

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

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

30. 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
SOA/TOGAF Practical Guide Team

31. 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 V2 ISO International Standard
SLIDE 31 of 70

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

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

34. No additional objective material
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
Steps
Select Reference models, viewpoints & tools
SOA meta-model & 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
Contract/Service Quality Catalog
Business Service Interaction Matrix
Business Service/Information matrix
Information component model
SOA/TOGAF Practical Guide Team

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

36. Extend Applications section to include ‘Applications & Services'
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
SOA/TOGAF Practical Guide Team

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

38. No additional objective material
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
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
SOA/TOGAF Practical Guide Team

39. 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.
Platform Service (Capability), Logical Technology Component (ABB)
Logical Application and Technology Matrix
This matrix is used to show and analyze the relations between the Logical Application Components and the Logical Technology Components
Logical Application Components and their relations to Logical Technology Components including derivations of the Service Qualities.
SOA/TOGAF Practical Guide Team

40. Example interactions among the Layers of SOA Reference Architecture
Consumer
Consumer Layer
Integration Layer
Business Process
Layer
Services Layer
Component Layer
Operational Systems Layer
14 April, 2018
(C) The Open Group 2011

41. 14 April 2018
Dispatch Management Solution Architecture - Using the Open Group SOA RA
Dispatch Portals
Order Management
Production
Dispatch
Dispatch Processes
Select Carrier
Place Delivery
Manage Delivery
Delivery
Track
Dispatch Services
Inter-national
Track Delivery
Delivery
Cancel
Delivery
Confirm
National
Inter-continental
Dispatch Components
Best-of-breed Existing Operational Systems
Carriers
Orders
Deliveries 41
(C) The Open Group 2011
(C) The Open Group 2008

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

43. Service Oriented Cloud Computing Infrastructure (SOCCI)
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.
wiki/doku.php?id=workgroups:cloud:service_oriented_cloud_computing_infrast ructure_project_page
SLIDE 43 of 70

44. SOA ABBs for Cloud - SOCCI
Governance
Information
Presentation Layer
Quality of Service
Consumer Interfaces
Integration
APIs
Business Processes
Business-Process-as-a-Service (BPaaS)
Services
Software-as-a-Service (SaaS)
Platform-as-a-Service (PaaS)
Infrastructure-as-a-Service (IaaS)
Service Components
Operational Systems
This high-level perspective shows the conceptual building blocks of an SOA solution, and how they relate to each other. It can be used as a basis for specific solution models, and also for models of larger SOA systems, including those of enterprise SOA.
SOI Framework
Compute
Network
Storage
Facilities
Infrastructure

45. SOCCI – Management of Cloud Elements
Quality of Service
Information
Governance
Consumer Interfaces
Business Processes
Service Components
Operational Systems
Integration
Cloud Service Consumer
Service Oriented Infrastructure
Compute
Network
Storage
Facilities
Business
Operational
SOCCI
Software-as-a-Service (SaaS)
Platform-as-a-Service (PaaS)
Infrastructure-as-a-Service (IaaS)
Business-Process-as-a-Service (BPaaS)
Services
API
Interfaces
Infrastructure
This high-level perspective shows the conceptual building blocks of an SOA solution, and how they relate to each other. It can be used as a basis for specific solution models, and also for models of larger SOA systems, including those of enterprise SOA.

46. SOCCI ABBs SOCCI Architectural Building Blocks
Elements of SOCCI
Network
Facilities
Compute
Storage
Metering
Billing Manager
Business
Location Manager
Metering Manager
Monitor
Provisioning manager
Resource manager
Configuration manager
Provisioning Manager
Configuration Manager
Monitoring & Event Manager
Capacity & Performance Manager
Operational
Virtualization Manager
SOCCI Management Building Blocks
The (virtualized) infrastructure constitutes all infrastructure elements needed on the cloud service provider side, which are needed to provide cloud services. This includes facilities, server, storage, and network resources, how these resources are wired up, placed within a data center, etc. In case of virtualization this also includes the virtualization such as hypervisors. It does not include any virtualization management software (as that is part of the virtualization management component of the OSS).
The decision whether the infrastructure is virtualized or not depends on the actual workload characteristics to be run on the respective infrastructures: For many workloads (e.g. compute & storage as-a-Service) it is very convenient to virtualize the underlying infrastructure, especially since virtualization enables some use cases which can basically not be realized with a physical infrastructure (e.g. all use case related to image management or dynamic scaling of CPU capacity as needed). For other workloads (e.g. analytics/search) it is required to have maximum compute capacity and use 100’s or 1000’s of nodes to run a single specialized workload. In such cases a non-virtualized infrastructure is more appropriate. This is not a violation of the architectural principles postulating as much as possible commonality across cloud services: While maximum commonality is a core architectural principle, it is allowed to have different infrastructure architecture per workload category. For example, a collaboration, web and infrastructure workload requires a different underlying infrastructure than an HPC or highly transactional workload. However, a requirement in any case is that all of these infrastructures get managed from a single, central CCMP and CCMP has the ability to place instances of each cloud services on the corresponding infrastructure (or IaaS service instance, in case a SaaS instance is not directly running on an infrastructure but leverages a IaaS cloud service as an alternative sourcing model).
The more homogeneous the infrastructure is, the more it caters the standardization needs of a cloud environment. Homogeneity on the infrastructure side is critical for enabling the high degrees of automation and economies of scale which are base characteristics of any cloud environment. However, it has to be acknowledged that in many cloud deployments (specifically private clouds) there are different workloads to be provided as a cloud service and each of these workloads might have special infrastructure needs. So although the ideal case is total homogeneity on the infrastructure side, it is important to note that there will cloud installations with a few variants in the infrastructure elements (e.g. different HW platforms).
The infrastructure is managed by the OSS as part of the CCMP, whereas the CCMP by itself is also running on the infrastructure.
Note: The physical existence of a virtualized infrastructure on the cloud service provider side is not mandatory, since it is also possible for a cloud service provider to consume infrastructure as a service (and the required CCMP) from a different cloud service provider and put higher value cloud services on top.

47. 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

48. SOA Governance Framework Standard
14 April, 2018
SOA Governance Framework Standard
SOA Governance
Reference Model
SOA Governance
Vitality Method
Ongoing and iterative over time
Keeps business and IT solutions aligned
Guiding Principles
Governing Processes
Governed SOA Processes
Artifacts
Roles and Responsi-bilities
Technology
Guiding Principles
Artifacts
People:
Roles and Responsibilities
Organizational Structure
Processes:
Governing Processes
Governed Processes
Technology:
Infrastructure
Tools 48
(C) The Open Group 2011
(C) The Open Group 2008 48

49. 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
Communication - educates, supports and communicates SOA governance across the organization
Compliance
Dispensation
Communication
SLIDE 49 of 70

50. 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

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

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

53. SOA Governing Processes – DDB Enforce Reduction In Duplication Process
14 April 2018
SOA Governing Processes – DDB Enforce Reduction In Duplication Process
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 UniqueService property
Petition Governance Board for exception to redevelop service
Inform developers of new services and
Requirement for signoff for new services
Compliance
Dispensation
Communication 53
(C) The Open Group 2011
(C) The Open Group 2009 53

54. No additional objective material
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
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
SOA/TOGAF Practical Guide Team

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

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

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

58. 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
Ship Date
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

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

60. Developing Service: Elements of SOA
3 February 2011
Developing Service: Elements of SOA
Human
Actor
Task
System
hasMember
Element
performs
Performs
Service
Subclasses 60
(C) The Open Group 2011
(C) The Open Group 2003

61. Developing Service: Adding Service Contract…
3 February 2011
Developing Service: Adding Service Contract…
Human
Actor
Task
Does
Service performed by elements
Of SOA environment
isPartyTo
Service Contract
Element
Performs
hasContract
Service 61
(C) The Open Group 2011
(C) The Open Group 2003

62. Developing Service: Adding System and Composition
3 February 2011
Developing Service: Adding System and Composition
Human Actor
Task
System
hasMember
Composition
Element
Orchestrates
*CompositionPattern
Performs
3 patterns of composition – choreography, collaboration, orchestration
Service
Service
Composition
Process 62
(C) The Open Group 2011
(C) The Open Group 2003

63. PlaceDelivery/Dispatcher
3 February 2011
Dispatch solution
Human Actor
Chief Dispatcher
Customer
Production Mgr
Task
PlaceOrder/Customer
PlaceDelivery/Dispatcher
SendOrder/ProdMgr
System
Group Dispatch
hasMember
isPartyTo
Composition
Service Contract
DeliveryContract
Element
Orchestrates
*CompositionPattern
Performs
hasContract
Service
PlaceDelivery
DeliveryConfirm
DeliveryTrack
DeliveryCancel
DeliveryFeedback
Service
Composition
Process
SelectCarrier
Place Delivery
ManageDelivery
Service
National
International
Intercontinental
(C) The Open Group 2006 63
(C) The Open Group 2011
(C) The Open Group 2003

64. Using the Ontology in Standards - S-RAMP
3 February 2011
Using the Ontology in Standards - S-RAMP
S-RAMP – SOA Repository Artifact Model and Protocol
OASIS Technical Committee formed December 2010
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 S- RAMP standard on registry/repository integration
the S-RAMP meta model is semantically consistent with the SOA ontology 64
(C) The Open Group 2011
(C) The Open Group 2003

65. Using the Ontology and S-RAMP
3 February 2011
Using the Ontology and S-RAMP
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 S- RAMP
Vendor neutral
Federation between vendors now possible
Helps solve DDBs problem of having multiple registries 65
(C) The Open Group 2011
(C) The Open Group 2003

66. PlaceDelivery/Dispatcher
3 February 2011
S-RAMP’s extensions to the
SOA Ontology
Task
PlaceDelivery/Dispatcher
Service
Instance
PlaceDelivery
Place Delivery
Element
Human Actor
Chief Dispatcher
Service Contract
DeliveryContract
Performs
hasContract
isPartyTo
Policy
BusinessPolicy
definedBy
setsPolicy
HasInstance
Organization
DDB Group
IsInterfaceOf
Service Interface
Delivery
isOutputAt
Information
Type
Customer, Ship Date
isInputAt
Service Operation
RequestDelivery
SOA
Model Type
GroupDispatch
Derived
Artifact Type
HasOperation 66
(C) The Open Group 2011
(C) The Open Group 2003

67. 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

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

69. SOA Governing Processes – DDB Enforce Reduction In Duplication Process
14 April 2018
SOA Governing Processes – DDB Enforce Reduction In Duplication Process
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 UniqueService property
Petition Governance Board for exception to redevelop service
Inform developers of new services and
Requirement for signoff for new services
Compliance
Dispensation
Communication 69
(C) The Open Group 2011
(C) The Open Group 2009 69

70. SOA Governance Vitality Method
14 April 2018
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
UniqueService Properties 70
(C) The Open Group 2011
(C) The Open Group 2009 70

71. 14 April 2018
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
(C) The Open Group 2009 71

72. 14 April 2018
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
(C) The Open Group 2009 72

73. Where to learn more about Open Group Standards
3 February 2011
Where to learn more about Open Group Standards
The Open Group SOA project page:
The Open Group Cloud Computing project page:
TOGAF-SOA “Practical Guide”:
Open Group’s SOA Source Book:
Navigating the Open Standards Landscape Around Architecture paper published jointly with OMG and OASIS:
OSIMM Standard:
Webinar: ?siteurl=opengroupevents&theAction=poprecord&ecFlag=true&recordID=
SOA Governance Framework Standard:
Webinarhttp:// d=22510
SOA Ontology:
SOCCI: wiki/doku.php?id=workgroups:cloud:service_oriented_cloud_computing_infrastructure_project_page 73
(C) The Open Group 2011
(C) The Open Group 2003

74. Thank You! 3 February 2011 3 February 2011 (C) The Open Group 200374
(C) The Open Group 2011
(C) The Open Group 2003
(C) The Open Group 2003 74

75. Where to learn more about S-RAMP
3 February 2011
Where to learn more about S-RAMP
SRAMP – SOA Repository Artifact Model and Protocol
OASIS Technical Committee formed December 2010
S-RAMP client you can access and experiment with
ATOM Publishing Protocol 75
(C) The Open Group 2011
(C) The Open Group 2003

76. How SOA Standards Relate
3 February 2011
How SOA Standards Relate
Semantic model for
Reference
Model
Ontology
Modeling
Languages
Maturity
Models
Language
for
Guides
Used By
Assesses
Reference
Architecture
Reference
Architecture
Reference
Architecture
Reference
Architecture
Foundation
Architecture
Common Systems
Architecture
Industry
Architecture
Organization
Solution
Architecture
Abstract Concrete
Influence and Refine
Navigating the SOA Open Standards Landscape Around Architecture
June 2009 76 76
(C) The Open Group 2011
(C) The Open Group 2003