Epc

Installation

© IDS Scheer AG / June 2002 5

4 Mapping of Processes: Methodological Aspects

Integrating ARIS and BusinessWare (BusinessWare) provides a seamless transitionbetween business process modeling in ARIS and its implementation as runtimesystems in BusinessWare.

For this, BusinessWare´s Statechart Diagrams (SCDs) must be generated from ARISeEPCs and vice versa. (The interface also comprises the export of other process modelsin ARIS, such as industrial or office processes or eEPCs in row and column display aswell as PCDs. For simplicity, this document only refers to eEPCs.)

4.1 eEPCs and methodological correctness in ARIS

In ARIS, eEPCs are the standard methodology for defining business processes.According to the ARIS philosophy of Professor Scheer, a process is a dynamic model,whichthat re-uses objects from static views (data, organizational and functionalviews) and combines them to create the business logic. Therefore it consists of a varie-ty of different object types, with some object types being of special importance for thedefinition of processes. Examples of such object types are: events, rules, functions,organizational units, application systems and connectors.

Vitria and IDS Scheer Confidential

Process-orienred Integration of IT-Applications

© IDS Scheer AG / June 20026

A small example can illustrate the basic concepts:


Mapping of Processes: Methodological Aspects


A function is the technical task or activity performed on an object in order to supportone or several business objectives.

Organizational units are the performers of the tasks required to attain the businessobjectives. The example above contains "persons" as one instance of organizationalunits.

An event represents a state that is relevant in terms of business management. It influen-ces or controls the further flow of one or more business processes. Changes in state arereflected in the changes of status of the relevant environment data (informationobjects). Events can trigger functions and they can also be the results of functions. Asopposed to a function, which represents a time-consuming process, an event occurs atone point in time.

Rules represent logic operators that allow specifying the logical links that exist bet-ween events and functions in process chains. The flow of control within a process isexpressed by the use of rules.

The example above also contains an entity as an example of a data object. Entities arereal or abstract elements that are of interest within the currently observed tasks of acompany.

An application system type is a placeholder for one or more application systems. Asingle application system is identified by its license number. A company may haveseveral application systems (several license numbers) of one application system type.

An eEPC can contain several other object types, such as knowledge objects. The ARISIntegrator for Vitria only processes the object types that are mentioned above.

Connectors link together all the objects in the process. Connectors are typed. Differentobject types are linked together using different types of connectors. Sometimes thereare even several connector types between two object types. For the ARIS Integrator forVitria, the type of connectors does not matter.

It is necessary to follow ARIS modeling guidelines for ARIS eEPCs. In particular, ruleshaving multiple incoming and outgoing connectors and multiple rules are not suppor-ted. Each function and event may have only one incoming and one outgoing connec-tion. If this is not the case, an error message is displayed and the export is canceled.

In order to create a valid process model in BusinessWare from the model that was gene-rated in ARIS, it is necessary that the ARIS modeling guidelines was followed forARIS eEPCs. In particular, the rules having multiple incoming and outgoing connec-tors and multiple rules are not supported. Each function and event may have only oneincoming and one outgoing connection. If this is not the case, an error message is dis-played and the export is canceled.

An overview of these guidelines can be found in the "method manual", which is partof the ARIS documentation. Section 4.2.1 deals with eEPCs.




It is recommended to run the appropriate consistency checks against the models befo-re proceeding to the export.

Additional modeling tips:In order to make the generated Automator models look better in BusinessWare, the usershould size all components in the eEPCs larger than the text it contains. (Switch off theauto adjust function for components)

4.2 Mapping of methodologies

There are inherent differences in the modeling methodologies of ARIS and BusinessWare that business process modeler has to be aware of. For example, the concept of anevent as an object in ARIS does not have the same meaning in BusinessWare. Most ofARIS events are transformed into BusinessWare transitions.

The following sections give details of different aspects of the mapping.

4.2.1 Functions and states

In ARIS, activities are denoted as functions, which are typically green rounded rec-tangles:

A function will always transfer to a state in BusinessWare. Depending on the context,it can become

Y a normal state,

Y a nested state

Y an action state or

Y an activity state.

In ARIS, an organizational unit can be assigned to a process:

Or:

This defines that the organizational unit is executing this function. A function with arelation to an organizational unit is transformed into an activity state.




This is the case for all types of relationships between the function and the organizatio-nal unit. It is also the case for the object types "organizational unit type", "organizatio-nal unit type cluster", "person type" and "person"

Result in BusinessWare:

An application system can also be assigned to a function:

Or:

When an application system is assigned to the function, it is assumed that this functionis executed in an external application. Out of this the ARIS Integrator for Vitria willcreate a normal state.

This is the case for all types of relationships between the function and the applicationsystem. It is also the case for the object types "application system type" and "applica-tion system class"

Result in BusinessWare:

Note: All other functions in ARIS will be transformed into an action state.

Note: Neither the application system nor the organizational units will be transferred toBusinessWare. Their existence or non-existence influences the way in which the ARISIntegrator for Vitria interprets the functions and generates the XMI output. All otherobjects in ARIS, which can additionally be connected to a function (like data and infor-mation objects), will neither be transferred nor will they influence the interpretation ofthe eEPC.




