Profile picture for user uro

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.

by Erik Hagen
Posted on Mon, 09/28/2009 - 18:42

Thanks Uwe, I find the topic highly relevant and your article giving useful insight. I have the following comment: The concept as such shouldn't be limited to EPC for the "Business Process Level". Some people would argue that BPMN can be used for the process flows also on that level, and some organizations indeed already have standardized on BPMN for that. In addition, of course, ARIS Function Allocations Diagrams and other model types provided by ARIS are needed to describe details that cannot be described by BPMN itself (such as e.g. risks or the relation to Capabilities and Business Services). Don't get me wrong, I agree that EPC is excellent at the "Business Process Level", but it shouldn't be the only option.

0
by Uwe Roediger Author
Posted on Tue, 09/29/2009 - 08:40

Hi Erik,

I agree that we cannot limit the busniess process level to EPC usage only. To use EPC at business level and BPMN at technical level is the preferred IDS positioning, but not the only one we will support. But you have to keep in mind that if BPMN is used at business level too it get's complicated to differentiate between 'business' BPMN and 'technical' BPMN.



For the discussed topic of abstraction layers vs. views this topic is not relevant from my point of view. I think the user would expect to be able to switch between business and technical view independent whta daigram types he's using.

0
by Ruben Rivera
Posted on Wed, 09/30/2009 - 18:47

Also I found the topic highly relevant and agree with Erik tha the article gives useful insight.

I think that the effects of the advantages or disavantages of using the same object at differents layers of abstraction could be higher or lower depending on who is modeling what.

Regards,

Rubén

0
by Ivo Velitchkov
Posted on Wed, 09/30/2009 - 19:20

Uwe,

I think that it all comes down to the capabilities of contemporary notations to satisfy interests of different stakeholders. It would have been great if there is just one notation with different rules for presentation, interpretation, interaction, selection etc depending on the user needs, and have neat way to transform or filter. Then may be the approach to have occurrence copies for identical objects might be the right approach. In the current situation the transformation integration is better to be in the transformation rules not in the objects as this would impose unnecessary limitations in each level.

 

Regards

Ivo

0

Featured achievement

Rookie
Say hello to the ARIS Community! Personalize your community experience by following forums or tags, liking a post or uploading a profile picture.
Recent Unlocks

Leaderboard

|
icon-arrow-down icon-arrow-cerulean-left icon-arrow-cerulean-right icon-arrow-down icon-arrow-left icon-arrow-right icon-arrow icon-back icon-close icon-comments icon-correct-answer icon-tick icon-download icon-facebook icon-flag icon-google-plus icon-hamburger icon-in icon-info icon-instagram icon-login-true icon-login icon-mail-notification icon-mail icon-mortarboard icon-newsletter icon-notification icon-pinterest icon-plus icon-rss icon-search icon-share icon-shield icon-snapchat icon-star icon-tutorials icon-twitter icon-universities icon-videos icon-views icon-whatsapp icon-xing icon-youtube icon-jobs icon-heart icon-heart2 aris-express bpm-glossary help-intro help-design Process_Mining_Icon help-publishing help-administration help-dashboarding help-archive help-risk icon-knowledge icon-question icon-events icon-message icon-more icon-pencil forum-icon icon-lock