OM
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
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.
In reply to Hello Ohayon, by M. Zschuckelt
