What are your views on using Occurrence copies of Process Interface object type and Signal Event object type in both EPC and BPMN diagrams.
I'm told for projects this is manageable but when you need to integrate this into the Enterprise Architecture of the business, the effort required to ensure integrity is very high and this includes ongoing maintenance
Your comments would be most valuable.
Hi,
I don’t know how are you going to use Process interface in BPMN (it is impossible for BPMN models), but of course you can use events in both types of models to connect them, but I cannot understand why do you use both types of models in parallel. And you can use not only signal event, for EPC it’s does not matter what kind of event you use.
What about integrity, if I’ve understood you clearly. There is standard built-in semantic check script for events checking on different models, it works on EPC models, so you should modify it for your needs. Other way we did is checking for start and end events connected models and then adding automatically text annotation for such event with name of previous or next process.
Regards, Alex
Penny,
like Alexander said there is no PI object in BPMN. What we did in the past was using the expandable meta model capability and allowed assignments of processes (BPMN) to start/end events, so that an end user/reader doesn't have to use the "occurrences" tab in the properties to navigate to the previous/next process.
I know that the BPMN purist might not like that, but I think that is a nice addition which was well accepted by our non-ARIS users.
-Roland
Hello Penny,
here is an example of the "pure" BPMN process interface. Here the events on both sides should not be occurrence copies. Mailing a letter is different from the postman delivering it to the recipient's letter box. The letter, however, is identical of course. Hence the message object should be an occurrence copy. And the pools participating in the collaboration should be identical on both sides as well.
I recommend writing semantic checks to check the integrity of models participating in a communication. Also do assignments to the black-box pool objects that take you to the description of the source/target process. I did so for a customer that used this pattern intensively.
Also consider, that for one process the event might be "invoice mailed", while for the receiving process it may be "letter received" initially. So with this pattern each process keeps its own view of its business. Consider, that you may be talking to different stakeholders or process owners on both sides of the interface.
Regards, M. Zschuckelt