MTAT.03.229 Enterppy grise System Integration Lecture 6 ... › 2008 › esi › uploads › Main › lecture6.pdf · service-oriented architecture. This includes Service-oriented

MTAT.03.229Enterprise System Integrationp y g

Lecture 6: Service-Oriented AnalysisLecture 6: Service-Oriented Analysis

Marlon Dumas

marlon . dumas ät ut . ee

SmartEDA: Integrated Land Development Application System in Queensland GovernmentApplication System in Queensland Government

EPACustomerDept. Mineral Resources Dept. Main Roads

Local Authority

Public servicesPermit Request and

Tracking

Portal

SmartEDA Portal

Land Dept.

Local Authority

Process centric servicesLand Development Application

Basic Services(data & logic-

centric)

Land Dev. Application

Data Service

Land Development Rules Service

Cadastral Service

)

Rules Engine

2Application DatabaseGeographical Information System

https://www.smarteda.qld.gov.au/

Danske Bank: Customer Package Process

Juni 2003 August 2003 December 2003October 2003 Marts 2007

Introduction of Customer packages.Word template to collect info

3© Steen Brahe, Danske Bank


Customer Create CardCreate Card

Create AccountCreate Account

Advisor Create CreditCreate CreditBackoffice workers

Email


Backoffice group createdHandles the creation process

4© Steen Brahe, 2007



Case Transfer SystemAutomatic validation and transfering




Workflow enabled creation process v. 1Automatic process control, 0% automated activities



Customer

ServiceA

Service B

Service C

Customer

XML

Not valid

Advisor Case Transfer System

Backoffice workers

Create CreditCreate Credit


Workflow v. 680% automated activities


Danske Bank SOA

Executable Business Process

A2

A1

A3

A4

WSDL A1 WSDL A2 WSDL A3 WSDL A4

Service Bus / Application Containers

App1: COBOL App2: PL1 App3: Java App4: C#


Lifecycle and Roles in an SOAy

DeveloperService &Process

Implementation

Service & ProcessDesign

SolutionArchitect

Tester

Service & Process Analysis

Testing &Deployment

BusinessAnalyst

Operation &Monitoring

Opportunity & Issue

Identification

AnalystAdministrator

9

Service Analysis and Design

Service Analysis: identification and definition of the business services that an organization provides or consumes, internally or externally.Service Design: definition of a set of technical services to support the delivery of business services through IT.Service Analysis Methods:Service Analysis Methods:• Top-down capability-driven method

– Steve Jones: “Enterprise SOA Adoption Strategies”. InfoQ, 2005.Mi f M i B i C bili M i– Microsoft Motion Business-Capability Mapping

• Bottom-up process-driven methods:– Thomas Erl: “Service-Oriented Architecture, Concepts, Technology, and p gy

Design”, Prentice Hall, 2005• Hybrid methods:

– O. Zimmermann et al. Elements of Service-Oriented Analysis and Design,O. Zimmermann et al. Elements of Service Oriented Analysis and Design, IBM, 2004.

– B. Hess et al. Structuring Software Cities - A Multidimensional Approach.

Top-down Service AnalysisPharmaceutical company “Pharmak” has four main areas:

• Sales:– contacts customer– receives order from customer– checks stock– requests for an order to be shipped - if item(s) on the order are available

• Manufacture:k it ( )– makes item(s)

– requests for an order to be shipped - after manufacturing the item(s)

• Logistics & Warehouse:g– adds new item(s) into stock– requests an external company, or internal logistics, to deliver an order to a

customer– receives supplies from suppliers

Top-down Service Analysis• Finance:

– prepares bill for customer– orders raw materials from suppliersorders raw materials from suppliers– receives invoice from suppliers– prepares invoice for customer

The organization interacts with the following partners:• Customer:

organization which buys, and potentially distributes manufactured products• Suppliers:

manufacturers or wholesalers of components/raw materialsmanufacturers or wholesalers of components/raw materials• Logistics Provider:

provides storage and transport services

Top-down Service AnalysisLevel 0 Architecture

Wh t

Customer

What

Who

Why

SuppliersLogistics Company

Top-down Service AnalysisLevel 1 Architecture

• We reason in terms of “capabilities” (what can each area do?)p ( )

• Service analysis is carried out according to each Level 0 element id tifi d b fidentified before,

• Decomposition: the enclosing service confers behavior andDecomposition: the enclosing service confers behavior and management onto those at a lower level:

• As a rule of thumb, a maximum of 8 Level 1 services for each Level 0, with a normal amount around 4.

• See: http://www.infoq.com/presentations/steve-jones-business-soa

Top-down Service AnalysisLevel 1 Architecture: Manufacture

Wh tWhat

Who

Why

Top-down Service AnalysisLevel 2+ Architecture

Drilling down from Level 0 into lower abstraction level elements is agseries of repetitions of the same steps.

Purposes:1. to delve deeper and understand the problem domain more,2 to identify:2. to identify:• Support Services• Shared Services

Top-down Service AnalysisThe Service Map

