SL
Hi all!
I’ve read many interesting discussions on the ‘versioning usage’ topic (best practice for AS IS and TO BE models, release management, etc.) but I found few information about “methological aspect” on ARIS documentation. Where can I find ARIS docs on this?
In my company, we are modeling our processes and we want to share and publish only the processes approved. So we have created two DBs: one available only to modelers (‘DB WIP’) and one published in ARIS Connect (‘DB Public’) available to viewers. Both DBs have the same structure and according to ARIS methology, they contain: a folder with objects library and a folder with the company map with sub-folders and sub-models (with two or three levels of dept).
When a model is approved, we want to “freeze” it and its sub-models approved in ‘DB WIP’ and to copy them in the ‘DB Public’. Our idea is to use versioning, so every time that a process is approved we must: (1) version the model approved in DB WIP; (2) Copy this model in DB Public (with merge, because import seems more complex for the previous versions); (3) and version the DB Public.
The disadvantage is that maintain two DBs and its versioning can be more complex. In fact, our doubt is that after two-three times there is an high probability to disallign the versioning between two DBs (for example, the DB WIB is to the 5° change list and the DB Public to the 3°).
According to yours ARIS experience, what do you think abut this method? Do you have any suggestion?
Sorry for longer post and thank you in advance!!
S.
Thu, 07/20/2017 - 17:08
Hello Sere,
if I understand correctly you are not using ARIS process governance.
So how have you implemented workflows for releasing and changing processes?
And how much of it is supported by ARIS?
The "traditional" release cycle management (RCM) concept is possible with features of Design server only.
Transport (merge) and versioning of models in two or three databases can be automated with a report script, which also helps to control the aligned versioning of your DB WIP and DB Public.
But if you take a closer look at Connect server you can probably implement your BPM lifecycle in one published db:
When publishing a versioned db in Connect UMC you can choose to publish the latest version of the db, so Connect client users will only see the latest change list containing your approved processes as soon as they are versioned (= read-only).
They can use a standard report to visually compare two versions of a model.
However, Architect/Designer client users can choose to login to the workplace view, i.e. current state of the db, which is editable, and shows all changes after the last versioning. So your modelers can change models and take them through the next release cycle.
Versioned models are only almost frozen (cf. this post regarding implicit changes of object occurrences).
It is preferable to version the whole db (i.e. create a new change list) when you approve/release several processes, instead of versioning single models. A disadvantage is the growth of a versioned db.
Regards, Martin
Hello Sere,
I reckon, you have worked out a good strategy for your versioning/publishing. I am pretty sure, that the version numbers will disalign sooner or later. But: What does it matter? The version numbers usually don't show up in public. What's crucial here: In WIP you version the freshly released slice of content: In public you version the whole DB. This way you could withhold some approved content from publishing, and continue publishing other slices. You only run into trouble, if slices intersect with later slices. So separating the libraries (which are likely to have a separate governance anyway) is a good idea, because they are most exposed to possible intersections between slices.
You could even consider to intentionally version more often in WIP, e. g. when some content is "ready for review" or whatever state. If you do that, there is definitely no chance to use a single DB with "publish the latest version" - and WIP will grow, of course.
Suggestion: When versioning the Public DB, refer to the version number published from the WIP in the version comment.
