May 20, 2005 - Garages are responsible for car repair. .... design facets as classes and their relationships for a particular design per- spective. ... begin,end,.
Bridging the Gap between Business and IT in Service Oriented Business Collaboration
Bart Orriens, Jian Yang (published as long paper at SCC 2005) May 2005
Infolab Technical Report Series, no. 20 May 2005
1
Introduction
Nowadays enterprizes need to be dynamic and adaptive in order to stay competitive. This has led to an increasing demand for providing business services on demand and on the fly, and automating business services adapting to changes in the area such as market conditions, organizational policies, usage scenarios, etc. Recently there has been increasing focus on service oriented computing, the new emerging paradigm for distributed computing and e-business processing, to deliver flexible and adaptable corporate business services by utilizing existing services cross organizational boundaries. business collaboration is a cooperation between multiple enterprizes working together to achieve a business goals. In order to realize the vision of developing business collaborations in a dynamic fashion while adhering to the requirements imposed by the business environment, the specifics of business collaborations must be properly captured and modeled. Business collaboration design needs to apply software development principles and at the same time incorporate the special requirements of modern business collaboration development, i.e, support for high (abstract) level specification and adaptive to market changes. This requires modeling languages, methodologies, techniques and tools that allow designers to rapidly develop and deliver collaboration designs based on proven and tested models. Furthermore, new designs must be verifiable to determine if the modeled collaborations are in accordance with current market conditions, government regulations, industry guidelines, internal policies and so on. Similarly, modifications to existing designs must be assessable to check that resulting collaborations remain compliant. This requires the modeling languages to facilitate the specification of both business and technical demands for a business collaboration, as well as dependencies among them. Unfortunately, current composite web service development and management solutions including the defacto standard BPEL4WS [3] are too lowlevel and not rich enough to capture both the business and technical requirements of relevance to business collaborations. As a result service composition based on existing technologies and standards is very much a manual process. In this paper we introduce a Business Collaboration Design Framework (BCDF) for designing business collaborations, which provides a systematic way for analyzing the requirements and modeling the activities involved in business collaboration development. The ideas presented are illustrated using a complex multi-party scenario, which outlines the manner in which a car damage claim is handled by an insurance company (AGFIL). AGFIL cooperates with several contract parInfolab Technical Report Series, no. 20
ties to provide a service level that enables efficient claim settlement. The parties involved are Europ Assist, Lee Consulting Services, Garages and Assessors. Europ Assist offers a 24-hour emergency call answering service to policyholders. Lee C.S. coordinates and manages the operation of the emergency service on a day-to-day level on behalf of AGFIL. Garages are responsible for car repair. Assessors conduct the physical inspections of damaged vehicles and agree repair upon figures with the garages. The remainder of the paper is structured as followed: The framework BCDF is first in section 2. Next, alignment of business and IT in the BCDF is discussed in section 3. In section 4 different models for business collaboration design are presented. After that the mechanism for alignment of business and technical requirements is introduced in section 5. Related work is presented in section 6 after which we draw conclusions and point out directions for future research in section 7.1
2
Business Collaboration Design Framework
This section introduces the framework for design of business collaborations, being the Business Collaboration Design Framework (BCDF). The BCDF employs a multi-layered approach where collaboration design is facilitated through the usage of perspectives and facets. The perspectives are referred to as Design Perspectives (DPs), which represent different ways of looking at a business process. Facets depict parts of a business collaboration while observing it from a particular perspective, and are dubbed Design Facets (DFs). An overview of the Business Collaboration Design Framework is provided in Fig.1, showing that the BPDF consists of three design perspectives (DPs), which are intersected with six design facets (DFs). These are briefly discussed in subsections 2.1 and 2.2 respectively. Subsequently, different ways of utilizing the DPs and DFs are discussed in subsection 2.3.
2.1
Design Perspectives
Design perspectives support ’separation of concern’ which allow designers to focus on one aspects at the time without having to concern about the other aspects. Three design perspectives are identified in BCDF: 1) business perspective: from which the purpose and the requirements of the 1
This work was partially funded with an UNSW Australian ARC Discovery Research Grant Infolab Technical Report Series, no. 20
Participant
Participant
&
# $&
#$
&
&
#$
&
#$ %&
!
"
Design Perspectives
#$
' ((
' ((
! ' ((
' ((
' ((
** ' ((
)
' ((
+
' ((
, ' ((
' ((
* ' ((
-% ' ((
Local Aspect
Participation Behavior Aspect
#$
Participation Behavior Aspect
Local Aspect
Design Facets
Collaboration Aspect
Fig. 1: Business Collaboration Design Framework (BCDF)
Infolab Technical Report Series, no. 20
business collaboration is modeled and specified in terms of Goal, Schedule, Resource, Enterprize, Stakeholder, Step (see Fig.2). 2) conceptual perspective: from which a computational independent conceptual model is generated that depicts the business activities involved in the collaboration in terms of Rule, Event, Document, Unit, Actor, Task (see Fig.5). 3) logical perspective: from which a service-oriented business collaboration is modeled in terms of Constraint, Trigger, Message, Endpoint, Service, Operation (see Fig.7). Together these three perspectives encompass the business, operational and technical side of business collaborations. They can be used for design in a top-down or bottom-up manner, corresponding to forward and reverse engineering in system development respectively.
2.2
Design Facets
Business collaboration design can be seen from different perspective (abstraction level) as well as being observed from different, but equally valid points of view as described in [7, 10, 11] that emphasis on the specification of different business description elements: what, how, where, who, when, why. Here we refer them as Design Facets in the context of business collaboration design. The what facet emphasizes the informational view of the business collaboration. The functional standpoint is taken in the how facet, which focuses on how things are done. The geographical facet of the collaboration is expressed in the where facet, whereas the who facet concerns about collaboration’s participants. The temporal aspect is covered in the when facet that deals with schedules and events. Finally the why facet concentrates on describing the rational behind a collaboration. The facets and their interactions provide a complete coverage for each individual design perspective.
2.3
Design Aspects
The design aspect views business collaboration design from different position: 1) collaboration aspect: describes the externally visible behavior between participants in a business collaboration, specifying how its participants are expected to behave in the collaboration. In the business perspective this aspect expresses the goals that participants pursue and the manner in which they will realize them through the trade of resources. 2) participant behavior aspect: describes how an individual participant can behave in a business collaboration, i.e. its externally observable (public) behavior. Participant behavior aspects in the conceptual perspective capture the potential document exchange behavior of the individual participants. Infolab Technical Report Series, no. 20
3) local aspect: describes the private behavior which is only of the interest of a particular participant, like how a participant internally realizes the services it exposes to other participants in the logical perspective.
3
Business-IT Alignment
In order to provide support for development and maintenance of correct and proper business collaborations, its important to have a clear understanding of how business and technical requirements are to be consistent with one another. To achieve consistency alignment of requirements is needed to ensure that different requirements form a coherent picture. In the context of BCDF three types of alignment are identified: 1) vertical alignment: concerns the alignment of different design perspectives, for example that strategies pursued at the business perspective are correctly enforced via business policies at the conceptual perspective. 2) horizontal alignment: deals with the alignment of different design facets within individual perspectives, like that services offered by endpoints at the logical perspective actually exist. 3) aspect alignment: focuses on alignment of design aspects in a perspective, e.g. that expected message exchange behavior of an participant defined in the collaboration aspect matches the supported messaging behavior in its participation behavior aspect. Key to the facilitation of vertical alignment in the BCDF is the identification and understanding of dependencies among the different design perspectives. We refer to the capacity of self-maintaining vertical alignment as vertical alignability. Similarly, the alignment capacity within a single perspective to ensure horizontal consistency is called horizontal alignability. Following the former aspect alignability represents the potential to support aspect alignment in individual perspectives to maintain aspect consistency. In this paper we focus on vertical alignability, which bridges the gap between business and technical requirements, i.e. aligns business and IT in business collaboration.
4
Modeling
There are two types of models in BCDF: meta models and instance models, both of which are defined from individual perspectives. The meta models are generic which provide design guidelines; while the instance models represent a particular design of an application, which have to conform to the meta-model in terms of the properties and associations. There are three meta-models, each of which describes the relevant elements of (six) Infolab Technical Report Series, no. 20
design facets as classes and their relationships for a particular design perspective. The relationships connect the classes to indicate the interactions between the design facets. Meta-models for the business, conceptual and logical perspective and their instance models are introduced in subsections 4.1 through 4.3 respectively. In this paper all the models are represented based on UML conventions. To facilitate communication and execution of models corresponding XML based languages have also been developed, illustrative examples of which are provided in Fig.4.
4.1
Business Perspective
The design activities in the business perspective are of a scoping and discovering nature. Scoping is reminiscent to early requirements analysis in software development, where the objective is to get an idea of the goals of a collaboration in order to establish its boundaries. Discovery is comparable to requirements analysis in software development, in which a description of the collaboration-to-be within its operating environment is established, and its major functions are linked to the goals. The purpose of these activities is to define one of all possible models conceivable in the Business Meta Model (BMM), where the resulting model is called a Business Model (BM). The classes and associations in the BMM are portrayed in Fig.2. In order to distinguish different design facets, we represent them in different shapes in their UML models. Classes need to be instantiated during design. A snippet of a BM for the AGFIL case study, the AGFIL-BM, is provided in Fig.3. One of the main classes to be instantiated first in the business meta model is the Goal class, whose instances are concrete goals in an application. Goals represent desirable aims such as 24hr receipt, manage claims (see Fig.4 for an XML version of manage claims). Goals are pursued by stake holders (e.g. insurance director) who serve for the participating enterprizes. A stakeholder can be interested in achieving multiple goals. The information about the participating enterprize is captured in the Enterprize class. Resource instances such as customer plus car provide an abstraction mechanism for means such as financial, human and informational capital. Resources can be scarce, which affects the feasibility of usage scenarios. Compromises may need to be made in which strategic considerations come into play. Goals are achieved through steps which represents high level functions such as process claim. Steps can be dependent on one another or contain other steps to form complex ones. consume claim must have been Infolab Technical Report Series, no. 20
Refers to Accompanies 1..n 1..1 Schedule
Utilized in
0..n
1..n
Owns
1..1
Fulfilled in
begin,end, synopsis, milestones, strictness
1..n
Resource
Needs
description, type, value, capacity,
Helps achieve 0..n
Pursued by/ Achieved in/ Realized at
1..n / 1..n / 1..n
0..n
importance, type, description
Applicable to
Complied to by
Goal
1..1
1..1
Drawn on by
Realizes/Positive contribution Conflicts/Negative contribution 0..n / 0..n / 0..n / 0..n
Adhered to by
1..n
Follows
Consumes/Supplies
Associated with 1..n
name, address, size industry, reputation, market share
Realizes
1..n
Taken care of by 1..n
Stakeholder
Represents
1..n
Involved in
1..n
Dependent on/ Consists of
1..n
Observes Enterprize
1..n
Maintains
1..n
Pursues
Aims for
0..n / 0..n
1..n / 1..n
1..n
name, contact information, profile, type
Step
description, size, complexity, type
Responsible for 1..n
1..n
1..n
Draws 1..n on
Performed in
Involves
1..1
Fig. 2: Business Meta Model (BMM)
Garage Inc.
Get repairs
Garage Owner Do repair
Handle car Consume car
Assessor Manager
Assessor Inc.
Inspect car Consume repair info
Supply repair info
Damaged car
Consume repair info
24hr receipt
Gather info
Helpline Director
1 day < acceptance
Process claim
Europ Assist
Supply repair info
Supply car Supply claim
Claim info
Consume assessment Manage claim Consume claim info
Customer plus car info
Consume claim Insurance Director
Assess Supply assessment
Quick assess
Assessment information
Car repair information Car repair information
Assess claims
Supply claim info Process claim
Consultant Supervisor Make report Supply evaluation
Lee C.S
Manage claims
Repair eval. information Get claim evaluation Complete claim
Fig. 3: AGFIL Business Model (AGFIL-BM)
Infolab Technical Report Series, no. 20
AGFIL
1) ============================================== 2)
============================================== 3)
1) 500” conclusion=“do assessment” /> ============================================== 2)
============================================== 3)
1) ================================ ============== 2)
============================================== 3)
Fig. 4: XML-based Illustrative Examples
completed before process claim can take place. Steps are of type ’internal’ or ’exchanged’. Internal steps like process claim are specific to an enterprize and are not observable by others (presented inside the stakeholder boundary in Fig.3). Exchange steps provide a mechanism for defining the supply or consumption of resources between stake holders (for example consume claim information). Steps can have schedules linked to them, reflecting applicable temporal constraints. For example process claim has to be carried out at most 1 day after it has been received, as defined in 1 day > performance. Schedules have a begin and end date to define a period of time in which a step is to be completed. Schedules for different steps must be synchronized to avoid conflicts, so that, for example, the schedule of process claim does not interfere with that of supply claim information.
4.2
Conceptual Perspective
At the conceptual perspective analysis is performed to study the collaboration and investigate its properties. As the result one possible instance model, called Conceptual Model (CM), is produced which is encompassed Infolab Technical Report Series, no. 20
Signaled by
Affects/ 1..n Generated by 1..n
Signals
0..n
Event
date, time, severity, type, frequency
Controls Controlled by 0..n
0..n / 0..n / 0..n
Originates from/ 1..n Consumed at 1..n
0..n
Rule
0..n
condition, action, Constrains priority, status, type Constrained version
Guides/ Governs/ Steers
0..n
by
1..n
Used/ Produced by 0..n / 0..n
0..n / 0..n / 0..n / 0..n 1..n / 1..n
1..n / 1..1
Received/Send by
Publishes/Subscribed to
Receives/Sends
Obeys
1..n / 1..n
0..n
Dependent on/ Consists of
Governed by
0..n 0..n / 0..n
0..n
Source of/ Target of
0..n / 0..n
0..n / 0..n
Follows
1..n / 1..n
Unit
1..n
address, contact info, permanent, type, size, multi-discipline
0..n
Document
syntax, semantics, size, type, language
Realizes/Positive contribution Conflicts/Negative contribution
Published/Subscribed to by
Maintains
Stores
0..n
Hosts
Employs Belongs to 1..n 1..n
Allocated to 1..n
Actor
name, type, location, contact information
Performs
1..n
1..n
Uses/ Produces Task
function, duration, pattern, size, type, throughput, latency
Carried out at
Affected by/ Generates 1..n / 1..n
Fig. 5: Conceptual Meta Model (CMM)
by the Conceptual Meta Model (CMM). The CMM is portrayed in Fig. 5, whereas an example AGFIL-CM can be found in Fig. 6. As illustrated in the AGFIL-CM in Fig.6 actors such as claim office employee and consultant interact with each other to perform tasks. Tasks are of type ’internal’ or ’communication’ (represented inside or on the boundary of the actors respectively). Internal tasks constitute private activities, e.g. collect claim form performed by claim office employee. Communication tasks involve receipt or sending of information like report invoice. Actors belong to units, which provide organizational grouping constructs (like division or project team). claim handling unit is such an example. Events are used to assess progress, keep logs to ensure non-repudiation, etc. Events describe business occurrences which have properties such as ’date’, ’time’. Events can trigger, modify, pause, resume or end a task. Events can be inward oriented affecting internal tasks, or outward directed in which case they influence communication tasks. claim received is an example of an internal event, whereas estimate send illustrates the usage of external events. Events are signaled by the receipt or sending of documents, like estimate Infolab Technical Report Series, no. 20
Garage Repairer
Repair Team Receive cust.info
Get cust.info Get claim info
Helpline Employee Validate info
Send car info
Notify AGFIL Consultant Receive cust. file
Customer claim
Claim made
Customer file Receive claim Claim received
Send cust. file Collect info
Collect claim form
Claim Office Employee Check claim form
Send invoice
Compare reports
Receive info
Car repair invoice
Get estimate
Contact asssesor
Estimate > 500 no
Estimate Receive estimate Amend estimate
Repair approved
Car repair assessment Receive asssesment Select assessor Send estimate Receive invoice
Reconcile info
Write report
Send assessment
Car repair report
Claim file
Send claim file
Review car
yes
Receive claim file
Finance Unit
Assessor Go to garage
Car repair report
Select garage
Prepare bill
Receive report
Assessor Unit
Garage selected
Car info Send cust.info
Report estimate
Car repair approval
Garage accountant
Cost report
Notify accountant
yes
Estimate repair
Receive car info
Customer info
Answer Cell
Receive approval
Repair car
no
Estimate > 500
Approve repair Agree repair
Receive invoice Check invoice
Report invoice Invoice
Finalize claim
Consultant Group Claim Handling
Fig. 6: AGFIL Conceptual Model (AGFIL-CM)
send being signaled by estimate. Documents are communicated between actors to further their own state as well as that of the overall collaboration, e.g. communication of invoice between claim office employee and consultant. All classes, properties and associations in the CMM can be constrained by rules. Rules comprise statements that define or constrain some aspect of the business, which are intended to assert business structure or to control or influence the behavior of the business [2]. A rule has a condition and action part, where the former describes what must be true in order for the latter to be true. An example of a rule regulating the performance of tasks is if estimate > 500, then select assessor, which is followed by consultant. Fig.4 contains the XML version of this rule. Other rules may constrain event occurrences, actor selection, etc.
4.3
Logical Perspective
A conceptual model is realized in the logical model where the collaboration collaboration is put into a computational context, which is referred as service oriented computing (SOC) in this paper. The Logical Meta Model Infolab Technical Report Series, no. 20
1..n / 1..n
Indicated by
Starts/ End of
Trigger
0..n 0..n
Controls
date, time, severity, type frequency
Controlled by 0..n
Caused/ Listened to by
Constraint
condition,action, priority, type, status
Guides 0..n
0..n
1..n / 1..n
network location(s), type, version, pooling, load balancing, capacity
Governed by
Provides 1..n
Input/ Output 1..n
Service
type, category, version
0..1 / 0..1
0..n
0..n
Provided 1..n by
0..n / 0..n
0..n / o..n
Follows
Causes/ Listens for Endpoint
Input for/ Output of
Request for/Response of
0..n / o..n
0..n
Constrained 0..n by
0..n / 0..n / 0..n / 0..n
Requests via/Responds with
Obeys
Constrains
0..n
headers, body, syntax, semantics attachments, type
Realizes/Positive contribution Conflicts/Negative contribution
Governs
0..n / 0..n
Indicates Message
0..n
Part of Constitutes
Operation
access point, execution time, transaction time, synchronicity
1..n
Started by/ Ends with 1..n / 1..n
Fig. 7: Logical Meta Model (LMM)
(LMM) is illustrated in Fig.7. A snippet for the AGFIL example is depicted in Fig.8 as one possible logical model (LM) of LMM. Actors involved in the AGFIL-CM are represented as ’endpoints’ in the context of service oriented computing. Endpoints such as claim handling endpoint have properties ’network location’ and ’type’. Endpoints can be specified in the abstract or in the concrete, and are the access points through which services are requested and/or provided. For example claim handling endpoint provides claim handling service, whereas requiring claim management service. Services expose their functionality through interfaces, prescribing the conditions under which other endpoints can access them. An example is claim management service provided by consultant endpoint to allow clients to request claim management. Services provide containers for collections of logically related operations. Operations such as place invoice are specific business functions, which process access information as well as nonfunctional properties. Inputs and outputs of operations are represented as messages, which represents containers of information (e.g., claim management request), consisting of meta-data and actual data. Meta-data comprises the information Infolab Technical Report Series, no. 20
Car Repair Endpoint
Car Repair Service Repair car Car repair request
Claim Assistance Endpoint
Make claim
Claim Assistance Service
Approve repair
Send estimate
Car repair response
Request repair
Claim processing request
Claim processing response
Request managem.
Process claim Claim Handling Service
Claim Handling Endpoint
Report invoice
Update claim
Bill repair
Consulting Endpoint
Manage claim
Claim update notificat. Claim invoice request Claim invoice response
Repair invoice notificat.
Repair OK
Report estimate
Claim manag. response
Claim req. ack.
Request billing
Encrypted if> 500
Claim manag. request
Car Billing Endpoint
Car Billing Service Repair billing request
Repair estimate response
Repair estimate request
Request processing Claim req. made
Report repair
Agree on repair
Place invoice
Claim Management Service Notify claim update
Request assessm.
Send invoice Car assessm. request Assess car
Report assessm.
Car assessm. response
Send report
Assessment Service
Assessment Endpoint
Fig. 8: AGFIL Logical Model (AGFIL-LM)
that is required to deliver the message and enable its processing. Examples include parameters concerning reliable messaging, encryption styles, digital signatures, the character scheme used, etc. The second type of information in messages are payloads, which contain any content of the message not conveyed in its meta-data (like text documents, images, video files, etc).
The receipt and sending of messages result in triggers, which express a relevant system occurrence e.g. claim request acknowledged. They are similar to events in the CMM, however here the emphasis is on monitoring the progress from a computational point of view. Triggers can be controlled by constraints, which have properties such as ’condition’, ’action’ and ’status’ and they can constrain any element of a LM (see Fig.4 for an XML based example of request assessment constraint adhered to internally by claim management service. Once a complete LM has been constructed, the design can be mapped to an executable BPEL representation. Infolab Technical Report Series, no. 20
5
Vertical Alignability
Vertical alignability (automatic or manual) requires traceability, while traceability requires a mechanism to identify and subsequently express all the dependencies between design perspectives. In this section, we shall explain how traceability throughout perspectives is supported in the BCDF framework, and subsequently exemplify the benefits the resulting vertical alignability brings.
5.1
Traceability
The design perspectives in the BCDF are different in terms of level of abstract and content. However, for the same business collaboration they are related to one another. These relationships need to be made explicit to trace areas at one perspective to the other. Therefore, mappings are provided to facilitate traceability between business, operational and technical requirements. These are realized by providing links between the classes (and their properties) in different meta-models and instance models at different perspectives. Implicit links already exist between classes that describe the same design facet at different design perspectives. Subsections 5.2 and 5.3 discuss the mappings between the different perspectives. Note that due to space limitations we do not discuss linkage of individual class properties here.
5.2
Business - Conceptual
Vertical alignability of the business and conceptual perspective is achieved through linkage of classes in the BMM and CMM representing the same facet. These links enable verification of high level goals against carried out business activities. It also facilitates assessment of the affect of strategic changes on these activities, and vice versa. To start with, the work a stakeholder promises to fulfill in a BM will be delegated to its actors, such as garage owner delegating car receipt and repair to garage repairer. enterprizes associated with stakeholders are organized in units to which actors belong, like Garage Inc having a unit repair team of which garage repairer is part. Resource trades between stakeholders are mapped to exchanges of documents between actors, like trading of car repair information leading to communication of car repair report and car repair invoice. Steps Infolab Technical Report Series, no. 20
associated with resource trade are decomposed into specific tasks, e.g. supply repair information is divided into report estimate and send invoice. Schedules constraining steps with regard to temporal requirements are split into events representing concrete business occurrences, e.g. claim made indicating a claim has been made. Achievement of goals pursued in steps is enforced via rules, like quick assessment resulting in if estimate > 500, do assessment (also see Fig.4).
5.3
Conceptual - Logical
Alignment of the conceptual and logical perspective is enabled by linking the classes capturing the same facet in the CMM and LMM. The links define how business activities are implemented in the computational environment. This gives designers the means to verify technical capabilities against to-be-performed activities, and determine the impact of business and/or technical changes. Actors are portrayed as endpoints in a LM, where an actor can offer multiple endpoints (offering different services) like assessor offering assessment endpoint. An endpoint also encompasses the where facet in the logical perspective (as services are location transparent), e.g. consultant group being represented in assessment endpoint as well. Communication of documents between actors is mapped to sending and receiving of messages among endpoints, like customer claim resulting in messages claim processing request and claim processing response. Tasks corresponding to document exchanges are decomposed into operations, e.g collect info is further divided in get claim history and get customer info. Events occurring during business activities are mapped to triggers in the computing context. To exemplify, claim made is captured claim request made and claim request acknowledged. Lastly, rules are implemented via constraints, such as estimate > 500, assessment being realized by (among others) request assessment constraint (see also Fig.4).
5.4
Verification and Changeability
The two previous subsections outlined how vertical alignability is supported within BCDF, enabling consistency among business, operational and technical requirements. There are two main benefits arising from this Infolab Technical Report Series, no. 20
capacity, being verification and changeability. Verification entails assessment of feasibility of business requirements with regard to available technical capabilities, as well as determining conformance of technical realizations against set out business demands. To exemplify look at the exchange of resources car repair information and assessment information. This exchange can be mapped to several document communications like car repair report and car repair assessment. Any properties constraining the resource exchange (e.g. quick, accurate, complete) will affect the characteristics of these communication behaviors. In turn these characteristics will influence the make up of the message exchanging behavior in the AGFIL-LM in Fig.8. As such, top-down verification of requirements against implementation is facilitated, where any conflicts can be detected and subsequently resolved. Verification can of course also be done in a bottom-up manner. Changeability is concerned with the ease with which changes in business collaboration can be effectuated. In this context vertical alignability enables determination of the impact and validity of modifications to collaborations. Let us assume that the internal implementation of claim management service has changed with regard to the techniques it uses to encrypt messages. As a result these now differ from the ones adopted by claim handling service in the AGFIL-LM. Tracing the change to the AGFILCM we find that communication of estimate must be done confidentially. Moving further up the AGFIL-BM states that exchange of customer plus car information must be done securely. Thus we find a conflicting situation in which a lack of technical inter-operability between the services claim handling service and claim management service leads to a lack of business inter-operability between AGFIL and Lee C.S as the security requirement can no longer be met. Once we identify all the affected areas, we can decide how necessary changes should be introduced and implemented. Changes can naturally be traced as well going from business to technical requirements.
6
Related Work
Most of the work in service composition and business collaboration has been focusing on the development of compositions without taking modeling and change management into too much consideration. BPEL [3], the de facto standard in this area, provides ”a model and a grammar for describing the behavior of a business process based on interactions between the process and its partners”. BPEL provides no basis though for high level modeling and mapping to technical demands. Representative work from Infolab Technical Report Series, no. 20
the scientific community on service composition specification is provided in [9] that provides an appropriate conceptual model for developing and describing web services and their composition. The framework includes the notion of goal specification, but no support is offered for capturing business or operational requirements. Some specific work has been done in the service composition arena concerning business-IT alignment. [5] presents a web service management architecture (WSMA) in which business level metrics are mapped to service executions to allow assessment from a business perspective. However, the metrics are fairly low-level, lacking support for capturing high level business requirements. [12] describes a rule inference framework called DYflow, where end users declaratively define their business objectives and the system dynamically to compose web services. But there is no clear-cut separation between technical and business oriented rules, compromising the framework’s capability to facilitate requirements alignment. Prominent work in the area of business process modeling is the ebXML framework. Its specification on business process modeling, ebBPSS [8] defines a comprehensive meta-model for describing public processes (i.e. collaborations). The implementation of instances of this meta-model is facilitated through other parts of the ebXML suite, e.g. ebXML’s messaging service. Although ebBPSS offers a very complete set of concepts to define business collaborations, it too does not provide a verification mechanism with which the consistency of business against technical realization can be easily determined. The system development community has focused much of its efforts in developing comprehensive methodologies for developing enterprize information systems. An exemplary proponent of this effort is Tropos [1], which is an agent-oriented software engineering methodology focusing particularly on activities that help to gain understanding of how and why the intended system would meet the set out goals. The main difference with our work lies in the fact that in [1] the notion of traceability is not made explicit in relation to alignability as in our business collaboration design framework, and its potential is thus not harnessed. The contributions of our work in comparison to the above mentioned work on business-IT alignment in business collaboration can be summarized as followed: • The BCDF provides the modeling languages, methodologies, and techniques needed for business collaboration design ranging from business to technical requirements, as such providing a comprehensive approach to business collaboration design. Infolab Technical Report Series, no. 20
• The support for traceability enables business-IT alignment, facilitating verification of business against technical requirements, as well as assessing the impact of business and/or technical changes on the business collaboration as a whole. • Its ability to develop business collaborations in a model-driven fashion, makes that the BCDF allows rapid development and delivery of business collaborations based on proven and tested models, which is a critical benefit in a highly dynamic business environment.
7
Conclusions
Current standards in business collaboration design, such as BPEL and ebXML, are not suitable for dealing with the complex and dynamic nature of developing and managing business collaborations in accordance with specified business requirements. Without the support for high level modeling facilities and traceability such standards can not facilitate the verification of consistency required in business processes crossing organizational boundaries. The challenge is thus to provide a solution in which business collaboration design can be done in an effective and traceable manner to realize alignment of business and technical requirements. In this paper we have presented the Business Collaboration Design Framework (BCDF), a framework that utilizes a multi-perspective and multifacet approach to collaboration design. Business collaborations are modeled in three different perspectives, intersected by six facets. The work presented herein emphasizes the relevance of the BCDF for modeling at high level and aligning these high level business requirements to technical realization. Work for future research will foremost be focused on the formalization of the BCDF to allow formal assessment of verifiability and changeability. Another issue that needs to be addressed is the development of a change management sub-system to control the evolution of business collaboration designs.
References [1] P. Bresciani, A. Perini, P. Giorgini, F. Giunchiglia, J. Mylopoulos, Tropos: An Agent-Oriented Software Development Methodology, Autonomous Agents and Multi-Agent Sytems, Vol. 8, pp. 203-236, 2004 [2] Business Rules Group, Defining business rules - What are they really?, http://www.brcommunity.com, July 2000 Infolab Technical Report Series, no. 20
[3]
F. Curbera, Y. Goland, J. Klein, F. Leymann, D. Roller, S. Thatte, S. Weerawarana, Business Process Execution Language for Web Services, http://www106.ibm.com/developerworks/webservices/library/ws-bpel/, July 31, 2002
[4] Cambridge Learner’s Dictionary, http://dictionary.cambridge.org [5] Business-Oriented Management of Web Services, F. Casati, E. Shan, U. Dayal, M. Shan, Communications of the ACM, Vol. 46 , No. 10, pp. 55-60, 2003 [6] CrossFlow Consortium, Insurance (Motor Damage Claims) Scenario, ESPRIT E/28635, January 8, 1999 [7] B. Curtis, M. Kellner, J. Over, Process Modeling, Communications of the ACM, Vol. 35, No. 9, pp. 75-90, 1992 [8]
ebXML, Business http://www.ebxml.org
Process
Specification
Schema,
[9] D. Fensel, C.Bussler, The Web Service Modeling Framework WSMF, Electronic Commerce Research and Applications, Vol. 1, No. 2, 2002 [10] A. Scheer, Architecture for Integrated Information Systems - Foundations of Enterprise Modeling, Springer-Verlag New York, Secaucus, NJ, USA, 1992 [11] F. Vernadat, CIMOSA - A European Development for Enterprise Integration Part 2, Enterprise Modeling, Pergamon Press Inc. Tarrytown, NY, USA, 1992 [12] L. Zeng, B. Benatallah, H. Lei, A. Ngu, D. Flaxer, H. Chang, Flexible Composition of Enterprise Web Services, Electronic Markets - The International Journal of Electronic Commerce and Business Media, Vol. 13, No. 2, 2003
Infolab Technical Report Series, no. 20
