MTAT.03.229 Enterprise System Integration Lecture 12 ... · Enterprise System Integration Lecture 12: ... Order Management Scenario ... behavior as a statechart diagram where

MTAT.03.229 Enterprise System Integration

Lecture 12: Service Analysis & Design Part 2: Process and Data-Driven Design

Marlon Dumas

marlon . dumas ät ut . ee

2

Service Analysis & Design

•  Service Analysis: identification and definition of the business services that an organization provides or consumes, internally or externally. –  Identify and define business-level services, their context

and their interactions •  Service Design: identification and definition of

technical services to support the delivery of business services. –  Identify and define technical-level services, operations,

inputs & outputs

3

Decomposing Information Systems

1.  Functional or capability-driven decomposition •  Which business functions, capabilities or specialization

perform work in the organization (organizational chart) 2.  Process-driven decomposition

•  Which chains of activities create value to the organization?

3.  Data-driven decomposition •  What information is stored & circulates in the

organization?

4

Service Analysis and Design Methods

Capability-driven methods •  Steve Jones: Enterprise SOA Adoption Strategies. InfoQ, 2005. •  Microsoft Motion Business-Capability Mapping

Process-driven methods •  Thomas Erl: “Service-Oriented Architecture, Concepts, Technology, and Design”,

Prentice Hall, 2005

Data-driven methods •  Petri Selonen: From Requirements to a RESTful Web Service. In REST: From

Research to Practice, Springer, 2011

Hybrid methods •  Zimmermann et al. Elements of Service-Oriented Analysis and Design. IBM, 2004

5

Examples of Process-Driven Service Design

•  Danske Bank: Customer Package Process –  Steen Brahe: BPM on Top of SOA: Experiences from

the Financial Industry. Proc. of BPM’2007 •  SmartEDA: Integrated Land Development

Application System in Queensland Government –  https://www.smarteda.qld.gov.au/

6

Danske Bank: Customer Package Process

Customer

Advisor

Create CardCreate Card

Create AccountCreate Account

Create CreditCreate Credit

Juni 2003 August 2003 December 2003 October 2003 Marts 2007

Introduction of Customer packages. Word template to collect info

© Steen Brahe, Danske Bank

7



Backoffice group created Handles the creation process

© Steen Brahe, 2007

8



Case Transfer System Automatic validation and transfering


9



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


10



Workflow v. 6 80% automated activities


11

Danske Bank Case: Architecture

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

Service Bus / Container

Service A1 Service A2 Service A3 Service A4

Executable Business Process (BPEL)

A1

A3

A2 A4

Human Task Handling Service


12

SmartEDA: Integrated Land Development Application System in Queensland Government

Public services

Basic Services(data & logic-

centric)

Process centric services

Permit Request and

Tracking

Portal

SmartEDA Portal

Land Dept.

Land Development Application

Land Dev. Application

Data Service

Land Development Rules Service

Application Database

Rules Engine

Cadastral Service

Geographical Information System

EPACustomerDept. Mineral Resources Dept. Main Roads

Local Authority

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

13

Process-Driven Service Design

1.  Identify which process(es) need to be supported 2.  Identify actors (cf. capability-driven analysis)

–  Distinguish external systems, internal systems (services)

3.  Capture each process (e.g. as a process model) 4.  Analyze tasks/events in process model to identify:

–  Atomic interactions (operations) that the process should provide

–  Atomic interactions (operations) that the process requires from other systems

14

Customer

SuppliersLogistics Company

MakeItem(s)

Ship Order Add to StockShip Order Bill Customer

Invoice

Invoice

PaymentOrder

Supply

Deliver

Deliver

Contact

OrderCheck Stock OrderCheck Stock

Customer

Manufacture Sales

Logistics & Warehouse Finance

Deliver

Ship Order

Invoice

Bill Customer

Order Management Scenario (case where items are taken from stock)

15

Customer

Warehouse Management

Check Stock

Make Order

Request Quote

Cancel Order

Order ManagementShip Order

Stock Availability

Customer Management

Bill Customer

InvoiceDeliver

sales

warehouse

customer

finance Manufacture

Sales

Logistics & Warehouse

Finance

Order Management Scenario Level 1 diagram (summarized)

16

Supplier

CustomerProcurement Service

Warehouse Inventory Control

Service

FinanceInvoicing Service

Inte

rface Inte

rface

Inte

rface

Supplier(Order Management Service)

