In many cases, release management boils down to the fact that models progress over time through a series of released states with intermitting periods of change. These changes should only become visible in the ARIS Business Publisher after they have been reviewed and again released.
This simple scenario is applicable to most mid-sized ARIS implementations and can be readily supported by correct usage of the versioned publication functionality of ARIS Business Architect and ARIS Business Publisher. There are arguably more challenging release scenarios and I advise the use of ARIS Process Governance in order to keep complex multi-database environments under control. Please do not hesitate to ask for details on this.
Back to the versioned publication feature: It perfectly handles the selection, update and deletion of models and objects (see figure below). The versioned publication always publishes the latest available version of all existing models. But what does this mean and how is this functionality used correctly?
There is a simple, single rule to follow: Only version released models!
A selection is published by versioning the models that need to be published (i.e. M1) and publishing the respective change list (i.e. Change list 1). As you can see, only M1 appears in the publication, M2 and M3 do not.
It is possible to add selections of models as they become released (i.e. M2). The previously released model might by that time again be ‘in progress’ of being improved and is consequently not included in this version (i.e. change list 2). As stated, the publication always publishes the latest versioned state of the model. This means that M1 remains unchanged in the publication (only consisting of object ‘1’). Take care! If there would have been an intermediate version of M1, even if that change list was never explicitly published, the ‘Add selection’ publication would also republish M1 in the intermediate state. Hence the rule: only version released models!
If a previously released model reached a new, second released state, it is possible to update the model simply by including it in a new change list. In the example, change list 3 includes again M1, now consisting of three objects. The publication of this change list correctly updates the published model. (In addition model M3 was included in change list 3 as new selection.)
Equally important as adding objects or models to the publication is deleting them. This is where older 7.1 versions were not performing consistently. The example shows the deletion of an object from M1 and the deletion of model M3. Change list 4 again only includes M1 (it cannot include M3, as this model is just being deleted). The publication of this change list correctly removes object ‘1’ and model M3 from the publication, while leaving model M2 unchanged.
In a nutshell, ARIS Business Architect and ARIS Business Publisher together offer a simple, yet powerful versioned publication feature that fulfills all requirements of a basic release scenario. A team of business analysts building up a corporate process model should not need much more. The ‘only version release models’-rule should be enforced by restricting version rights to the functional application manager or team leader.
For more complex release scenarios, with for example multiple sign-offs, AS-IS and TO-BE models to be published, local variants of a corporate or external reference models or M2E content, ARIS offers more powerful tools for release cycle management and accompaning services to get you there faster.
