version 1 - arcwaystructure of information and the relationships between different pieces of...

Copyright: ARCWAY AG 2011

Version 1.2

ARCWAY Modeling guide V1.2 page 2 of 35


1 Introduction ................................................................................................................................. 3

2 Basic modeling concepts .............................................................................................................. 4

2.1 Plans .................................................................................................................................... 4

2.2 Cockpit Repository ............................................................................................................. 10

2.3 Element types ..................................................................................................................... 11

2.4 Hierarchies ......................................................................................................................... 12

2.5 Integration of plans and evaluation of relationships ............................................................ 13

3 Requirements management ....................................................................................................... 16

4 Modeling of processes ............................................................................................................... 18

5 Modeling of an organization ...................................................................................................... 26

6 Modeling of IT ........................................................................................................................... 28

7 Modeling of information ............................................................................................................ 31



ARCWAY Cockpit helps teams to visualize business processes, to depict IT-Architectures clearly and to

formulate requirements for IT-Solutions in a precise way in order to coordinate them.

This document describes the integrated modeling with ARCWAY Cockpit.

A business process is a sequence of steps to achieve a business result. In contrast to a project it is passed

through multiple times. The particular process steps are performed by individuals in organization units

(department, position, team, ...) and IT applications.

Since business processes exceed department, company and application boundaries, in the modeling of

business processes the structure of the organization and the application landscape is to be taken into

account.

This definition points out the relevant topics for business process modeling:

business processes

organization

IT

The adequate modeling of business processes and the executing organization and IT structures enables to

create transparency and overview. Based on this it is possible to identify optimization potentials and

requirements in a structured way.

Figure 1 – Business process modeling - subjects

In ARCWAY Cockpit ARCWAY offers a tool that supports the presentation and linking of these aspects. It

enables the creation of the necessary models and their relations and provides a fully featured

requirements management.

The first part of this document gives an introduction to the basic modeling principles and their support by

ARCWAY cockpit. In the second part there is a detailed description of the several modeling subjects.

processes

organization IT

modeling



Plans are graphical representations of models or certain parts or aspects of a model.

In the modeling of business processes and their environment different aspects must be taken into ac-

count. In Cockpit there are different types of plans for these aspects. The most important ones are: land-

scape, event-driven process chain, organization chart and UML class diagram. They are used to answer

different questions.

landscapes represent compositional structures

o What is made using which information and how does the information flow?

(business landscape)

o Which systems are used to execute the tasks, which interfaces do they have and

where is the data stored? (application landscape)

Organization charts represent organizational structures

o Who reports to whom and who is responsible for what?

Event-driven process chains represent processes

o What is made when?

UML class diagrams represent the structure of information

o What is the structure of certain kinds of information and which dependencies exist

between different bits of information?

The following sections provide an introduction to the various plan types.

In ARCWAY Cockpit compositional structures are represented by landscapes. Compositional structures

are structures which carry the processes. As introduced in Chapter 1, these may be functional structures,

organizational structures or application structures. For functional structures and application structures

landscapes are used. Organizational structures are represented by organization charts in Cockpit.

A landscape shows the cooperation of active elements, the so-called agents, which are responsible for a

certain job. The agents can work together using passive elements. They are representing information that

is changed, read or replaced.

A landscape consists of:

active elements, agents, that stand for business functions, organization units or applications

and passive elements representing information like business data, application data or interfaces.

Two active elements are always connected with each other via a passive element.

Landscapes are the concept behind ARCWAY Cockpit that gives, with little effort, an overview of the

balance between business and IT.



Landscapes provide a clear presentation of complex issues in a few central plans. Based on those a variety

of processes can be understood, put into relation with each other and categorized.

To achieve these goals, landscapes with different priorities will be useful:

The business landscape is a pure business view on the company or organization. Business

functions that must be executed within the company and business data, which is required,

processed or produced by the functions, are illustrated.

Depending on the use case, it may be useful to integrate business functions and organization

units in the business landscape. These possibilities will be discussed in more detail in the

subsequent chapters.

Warehouse Management

Customer Order Management

Supplier Management

Customer Order

SalesManagement

BusinessAssessment

Supplier Base

Customer Management

Customer Base

Inventory List

Customer

Requisition Note

Supplier Order

Invoicing

Supplier

Bank

Inventory Management

Incoming Goods Inspection

Outgoing Goods Inspection

Customer Invoice

Customer Data

Customer Order

Dispatch

Receipt ofPayment

Payment Order

Supplier Invoice

Supplier Order

Delivery

Warehouse Logistics

Figure 2 – Business landscape



The application landscape depicts an IT perspective. It shows the applications, application data

and the channels between the applications.

Figure 3 shows an application landscape within business functions and business data are

