User defined attribute

Hello Mijo,

to me it seems very unusual, to have an attribute type with an enumeration of 500 literal values. Without any idea, what it is, that you want to store in that attribute type, I would suggest the following:

Find an object type, that represents the concept of that intended attribute type. Create a library of 500 objects and find a suitable model type, where you can represent semantic relationships between the objects you intended to carry that attribute type and those objects. (Or if there is no such model type, create one yourself.)

This makes it a lot easier to maintain those 500 instances and you can give ownership for the library to someone who does not have Configuration privileges. Also with objects you have attributes at you disposal, e.g. "Description/Definition" that can help users to find the correct one among the 500. That saves you a lot of hassle, if you find one of those 500 obsolete or discover the 501st. If the attribute type was supposed to be mandatory, establish semantic checks for validating that the relationship to that object type exists.

Regards, M. Zschuckelt

Hello Mijo,

simple as that: Suppose you have a process owner "John Doe", who leaves the company. Responsibility for his processes gets redistributed to other process owners, not just one.

1. You need to find and maintain all processes, that John Doe owned.

2. You have to get rid of the attribute value "John Doe".

So renaming the attribute value does not do the job. Later a new process owner is appointed and you have to add a new attribute value. During daily business you have to keep editing the ARIS method.

If you use "internal person" object for "John Doe" and the other 100 process owners, you can simply model a relationship between the process object in the function allocation diagram and use a connection type like "is technically responsible for" (or some other connection type you prefer) between John Doe and the process object. This way you can simply go on the "John Doe" object and learn about all processes he is responsible for. That also makes it easy to reassign all processes when John Doe leaves the company.

Also you could give ownership of the library of process owners to the "Global process owner" and you do not have to fiddle with the ARIS method at all, when personnel changes. In the ARIS method filter you only define, that an internal person can be connected to a process in the function allocation diagram using the "is technically responsible for" connection type and for the methodical part you are through with the topic.

Changing personnel should not be an issue of the ARIS method configuration, because it is model content. You do yourself a favour if you do not introduce ever changing content in method literals.

Regards, M. Zschuckelt

Hello Mijo,

sorry, so here is the final answer: no. The method is not intended for modelling purposes. There is the Excel-Import report, which would be my recommendation to use for creating the 100 person objects, but as far as I know there is not even an API to achieve what you intend using a report script.

Consider also the scenario, that you create versions of your model content. Suppose one day you delete the process owner "John Doe" from the attribute value list, who used to be a process owner in history. As this is an object in the method, I could imagine, that after deleting it even when looking at the old versions you might not see the attribute value "John Doe" any more. But I have not tested this. It's just a hypothesis. So my strong recommendation is: The method should be stable! Process ownership isn't and neither is the set of process owners. So make Process owners a part of your meta-model, if they matter to you.

Attribute types of type value are intended for stable categorization schemes like "high, medium, low" and the like. Such schemes tend to have few categories. Of course you can also use a screw driver as a hammer, but you might not become happy with it.

Sorry that I stressed this again,

Regards, M. Zschuckelt