Uwe Roediger's picture

In other articles (e.g. “Data modeling in ARIS”) I spoke about the different abstraction layers that we use in IDS SOA methodology. Again the picture with a part of the elements according to the three levels:

Abstraction layers

Not all artifacts will be described with different object types for the different levels. The organizational unit for example will be assigned to the business function as well as to the technical function. Same is true for capabilities or KPI’s. On the other hand we have elements like process steps, data objects or services where we are distinguishing clearly what object type has to be used at a certain level (e.g. Business level – Business Service; Automation level – Software Service; Execution level - Webservice).

But is this approach really the optimal? Often we are asking ourselves this question, the last time when we started to implement a common EPC2BPMN transformation. It was the question if we should re-use the function from EPC as occurrence in BPMN or if we should create a new definition and link it with the source object.

We decided not to re-use because of the following reasons:
• One function on business level is not always connected 1:1 with a technical function. I could be that a one business process step has to be transformed into several technical steps.
• It happens that a certain attribute of a business function should have another value than the same attribute of the technical function (e.g. the name of a technical function has to follow some restrictions that are disturbing at business level).
• Changes done at technical level to the element would directly visible at business level too.
• It would not be possible to create a new version of the business function and to work with this new version at business level but to use the old version for the implementation at automation or execution level

So we had good reasons for our decision, but there are also disadvantages:
• The size of the database is growing because more objects are created.
• The elements at business and technical level have to be kept in synch.
• If a business function corresponds to exactly one technical function and if at technical level only additional attributes are needed we have a redundancy but no added value.
• If elements have semantically relations to each other (service knows data, service knows function, function knows data) and all of these elements have different types at the different abstraction layers, we get a very complex object net that has to be kept synchronized. This leads to the need for a very sophisticated internal round-trip support between the abstraction levels.

One often heard proposal is: “Why don’t we avoid the redundancies, use always the same elements and offer only special views for the different roles and abstraction layers?”
This idea seems to be a simple solution for the described problems. We could start with a business process (EPC view), containing business data objects and business services. At the next step technical information will be added like logical data objects and software services. The customer can switch between an EPC and BPMN view showing the same process elements and will see only the data objects and services relevant for the current context.

But there is a big problem with this idea. It seems possible to create read-only views for opening diagrams and navigate through the repository. But is this enough or is it essential that the elements and diagrams can also be changed in the different views? If yes, how could conflicts be avoided or solved that occur due to changes done by different roles? And how could be prevented that changes at the technical level are propagated to the business level too? Sometimes this might make sense but for sure not always.

Also an interesting question is, if a mix of the two concepts would be possible and meaningful. But in this case it’s a hard decision to decide when to use different objects to differentiate between the abstraction layers and when only to create views.

What do you think about this topic? Is this relevant for you daily work with our tools or do we break our heads about pure theoretical problems far away from the customer needs? Your input is highly welcome.