represented and additionally assigned to the corresponding applications and data storages. Fur-

thermore the users of the applications are illustrated.

SAP Systems

SAPPortal

Business Warehouse

Sales Management

SAP SCM

SAP CRM

Customer OrderManagement

Supplier Management

WarehouseManagement

BW Database

SCM Database

CRM Database

Customer Order

Supplier Order

Business Assessment

Inventory List

Customer Base

Supplier Base

Sales Manager

PurchasingAgent

Warehouseman

AccountManager

Legacy FinancialManagement

Invoicing

Customer Management

CarPart Web Shop

Staff MemberAccounting

Office

Customer

BWClient

CSVInterface

CSVInterface

Copies of ApplicationData

Requisition Note

Figure 3 – Application landscape



The organization chart depicts the organization units and their relationships.

Figure 4 - Organization chart shows an example of an organization chart. In addition the business func-

tions, an organization unit is responsible for are shown.

Management

PurchaseDepartment

Sales Department Finance DepartmentHuman

ResourcesDepartment

Supplier Management

Incoming GoodsInspection


Warehouse Logistics

Customer Management


Sales Management

Outgoing GoodsInspection

Invoicing

Figure 4 - Organization chart



In ARCWAY Cockpit processes are represented by event-driven process chains (EPCs). An EPC shows

the sequence of events and steps to be undertaken for a business process and thus describes their

temporal or logical order.

An EPC essentially consists of the notation elements:

event

process step / process

control flow elements

Events trigger certain process steps, which result again in events. Thereby events and process steps usually

alternate. However, for the purpose of clear and well-readable graphs it is advisable to omit trivial events.

A single process step can also represent a whole separate process that is shown on another plan. This is

explained in more detail in Section 4.1.2Fehler! Verweisquelle konnte nicht gefunden werden..

Control flow elements enable the description of the workflow. In addition to sequential workflows it is

also possible to describe case distinctions and parallel workflows.

New Customer Order

Customer wants toplace an order

Search for customerdata

XOR

Customer is recordedalready

Customer is notrecorded yet

New customer

Customer is created

XOR

Record customer order

Customer ordercreated

Check warehousestock

XOR

Spare part is in stockSpare part is not in

stock

Commissioning ofsuppliers

Spare part is in stock

XOR

Commissioning ofprovision

Spare part provided fordispatch

Figure 5 – Event-driven process chain

While EPCs are well-suited to represent the workflow of a single process, the complete modeling of all

business processes of a company will be extensive and complex. In addition the large number of plans will

reduce the clarity of the process documentation and make it more difficult to get a quick overview.



In section 2.1.1 the representation of compositional structures by using landscapes was presented. Land-

scapes provide an abstract overview. Detailed process flows in the form of EPCs can be created for those

areas for which such level of detail is required.

In ARCWAY Cockpit information structures are represented by UML class diagrams. They show the

structure of information and the relationships between different pieces of information.

A UML class diagram essentially consists of the notation elements:

business data, application data

attribute

folders

relationships (associations, aggregations, compositions und specializations)

Relationships between data are represented by relation elements. In addition business and application

data can be grouped by folders and their attributes can be shown.

Figure 6 shows an example of a UML class diagram. Relation elements show the relationships between

data elements, for example a supplier has got 0..n contact persons and 0..n terms of payment. Also single

attributes such as address and title of a contact person are shown.

Supplier

Company Name

Payment Terms

0..n

Vendor Number

Department

Street

Zip Code

City

Country

Contact Person

Phone

Salutation

Title

First Name

Surname

Email

0..n

Credit Limit

Term of Payment

Discount

Tax Number

Phone

Fax

Email

Homepage

Figure 6 – UML class diagram



Each plan consists of several plan elements. In Cockpit there is a further distinction between local ele-

ments and global elements. Local elements appear only on one plan, while global elements can occur on

several plans.

If you change a property of a global element, for example name or description, it always affects all occur-

rences of the global element. Global elements are managed in the Cockpit repository and occurrences on

different plans can be created by dragging them onto a plan editor from there.

Figure 7 – Repository and plan elements

Figure 7 shows this concept with an example. On the left side the repository containing the global ele-

ments available in the project can be seen. On the right side details of two plans are shown. The global

element “Business Assessment” occurs in both plans. A change of the plan element name in plan A

would implicate a change of the plan element name in Plan B, as the underlying repository element is

modified.

There are three ways to create an element in a plan:

1. An existing global element from the repository can be added to the plan.

2. A new global element can be created in the plan and will be added to the repository.

3. A new local element can be created in the plan and will not be added to the repository.



In most cases global elements should be created, which can then be reused on other plans. Local ele-