Process-Driven Service Design Steps 1-2. Identifying Process & Actors

Process we need to support

Service Required by Process

Service Required by Process

External Actor

17

Process-Driven Service Design 3. Capturing the Order Management Process

18

Step 4. Identify operations (Order Management Service)

Provided operations (to customer) •  Receive RQF •  Receive order Required operations •  From inventory control

–  Check stock availability –  Request order shipment

•  Invoicing –  Request invoicing

•  From

19

Step 4. Identify Operations

Order Management •  RFQ •  Place order

Inventory Management •  Check stock availability •  Request shipment

Invoicing •  Request invoicing

Customer •  Receive RFQ response •  Receive invoice •  Receive shipment

notification

20


•  Less obvious provided operations of order management service –  Cancel order/request order cancellation –  Modify order/request order modification –  Check order status – …

21

Step 4. Identify operations

Less obvious required operations •  To prepare quote

–  Retrieve price list –  Retrieve customer data (contractual terms)

•  To prepare shipment order –  Retrieve customer delivery data

•  To prepare invoice request –  Retrieve customer invoicing data

22


Order Management • RFQ • Place order • Request order cancel. • Check order status • …

Inventory Management • Check stock availability • Request shipment

Invoicing • Request invoicing

Customer • Receive RFQ response • Receive invoice • Receive shipment notification

Catalogue (Price List) • Retrieve price

CRM • Retrieve contract terms? • Retrieve invoicing address • Retrieve shipment address •  ..

23

Process-Driven Design Drawbacks and Limitations

•  Some services remain coarse-grained –  Cf. for example order management service or CRM

service – lots of operations, can we break down? •  How complete is the design?

–  Did we forget something in the order management service? How do we check completeness?

•  Evolutions –  Processes change frequently, so service design has to

follow up

24

Data-Driven Service Design

•  Suitable for RESTful service design •  Starts from a data model •  Key entities in model become “resources” •  CRUD framework used to identify operations •  Sample method (must read):

–  Petri Selonen: From Requirements to a RESTful Web Service. In REST: From Research to Practice, Springer, 2011

25

Data-Driven Service Design

1.  Capture domain model –  High-level data model

2.  Refine domain model into resource model –  Identify resources of different types and hypermedia

relations 3.  Derive REST API

–  Use CRUD framework

26

Example: Domain Model

title : Stringdescription : Stringcreated : datemodified : datethumbs_up : Integerthumbs_down : Integer

POI

Viewcount : Integer

username : String

User

Tag : Stringlon : floatlat : floatalt : float

LocationDOWNUP

«enumeration»

RATING

body : String

Comment

thumb : RATING

Rating

Search by Location (radius, bounded box)

thumbs_up and thumbs_down are the number of thumbs up/down ratings given by users

Search by popularity

Search by Tag

A User has a unique username

*1

owns

*

0..1

owns

*

1

*10..1

owns

*

1

*

© P. Selonen, 2011

27

Deriving Resource Model: Principles

•  By default, classes become <<item>> resources with a URI and representation.

•  Attributes of classes become attributes of respective <<item>> resources and manifest themselves as resource representations.

•  By default, associations become <<ref>> associations between resources that appear as links in the representations. Bidirectional associations are represented as two directed <<ref>> associations.

•  Composite associations become <<sub>> associations between resources.

© P. Selonen, 2011

28

Deriving Resource Model: Principles

•  Associations representing collections become <<container>> resources containing <<item>> resources.

•  “Main entity” becomes “root” of the application •  Queries (e.g. filters) become “projections” over

container resources •  Constraints may be added in the resource

model, e.g. <<readOnly>>

© P. Selonen, 2011

29

Example: Resource Model (top-level)

© P. Selonen, 2011

30

Example: Resource Model (zoomed)

31

Example: REST API

32

Example REST API (projection)

33

Beyond Resource Models: Resource Statechart Diagrams

•  Resource models focus on data •  When a resource has a non-trivial lifecycle (e.g.

a PO), it may be useful to also model its behavior as a statechart diagram where transitions correspond to possible operations (URI + HTTP verb)

34

Summary

•  Service analysis and design methods allow us to go all the way from business models to service API designs

•  We have seen how to chain a capability-driven method with a process-driven and a data-driven method for service analysis and design

Documents

MTAT.03.229 Enterprise System Integration Lecture 12 ... · Enterprise System Integration Lecture 12: ... Order Management Scenario ... behavior as a statechart diagram where