Process-driven service analysis

1 C1. Collect the documentation related to the business requirements and context of aservice-oriented architecture. This includes

Service-orientedanalysis

Define business requirements

business objects and business processes

2. Identify existing application logic which already covers any requirement

Identify automation

systems

documented in Step 1.

3. Identify service operation candidates and group them into service candidates.

Model candidate services


Starting point: Business Process Models:• a thorough knowledge of the underlying workflow logic is

required,• the scope of business services may vary:

serviceprocess

processstep

sub-process

service

service


Sources from which business services can be derived (cnd)

Deliverables: Task-centric business services (Level 1):Deliverables: Task-centric business services (Level 1):contain a set of operations that relate to a particular task of a process.

Pros• require little analysis effort to be producedrequire little analysis effort to be produced,• meet immediate requirements.

Cons• limited reusability potential: modeling reusable task-centric

business services often requires an initial analysis of multiplebusiness services often requires an initial analysis of multiple business process models in order to identify commonalities.

Process-driven service analysisRailCo has a legacy system for order management and invoice processing specifically built to interact with a major client (“TLS”).Railco intends to make this system more extensible and generic toRailco intends to make this system more extensible and generic to be able to interact with other customers and to improve the performance of their order-to-cash process.

The service analysis is conducted over two internal business processes pitched to work with the B2B solution of TLS:processes, pitched to work with the B2B solution of TLS:

- Invoice Submission Process: sends an invoice to TLS,uses the Invoice Submission Web Serviceuses the Invoice Submission Web Service.

- Order Fulfillment Process: accepts and processes Purchase O d f TLS th O d F lfill t W b S iOrders from TLS, uses the Order Fulfillment Web Service.


Create and Issue Invoice

Start Invoice Submission Order Fulfillment

Export Invoice

Transform Invoice

Receive PO

Start

Validate Invoice

invoice no

Validate PO

PO valid?

no

valid?

time formetadata

check?

Check Metadata

yes

yes

no

Send Notification

yes

Tranform PO

Import PO

Metadata valid?

no

yes

no

Send POto Queue

Import PO

Submit Invoice

Stop

Stop

Process-driven service analysisApplying the framework: Step 3 - Model candidate services

Model candidate DecomposeModel candidate services

Decompose business process

Refine and apply service-orientation

Identify application i ti

Identify operation candidates

Identify service compositions

service operations

C t li ti

Abstract orchestration logic

Revise operation grouping

Create application service candidates

Create service candidates

grouping

Analyze

Revise service compositions

Analyze processing

requirementsRevise operation

grouping

Process-driven service analysis1 – Decompose the business processBreak down the workflow logic in the “most granular”representation of process steps


Start

representation of process steps.

Invoice Submission Process

Export Invoice

Transform Invoice

• Create electronic invoice,• Issue electronic invoice,• Export electronic invoice to network folder,

Validate Invoice

invoice noExport electronic invoice to network folder,• Poll network folder,• Retrieve electronic invoice,• Transform electronic invoice to XML document

valid?

time formetadata

check?

Check Metadata

yes

yes

noTransform electronic invoice to XML document,• Check validity of invoice document. If valid, end,• Check if it is time to verify TLS metadata,• If required perform metadata check If the check fails end

Metadata valid?

no

yes

no

• If required, perform metadata check. If the check fails, end.Submit Invoice

Stop