ments are rather necessary in exceptional cases especially when an element has no name or to include

comments in a plan.

In chapter 1 the topics relevant for business process modeling were presented. Plan types necessary for

the graphical representation were shown in section 2.1.

All topics and plan types have in common that their elements can be assigned on an abstract level to only

three types of modeling elements:

Functions represent the active modeling elements. In addition to process steps and business

functions they also include organization units and applications.

Information stands for all passive elements such as business data, application data or interfaces.

Events are modeling elements that represent the chronological order of a process or a condition.

The basic principle in ARCWAY Cockpit is that all elements can be assigned to one of these three basic

types. The global elements in the repository always are of one of these three basic types. Depending on

the aspect to be represented an element can have a more concrete denotation in the various plans (like

organization unit, application e.g.) which is not represented in the central repository.

The following table shows how the elements used in the different plan types can be mapped to the three

basic repository types.

basic repo-

sitory types

EPC elements landscape

elements

organization chart

elements

UML class diagram

elements

function process step

process

business function

application

organization unit

business function

organization unit

person

agent

organization unit

business function

information business data

storage

business data

application data

interface

storage

business data

application data

entity type

attribute

folder

event event

Table 1 - Basic Cockpit types and plan elements

Cockpits element repository only distinguishes between the three basic types. Cockpit doesn’t know any

other types. To create occurrences of the elements on a plan there are general, non-colored plan element

templates. The further distinction, for example of functions in business functions and applications is of a

mere conceptual nature. For this purpose differently colored plan element templates are used.



For instance, for landscapes there are the templates "agents", "business function" and "application".

“Agents” is a general, not pre-colored template representing any function, whereas the templates "busi-

ness function" and "application" are pre-colored. The goal of the coloration is the use of a consistent

colors scheme across different plans and projects. For Cockpit itself the color is of no technical impor-

tance. Only the reader of the plan will immediately recognize a function as a business function or as an

application.

In many cases it is not appropriate to present all details of a modeling object in one single plan. It is useful

to focus on the essentials in more abstract overview plans and to refine details on other plans.

Cockpit supports this approach through its hierarchy concept, which implicitly creates relations while

modeling. In fact this happens automatically when an element is graphically included into another ele-

ment on some plan.

If such a refinement of an element exists on another plan, Cockpit allows navigating to this plan, although

there was no explicit relation created between the plans by the user previously. Relations between plans

hence are not to be created explicitly, but exist implicitly due to the contents of the plans. Thus, the navi-

gation links between plans are always consistent with the plan content.

New Customer Order






XOR



New customer

Customer is created

XOR





XOR


stock



XOR



New customer

Customer Management


Record CustomerData

Record StandardPayment Method

Record StandardDelivery Address

Record StandardInvoice Address

Customer iscreated

Commissioning of suppliers

Spare part is notin stock

Supplier Management

XOR

Existing masteragreement

No existing masteragreement

Create orderrequest

Order requestcreated

Selection ofsupplier via

invitation to bid

Supplier found

XOR

Create order

Order has beencreated

Dispatch order

Delivery has beensent

Search for masteragreements

Figure 8 - Cockpit-hierarchies

Figure 8 shows how the sub-process “Commissioning of Supplier” is refined. Cockpit automatically

creates the relationships between “Commissioning of Supplier” and the contained elements that are also

visible in the repository as a tree structure.



Hence it is possible to have one single plan for the overview and use it as a starting point for navigation to

additional plans for more detailed information.

Figure 9 - Hierarchy-symbol

If an element is refined in another plan in ARCWAY Cockpit, this is indicated by the symbol shown in

Figure 9. In navigation mode a double click on an element with this symbol enables to drill-down to the

refining plan. If more than one refining plan is available, a selection dialog appears.

The use of landscapes itself provides a high value through the obtained overview. Additionally it is possi-

ble to relate the plans to each other showing a system from different views. ARCWAY Cockpit supports

this by the concept of hierarchies already presented in section 2.4.

In addition to the hierarchy-relationships, all other modeled relationships are shown by selecting an ele-

ment in ARCWAY Cockpit, for example in Figure 9 the relationship "Supplier Management" modifies the

"Supplier Base”.

Based on such relationships, it is possible to answer for example the following questions:

Which applications are supporting a process?

Which processes are supported by an application?

Which business functions in a company are involved in the execution of a process?

Which business data is modified by a business function?

In which processes certain business data is read?

Cockpit supports the analysis of the relationships directly in the tool through the detail view, the reposito-

ry and the element graph. In addition, an evaluation can be done by generating reports.



New Customer Order






XOR



New customer

Customer is created

XOR





XOR


stock



XOR



New customer

Customer Management


Record CustomerData

Record StandardPayment Method

