CU
We are currently just starting our journey with ARIS, BPMS & ESB, so we are investigating some of the governance we might want to wrap around the software stack we've purchased.
As a first step we are reviewing the different components/objects available in the 3 different modeling languages, (available under the licensing we have purchased) that ARIS supports i.e. EPC, BPMN & Archimate. We will then decide on a standard set to be applied across the organisation.
We will also be considering standards for individual models and I would appreciate your thoughts, or lessons learnt in relation to this. Particularly from those that are using the full ARIS, BPMS, ESB stack.
Should we allow composite pallets to be used in a single model e.g. EPC combined with BPMN?
- Is this considered to be good practice?
- What are the implications further down the stack if we do this e.g. for process automation in BPMS, or even further down in ESB?
- What impact will using composite models have on reporting?
I'm also interested to hear from you generally on:
- What you wish you had been made aware of at the very beginning of your journey that might have changed the way you approached implementation of ARIS?
- Any other lessons learnt, hints or tips, that you think it would be useful to pass on.
Thanking you in advance for any advice provided.
Hello Claire,
if you put multiple notations in a single model the immediate impact is that you leave the standard, which may be detrimental to integration with other tools you might want to integrate with. E. g. if you put non-standard elements in a BPMN model, it is unclear how that behaves, if you want to integrate with other tools that speak BPMN. Certainly the BPMN export format won't know how to handle your additional information. The same applies to Archimate, which has got a well defined exchange format prescribed by the standard.
Rather use layering techniques (with the assignment mechanism of ARIS and occurrence copies) to connect different viewpoints.
Since each ARIS model is only a view on the underlying model of definitions you can report on all connections existing independent of the chosen viewpoints.
If you prefer BPMN over EPC for the business viewpoint: Make sure you reduce the vocabulary for that level. The full BPMN vocabulary is adequate for IT people describing technically executable processes. You could use EPC for business level and BPMN for solution design level. Archimate is another option, which offers high-level views on the architecture from business strategy down to deployment, but it is not intended to do the (executable) details like BPMN does. You can read that statement also in the Archimate specification. Rather the specification gives hints where to make the links.
Lesson learned: Use each notation for what it was designed for. Also observe chapter 7.2 of the BPMN specification on the scope and limitations of BPMN. Use layering techniques to connect the viewpoints. In ARIS use assignments to connect BPMN items to models describing what BPMN can't model well: Risk, data, organization, roles, UI, capabilities...
This is really excellent practical advice. Thank you very much M. Zschuckelt.
My pleasure. And another remark: Mixing notations in a view is also detrimental to the readability for people who were educated in a certain notation. It will confuse them as well. In ARIS the different notations (symbols) map to suitable object types on definition level, e.g. a data object in BPMN may appear as a Cluster/data model symbol in an IE data model type: Identical object, hence you have all the links to do reporting across notations and thus add the links BPMN alone is not capable of.
EDIT: And another thought: Consider the stakeholder roles you want to bring together, which might be Process owners, data architects, service architects, application architects, product owners... Each will have their view, so let them contribute their view with a suitable notation (e.g. IE data model for data architects). Sketch a map of what the concepts (object types) are each stakeholder deals with and identify, where they relate to each other. Each object anyone creates should be owned by a well identifiable stakeholder and should be governed in a view this stakeholder is in control of. Then it should become clear who will relate to which concepts from other domains. We call this sketch a metamodel.
