Generating hierarchical identities

Hello Mr. Gagge,

last question first, because it is the most important one: Is it worth the effort, maintaining a numbering scheme for your processes? Technically every ARIS model and every ARIS object has got an identity, ARIS hides it well, because it is a 128 bit hexadecimal GUID. No one is ever going to read that or work with it - unless it happens to be a piece of software code. But keeping that in mind you can rest assured, that nothing will change that identity ever. You would have to create a new model, copy everything over from the old model and throw away the old one in order to break that identity.

When you contemplate having a human readable numbering scheme and consider renumbering objects due to changes in the hierarchy, it becomes questionable what the value of "identity" is in this case. People will find the same object suddenly under a different identity. People might start using these identities as techie-talk like in "I'm the owner of the 2.3 process family. (You are not in the know what 2.3 is? Well that's the new combination of the 2.4.3 and 3.2.5 process areas of last year)." (??!)

Speaking of references in quality manuals. The quality manual should be generated from your modelling. Then the numbering can be created upon reporting (and forgotten with the next process change). Or even better: The quality manual should be accessed online directly in the Connect Portal. Of course, not every business has everybody equipped with a tablet or other online access. There is analog work to be done.

If the content of your quality manual really is out of scope of your modelling, I would suggest to refer to the names of processes or other objects instead of numbers. As you realized with your renumbering considerations, the names of the objects are probably more stable than their numbering. Terms mean more to people than arbitrary numbers.

Now, in case a numbering is worth the effort (you are very convinced it is, because you give a lot of thought on this), here is an idea: Do the numbering upon sign-off. When anything unnumbered gets a signoff, the sign-off process will create the number by looking at the number of the superior object (e.g. 2.3), then looking at all objects below 2.3, take the largest one of those and add +1 in the last digit. In the course of this it may happen, that the object being signed off has changed its position in the hierarchy (maybe before it was under 2.2). In this case it must get an entirely new number and the entire tree below it also has to be renumbered. If you are using APG for sign-off procedures the execution of such a report would be just another step. I know a customer who does it that way. And you are independent of Macros, which do not work in Connect Designer.

As to which Attribute type to use: AT_ID is a candidate, if you do not intend to use it for the built-in ID generation mechanism. It can be a string of up to 32 characters. AT_REFERENCE_ID is a candidate, otherwise you certainly can make your own ID attribute. The nice thing with AT_ID is, that ARIS will check it is unique globally.

For the service architecture there is the service architecture diagram for building your hierarchy. If you like the standard symbols for different hierarchical levels you don't even have to make up your own. The Service allocation diagram is the analogon of the function allocation diagram for services. You put a single service in the center and everything that describes it all around it. For example here you could associate the process that implements the service (if it is provided in-house).

Thanks for your analysis. Since there's no easier way, we'll probably go for manual management. We do need external references: we have a balancing act between our intranet from which we want to direct people to the appropriate models; ARIS;  and documents in stores such as SharePoint from which certain models should be referenced. URL's are a starter, but a stable identiy is a pretty good enterprise content managment principle, allowing us actually to replace a model entirely (with a new GUID and URL) in a later version, if needed.

Well, some scripts could support you in your numbering scheme.

Indeed the GUID is encoded in the URL, so it is stable as long as the model lives. So if you maintain the model instead of creating new models (with new GUID and URL) for "new versions", all your links in your documents will remain valid. Use the versioning mechanism of ARIS instead for managing and publishing new versions of your model.

Have you taken into consideration to link the other way round - from ARIS model to Sharepoint location? You could have an object of type information carrier in ARIS as a representative of your sharepoint document. You link this object to process steps or whatever objects are appropriate and this object is the single point inside ARIS which knows the link to the Sharepoint document. That makes maintaining that link simple. And in the portal you can access the document with a click of your mouse, while Sharepoint enforces the access permissions the user has.