Record StandardDelivery Address

Record StandardInvoice Address

Customer iscreated

Commissioning of suppliers

Spare part is notin stock

Supplier Management

XOR

Existing masteragreement

No existing masteragreement

Create orderrequest

Order requestcreated

Selection ofsupplier via

invitation to bid

Supplier found

XOR

Create order

Order has beencreated

Dispatch order

Delivery has beensent

Search for masteragreements



Supplier Management

Customer Order

SalesManagement

BusinessAssessment

Supplier Base

Customer Management

Customer Base

Inventory List

Customer

Requisition Note

Supplier Order

Invoicing

Supplier

Bank




Customer Invoice

Customer Data

Customer Order

Dispatch

Receipt ofPayment

Payment Order

Supplier Invoice

Supplier Order

Delivery

Warehouse Logistics

Business Landscape Process Flows

Management

PurchaseDepartment


ResourcesDepartment

Supplier Management



Warehouse Logistics

Customer Management


Sales Management


Invoicing

SAP Systems

SAPPortal

Business Warehouse

Sales Management

SAP SCM

SAP CRM


Supplier Management

WarehouseManagement

BW Database

SCM Database

CRM Database

Customer Order

Supplier Order

Business Assessment

Inventory List

Customer Base

Supplier Base

Sales Manager

PurchasingAgent

Warehouseman

AccountManager


Invoicing

Customer Management

CarPart Web Shop


Office

Customer

BWClient

CSVInterface

CSVInterface


Requisition Note

Organigramm Application Landscape

Figure 10 – Concept of landscapes and integration of maps

Figure 10 shows an example of how the linking of elements can take place.

The business landscape depicts the business functions of a company and what business data they edit or

exchange via their interfaces. Putting a business function as a swimlane into the background of process

steps in an EPC, Cockpit automatically connects them. Due to the hierarchical relations it is possible to

evaluate, which processes and process steps are part of a business function.

In the application landscape the business functions are placed into the various applications, which support

the business functions in terms of IT. Also the business data can be assigned to the databases managing

them. Due to the hierarchical relations it is now possible to evaluate which applications support a business

functions and vice versa.



The organization chart shows the relevant organization units and their structure. The link to the other

plans takes place by assigning the business functions to the organization units. By means of the relations

it can be evaluated, which organization units are responsible for a business function or which business

functions are executed by an organization unit.



ARCWAY Cockpit not only offers a modeling component but also a complete and integrated

requirements management. It allows to manage requirements and to link the requirements with the plan

elements.

Figure 11 shows a screenshot of the requirements management component of ARCWAY Cockpit.

Figure 11 – Requirements management in ARCWAY Cockpit

Using the requirements management component, it is possible to detect potential for improvement and

to prioritize them. Based on this, ARCWAY Cockpit allows to manage the specifications of several imple-

mentation projects and furthermore to create complete requirement specifications.

The graphical plans offer the following benefits for the requirements management:

The plans are of great benefit in finding requirements. They enable a consistent and common pic-

ture of the relevant subject area for all involved people and they bring transparency into complex

subjects.

Collecting the requirements of the several plan elements allows a structured approach along a

common model. This ensures that the requirements are collected efficiently and technically com-

pletely.



The linking of the requirements with the modeling elements provides a comprehension long after

the capturing by the context information.

This comprehension is for example of high value for a following prioritization of requirements and

for the change management. Especially, if a person wants to understand a requirement from

another author, this context information has a high benefit.

Another aspect of the requirements management component of ARCWAY Cockpit is the ability to link

requirements to each other. This has among other things the following benefits:

The effects of changing one requirement on other requirements can be traced in a structured

way.

The appropriate coverage of business requirements by implementation requirements can be veri-

fied.

Figure 12 – Relation graph and editor for requirements

Figure 12 shows the relation graph of a requirement automatically generated on base of the defined de-

pendencies. In addition, the default editor for requirements is shown. Apart from the properties visible in

the editor screenshot, requirements can be enriched with user-defined properties (so called “custom

properties”) like it is the case for any other Cockpit element.



The key questions in the modeling of processes are:

What is done?

How is it done?

The “What” is shown clearly using business landscapes. Based on these overview diagrams the “How”

question is answered with the help of EPCs modeled for those selected process flows which are relevant

for the intended purpose.

The following sections describe how the various plans could be modeled and what is to be taken care of.

To illustrate what is being done in the company, the relevant business functions are represented in a busi-

ness landscape. Additionally, it can be shown which business data is exchanged between business func-

tions via certain interfaces, which business data is required for the execution of a business function and

which business data is modified or created. The following table shows the most important plan elements

used in a business landscape and their meanings:

Plan element Description

Business Function

