members like us who come from the PLM and PDM world are used to version and revision control. For drawings there can be several versions but the published version is revision controlled. This is where we ensure that form fit and function is taken care of for backward compatibility etc. In aris we have version control. In the workspace if multiple working versions are present for the same process model (activity level) then how do you manage it?
I was wondering if we start think about seperating version and revision control.
adding some more details
In any manufacturing organization there are several set of changes which do on like Engineering Change Order which can lead to Manufacturing Change Order and Product Change Order. These are all handled within the PDM or PLM tools using complex methods to accommodate various enterprise wide data synchronization process (including materials management, cut-off). The 2 most common concept are version control and revision control – which are treated separately and differently. In the Engineering world there can be many versions of a drawing but there is only one published “live” revision which actually drives the product and manufacturing change if necessary. I see a similar analogy for ARIS models. There can be multiple versions of a ARIS model based on the waves of “go-live”. There should be only one revision which should drive the product change – which means the next wave of go-live for the IT Products. This can be different from the current “live” model with an effective date matching the go-live date. The current ARIS version control does not seem to be geared towards that but this can be achieved through multiple nested group structure. I was wondering if anybody had any experience of developing such a model.
I have the same concerns, especially in keeping designs in sync when having more than one supporting application scenario supporting a process i.e. moving from a mainframe environment to a SOA (composite applications) environment. You have 2 designs using the same functions i.e. record claim in the mainframe environment + in the SOA world. This will be until you have migrated completely to the SOA environment.
I currently have a single db environment, but split in 2 major components i.e. Enterprise Architecture (AS - IS) environment with restricted access rights and a Solution Architecture (TO - BE) environment where projects are changing the current AS - IS designs. We apply versioning at the EA level, then move the models to the Solution Architecture folder structure. Here we follow a strict model driven SDLC approach in the form of modelling and generating detail business requirement specifications (BRS). The BRS is then used to design detailed system requirement specifications (SRS). There are other key SDLC steps, but will not cover it now. Once the designs have been realized, the status of models are changed to release and then moved back to the EA view by the EA architecture team. Here the latest design is again versioned. This way solution models can be compared to enterprise architecture models.
We try to keep only one workspace version, but only in workspace once it has been versioned. The only problem is if you have multiple people that work on the same object accross different projects. Here again we apply management principles and treat an object as a object oriented object, with other words limited or "no" duplication via definition copies, but rather collaboration between team members to combine design changes to an object.
We had this problem in a public sector project in Germany (public bid request for SAP implementation projects) and saved the end-to-end models that were part of the RFP in a seperate ARIS database. If there were discrepancies between the original E2E and the final implementation a year later, we were able to compare the RFP version with the latest implementation version.
