mtat.03.229 enterprise system integration lecture 7
TRANSCRIPT
MTAT.03.229 Enterprise System Integration
Lecture 7: Service-Oriented Analysis
Marlon Dumas
marlon . dumas ät ut . ee
2
Lifecycle and Roles in an SOA
Service Implementation
Service Analysis
Service Design
Testing & Deployment
Operation & Monitoring
Opportunity & Issue
Identification
Business Analyst
Developer
Tester
Administrator
Solution Architect
Service Analysis: identification and definition of the business services that an organization provides or consumes, internally or externally. Service Design: identification and definition of technical services to support the delivery of business services through IT. Service Analysis Methods: • Top-down capability-driven method
– Steve Jones: “Enterprise SOA Adoption Strategies”. InfoQ, 2005. – Microsoft Motion Business-Capability Mapping
• Bottom-up process-driven methods: – Thomas Erl: “Service-Oriented Architecture, Concepts, Technology, and
Design”, Prentice Hall, 2005 • Hybrid methods:
– 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 Analysis
Top-down Service Analysis Four step framework
WHAT
WHO
WHY
HOW
definition of the services scope: what the services are
external actors driving or interacting with the services
reasons of the service-to-service and service-to-actor interactions
details of services to be delivered by the IT team
Services
Actors
Reasons of the Interactions
Design & Implementation of Services
Top-down Service Analysis Service: “A discrete domain of control where a collection of tasks are performed to achieve a goal. A service is to represent what the business does and to place boundaries which all parties agree on.” Actor • Consumer (person, system or service) of a service. • Actors are external to the services, rather than being the internal
objectives of those services. Interaction
The key element in adding the interactions is to understand “why” various services and actors interact. An interaction can be: • physical • electronic: manual / semi-manual / automated
Top-down Service Analysis The framework is applied at increasingly finer levels of granularity
Level 0
• Definition of the core services to the business domain.
Level 1
• Decomposition of the Level 0 model into finer-grained services for each core service.
Level 2+
• Further refinements of the previous levels, defining support and shared services integrating and complementing the services already defined.
Top-down Service Analysis Pharmaceutical 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: – makes item(s) – requests for an order to be shipped - after manufacturing the item(s)
• Logistics & Warehouse: – 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 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 materials • Logistics Provider: provides storage and transport services
Top-down Service Analysis Level 0 Architecture
What
Who
Why
Level 1 Architecture
• We reason in terms of “capabilities” (what can each area do?)
• Service analysis is carried out according to each Level 0 element identified before
• As a rule of thumb, a maximum of 8 Level 1 services for each Level 0, with a normal amount around 4.
Top-down Service Analysis
Top-down Service Analysis Level 1 Architecture: Manufacture
What
Who
Why
Level 2+ Architecture
Drilling down from Level 0 into lower abstraction level elements is a series of repetitions of the same steps.
Purposes: 1. to delve deeper and understand the problem domain more, 2. to identify: • Support Services • Shared Services
Top-down Service Analysis
Top-down Service Analysis Level 2+ Architecture
Support Services
• Technology systems or business units that provide supporting functions necessary for the IT system to be delivered, e.g.
Business Support Services (e.g. HR, Desktop Support): Elements required only for the business to operate, not for the
business operation of the system.
Technical Support Services (e.g. hosting provider, printing service): Technical system that provides support to a business function, rather than being the specific business function themselves.
Top-down Service Analysis Level 2+ Architecture: Support Services
Technical Support Services: Printing, OCR Business Support Service: Human Resources
Top-down Service Analysis Level 2+: Shared Support Services
Business Support Service shared within the same domain (Manufacture)
Technical Support Service shared across different domains (Manufacture, Finance…)
Top-down Service Analysis The Service Map
Process-driven service analysis
1. Collect the documentation related to the business requirements and context of a service-oriented architecture. This includes business objects and business processes
2. Identify existing application logic which already covers any requirement documented in Step 1.
3. Identify service operation candidates
and group them into service candidates.
Starting point: Business Process Models: • a thorough knowledge of the underlying workflow logic is
required, • the scope of business services may vary:
Process-driven service analysis
Sources from which business services can be derived (cnd)
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 produced, • meet immediate requirements.
Cons • limited reusability potential: modeling reusable task-centric
business services often requires an initial analysis of multiple business process models in order to identify commonalities.
Process-driven service analysis
Process-driven service analysis RailCo 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 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:
- Invoice Submission Process: sends an invoice to TLS, uses the Invoice Submission Web Service.
- Order Fulfillment Process: accepts and processes Purchase Orders from TLS, uses the Order Fulfillment Web Service.
Process-driven service analysis Invoice Submission Order Fulfillment
Process-driven service analysis Applying the framework: Step 3 - Model candidate services
Process-driven service analysis 1 – Decompose the business process Break down the workflow logic in the “most granular” representation of process steps.
Invoice Submission Process • Create electronic invoice, • Issue electronic invoice, • Export electronic invoice to network folder, • Poll network folder, • Retrieve electronic invoice, • Transform 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.
Process-driven service analysis 2 – Identify business service operation candidates Some steps can be easily identified as not belonging to the potential logic to be encapsulated in a service candidate (e.g. activities performed manually or by some legacy logic).
Invoice Submission Process • Create electronic invoice, Manual step (accounting clerk)
• Issue electronic invoice, Manual step (accounting clerk)
• 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.
Process-driven service analysis 3 – Abstract orchestration logic Identify the parts of the processing logic that this layer would 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:
• if the invoice document is valid, proceed with the metadata check, • else, end process, • if the interval period for performing a metadata check has completed, perform the
metadata check, • else, skip the metadata check. • if the PO document is valid, transform the PO document, • else, end process.
Process-driven service analysis 4 – Create business service candidates
• The identified steps are grouped by logical context, with each group representing a service candidate.
Process-driven service analysis 5 – Refine and apply principles of service-orientation Refine the candidates according to the principles of reusability and autonomy.
Validate invoice
Process-driven service analysis 6 – Identify candidate service compositions Identify the set of most common scenarios that can take place, in order to: • evaluate the appropriateness of the candidate contexts, • identify potential service composition, • highlight any missing workflow logic.
Technical Support Services shared across different domains (Finance,
Sales)
Task-centric Business Services
Core Business Services
Process-driven service analysis 7 – Revise business service operation grouping Revisit contexts and operation candidates. New services may be created. For complex cases, further steps can be taken:
8 – Analyze application processing requirements
9 – Identify application service operation candidates
10 – Create application service candidates
11 – Revise candidate service compositions
12 – Revise application service operation grouping
Process-driven service analysis The 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: • processes become the dominant feature: POA rather than SOA, • task-centric business services (Level 1) are tightly bound to the context of a
single 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
reusability (process-oriented system treated as legacy application).
Meet-in-the-Middle Approach to SOA 1. 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. 3. Refactor the current solution by attacking the major inflexibilities.
built independently already existing
Synthesis Service Analysis
Identification and definition of the services an organization wants to provide or that are involved in a particular project; Service: a discreet domain of control that contains a collection of
tasks to achieve related goals. Deliverable: Service Interaction Map (SIM). Approaches:
– Top-down service decomposition. – Bottom-up: identify services from business process
models – Meet-in-the-middle.
33
References and acknowledgments • Example used for top-down service analysis inspired by:
– Steve Jones: “Enterprise SOA Adoption Strategies”. InfoQ, 2005.
• Example of process-driven service analysis inspired by: – T. Erl: “Service-Oriented Architecture: Concepts, Technology, and
Design”, Prentice Hall, 2005.
• Reading of the week: – O. Zimmermann, V. Doubrovski, J. Grundler, K. Hogg:
Service-oriented architecture and business process choreography in an order management scenario: rationale, concepts, lessons learned. OOPSLA Companion 2005: 301-312