A business function represents a scope of functions or an area of respon-

sibilities.

Tasks and activities which belong to a business function can be part of

several process flows. They can be executed by one or more organization

units.

Business Data

Business data are business objects relevant for the process which are

required, created or modified by business functions.

Business DataInterface

The business data interface is an interface between two business func-

tions to exchange business data.

read

An arrow pointing from the business data to the business function is

representing the reading of the business data by the business function.

write

An arrow pointing from the business function to the business data is

representing the creation of the business data by the business function.



read / write /modify

A double arrow between business functions and business data describes

that the business data can be read, written and modified by the business

function.

connected viainterface

An interface symbol describes a communication link between two busi-

ness functions. In contrast to access via a common business data symbol,

the interface means that the information is only passed through at the

interface and is not accessible permanently.

Figure 13 – Plan elements in business landscapes

Procedure

To create a business landscape it is possible to proceed in several ways:

Generating a list of relevant business functions

First of all the relevant business functions are added to the plan completely and positioned so that

the business functions related to each other are placed next to each other or one upon the other.

Then the business data which is required, created or modified by the business functions is added

and the particular access directions are set.

Generating the landscape based on central process flows

A business landscape is created step-by-step based on central process flows. Subsequently the

landscape can be completed by considering further more specific process flows.

Passing through process flows is also useful for the first case to check the completeness of the business

functions and business data.

Compared to a pure enumeration of the business functions the addition of business data has some bene-

fits. Among other things, jumps between levels of abstraction or regarding the granularity of the business

functions or an unclean separation of business functions can be detected.

Once all the relevant process flows can be explained using the business landscape, it can be considered as

appropriate and complete.

Example

At the beginning of Figure 14 the customer was added, who sends its customer data to the customer

management. They check the customer base and update the customer data. For a new customer they

create a new customer in the customer base.

In another process the customer sends a customer order to the customer order management. They have

read access to the already recorded customer data and the inventory list, to create an internal customer

order.



In addition to the customer order management the warehouse management has also access to the cus-

tomer orders to perform the delivery to the customer.

The customer order management has a modifying access to the customer orders, because they have to be

able to change customer orders. The warehouse management has also a modifying access to the custom-

er orders, because changes on the processing status of the customer order are saved directly into the

customer order.



Supplier Management

Customer Order

SalesManagement

BusinessAssessment

Supplier Base

Customer Management

Customer Base

Inventory List

Customer

Requisition Note

Supplier Order

Invoicing

Supplier

Bank




Customer Invoice

Customer Data

Customer Order

Dispatch

Receipt ofPayment

Payment Order

Supplier Invoice

Supplier Order

Delivery

Warehouse Logistics

Figure 14 – Business landscape



Levels

To create the business landscape above, at first the business functions “inventory management”, “incom-

ing goods inspection”, “outgoing goods inspection” and the “warehouse logistics” were added among

others. After including the relevant business data on this level of abstraction, it became obvious that these

business functions were too detailed for an overview. Because of that they were grouped into the busi-

ness function "warehouse management ", which was afterwards detailed in a separate plan. In the ex-

ample, the detailed business functions are still shown, nevertheless, but at this level they could be left out

now.

By using several levels the central business landscape remains clear, but still allows the drill down into

more detailed levels of the model. On these lower-level plans, data, which is required or used, can be

shown in more detail or more comprehensively, too.


Warehouse Logistics




PurchaseJournal

Sales Journal

Warehouse

Availability Check

Provison Order Delivery Note

Customer

Dispatch


Customer Order Inventory List

SupplierManagement

Requisition Note

Supplier Order

Supplier

Delivery

Goods Receipt Note

Goods Issue Note

Availability Notice

Open Provisions

Figure 15 – Business landscape detailed level

Figure 15 shows the detailed business landscape for the warehouse management. In addition to the busi-

ness data at the external interfaces the business data within the warehouse management is included. It

also would have been possible to describe the business data at the interfaces in more detail for example

by showing the detailed information contained in the customer orders.

When working with multiple levels, the overview landscape should be created in any case. Detailed plans

for several areas can then be drawn as required.



To illustrate how something is done in the company, the several processes are shown in detail in form of

event-driven process chains (EPCs). For this purpose, the several process steps and events of the process

are listed in their logical sequence.

The following table shows the most important plan elements used in an EPC and their meanings:


Process Step

A process step represents a single step within a process flow which is not

refined in the further modeling.

Process

A process is a step within a process flow, which is detailed in a separate

plan. Thus the process represents a logical sequence of process steps and

events.

Event

An event is generated by a process step and may result in different

process steps again.

Business Data

Business data is read, written or modified by the process steps.

The business data corresponds to the business data elements from the

business landscape.

