Best Practice - Release Management in ARIS Architect

Hi Volker,

This is almost exactly the same procedure I use, the difference being that I don't use variant copies for changing the model. The reason I don't use them is because I use the Change Management attributes, along with versioning, when it comes time to change a model. If you make a variant copy of a model, the "History" of any changes contained in the Change Management attributes of the original model do not carry over to the variant copy. Further, 'Version" numbers do not carry over to a variant copy.

The way I handle the update to a model is, after the requested change to the process has been approved by the interested parties, I move the model from the 'Release" group into the group where the modeler has update priveleges. I guess I consider versioning, Change Management and a good database backup strategy as a "safety net." You could also adopt a "version strategy" for web publishing that allowed for a few different versions to be avilable on the web site at any given time.

Just a couple thoughts for you.

Best Regards,

Bob

Hi Volker,

Apart from the issues highlighted by Bob, using Variants to design TO-BE process (in the same database but within a separate folder under "Main group") also have few other disadvantages:

• Increase in probability of messing up object usage (Occurrence & Definition copies) across process models.
• Process Analysis on the database should always take into consideration the existence of such model variants (which could be high if its a large organisation with lot of processes with some amount of decentralised process ownership).
• Variants can be created in Business Architect only - so you need sufficient Business Architect : Business Designer user ratio to ensure Business Architect users do not become a bottleneck in the Process Optimization exercise (This although is not a major issue as having Architect review / approve usage of Variants is a good practice).

The approach mentioned in your post also have lot of human dependancy -- wondering whether that's ok or should you look for an approach with as minimal human dependancy as possible.

As for our experience, we currently use multiple databases integrated with RCM. The development database will have the models locked, if they are submitted for review & release in RCM and are unlocked after RCM approvals are done.

Though the approach itself hasn't presented any issues so far, the RCM implementation is rather viewed as a imperfect solution with lot of open issues. Now we are told APG will handle our needs but yet to see a good business case for it.

Few things I would like to know more from experiences of yourself & other community members:

1. How are the model reveiws / approvals handled in your approach? Is it using RCM / APG or some other way?
2. How are model merging supposed to be handled in your approach? Will it be simple?
3. What has been the experience of organisations using APG? Good Practices / Lessons from that experience?

Anyways, this is definitely a weakness with ARIS and need IDS to come up with a strong solution. Is anyone listening?

 

Hi Volker,   Just some possibilities for your consideration:   1)      I do move the objects as well as the models. The subject of the ‘ownership’ of the objects by a given process is basically a philosophical one and I’ll offer you my view, for what it’s worth. My feeling is that, as a general guideline, it should be very difficult to re-use functions and events. When I train new modelers, I always stress that they should use as many words as possible in order to make these objects specific to their process. I have found that this philosophy minimizes the effect of objects not being ‘owned’ by a given process. Of course, events end up being re-used when associated with a process interface (to link to another process). However, these ‘shared’ events should never be changed anyway without collaboration between the various process teams involved as these events are actually ‘owned’ by all the processes on which they occur. As an example, I don’t know if you’re using SAP Solution Manager or not but, one thing that happens when you synchronize from SolMan to ARIS is you end up with many duplicate objects in the ARIS database. You may instinctively want to ‘consolidate’ the objects but, in reality, you must first investigate the objects to determine if they are truly the same. For example, after one synchronization, I had an object named ‘Cancel invoice’ that had been duplicated 11 times in the ARIS database. After analyzing them, I found for example one was actually aimed at canceling a ‘customer invoice,’ one was a ‘vendor invoice,’ one was a ‘background invoice,’ one was an ‘online invoice,’ etc. So here’s a guideline I like to use regarding naming for functions: If the function is ‘carried out’ by the same role, takes the same amount of time, carries the same costs and uses the same data as input/output, it’s probably the same function. If any of these things are different, the function should have a unique name. I’m always looking for folks to use this line: ‘It’s exactly the same as this other function except for…..’ which basically says to me that it’s exactly the same EXCEPT FOR WHERE IT ISN’T! Seriously, if it isn’t the same then guess what, it’s unique!! 2)      If I understand this one correctly, you’re referring to a process interface ‘link.’ The approach I’m used to here is to have the word “DRAFT” (kind of like a watermark) in the model header for models under development. Then, you can allow these models to be linked via process interfaces. I’ll offer another tip on this subject as well, just as an aside. When a process interface is required and the modeler knows that the model they need to link to this process interface has not yet been created, I created a ‘blank’ model that they use to make the assignment to the process interface. This will, by design, fail the Semantic Check. What it offers you is the ability to run a Semantic Check against all models (perhaps of a given team) and quickly get a list of all models yet to be developed. 3)      I would then use ‘versioning’ to be sure everyone sees what they need to see on the web site. So, if you have folks who only get to see the ‘released’ models, and one of these models has been moved to another location to be changed (such that they wouldn’t have access), they could always view the model in its most recent ‘released version.’ I currently have the luxury here such that ‘everyone wants to see everything’ and, if you use the ‘DRAFT’ scenario mentioned earlier, folks are always aware that the model is ‘under construction’ at the moment.   To Shankar's questions I've unfortunately not had the funding for either RCM or APG....which is probably why I end up with all these long-winded responses :-)     Just some food for thought…. Best Regards,   Bob