Examples:

Or:

Nothing but an action state will be created:

If an organizational unit as well as an application system is assigned to the same func-tion, the export result will be an activity state. In other words: the organizational unitgets the priority.

For nested states, see Section 4.4, "Nested Models".




4.2.2 Events, States and Transitions

The transformation of ARIS events (different to Vitria BusinessWare events) dependson the context in which it is used in an eEPC.

If the event is a starting event in an eEPC, it will become a start state in BusinessWare.

The start state will appear as follows:

If the event is an ending event in an eEPC, it will become an end state in BusinessWareand the name of the event will become the return parameter of that end state.

In BusinessWare the appearance is as follows:




In ARIS there are also so-called "trivial" events. A trivial event is a simple intermedi-ate state between two functions (and is often omitted):

In BusinessWare, the event will disappear and become a transition. The event namewill be placed in the description filed of the connecting transition.

The BusinessWare-transition is tagged with information, which allows the ARISIntegrator for Vitria to re-create the trivial event, when the process is re-imported intoARIS.




4.3 Mapping of rules

ARIS rules are used in ARIS processes to define the control flow. Connectors in ARISdo not have a 1:1 counterpart in BusinessWare. Therefore the mapping is not in astraight 1:1 fashion.

Basically, BusinessWare fork, join or normal splits are used depending on the connec-tor type. Since a state must always follow a fork in BusinessWare, but a function doesnot always follow a connector in ARIS, dummy states may have to be created for someevents (which will be ignored when re-importing the process into ARIS). To ensure thatthey are ignored, they must be tagged accordingly. The name “Wait for name of follo-wing event“ has been adopted.

Example without dummy states - an opening and closing XOR-rule in ARIS:

The XOR implies, that only one of the outgoing connectors can be used. Therefore, wedo not need a split - the opening and the closing XOR will become action states. TheXORs are being numbered, because BusinessWare requires unique state names.




The second example illustrates AND-rules. An AND expresses parallel execution ofseveral branches of a process.

In BusinessWare, this corresponds to a fork/join-combination. The generated model inBusinessWare contains dummy states "Wait for Prices/Taxes to be determined".




Example with OR-rules:

If a process contains an opening OR-rule, one, some or all-subsequent paths will beexecuted. In ARIS subsequent events determine which paths will be taken.

However, OR-rules should be avoided. BusinessWare does not have an equivalent con-cept. In BusinessWare Automator models are not able to fork a process "dynamically"and assign conditions to the particular branches in order to determine, whether thisbranch will be used in a specific instance of that process.




A workaround this situation (in BusinessWare), could be to model all possible pathsand actions explicitly, like in the following example:

Unfortunately, this BusinessWare-process cannot be generated from ARIS with thecurrent release of the Integrator. ARIS-processes, which contain an opening OR-rule,should be refined in ARIS prior export to BusinessWare. The process should be speci-fied in ARIS more precisely. The goal should be the avoidance of OR-rules.




Using the current ARIS Integrator an ARIS process with OR-rules would look like thisin BusinessWare:

If this process would be executed in BusinessWare the two "Wait for.."-states wouldblock each branch in processing. However, the process can be transferred toBusinessWare. The necessary adjustment to make this process model run accurately inBusinessWare can be done in ARIS or BusinessWare.




Dummy states for ARIS event cascades:

If a process model in ARIS contains cascading rules, like in the example below, addi-tional dummy states have to be generated in BusinessWare.

The generated BusinessWare process contains dummy states "Wait for event". Theseare necessary to avoid cascading forks, which are not permitted in BusinessWare. Theother "Wait for ..." dummy states are created as consequence of this necessity.




4.4 Nested Models

Processes can be organized in sub-processes. In ARIS, this is indicated by a little"model"-icon at the lower right corner of an object. Function objects can be detailed bysub-processes.

When exporting an ARIS-process that contains detailed functions, these functions(sub-processes) will also be automatically exported. The ARIS Integrator for Vitriaalways exports the entire set of processes, which is spawned from the top-level.

In case of a nested function it does not matter whether an application system or an orga-nizational unit is assigned to it. The function is primarily a placeholder for the detailedprocess. It always becomes a nested state in BusinessWare.

The starting event from the ARIS sub-process will always become an action state inBusinessWare, because a nested model is typically triggered from the higher levelmodel.

A nested process also has a return value in BusinessWare. This value is of type "string".The ARIS Integrator for Vitria generates this return value from the name of the termi-nating event of the ARIS sub-process.

4.5 Summary

The following table gives an overview of the mapping between the methodologies:


ARIS BusinessWareeEPC (office process, industrial process, PCD, Process modeleEPC in column/row display)Function with subprocess Nested stateFunction with assigned application system Normal stateFunction with assigned organizational unit Activity stateFunction without assigned process or Action stateapplication system or org. unitStarting event of an eEPC Event on transition from start stateEmbedded event TransitionEnding event of an eEPC Event on transition to terminator stateConnector TransitionOpening AND/OR rule ForkOpening XOR rule Action stateClosing AND rule JoinClosing OR/XOR rule Action state

Epc

Documents

Transcript of Epc