Control Flow

A control flow is a predecessor-successor relationship between a process

step (or process) and an event.

AND

AND-Splitter

A splitter represents possible alternative or parallel processes. There are

three types of splitters:

AND: An AND splitter shows, that all out-going paths are passed

through in parallel.

OR: An OR splitter shows that one or more out-going paths are

executed.

XOR: A XOR splitter shows that exactly one of the several out-

going paths is traversed.

AND

AND-Connector

A connector represents a convergence of possible alternative or parallel

processes. Corresponding to the splitters, there are three types of con-

nectors:

AND: An AND connector shows that all incoming paths are

passed through.

OR: An OR connector shows that one or more incoming paths

are executed.

XOR: A XOR connector shows that exactly one of the several in-

coming paths is passed through.



Business Function

By putting a business function into the background of a process step or

process it is shown that the process step or process belongs to the busi-

ness function.

A business function corresponds to the element business function from

the business landscapes.

Organisational Unit

By putting an organization unit into the background of a process step or

process it is shown that the organization unit is involved in the execution

of the process step or process.

An organization unit corresponds to the element organization unit from

the organization landscape.

Application

By putting an application into the background of a process step or

process it is shown that the application supports the execution of the

process step or process.

An application corresponds to the element application from the applica-

tion landscape.

Figure 16 – Plan elements in EPCs

Procedure

To create an EPC first it has to be considered which event triggers the process. After that the process

steps following an event and the events resulting from a process step are modeled alternatingly. Process

steps and events are brought into a sequential order by using control flows.

In addition to the mere sequences of process steps it is also possible to model case distinctions and paral-

lel processes.

In theory events and process steps are always used alternately. In practice it has turned out to be useful to

leave out the representation of trivial events.

In addition to these standard EPC elements ARCWAY Cockpit provides additional plan elements to create

connections to other subject areas. For a process step it is possible to show which organization units are

involved in the execution, which business function it belongs to or which applications support it. This is

done by putting the corresponding plan elements into the background of the respective process steps.

Cockpit recognizes this assignment automatically. The connection is then visualized and can be navigated

via the Repository or Details View.

Example

Figure 17 shows the example process “New Customer Order” with the starting event “Customer wants to

place an order”. The process step “Search for customer data” follows to the start event. The result of this

process step is either the event “Customer is recorded already” or the event “Customer is not recorded

yet”. To be able to perform the process step “Record customer order” exactly one of the paths starting at

these two events must have been passed through, as indicated by the XOR-Connector.



New Customer Order



XOR



New customer

Customer is created

XOR




XOR


stock



XOR



Figure 17 - Event-driven process chain (EPC)

An example for putting related model elements into the background of process steps is shown in Figure

18. The business functions which belong to the respective process steps were placed into their back-

ground. There are no business functions put into the background of the processes “New customer” and

“Commissioning of suppliers”. Here the decision was made to show the related business functions for the

single steps of these processes in the respective detailed plans for these processes.

The assigning of business functions to the process steps helps to understand the process flows. In addition

to that - assuming this is done completely for all EPCs - it allows for an evaluation of which business func-

tions are involved in which processes and process steps.



New Customer Order






XOR



New customer

Customer is created

XOR





XOR


stock



XOR



Figure 18 - EPC with backgrounding

Levels

Since the EPC representation sometimes leads to quite extensive plans it can be useful to omit trivial

events. This means events, whose occurrence is self-explanatory. This is reasonable especially for pure

sequential sections. Thus, for example the event "Customer order created" after the process step "Record

customer order" may be omitted if it does not significantly contribute to the comprehension.

The use of sub-processes is another way to reduce the scale and the complexity of the plans. This also

allows the reuse of parts of the process in multiple processes, so that they do not have to be captured

redundantly.

In order to show that a process step is described by a separate process, the plan element “process” is

used instead of the plan element "process step”. In the example the process steps “New customer” and

“Commissioning of suppliers” are modeled as separate processes which can also be integrated into other

processes.

In the plan where the process is refined the process’ plan element has to be placed as a frame around the

process steps of the sub-process. As an example Figure 17 shows the process “New customer order”. The

process “New customer order” can be used as a sub-process in other processes.



The main question in the modeling of an organization in the context of process modeling is:

Who does what?

To show what is done by whom in a company, the relevant organization units are represented in an or-

ganization chart.

The following table shows the most important plan elements used in an organization chart and their

meanings:


Organization Unit

An organization unit is a department, team or a position that executes

the tasks to be performed within the company or participates in them.

Business Function

A business function corresponds to the element business function

from the business landscape.

By putting an organization unit into the background of a business

function it is shown that this organization unit contributes in the ex-

ecution of the tasks of the business function.

