Enabling Flexible Integration of Business and Technology Using Service-based Processes Jelena Zdravkovic, University of Gävle/Royal Institute of Technology.

Slides:



Advertisements
Similar presentations
Design by Contract.
Advertisements

IX- CONSTRUCTION PLANNING
Ch:8 Design Concepts S.W Design should have following quality attribute: Functionality Usability Reliability Performance Supportability (extensibility,
Stereotypes & Framework in conceptual architecture Lecture
Information Technology IMS5024 Information Systems Modelling Event-driven modelling.
Using Data Flow Diagrams
Solutions to Review Questions. 4.1 Define object, class and instance. The UML Glossary gives these definitions: Object: an instance of a class. Class:
RBM in the context of Operations and Programme and Project Management Material of the Technical Assistance Unit (TAU)
OOAD Using the UML - Use-Case Analysis, v 4.2 Copyright  Rational Software, all rights reserved 1/18 Use Case Analysis – continued Control Classes.
OASIS Reference Model for Service Oriented Architecture 1.0
1 Introduction to XML. XML eXtensible implies that users define tag content Markup implies it is a coded document Language implies it is a metalanguage.
Business Process Orchestration
Fundamentals of Information Systems, Second Edition 1 Information and Decision Support Systems Chapter 6.
Kmi.open.ac.uk Semantic Execution Environments Service Engineering and Execution Barry Norton and Mick Kerrigan.
System Engineering Instructor: Dr. Jerry Gao. System Engineering Jerry Gao, Ph.D. Jan System Engineering Hierarchy - System Modeling - Information.
Software Testing and QA Theory and Practice (Chapter 10: Test Generation from FSM Models) © Naik & Tripathy 1 Software Testing and Quality Assurance Theory.
Distributed Databases
Process-oriented System Automation Executable Process Modeling & Process Automation.
What is Software Architecture?
Data Flow Diagrams (DFDs)
Chapter 10 Architectural Design
THE NEXT STEP IN WEB SERVICES By Francisco Curbera,… Memtimin MAHMUT 2012.
Chapter 6 System Engineering - Computer-based system - System engineering process - “Business process” engineering - Product engineering (Source: Pressman,
Slide 1 Wolfram Höpken RMSIG Reference Model Special Interest Group Second RMSIG Workshop Methodology and Process Wolfram Höpken.
Implementation Yaodong Bi. Introduction to Implementation Purposes of Implementation – Plan the system integrations required in each iteration – Distribute.
Chapter 5 Analysis Model. Analysis model (AM) The first step in describing how the system will implement the requirements specification The first step.
1 Web Service Choreography Interface (WSCI) 1.0 W3C Note 8 August Dumitru Roman.
Architecting Web Services Unit – II – PART - III.
10/18/20151 Business Process Management and Semantic Technologies B. Ramamurthy.
(Business) Process Centric Exchanges
Requirements as Usecases Capturing the REQUIREMENT ANALYSIS DESIGN IMPLEMENTATION TEST.
Illustrations and Answers for TDT4252 exam, June
An Ontological Framework for Web Service Processes By Claus Pahl and Ronan Barrett.
Chapter 10 Analysis and Design Discipline. 2 Purpose The purpose is to translate the requirements into a specification that describes how to implement.
Software Engineering Prof. Ing. Ivo Vondrak, CSc. Dept. of Computer Science Technical University of Ostrava
1 Capturing Requirements As Use Cases To be discussed –Artifacts created in the requirements workflow –Workers participating in the requirements workflow.
1 ECCF Training 2.0 Implemental Perspective (IP) ECCF Training Working Group January 2011.
Computing and SE II Chapter 9: Design Methods and Design Models Er-Yu Ding Software Institute, NJU.
UML’s StateChart FSM, EFSM in UML Concurrent states Tool support.
Course: COMS-E6125 Professor: Gail E. Kaiser Student: Shanghao Li (sl2967)
CEN/ISSS eBIF GTIB Project Meeting, Brussels Mar , 2009 CEN/ISSS eBIF GTIB Project Meeting, Brussels 1 CEN/ISSS eBIF Global eBusiness Interoperability.
Dr. Rebhi S. Baraka Advanced Topics in Information Technology (SICT 4310) Department of Computer Science Faculty of Information Technology.
Analysis Yaodong Bi. Introduction to Analysis Purposes of Analysis – Resolve issues related to interference, concurrency, and conflicts among use cases.
Behavioral Framework Background & Terminology. Behavioral Framework: Introduction  Background..  What was the goal..
IBM Global Services © 2005 IBM Corporation SAP Legacy System Migration Workbench| March-2005 ALE (Application Link Enabling)
Data The fact and figures that can be recorded in system and that have some special meaning assigned to it. Eg- Data of a customer like name, telephone.
1 Chapter 2 Database Environment Pearson Education © 2009.
OOD OO Design. OOD-2 OO Development Requirements Use case analysis OO Analysis –Models from the domain and application OO Design –Mapping of model.
© The ATHENA Consortium. CI3 - Practices of Interoperability in SMEs Proposed Solutions.
Diagrams. Typically, we view the static parts of a system using one of the four following diagrams. 1. Class diagram 2. Object diagram 3. Component diagram.
PDEVS Protocol Performance Prediction using Activity Patterns with Finite Probabilistic DEVS DEMO L. Capocchi, J.F. Santucci, B.P. Zeigler University of.
Extension du formalisme SES pour l’intégration de la hiérarchie d’abstraction et la granularité temporelle au sein de la modélisation et la simulation.
SE 548 Process Modelling WEB SERVICE ORCHESTRATION AND COMPOSITION ÖZLEM BİLGİÇ.
SECURE TROPOS Michalis Pavlidis 8 May Seminar Agenda  Secure Tropos  History and Foundation  Tropos  Basics  Secure Tropos  Concepts / Modelling.
Business Process Execution Language (BPEL) Pınar Tekin.
CHAPTER
Information Delivery Manuals: Process Mapping
Classifications of Software Requirements
Architecting Web Services
Architecting Web Services
Web Ontology Language for Service (OWL-S)
UML’s StateChart FSM, EFSM in UML Concurrent states Tool support.
COIT20235 Business Process Modelling
Chapter 2 Database Environment.
BPMN - Business Process Modeling Notations
Lecture # 7 System Requirements
Design Yaodong Bi.
Business Process Management and Semantic Technologies
Presentation transcript:

Enabling Flexible Integration of Business and Technology Using Service-based Processes Jelena Zdravkovic, University of Gävle/Royal Institute of Technology (KTH) Martin Henkel, Stockholm University/Royal Institute Of Technology (KTH) Sweden

Business and Technical Processes When designing executable enterprise processes, the alignment between business and technical requirements is still one of the main problems. From the business perspective, a process (i.e. business process ) is modelled to closely follow the business activities, events and message exchanges. From the technical perspective, the process design must be aligned with constraints of existing systems and implemented services.The final process ( technical process ) is influenced by both the business and technical perspectives. If there are no constraints from existing services, the technical process will directly correspond to (i.e. realize) the business process.

A Way to Align Business and Technology In the majority of cases, business and technical processes will differ. This misfit can result in a technical process that does not support all aspects of the business. For a system designer it is important to avoid service designs that may not be aligned with requirements of business processes. We have examined criteria that system designers should adhere to when designing services, to be able to construct a technical process that may realize a business process.

Case Study - Sandvik

Compared to the business process, the technical process must adhere to a set of system constraints: The customer profile is retrieved with two activities, as the customer contact and order history information are located in different ERP systems. The customer price cannot be concurrently obtained with the stock information, because the first activity requires the stock value as an input. Based on the customers service ability product information may be sent as a HTTP message or a FTP file. Storing and sending of product information may be managed by the internal systems only as a long-running transaction, because the services that implement the activities do not support the two-phase commit. Case Study - Sandvik

To make a structured examination of differences between bussiness and technical processes, we use a conceptual framework that identifies five aspects of process design - functional, behavioural, informational, organizational and transactional. When designing a business as well as a technical process, each of the process aspects must be considered. Based on the considerations of the design aspects, we have identified rules for transformations from business to technical processes. We have used those rules as a basis to define criteria for design of system services. Our Approach

The functionality of an activity is determined by the activity name, which describes the goal to be fulfilled, exchanged messages, and input and output constraints. In a business process, the functionality of activities is governed by business rules. When realizing the business process, the functionality of existing services will be the base for selecting the activities for inclusion in a technical process. Due to that, activities in the technical process may be designed to aggregate exchanged messages differently than business process activities, or they might specialize them, or impose different input/output constraints. Functional Aspect

FUNCTIONALAggregationSpecialisationConstraints Transformation rule Activities should be aggregated such that the message exchange of an activity in the technical process contributes to the message exchange of at most one activity in the business process. Activities in the technical process may specialize the activities in the business process as long as the goals of those business activities are fulfilled. The input constraints of activities in the technical process must be the same or weaker, while the output constraints must be the same or stronger. Service design Support finer granularity of activities, or support several levels of granularity. Example: ”Get customer profile” is realized with two activities “Get customer contact” and “Get customer orders”. Specialization to different systems should be offered. Example: “Send product information” is specialized into sending with both the FTP and HTTP protocols. Design services with minimal input constraints and maximal output constraints. Example: “Get customer price” should support required currencies.

The behavioural aspect addresses the process control flow. Three basic control flow construct are used to express the order of activities (i.e. sequence and parallel execution) and conditional branching. In a business process the use of the control flow constructs are governed by business rules, for example stating that the payment should be done before the product is delivered. When realising a business process as a technical process, existing services may impose different control flow due to existing dependencies and supported conditions. Behavioral Aspect

Behavioural Aspect BEHAVIOURALOrderingConditional Branching Transformation rule The ordering of activities in the technical process must be designed such to support the orders specified in the business process. This ensures that the required ordering of the business states is realized. Every branch in the business process corresponds to at least one branch in the technical process. Otherwise it is not possible which branch of the BP is executed. Service design Design services by avoiding ordering dependencies. Example: the customer- based product price cannot be obtained concurrently with the stock information, because the Order system requires the stock value to calculate the price. Design services to avoid implementation of conditional choices, and in addition, to support at least the choices discerned by the required cases.

The informational aspect is related to the concepts needed for representing process internal data and the data that the process exchanges with the external environment. In a business process the concepts are modelled to resemble business concepts such as customers, orders etc. In the technical process, the business concepts are represented by well-defined information structures, for example by using the XML Schema standard. Those structures might include some technical concepts such as system identifiers. Informational Aspect

INFORMATIONALInformation inclusion Transformation rule Business concepts must be included in the technical process. This requirement means that it should always be possible to trace information concepts in a business process to their equivalent concepts in the technical process. Service design Design services to support more business concepts than required. Example: the CRM system in Figure 1 should be designed to support broad customer information.

The organizational aspect concerns the responsibility for executing activities. When designing a business process the responsibility is assigned to business roles. In a realization of a business process, i.e. in the technical process, these roles have their correspondence in the responsibility to execute services. Organisational Aspect

ORGANISATIONALRole Mapping Transformation rule The activities in the technical process must be owned by, or under supervision of the parties that are responsible for the corresponding business activities. Service design Design services with well- described interface descriptions. These descriptions allow several parties to implement the same service, thereby enabling inclusion of new parties in the process when the business requires it.

The transactional aspect rules consistent execution of a set of activities. In the business processes, the loosely coupled process activities may have short or long duration, and thereby process transactions comply with two different models - the atomic transaction model or the long-running model. In the technical process, transactional properties of existing services might impose constraints for implementation of a particular transaction model. Transactional Aspect

TRANSACTIONALModel Mapping Transformation rule The activities in the technical process must support at least those transactional properties that are defined for the activities in the business process. Service design Design services to support both atomic and long-running models. Example: the business process requires that storing of the product information should not be done unless the information is sent successfully to the customer. In the technical process, the activities for sending of FTP/HTTP messages cannot be designed as atomic due to used non-transactional message protocols.

In this study we have discussed the gap between business processes and their realization in a technical system environment. With the Sandvik’s example, we have shown how existing services change realizations of business process. Based on the transformation rules that must be followed to successfully realize a business process, we defined criteria that system designers should adhere to when designing services. The notion of technical and business processes, along with the notion of the realization rules are a fundament for process designers to discuss and manage both business and technology. The abilities of the existing services to support realization of a business, is one of the major concerns in that context. Conclusion