Using Variants of Functions

Hello Christoph,

in reply to a different post I explained, why I think it is not a good idea to have libraries of functions:

http://www.ariscommunity.com/users/ralf-butler/2014-06-07-connection-occurrence-issue

While it is a good idea to have libraries of person types, org. units, Application system types, Entity types, ERM attributes and many more object types, please don't do that for functions. They are the one type, which brings together all the rest and that is unique in every process, and may they be as similar as anything.

Variants may be a solution, but I would suggest to use them for entire processes, e.g. a reference process versus its local peculiarities in different org. units or geographies. Variants essentially are definition copies, which additionally maintain a logical link to the object they were copied from.

If you want to create a functional library - in the sense that there must be an abstract function, which performs a certain task in the context of various processes, try to establish a capability architecture, where common capabilities support the function instances in different processes. Another way of looking at reusable functions might be the concept of "Business Services" (Object type "Service type"), but probably one would apply that concept for higher-level functions.

Regards, M. Zschuckelt

Hi Zschuckelt,

Thanks for your opinion. What you say makes sense and I think I understood what you pointed out. Out of the context of my specific problem: If I do the exact same step in two different processes, I still should go for two separated functions (even if this precise step is EXACTLY the same in both processes)? If so what sense does it make to have instances of functions?

Since we can not use multiple instances combines with risks, we anyway will need to go for the variant solution. One concern towards that is about the versioning. Does that work without problems on variant functions?

Also, what exactly do you mean with capability architecture? I did not quite understand that paragraph.

Thanks a lot!

Christoph

Hello Christoph,

Let's say you have a "process 1" sequence with the steps "Do A" - "Do B" - "Do C". And in another "process 2" you have the sequence "Do F" - "Do B" - "Do G". You would like to reuse "Do B", which I say you should not.

You can see it from the technical point of view: If you reuse "Do B" function in both processes, the "Do B" definition has two predecessors "Do A" and "Do F" and likewise two successors "Do C" and "Do G". So if you examine the objects at definition level those relations are ambiguous. And ARCM is stumbling across the function hierarchy, because it doesn't know whether the "Do B" function is a process-oriented subordinate to "process 1" or "process 2" function.

Seen from the business point of view: "Do B" may be exactly the same function, but possibly it has to be carried out by different roles in the different processes, so the satellite objects may vary from process to process. Or the expertise needed to perform the same function may vary depending on the topic of the process. E. g. "Assess indemnification claim" in an insurance may depend on the insured risk (sickness, house). The description of how it has to be done will differ considerably. So a function is never free from the context of the process.

Now the capability idea. ARIS offers an object type called "capability". Let's say you define a capability "can do B". Now in each process you assign "can do B" to the "Do B" function with the "supports" connection. You place "can do B" in a capability library. And then you describe everything that is common to all "Do B" functions at the capability "can do B". You may also use such capabilities to identify candidate roles for performing the "Do B" functions, if you have assigned the capability to a person type. Or you might assign capabilities to org. units, which provide "Do B" services. Maybe you define capabilities at a more granular level than "can do B", so you use them in the sense of qualifications or authorizations. Then multiple qualifications might be required to perform "Do B" in a certain process and you might discover, that in another process "Do B" actually needs almost, but not quite the same capabilities.

To sum it up: Use functions as the knots of knitting your process flows. Use capabilities to weave the common patterns of the functionality into the mesh.

Regards, M. Zschuckelt

Hello Christoph,

the delegate approach is -- also in my experience -- a sound approach. If the requirements in one of the two flows changes, the to step B might not be the same anymore. The delegate approach let you fix that elegantly.

Hello Mr. Zschuckelt,

I by principle define each step of a workflow in a way,  it is independent of its predecessors and its successors. Each step gets its input data, does its duty and emits its output. A step is a function and as a function is side-effect free. As a result a step could be called from everywhere.

Beside this even within a single workflow a step following a join node has more than a single predecessor and a step directly followed by a fork node has more than a single successor. How does this technically differ from the case of Christoph. 

Hello Zschuckelt,

thank you very much for this elaboration! I did not know ARIS has this object type. I will give it a try and see how this approach fits together with the work we've done already. I even like the approach more then the variant version since you again have only one central point (the capability) on where to do the data maintenance in case something changes in the way how the function is carried out. Maybe it even makes sense to combine both approaches in order to have the benefit of a central point of maintenance but still have some sort of connection between all "same" functions. We'll see :)

Thanks again for your time and help! It's much appreciated!

@Carsten: Thanks for your opinion as well!

Christoph