is subordinate

The relationship between two organization units depicts the hierar-

chical structure of the organization units or a thematic classification of

the organization units.

participates in

The relationship of an organization unit to a business function shows

that this organization unit participates in the execution of the tasks of

the business function.

Figure 19 – Plan elements in organization landscapes

Procedure

To create the organization chart at first the relevant organization units are to be added to the plan. As

required, the organization can be modeled down to the level of individual positions. The hierarchical order

of organization units is represented by relationships between the organization units.

The hierarchical relationship is useful for a functional division of departments. In this case the sub depart-

ments are part of the superior department. The hierarchical relationship is also appropriate, if there is no

functional subdivision but only a reporting line to be represented, for example the subordination of de-

partments under the management.



Relationships between organization units and business functions show which organization units partici-

pate in which business functions.

Example

Figure 20 shows an organization chart where the management was put above all other sections. The

assignment of the business functions takes place at the highest possible level. So the assignment of the

business functions to the sales department means that it is relevant for all subordinate sales departments.

This avoids the multiple assignments to all subordinate elements.

Management

PurchaseDepartment


ResourcesDepartment

Supplier Management



Warehouse Logistics

Customer Management


Sales Management


Invoicing

Figure 20 – Organization chart

Levels

If the organization chart becomes too large, equivalent to the business landscape, a detailed plan of sev-

eral model elements can be created. The assignment of the business functions then can take place in the

detailed plans.



The key question in the modeling of IT in the context of the process modeling is:

By what are the processes supported?

To depict how the various process steps are supported by IT, the relevant applications are shown in an

application landscape. It has to be considered between which applications there are interfaces, which data

is exchanged between them and where which application data is stored.

The following table shows the most important plan elements used in an application landscape and their

meanings:


Application

An application is a single software system or a module of a software

system.

Application Data

Application data elements can represent data storages or IT-specific data

that is necessary for storing or processing business data.

Examples for application data elements are databases, database tables,

data files and the data contained therein.

Application DataInterface

The application data interface is an interface between two applications

where application data is exchanged.

read

An arrow pointing from application data to an application means that

the application reads the application data.

write

An arrow pointing from an application to application data means that

the application creates the application data.

read / write /modify

A double arrow between an application and application data means that

the application can read, write and modify the application data.



connected viainterface

An interface symbol shows a communication relationship between two

applications. In contrast to using an application data element which both

applications have access to, using the interface symbol means that the

information at the interface is just transferred and is not accessible per-

manently.

Application

Business Function

support

A business function corresponds to the element business function from

the business landscape. By including a business function into an applica-

tion it is shown that this application supports the execution of the tasks

of the business function.

Figure 21 – Plan elements in application landscapes

Procedure

For creating an application landscape it is useful to play through a process and to step by step include the

involved applications into the landscape. The users of the applications often are illustrated on the left side,

because the reading direction is from left to right. In addition to that a uniform layout of the various ap-

plication landscapes increases the comprehensibility.

Starting with the user the applications which provide the user interfaces and the interfaces to the user are

included. After that systems which are involved in the background and the interfaces between them are

included. In addition application data, i.e. the data storages and the contained data, is included.

Furthermore the structure of an application itself can be looked at. In this case the plan element “applica-

tion” represents a single module or a logical unit of an application. There can then be interfaces between

these application parts again.

Example

Figure 22 shows an application landscape. The users are placed on the left side. They are connected via

interfaces with various applications which provide a user interface. One of the applications is the SAP

portal. This is in turn connected in the background with two other SAP systems via two interfaces.

The applications SAP CRM and SAP SCM each have their own database and are connected to a business

warehouse via a CSV-interface and to a web shop via an additional interface.



CarPart Application Structure

SAP Systems

SAPPortal

Business Warehouse

Sales Management

SAP SCM

SAP CRM


Supplier Management

WarehouseManagement

BW Database

SCM Database

CRM Database

Customer Order

Supplier Order

Business Assessment

Inventory List

Customer Base

Supplier Base

Sales Manager

PurchasingAgent

Warehouseman

AccountManager


Invoicing

Customer Management

CarPart Web Shop


Office

Customer

BWClient

CSVInterface

CSVInterface


Requisition Note

Figure 22 – Application landscapes

Business functions can be associated with applications which support them. In addition, the business data

is assigned to the storages, e.g. the database, in which it is stored.

Levels

The application landscape can become quite large, if particular applications are considered in detail. In

this case, equivalent to the business landscape, it is possible to model several applications in more detail in

separate plans.

If the application landscape already becomes too large without such detailed modeling, the plan element

“application” can also be used to group multiple applications logically. Then only this group is depicted at

the highest level.



The key question in the modeling of information in the context of process modeling is:

