What are advantages / disadvantages of managing changes in models in ARIS by using versions feature

Ohayon Morgan on April 25, 2022

Hello Everyone,

I would like to know if someone already make a pro / cons analysis managing changes in models in ARIS by using versions with an emphasis on technological process modeling (functional and infrastructural architecture functionality) in terms of workflow and technical system (DB size, performance, etc.)

The use case is that each model will be approved and will be required to manage versions - to produce an approved version. The model will then be editable and editable and when approved another version will be created. This will make it possible to make changes at the model level (not at the level of several models and at this stage not by creating a change request) that can be retrieved (if required) and viewed in the model as previously approved

Also what is the best practice for managing changes in models?

thank a lot for your help

Notify Moderator

Best Reply

M. Zschuckelt on April 25, 2022

Hello Ohayon,

it may not just be a question of pro and con but also a question of the design of the governance, so you balance pros and cons with requirements you have.

Versions are the only way to distinguish between published content and work in progress in the same database. By default you always submit a single model for approval and versioning. You should have an idea if this is the right unit-of-work that you want to get approved at a time. If a logical context is distributed over multiple models, the standard won't suit you. You would build a custom workflow in this case, where you have the opportunity to treat a whole model context together and even have it approved with a single decision.

If you are worried about database sizes growing due to too many change lists (aka versions) getting created every day (suppose you had hundreds or thousands of model submissions per day), you could build a mechanism of not versioning your approved models straight away, but leaving them in a locked state and having a nightly report combine them in a single change list. This strategy will contain the growth of the number of change lists at the price of having to wait until the next day to see the approved result. In return it will become easier for you to identify a particular change list simply by its creation date.

Last but not least you could consider a strategy of using multiple DBs if your governance process involves reviewers who are not designers. Suppose you had a DESIGN database and a PUBLISHED database. Then reviewers could see a version published in your DESIGN database and only after final approval the approved version would be merged to the PUBLISHED instance and versioned there again.

I hope I could inspire you to some ideas to tackle the topic creatively.

or register to reply.

Show in context Notify Moderator

3 Replies

MZ

M. Zschuckelt on April 25, 2022

Best reply

Hello Ohayon,

it may not just be a question of pro and con but also a question of the design of the governance, so you balance pros and cons with requirements you have.

Versions are the only way to distinguish between published content and work in progress in the same database. By default you always submit a single model for approval and versioning. You should have an idea if this is the right unit-of-work that you want to get approved at a time. If a logical context is distributed over multiple models, the standard won't suit you. You would build a custom workflow in this case, where you have the opportunity to treat a whole model context together and even have it approved with a single decision.

If you are worried about database sizes growing due to too many change lists (aka versions) getting created every day (suppose you had hundreds or thousands of model submissions per day), you could build a mechanism of not versioning your approved models straight away, but leaving them in a locked state and having a nightly report combine them in a single change list. This strategy will contain the growth of the number of change lists at the price of having to wait until the next day to see the approved result. In return it will become easier for you to identify a particular change list simply by its creation date.

Last but not least you could consider a strategy of using multiple DBs if your governance process involves reviewers who are not designers. Suppose you had a DESIGN database and a PUBLISHED database. Then reviewers could see a version published in your DESIGN database and only after final approval the approved version would be merged to the PUBLISHED instance and versioned there again.

I hope I could inspire you to some ideas to tackle the topic creatively.

Like

Sign in
or register to reply.

Notify Moderator
OM

Ohayon Morgan on April 27, 2022 as Reply to M. Zschuckelt

Thanks a lot for your answer

Like

Sign in
or register to reply.

Notify Moderator
Theo Padding on May 2, 2022 as Reply to M. Zschuckelt

You could consider a separate Archive database with all versions. This keeps the published database small, because no versioning is needed :-).

Like

Sign in
or register to reply.

Notify Moderator

What are advantages / disadvantages of managing changes in models in ARIS by using versions feature

Best Reply

3 Replies

Arbeitsgruppe Modellierungskonventionen der ARIS User Group DACH

Master Operational Excellence in 2025: Insights You Won’t Want to Miss!