Hello,

I've read the above discussion with great interest. The structure of groups corresponds largely with what we intended to do with our system except that we were thinking of using three groups:

• a group of unreleased documents where newly created models or models under revision would be stored. The designers would only get write access in this group.
• a group of public information where the approved models that are available to everyone within the organisation would be put (this group would be the part of the publication that would be accessible through anonymous acces)
• a group of sensitive information where the approved models would end up that are only available to a certain departement within the organisation. (this group would be published and accessible with usernames and passwords)

Within each group we would be using a same substructure of groups. At a certain level all the models (like flowcharts or EPC) related to a certain department would be stored in a group of that department. The objects related to these models would also be in that same group. This allows us to protect models and objects from one department to be changed (un)deliberately by another departement through privileges on the group.

Suppose one model in such a group would get its approval. Then I would have to move it together with its objects to the corresponding group in the public or sensitive folder and perform the update of the publication. Now I have two questions:

1. given the fact that I cannot easily select only the objects of only one model in a group, do I have to create a group for each model, or should I just move along all elements every time I make an update?
2. If I move around the models and objects to "public" or "sensitive" for updating the publication, wouldn't it be wise to move them back to the unreleased folder so that the designers can continue to use the objects?

(I also need to mention that we would be using versioning of the models, so the update would only include the updated elements.)

I hope my questions are clear enough.

Thank you for your thoughts.

Hi Bruno,

I hope that I understand your questions properly and will attempt a reply:

1. If you use the 'Update' button when web publishing, then only changes which differ from the previous web publish are considered. So there isn't a need to 'single out' a model that has, for example, moved from one group to another for publishing purposes as the entire database is analyzed during this publishing procedure.

2. Some objects are meant to be re-used and should be kept in 'Libraries.' In our example we currently maintain libraries for 'Organization' (e.g. Roles), Application Systems (e.g.Application System, Application System Type) and Data (Technical Terms, Clusters). Functions and events should be named uniquely enough that apply only to the process on which they occur. Given that this is really a guideline and that we do on occasion need to re-use these objects (especially when the event is required for process interfacing between multiple models), it would be a matter of giving the modelers 'Read' access to the 'Released' group. Renaming/Changing of 'Released' objects needs to be carefully controlled with regard to 'occurrence copies.' Some projects I've been on have elected to also have also a 'Process Object Library' where they would store functions/events. While modelers could re-use these objects, they were not permitted to change the objects...without some necessary discussion. I've found over the years that using as many words as possible to define functions and events greatly reduces the issues associated with reusing them. If you happen to use the 'Model Generation' functionality to create end-to-end views composed of several discrete EPC's, the importance of naming objects correctly becomes self evident.

 

Best regards,

Bob

Hi Bob,

thanks for your helpful feedback. You are right, I see also the advantage of keeping the version history. My approach is to copy not the model files themselves back, instead copy the model content (select all + copy + paste all). But I am not so happy with this approach ...

Please let me ask you some questions regarding your procedure.

1. How do you deal with the objects inside the model? If you just provide the model, no one will be able to change an object - or do you also move the objects to the RW area? (Note: such an object may perhaps not be owned by this particular process itself!)
2. If you have another team trying to reference (link) a model that is currently moved-away from the release folder, how do you deal with that? Do you allow them also to reference a model that is currently in development? Or do they have to wait until the model has been released?
3. In case of publishing, how do you publish if some models are currently not in your release group?

Thanks a lot in advance!

Volker