Process-driven service analysis2 – Identify business service operation candidatesSome steps can be easily identified as not belonging to the potential logic to be encapsulated in a service candidate (e gpotential logic to be encapsulated in a service candidate (e.g. activities performed manually or by some legacy logic).

Invoice Submission ProcessInvoice Submission Process• Create electronic invoice, Manual step (accounting clerk)

• Issue electronic invoice, Manual step (accounting clerk)

E l i i i k f ld• Export electronic invoice to network folder, Custom developed component (legacy logic)

• Poll network folder, Performed by a custom developed component

• Retrieve electronic invoice, Performed by a custom developed component

• Transform electronic invoice to XML document, Performed by a custom component

• Check validity of invoice document. If valid, end, Performed by Invoice Submission WS

• Check if it is time to verify TLS metadata, Performed by the Invoice Submission WS

• If required, perform metadata check. Performed by the Invoice Submission WS

If the check fails, end.

Could become a separate service candidate.Could become part of a generic service candidate. Cou d beco e a sepa ate se ce ca d dateCou d beco e pa t o a ge e c se ce ca d date

Process-driven service analysis3 – Abstract orchestration logicIdentify the parts of the processing logic that this layer would potentially abstract (e g business rules conditional / exception /potentially abstract (e.g. business rules, conditional / exception / sequence logic).

The workflow logic of separate process service candidates, derived from the Invoice Submission and Order Fulfillment processes would include the following conditions:g

• if the invoice document is valid, proceed with the metadata check,• else, end process,, p ,• if the interval period for performing a metadata check has completed, perform the

metadata check,else skip the metadata check• else, skip the metadata check.

• if the PO document is valid, transform the PO document,• else, end process.

Process-driven service analysis4 – Create business service candidates• The identified steps are grouped by logical context, with each group representing

a service candidate.• The context depends on the type of the business services chosen.

InvoiceProcessing

MetadataChecking

Process-driven service analysis5 – Refine and apply principles of service-orientationRefine the candidates according to the principles of reusability and autonomy

InvoiceProcessing

PollingNotification

autonomy.

if documents arrive forwhich there are subscribers,issue notifications

Validate invoice

TransformAccount Documents

MetadataCh kiAccount DocumentsChecking

Process-driven service analysis6 – Identify candidate service compositionsIdentify the set of most common scenarios that can take place, in order to:• evaluate the appropriateness of the candidate contexts• evaluate the appropriateness of the candidate contexts,• identify potential service composition,• highlight any missing workflow logic.

Core Business Services

Task-centric Business Services

Technical Support Services shared across different domains (Finance,across different domains (Finance,

Sales)

Process-driven service analysis7 – Revise business service operation groupingRevisit contexts and operation candidates. New services may be createdcreated.For complex cases, further steps can be taken:8 – Analyze application processing requirements8 Analyze application processing requirements

9 – Identify application service operation candidates

10 – Create application service candidates10 Create application service candidates

11 – Revise candidate service compositions

12 – Revise application service operation groupingpp p g p g

(Optional) Keep an inventory of service candidates

Process-driven service analysisThe reverse of the medal: Percolating Processes (according to S. Jones)Organizations start with a detailed Process Map and then try to fit this into a SOA:SOA:• processes become the dominant feature: POA rather than SOA,• task-centric business services (Level 1) are tightly bound to the context of a

i l b diffi lt i ibl t hsingle process → become difficult or impossible to change,• fine grained services (Level 2+) proliferate and become difficult to manage.

Effects• the system slowly or quickly stagnates,• new solutions are built on top of the existing ones due to the lack of• new solutions are built on top of the existing ones, due to the lack of

reusability (process-oriented system treated as legacy application).

Meet-in-the-Middle Approach to SOA1. Create the Service Interaction Map (SIM) independently of the Process Map:

this provides the structure for:– breaking down the processes,– creating a clear hierarchy of use.

2. Overlay the SIM onto the Process Map, to understand potential cuts.y p, p3. Refactor the current solution by attacking the major inflexibilities.

Export Invoice

Transform Invoice


Start

Validate PO

PO valid?

Receive PO

Start

no

yes

InvoiceProcessing

LegacySystem

export electronic invoiceto network folder

import electronic PO intoaccouting system

poll network folder for invoice

retrieve electronic invoice

transform electronic invoice to XML

Manufacture Sales

Research & Development Supplies In

Quality Control Regulatory Approval

Order Management Contract Management

...

Validate Invoice

invoicevalid?

time formetadata

check?

Check Metadata

Submit

Metadata valid?

no

yes

yes

no

yes

no

Send Notification

Send POto Queue

Stop

Tranform PO

Import PO

MetadataChecking

POProcessing

send PO to accountingclerk’s work queue

document

check validity of invoicedocument ; if valid, end process

check if it is time to verify TLS metadata

if required, perform metadata check; if metadata check fails ,end process

receive PO document

validate PO document

if PO document is invalid , sendrejection notification and end process

Logistics & Warehouse Finance

Logistics Management Stock Forecasting

Stock Control

Warehouse Management

Stock Availability

Product Manufacture Packaging

Order Supplies ...

...

Invoice

Stop

transform PO XML document into native electronic PO format

built independentlyalready existing

SynthesisService Analysis

Identification and definition of the services an organization wants to gprovide or that are involved in a particular project;Service: a discreet domain of control that contains a collection of

tasks to achieve related goalstasks to achieve related goals.Deliverable: Service Interaction Map (SIM).Approaches: pp

– Top-down service decomposition.– Bottom-up: identify services from business process

d lmodels– Meet-in-the-middle.

ReminderReminder

• Lecture next week will be at 10:15 in room 305.• Practical session at 12:15 in room 203

34

References and acknowledgmentsReferences and acknowledgments• Slides about the Danske Bank case study are from a talk by

St B hSteen Brahe: http://brahe.org/MamboPHD/

• Example used for top-down service analysis inspired by:St J “E t i SOA Ad ti St t i ” I f Q 2005– Steve Jones: “Enterprise SOA Adoption Strategies”. InfoQ, 2005.

• Example of process-driven service analysis inspired by:T Erl: “Service Oriented Architecture: Concepts Technology and– T. Erl: Service-Oriented Architecture: Concepts, Technology, and Design”, Prentice Hall, 2005.

• Reading of the week:g– E.S.K. Yu and J. Mylopoulos: Modelling Organizational Issues for

Enterprise Integration. In Proceedings of the International Conference on Enterprise Integration and Modelling Technology Turin Italyon Enterprise Integration and Modelling Technology, Turin, Italy, October 1997, pp. 529-538

35