Changed Model Types

The previous subsection introduced the new object and symbol types, which were added to the ARIS modelling language. Besides, also model types (i. e. diagrams) are needed to do the actual modelling. This subsection describes the model types changed by the ARIS extension.

The model types do not distinguish internal and external views on the service descrip- tion (see subsection 3.3.1), because there is no general applicable rule defining which information must belong to which view. Instead, it is expected that users separate the

Capability

Sub Capability 1 Sub Capability 2 encompasses

Figure 3.11: Service architecture diagram used for modelling capability architecture

views on their own and distributed the information between different model type instances of the same type.

Service Architecture Diagram

The SOA meta model shown in figure 3.6 specifies that it must be possible to build a hierarchy of service types. For this purpose, the model type “service architecture diagram” is used. As shown in figure3.10, an “encompasses” connection type can be established between two “service type” object types. The usage of the “encompasses” connection type is not constrained by the symbol type of the object types. Therefore, it is possible to do arbitrary nesting between different service types. This is needed, because the number and naming of symbol types must be customisable so that users can introduce their own symbol types (i. e. categories) of service types.

The model type “service architecture diagram” existed before, but was named “enter- prise architecture model” before. It was previously used to model a hierarchy of “functional cluster” object types. As the belonging proprietary modelling technique “IT city planning” is not used anymore, the model types used before were renamed and reused for service- oriented modelling on a computational independent level.

The model type “service architecture diagram” can also be used to describe a hierarchy of “capability” object types. This is not shown in the SOA meta model, because it was not a requirement of the involved consultants. Instead, it was already possible to model a hierarchy of “information system function” object types in the past. As the “capability” object type is replacing the “information system function” object type, this model concept must be preserved in the ARIS modelling language. Similar to the hierarchy of service types, also an “encompasses” connection type can be modelled between “capability” object types in the “service architecture diagram” model type as shown in figure3.11.

A service architecture diagram can also be used to relate capabilities to service types. Here, the connection type “encompasses” is established pointing from a “service type” ob- ject type to a “capability” object type. However, modelling the capabilities of a service type in the service architecture diagram is not recommended, because the service architecture diagram should contain overall information on the service architecture but not specific in- formation only influencing a single service type. For the latter case, the model type “service allocation diagram” should be used, which is introduced in the following paragraph.

Service Type Capability encompasses Software Service Type supports Organizational unit provides Business Object 1 Business Object 2 is input for has output of Business Object 3 is owner of Organizational unit type is responsible for Process realizes Objective Product/Service realizes supports KPI Instance is measured by

Figure 3.12: Service allocation diagram

Service Allocation Diagram

Figure3.12 shows the model type “service allocation diagram”. A service allocation di- agram is used to describe an individual service by collecting all necessary information. For example, capabilities can be related to the service type and a service owner can be defined. The “service allocation diagram” model type existed prior extending ARIS, but the model type was called “IE context model”. This model type was also used in the now obsolete modelling technique “IT city planning”.

The connection types used in the “service allocation diagram” often do not correspond to the relations defined in the SOA meta model. For example, the SOA meta model defines a connection type “describes” pointing from a capability to a service type. However, in the service allocation diagram a connection type “encompasses” pointing in the opposite direction is used. The reason for this discrepancy is that existing connection types were reused while designing the ARIS extension. Even though this is not an optimal solution from a scientific point of view, it is a pragmatic solution enforced by the ARIS method owners.

As shown in figure 3.12, a service type can own, process, and produce business ob- jects. Such business objects are represented in the ARIS modelling language by the object types “technical term” and “cluster”. The shown connection types can be defined between technical terms and service types as well as between clusters and service types.

There are different object types possible to represent an organisational object. Fig- ure3.12 only shows the object type “organisational unit”. However, the connection types relating the object types “service type” and “organisational unit” shown in figure3.12can

Service Type

Service Type Service Type

Service Type activates

Figure 3.13: Service collaboration diagram

be also modelled between the object type “service type” and the following object types, which all represent an organisational object in the ARIS modelling language:

• organisational unit type

• organisational unit • person • group • position • location • person type

The service allocation diagram documents static aspects of the service description. It can be used as a view on internal as well as external description elements. Dynamic descriptions are modelled in the service collaboration diagram, which is discussed in the following subsection.

Service Collaboration Diagram

Figure3.13 shows a “service collaboration diagram” model type. It is used to model dy- namic aspects of the computation independent service description. Prior the ARIS exten- sion, a model type “IE activation model” existed. This model was renamed by the ARIS

extension. The service collaboration diagram provides various constructs to model the dynamic relationships between services and their environment. However, those modelling capabilities already existed before and were not changed by the ARIS extension. The model type is still affected by the ARIS extension, because the “functional cluster” ob- ject type was renamed to “service type” and a new symbol type “business service” was introduced.

Service Support Matrix

A service support matrix is used to model the spatial availability of a service. However, the service support matrix is not an own model type in the ARIS modelling language but instead a specific feature of the ARIS software tools. The ARIS software tools allow cre- ating a matrix by assigning different object types as column and row headers. At the end of the chapter in section3.7, an example of such a matrix is provided in figure3.16. It can be seen that the service type defines the column header and the different locations define the row headers. The cells contain all those realisations of the service type, which are available at the location specified in the row header.

Time Based Modelling

Similar to the service support matrix, time based modelling is a specific feature of the ARIS software tools, but it is not an own model type in the ARIS modelling language. Time based modelling looks similar to a service support matrix. The column header is defined by the service type and each row represents a point in time or a time range. Each cell contains all realisations of the service type, which are available at the time specified in the row header.

Event-driven Process Chain (EPC)

Besides services using the different model types described in the previous paragraphs, services are also used in business process modelling. Therefore, it was necessary to extend the EPC notation. Figure 3.14 shows the possible connection types. It can be seen that “function” object types can be related to “service type” object types using the “supports” connection type. This modelling construct describes that the execution of the function is supported by the service type. An employee executing the business process can look up the description of the service type to identify a service realisation or service provider.

Another use case of service-oriented business process management aims at automat- ing all functions of a business process so that the business process itself can be executed on a process engine. Therefore, it is possible to relate “software service type” object types and their operations (i. e. “software service operation type” object types) to functions in the business process using the “supports” connection type. Here, it is important to note that the software service types represent services implemented through technology, but not specifying which technology is used. This ensures that the business process models do not contain any platform specific details. This is important, because if technology changes, the business process models can be reused without changing them.

The relations shown in the EPC model in figure3.14can also be modelled in a “function allocation diagram” model type. A function allocation diagram is assigned to a function in a business process model to move information in a separated view. This reduces the overall

Service Type StartEvent Function OT IntermediateEvent supports Capability supports Business Object 1 Business Object 2 Software Service Type Organizational unit Software Service Operation Type supports carries out supports

Figure 3.14: Extended EPC model

complexity of the business process model, because not all information is made available in one diagram. The “function allocation diagram” model type cannot be only assigned to a function of an EPC model, but to any “function” object type. This object type is also used in BPMN models. Therefore, the ARIS extension also supports service-oriented business process management using BPMN for business process modelling.