MTAT Enterprise System Integration. Lecture 12: Service Analysis & Design Part 2: Process and Data-Driven Design

Transcription

1 MTAT 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 2

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? 3

4 Service Analysis and Design Methods Capability-driven methods Steve Jones: Enterprise SOA Adoption Strategies. InfoQ, 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,

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 5

6 Danske Bank: Customer Package Process Customer Create Card Create Account Advisor Create Credit Juni 2003 August 2003 October 2003 December 2003 Marts 2007 Introduction of Customer packages. Word template to collect info Steen Brahe, Danske Bank 6

7 Danske Bank: Customer Package Process Juni 2003 August 2003 October 2003 December 2003 Marts 2007 Backoffice group created Handles the creation process Steen Brahe,

8 Danske Bank: Customer Package Process Juni 2003 August 2003 October 2003 December 2003 Marts 2007 Case Transfer System Automatic validation and transfering Steen Brahe,

9 Danske Bank: Customer Package Process Juni 2003 August 2003 October 2003 December 2003 Marts 2007 Workflow enabled creation process v. 1 Automatic process control, 0% automated activities Steen Brahe,

10 Danske Bank: Customer Package Process Juni 2003 August 2003 October 2003 December 2003 Marts 2007 Workflow v. 6 80% automated activities Steen Brahe,

11 Danske Bank Case: Architecture Human Task Handling Service Executable Business Process (BPEL) A1 A2 A4 A3 Service A1 Service A2 Service A3 Service A4 Service Bus / Container App1: COBOL App2: PL1 App3: Java App4: C# Steen Brahe,

12 SmartEDA: Integrated Land Development Application System in Queensland Government Dept. Mineral Resources EPA Dept. Main Roads Customer Local Authority Land Dept. Permit Request and Tracking Portal SmartEDA Portal Public services Land Development Application Process centric services Land Development Rules Service Cadastral Service Land Dev. Application Data Service Basic Services (data & logiccentric) Rules Engine Geographical Information System Application Database 12

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 13

14 Order Management Scenario (case where items are taken from stock) Make Item(s) Contact Manufacture Sales Check Stock Order Ship Order Add to Stock Ship Order Bill Customer Customer Deliver Invoice Logistics & Warehouse Finance Deliver Order Payment Invoice Supply Logistics Company Suppliers 14

15 Order Management Scenario Level 1 diagram (summarized) Stock Availability Check Stock warehouse Warehouse Management Ship Order Order Management sales Request Quote Make Order Cancel Order Customer customer Deliver Bill Customer Invoice Customer Management finance Manufacture Sales Logistics & Warehouse Finance 15

16 Process-Driven Service Design Steps 1-2. Identifying Process & Actors Supplier External Actor Customer Procurement Service Interface Process we need to support Supplier (Order Management Service) Interface Interface Service Required by Process Warehouse Inventory Control Service Service Required by Process Finance Invoicing Service 16

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

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 18

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 19

20 Step 4. Identify Operations Less obvious provided operations of order management service Cancel order/request order cancellation Modify order/request order modification Check order status 20

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 21

22 Step 4. Identify Operations 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.. 22

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 23

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,

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 25

26 Example: Domain Model A User has a unique username Search by popularity Search by Tag thumbs_up and thumbs_down are the number of thumbs up/down ratings given by users Search by Location (radius, bounded box) POI title : String description : String created : date modified : date thumbs_up : Integer thumbs_down : Integer * owns User username : String 1 owns * * Comment body : String * 1 owns * Rating thumb : RATING Viewcount : Integer 1 lon : float lat : float alt : float 0..1 Location * Tag : String «enumeration» UP DOWN RATING P. Selonen,

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,

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,

29 Example: Resource Model (top-level) P. Selonen,

30 Example: Resource Model (zoomed) 30

31 Example: REST API 31

32 Example REST API (projection) 32

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) 33

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 34