ESOA

Enterprise Service
Oriented Architecture
 

By – [NAME]
[PROJECT NAME] – SAP Technical Architecture
Version: 0.2
Security Classification: Confidential
Requirements

This document aims to define the solution to apply the following

design principle in [PROJECT NAME] Programme:

[CLIENT] intends to move towards a SOA-based architecture using:

XI (PI) to provide the integration layer; and
the Enterprise Service Repository to define appropriate services.
… all Deliverables provided by the Service Provider pursuant to this Work Order must adopt
this approach unless otherwise advised by [CLIENT]. Any alternatives will be identified and
accepted on a case-by-case basis.

Enterprise Service Oriented Architecture [REQUIREMENTS CLARIFICATION] STATUS:

Draft
VERSION: 0.2
[PROJECT NAME]/1(CB_40) Page 2
Contents

• What is SOA?

• Why a service oriented approach?

• SAP’s SOA Approach: eSOA

• Adapting eSOA at [PROJECT NAME]

Enterprise Service Oriented Architecture [REQUIREMENTS CLARIFICATION] STATUS:

Draft
VERSION: 0.2
[PROJECT NAME]/1(CB_40) Page 3
What is a Service Oriented Architecture?

[SYSTEM INTEGRATOR] defines a Service

Oriented Architecture (SOA) as an
architecture that defines how separate
business functions implemented by
autonomous systems interoperate to
execute a business process.

Services are shareable software modules for organizing and processing information in
support of a business process.

SOAs:
Promote a focus on business value and processes rather than underlying technology.
Are forward enabling and allow easier reuse of existing functionalities.
Enable faster, low-cost, low-risk and platform-neutral system integration and development.

Enterprise Service Oriented Architecture [REQUIREMENTS CLARIFICATION] STATUS:

Draft
VERSION: 0.2
[PROJECT NAME]/1(CB_40) Page 4
Contents

• What is SOA?

• Why a service oriented approach?

• SAP’s view on SOA: eSOA

• Adapting eSOA at [PROJECT NAME]

Enterprise Service Oriented Architecture [REQUIREMENTS CLARIFICATION] STATUS:

Draft
VERSION: 0.2
[PROJECT NAME]/1(CB_40) Page 5
Key SOA differentiators

the attention to mirroring actual business processes

services execute complete business transactions rather than application functions
the focus is on services to be provided rather than on their implementation
the emphasis on interoperability
through assemblage or encapsulation of business functionalities
the service location transparency (split in between service consumers and providers)
the standards-based implementation via Web Services

Enterprise Service Oriented Architecture [REQUIREMENTS CLARIFICATION] STATUS:

Draft
VERSION: 0.2
[PROJECT NAME]/1(CB_40) Page 6
Process Centric and Loosely Coupled Design

Service
•The Consumer, the Provider and the Directory roles Consumer
are clearly separated XML
SOAP 2

Find
•Services generally exchange XML documents in a Bind
location, protocol, and platform independent manner Service 3
Directory XML
SOAP
•Provision of services is decoupled from the
consumption of services XML 1 Publish
SOAP
Service
•SOAs are based upon open standards e.g. XML and Provider
SOAP
1 Service
2 registration
Service location
3 Service consumption

Enterprise Service Oriented Architecture [REQUIREMENTS CLARIFICATION] STATUS:

Draft
VERSION: 0.2
[PROJECT NAME]/1(CB_40) Page 7
Traditional Architectures

• Integration partners
need to agree on
System A System B programming language,
object model, Application
Programming Server, etc.
Language

Database Agreements Database

Object
Model
Operating Schema Operating • Any new partner needs
System System to have the same stack or
Application build an ad-hoc “adapter”
Server
to interface with it.

Enterprise Service Oriented Architecture [REQUIREMENTS CLARIFICATION] STATUS:

Draft
VERSION: 0.2
[PROJECT NAME]/1(CB_40) Page 8
 Service Oriented Architectures

• Integration points are

defined only by the data
System A System B schema and the process
agreements
Programming Programming
Language Language

Database Agreements Database

Object Object
Model Model
Operating Schema Operating
System System
Application
• Any new partner can
Server Application integrate using standard
Server technologies regardless
of their internal
technology stack

Move from a tightly coupled solution to a loosely coupled, interoperable solution

Enterprise Service Oriented Architecture [REQUIREMENTS CLARIFICATION] STATUS:

Draft
VERSION: 0.2
[PROJECT NAME]/1(CB_40) Page 9
SOAs require an approach shift

Distributed Component Service Oriented