What is the structure of the information and which are the interdependencies between different

pieces of information?

To depict how the relevant information in the observed processes is structured and how different pieces

are interrelated, they are represented in a UML class diagram. In data modeling Entity Relationship Dia-

grams (ERD) are frequently used, too. But since UML class diagrams have become most widely accepted in

practice, they are used for data modeling in Cockpit. To create a UML class diagram it has to be consi-

dered which attributes the several classes have and which dependencies exist between these classes.

The following table shows the most important plan elements used in a UML class diagram and their

meanings:


Entity Type

An entity type (in UML also called class) is a category of similar

entities. Entities are clearly determined information objects. They

are the concrete instances of an entity type.

The typification of entities and the relationships between them to

relationship types is done by abstraction.

Business Data

Business data represents entity types regarded from a business

perspective.

Application Data

Application data represents entity types regarded from the IT pers-

pective.

Attribute

An attribute is a property of an entity type (such as name and date

of birth of the entity type employee).

Package

A folder is used to group semantically related entity types.

Specialisation

Relationship between a more general and a more specific entity

type in which the more specific entities are contained in the more

general entity types.

The more specific entity type implicitly has all the characteristics

(structural and behavioral characteristics) of the more general entity

type.



Composition

Relationship between the whole and its parts, in which the parts

cannot exist without the whole.

Aggregation

Relationship between the whole and its parts, in which the parts

can exist without the whole.

Association

General relationship between two entity types. The possibility of

more than two entity types being related through an association is

very rarely used in practice.

Figure 23 – Plan elements in UML class diagrams

Procedure

To create a UML class diagram it is useful to play through processes and to step by step add the required

and resulting information to the plan as entity types. Frequently, the less dependent information such as

master data is depicted on the left side, as the reading direction is from left to right. In addition, a stan-

dardized layout in the different plans enhances the comprehensibility.

The dependencies between the entity types are modeled by relationships. These can be specializations,

compositions, aggregations and associations.

The specialization is used to indicate that the more specialized entities are also entities of the more gener-

al entity type. Common properties of different entity types can be modeled with a common supertype. For

example the more specialized entity types “truck” and “car” can be modeled from a general supertype

„vehicle“ by specialization relationships.

The association describes a general relationship between two entity types, for example “driver uses car”.

The composition is used to depict parts of the whole, for example “bill has invoice items”. The invoice

items cannot exist without the bill.

The aggregation is not clearly specified in the UML, the specific meaning is left to the modeler. Typically,

the aggregation as well as the composition is used to express a relationship between the whole and its

parts. In the aggregation the parts can also exist without the whole, i.e. the bond is weaker than in the

composition.

For the individual entity types their several attributes can be modeled, if this level of detail is relevant.

Example

Figure 24 shows an example of a UML class diagram. Relationship arrows depict the compositions be-

tween the data elements. 0..n “contact persons” and 0..n “payment terms” belong to a “vendor”. In

addition individual attributes for example “salutation” and “title” of a contact person are shown.



Supplier

Company Name

Payment Terms

0..n

Vendor Number

Department

Street

Zip Code

City

Country

Contact Person

Phone

Salutation

Title

First Name

Surname

Email

0..n

Credit Limit

Term of Payment

Discount

Tax Number

Phone

Fax

Email

Homepage

Figure 24 – UML class diagram

Levels

If all information is considered in detail, the class diagrams can become very extensive. In this case it is

possible e.g. to depict the information on multiple levels, i.e. to create own plans for single entity types.

On these plans only the attributes of the entity type and the parts, which are contained in the entity type

through a composition relationship are shown.

If the class diagrams already become too large without such detailed modeling, the plan element “pack-

age” can also be used to group multiple entity types logically. Then only this group is depicted at the

highest level.



ARCWAY AG is the specialist for the optimization of business processes between IT departments and

business departments. ARCWAY offers solutions that improve processes within companies as well as

processes in which external parties are involved, e.g. technical sales and distribution processes and project

implementation processes of IT companies.

The uncomplicated tool for business process driven requirements management, ARCWAY Cockpit 3, de-

veloped by ARCWAY AG, consolidates business and IT views to clear, visually appealing presentations of

even complex issues and relations by means of its intuitive landscape concept. Thus, Cockpit 3 facilitates

the coordination of the different stakeholders by means of a unified language and allows preventing high

costs of rework.

ARCWAY AG

Potsdamer Platz 10

D-10785 Berlin

Phone +49 30 800 9783 - 0

Fax +49 30 800 9783 - 100

[email protected]

www.arcway.com

mailto:[email protected]

http://www.arcway.com/

version 1 - arcwaystructure of information and the relationships between different pieces of...

Documents