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
Danske Bank: Customer Package Process
Customer Create CardCreate Card
Create AccountCreate Account
Advisor Create CreditCreate CreditBackoffice workers
Juni 2003 August 2003 December 2003October 2003 Marts 2007
Backoffice group createdHandles the creation process
4© Steen Brahe, 2007
Danske Bank: Customer Package Process
Juni 2003 August 2003 December 2003October 2003 Marts 2007
Case Transfer SystemAutomatic validation and transfering
5© Steen Brahe, 2007
Danske Bank: Customer Package Process
Juni 2003 August 2003 December 2003October 2003 Marts 2007
Workflow enabled creation process v. 1Automatic process control, 0% automated activities
6© Steen Brahe, 2007
Danske Bank: Customer Package Process
Customer
ServiceA
Service B
Service C
Customer
XML
Not valid
Advisor Case Transfer System
Backoffice workers
Create CreditCreate Credit
Juni 2003 August 2003 December 2003October 2003 Marts 2007
Workflow v. 680% automated activities
7© Steen Brahe, 2007
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#
8© Steen Brahe, 2007
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
Process-driven service analysis
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
Process-driven service analysis
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.
Process-driven service analysis
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
Create and Issue Invoice
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
Create and Issue 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