Architectures Architectures
Functionality oriented Process oriented
Designed to last Designed to change
Long development cycle Interactive development & deployment

Cost centered Business centered

Application block Services orchestration
Tightly coupled Loosely coupled
Homogeneous technology Heterogeneous technology
Object oriented Message oriented
Known Implementation Abstraction

Enterprise Service Oriented Architecture [REQUIREMENTS CLARIFICATION] STATUS:

Draft
VERSION: 0.2
[PROJECT NAME]/1(CB_40) Page 10
Contents

• What is SOA?

• Why a service oriented approach?

• SAP’s SOA Approach: eSOA

• Adapting eSOA at [PROJECT NAME]

Enterprise Service Oriented Architecture [REQUIREMENTS CLARIFICATION] STATUS:

Draft
VERSION: 0.2
[PROJECT NAME]/1(CB_40) Page 11
What is eSOA?

• eSOA is a business driven software architecture that increases

adaptability, flexibility, openness and cost-efficiency

With enterprise SOA, you can:

Create new applications on top of existing enterprise solutions
Automate new or existing business processes
Increase the value of your current systems
Improve the ability to link other applications to SAP

Enterprise Service Oriented Architecture [REQUIREMENTS CLARIFICATION] STATUS:

Draft
VERSION: 0.2
[PROJECT NAME]/1(CB_40) Page 12
 Web Services vs Enterprise Services
Web Services
• Open standard for system interaction, independent of
technical architecture
• Self-contained, self-describing, modular functionality
• Mostly used to provide functionality of one given system

Enterprise Services
• Portfolio of pre-built web services that provide business functionality
• Have enterprise quality in scalability, robustness, security,
manageability, supportability, etc…
• Published in a central services repository (ESR)
• Example “cancel order”: triggers a whole series of activities such as
take the order out of production, do not order the needed material from
the suppliers, do not invoice to customer, etc…

Enterprise Service Oriented Architecture [REQUIREMENTS CLARIFICATION] STATUS:

Draft
VERSION: 0.2
[PROJECT NAME]/1(CB_40) Page 13
User Interface

Composition Environment

Process Integration

Application Services

Enterprise Service Oriented Architecture [REQUIREMENTS CLARIFICATION] STATUS:

Draft
VERSION: 0.2
[PROJECT NAME]/1(CB_40) Page 14
Realizing SAP eSOA

• SAP Netweaver 7.1 as a Business Process Platform

• SAP Netweaver 7.1 Composition Environment (CE) to create Composite

Applications

• Enterprise Service (ES) bundles delivered with SAP Business Suite

Enhancement Packages (EhP) are imported into ESR contains ready to use
services for SAP solutions

• ES Workplace to explore enterprise services

delivered by SAP. Search in Solution Maps,
ES Bundles or by Index

Enterprise Service Oriented Architecture [REQUIREMENTS CLARIFICATION] STATUS:

Draft
VERSION: 0.2
[PROJECT NAME]/1(CB_40) Page 15
Enterprise Service Oriented Architecture [REQUIREMENTS CLARIFICATION] STATUS:
Draft
VERSION: 0.2
[PROJECT NAME]/1(CB_40) Page 16
Contents

• What is SOA?

• Why a service oriented approach?

• SAP’s SOA Approach: eSOA

• Adapting eSOA at [PROJECT NAME]

Enterprise Service Oriented Architecture [REQUIREMENTS CLARIFICATION] STATUS:

Draft
VERSION: 0.2
[PROJECT NAME]/1(CB_40) Page 17
Assumptions
• [PROJECT NAME] aims to deliver a new operating model for [CLIENT] Customer Branch in
the UK and this requires significant changes in the IT landscape as well

• Core operational requirements of the programme will be technically realized with SAP products
such as SAP IS-Utilities and SAP CRM but the programme will also incorporate specific solutions
from other software vendors such as AMTSybex, Opentext, KOFAX, Click Software, QAS, etc…

• As a primary difference between custom and packaged solutions, most of the technical
realization can be achieved by configuring the packaged software (in this case SAP systems) and
do not require bespoke development. This is also valid for some integration scenarios where an
out-of-the-box integration is provided between systems (e.g. integration between QAS and SAP)

• Process steps in Business Process Modelling (in ARIS) will be mapped to the out-of-the-box
SAP functionality where possible (e.g. a process step will be mapped to an SAP transaction).

• Where the requirement can not be met with configuration of the systems, a development
requirement will be recorded in RICEF (Reports, Interfaces, Conversions, Enhancements, Forms)
inventory. Any exceptions to this will be evaluated on a case by case basis

Enterprise Service Oriented Architecture [REQUIREMENTS CLARIFICATION] STATUS:

