Hi
What are the arguments to use a library for objects like roles/ous, input/output, IT-stuff, etc.
In our firm, we have two fighting teams. One side will not take care about the group where the object will be stored (even the function-objects). I prefere to have some structure within the DB, and I undersand also the library idea.
But can you provide some pro arguments? Exept a clean DB, I dont have more pro's.
Thank you
Dominik
Hello Dominik,
since it is not possible to reach the property windows from the search windows when multiple objects are selected, this is a pro argument
Imagine you want to edit properties of all positions. If you list them with the search function, you can't edit properties of all objects.
In the explorer, you can...
I always use libraries for the "unique" reusable objects :
- Position
- Organisationnal Units
- Persons
- Applications, datas, exploitation systems, database systems
- Risks
- Business Rules ...
but not for
- events
- functions (i recommand no to try to reuse) :)
- operands ...
Regards
Good Morning Dominik
To piggyback on the answer Vincent gave, I'll add a few more pros as to why you should keep a library.
Properties and Attributes
- If you keep a library (of roles, for example) it is the standard of your entire process catalog. All process models should be built using objects from the library to maintain a consistency across your organization. This prevents other users from creating one-offs that don't fit with other models.
- When all models are built using objects from the library, property and attribute changes can be made to that library object and those changes will cascade down to every instance of the object throughout the catalog (this assumes the proper copy and paste operation was used)
- Also, if you are part of a growing business, it will be much easier for new domestic or international affiliates to understand the how they are going to set up operations and the people their going to need.
Hope this helps you win your battle.
Ryan
Another important reason is governance. This may not be too important when you area starting out but it will become an issue as your modeling matrues and expands. There are multiple important aspects of governance:
1) Permissions are set in ARIS at the folder level. Moving reusable objects into there own folder allows you to control who is allowed to modify them.
2) You can immediately tell the difference between an "official" (or approved) object and one that is not. This can help you determine whether or not to reuse an object in your model.
3) Having standardized and resuable objects is the only way you be able to do impact analysis moving forward.
This is also not an all or nothing choice. From an Enterprise Architecture perspective the various architects maintain the library folders and include only approved objects. As other modelers are building out their models they can create new objects in their working folder where their models are. As the in progress models become stable the Architect can quickly find new objects in the modelers folder and determine whether they are truely new and needed to added to the library or if there is another (standard) object with a different name. If so, the new object can be easily consolidated into the standard object using basic ARIS functionality.
Rick
I understand the idea of using a "library" of pre-defined objects so we can re-use them and have consistency across all process models.
However, in my experience, this is practically impossible to manage. We have multiple teams all over the world creating new objects and new models all the time. I don't understand how I can possibly tell them "you must always use an object from the library" when most of then do not exist yet. Also it seems like a huge administrative job to constantly go through all of the objects (numbering in the thousands or tens of thousands) to rationalize them, move them to the library, etc.
To my knowledge there are many practical difficulties here; for example there is no easy way (that I know of) to gather all objects to a specific location; I think you have to deal with them one by one.
Does anyone have a practical process for managing this ; if yes, how does it work? And how many people does it take to administer it?
thanks in advance
John