Draft
VERSION: 0.2
[PROJECT NAME]/1(CB_40) Page 18
SOA Infrastructure @ [PROJECT NAME] - Overview

User Interfaces (SAP Netweaver Portal, Adobe Forms, SAPGUI,etc…)

Composition Layer (Visual Composer, Guided Procedures, etc…)

Process Integration

Enterprise
Enterprise Service Bus Services Repository

Application Layer

non-SAP/Legacy
Applications MQ Series
SAP Business Applications (QAS, DTS,
(CRM, IS-U, etc…) Click, etc…)

Enterprise Service Oriented Architecture [REQUIREMENTS CLARIFICATION] STATUS:

Draft
VERSION: 0.2
[PROJECT NAME]/1(CB_40) Page 19
Key Design Principles

Use Standard (SAP) functionality wherever possible

Design for Service Reusability & Composition
Use Enterprise Services Repository (ESR) as the central repository & registry for enterprise
services
Use composition tools where appropriate
Design for Loose Coupling
Use SAP PI as the Enterprise Service Bus where appropriate (refer to Integration
[REQUIREMENTS CLARIFICATION]paper for more details on SAP PI usage types)
Design for Orchestration
Use SAP Netweaver Business Process Management (BPM) tools for task-automation where
appropriate. This includes SAP Workflow, Guided Procedures and ccBPM
Design for Data Abstraction
Use pre-defined SAP data models and semantics
Where the integration of different data types from different systems is required for the new
service, use Global Data Types provided by SAP

Enterprise Service Oriented Architecture [REQUIREMENTS CLARIFICATION] STATUS:

Draft
VERSION: 0.2
[PROJECT NAME]/1(CB_40) Page 20
SOA Governance – Basic Principles
• Identify and align business and technology goals

• Identify tactical service implementations to support the business case

• Manage journey issues & risks

• Create service identification procedures for identifying services and service lifecycle management.

• Identify responsible parties both from business and IT departments

• Identify architecture enhancements required across layers to support SOA (e.g. Enterprise Services
Repository, Enterprise Service Bus)

• Identify Enterprise Services standards (e.g. WS-Security and other standards)

• Define basic metrics to measure SOA success. e.g. :

Service Utilization
Governance cost
Cost to build a new service
Elapsed time to build a service

Enterprise Service Oriented Architecture [REQUIREMENTS CLARIFICATION] STATUS:

Draft
VERSION: 0.2
[PROJECT NAME]/1(CB_40) Page 21
Web Services – Primary Technology Standards

Service Description Discovery and Publication

WSDL UDDI

Data Exchange Protocols

SOAP

Data Representation
XML

Network and Transport Protocols

TCP/IP, HTTP, HTTPS, FTP, SMTP

Enterprise Service Oriented Architecture [REQUIREMENTS CLARIFICATION] STATUS:

Draft
VERSION: 0.2
[PROJECT NAME]/1(CB_40) Page 22
Web Services – Emerging Standards
Business Performance Management
WS Distributed Management, WS-Manageability, WS-Provisioning

WS-Federation, WS-Privacy, WS-Policy, WS-Federation, WS-SAML, XML

WS-Security, WS-Secure Conversations, WS-Security Policy, WS-Trust,
Business Process Orchestration
BPEL4WS, BPML, BPMN, BPQL, WSCI, WS-CDL

Messaging

WS-Atomic Transaction, WS-Coordination, WS Business

WS Addressing, SOAP MTOM, WS-Reliable Messaging

Activity, WS-CAF(WS-CTX, WS-CF, WS-TXM)

Digital Signature, XML Encryption

Discovery and Publication

Quality of Service
Service Description UDDI, WS-Inspection,

WSEL, WSIL
WSDL WS-Meta-data Exchange,

Security
WS-Resource Framework

Transactions

Presentation
WSRP
Data Exchange Protocols
SOAP

Data Representation
XML

Network and Transport Protocols

TCP/IP, HTTP, HTTPS, FTP, SMTP

Enterprise Service Oriented Architecture [REQUIREMENTS CLARIFICATION] STATUS:

Draft
VERSION: 0.2
[PROJECT NAME]/1(CB_40) Page 23
Service Identification - Decision Tree
Standard functionality exist?
Business Process Configure relevant
Modelling in ARIS systems
Yes
No

Development
Requirements
Recorded SERVICE CRITERIA
in RICEF
a) Expose common functionality that is required by
multiple systems

OR
Search pre-delivered Functionality is distributed throughout disparate
services Systems,

b) Likely to change Frequently,

c) Add value to business and reduce costs

Apply
Service Criteria
to Interface
and Enhancements

Design and implement No Yes Design and Implement

using ABAP/Java/etc… using a new service
Service Criteria met?

Enterprise Service Oriented Architecture [REQUIREMENTS CLARIFICATION] STATUS:

Draft
VERSION: 0.2
[PROJECT NAME]/1(CB_40) Page 24
Service Identification Process

Business Processes Record Search Evaluate Design &

requirement modelled in developments existing Service Implement
ARIS in RICEF services Enablement Service

SERVICE CRITERIA
Reflection of Interfaces and This can be:
business Extensions are Expose common
processes potential service SAP ES functionality that is
as a model candidates required by multiple
and process flow OR systems

OR
Pre-delivered
services by Functionality is distributed
other vendors throughout disparate
Mapping of process such as QAS Systems,
steps to systems help
Identify missing Likely to change
functions Frequently,

Add value to business

and reduce costs

Enterprise Service Oriented Architecture [REQUIREMENTS CLARIFICATION] STATUS:

Draft
VERSION: 0.2
[PROJECT NAME]/1(CB_40) Page 25
Conclusions
• A stepwise adoption of eSOA will be followed
SOA is a journey and the level of adoption should grow in time
Think big, start small
• [PROJECT NAME] application landscape allows eSOA enablement
ARIS for Netweaver for Business Process Modelling
SAP PI as ESB and ESR
Visual Composer & Guided Procedures for Composition
SAP Netweaver Portal & Adobe Interactive Forms for User Interaction
• A service enablement will not be considered where the required functionality
can be met by configuring existing systems – breaking the code is not best
practice!
• Each interface and extension in RICEF inventory is a potential candidate to
be a service
• Once identified, services will be designed, implemented and tested using a
set of standards and procedures details of which will be defined during the
detailed design

Enterprise Service Oriented Architecture [REQUIREMENTS CLARIFICATION] STATUS:

Draft
VERSION: 0.2
[PROJECT NAME]/1(CB_40) Page 26
APPENDIX - Glossary

• XI (PI): Exchange Infrastructure (Process Integration). SOA Middleware product from SAP
• Enterprise Service Repository (ESR): Central Repository where enterprise services, business objects,
processes and their metadata is store. It’s part of SAP Netweaver platform and also includes a UDDI v3.0 based
service registry
• Enterprise Service Bus (ESB): ESB refers to a software architecture construct. This construct is typically
implemented by technologies found in a category of middleware infrastructure products, usually based on
recognized standards, which provide foundational services for more complex architectures via an event-driven
and standards-based messaging engine (the bus).
• Composite Applications (CA): CAs are assembled using re-usable services from existing standards and
custom-built applications that may reside within or across enterprise boundaries
• Composition Environment (CE): SAP Netweaver based runtime platform and infrastructure for designing,
deploying and managing composite applications.
• Enhancement Package (EhP): Enhancement packages represent the new SAP approach to accelerate the
delivery of new functionalities to customers via optional packages. These optional enhancement packages can
be configured in a completely modular fashion, by switching on only the desired features.
• Core Components Technical Specification (CCTS): CCTS is a specification driven by UN/CEFACT
council. It defines meta models and rules necessary for describing the structure and contents of conceptual and
physical/logical data models, process models, and information exchange models.
• Global Data Types (GDTs): GDTs are data types based on CCTS. Basically the advantage of the CCTS
methodology is that it allows for definition of generic data types and data types for a specific vertical industry.

Enterprise Service Oriented Architecture [REQUIREMENTS CLARIFICATION] STATUS:

Draft
VERSION: 0.2
[PROJECT NAME]/1(CB_40) Page 27
Control information
Product History
Version Date Author Comments
0.1 29/04/08 [NAME] 1st Draft
0.2 06/05/08 [NAME] Changes after 1st review

Approval
Approver Role Signature
[NAME] [CLIENT] Programme Technical Architect
[NAME] [CLIENT] Enterprise Architect
[NAME] [CLIENT] Programme Technical Architect
[NAME] [CLIENT] Technology & Logistics Lead
[NAME] [CLIENT] Programme SAP Technical Architect

[NAME] [SYSTEM INTEGRATOR] Technology Delivery Lead

[NAME] [SYSTEM INTEGRATOR] Lead Solution Architect

[NAME]
Enterprise Service Oriented Architecture [SYSTEM INTEGRATOR]
[REQUIREMENTS CLARIFICATION] Technical Design Authority STATUS:
Draft
VERSION: 0.2
[PROJECT NAME]/1(CB_40) Page 28