It is just important to maintain the ARIS models and objects in the right way. This maintenance in the different projects and environments is simple when everybody knows the way he must work. A good explanation to the designers and control of the recommended activities by the architect or the BPM department is necessary. In this article a way to maintain all the models and objects is described.
The maintenance of all the different environments is crucial because a difference in a model between several environments can confuse the modeler and the architect for which one is correct. Thus it is important to follow a good procedure for exporting and maintaining models. The architect could place the version or publication date as a free format text in the model to prevents the confusion about the right version. In figure 1. I show the way I work with the four environments Development, Test, Acceptance and Publication.
Fig. 1. Maintenance procedure
The data transfer between different databases is done by using export files. An export file is created for a model or a group of models from the source database en imported into the target database. The creator of the export file is not always the same person as the importer of the export file.
The procedure for maintaining a model follows the next steps:
The designer will make a new model or update an existing model in the Development database. When it is ready, a semantic check must be done by the designer before the next step will be executed. Errors will be corrected by the designer in the Development database. The correct model will be transferred to the Test database.
The Test database contains all the models which will be reviewed by the stakeholder. When the model is not correct, the designer will modify the model in the Development database. After correcting and checking the model, it’s exported to the Test database for a new review. The designer will email the architect (or BPM department) with the message to import the model in the Acceptance database when the stakeholder accepts the model. In some organisations the signature of the stakeholder must be on the hard copy of the model.
The Acceptance database contains all the models which will be checked by the architect. The architect will import the new models after a mail from the designer. This mail contains:
– a report with a graph of the new model and corresponding objects.
– the accordance of the stakeholder by mail or on the hard copy.
– all the information the architect needs to import the right model(s) and object(s) to the Acceptance database.
The architect will check the model against the current standards, conventions and completeness of the basic objects. When a model contains a “new basic object”, the architect will discuss with the designer for the reason and need of this object. When accepted, the architect will first create the basic object in the corresponding basic model before he imports the new model in the acceptance database. This new model contains a reference to the new basic object. Normally the designer will change the new model after changing the basic models by the architect. This change must be effected by the architect to the corresponding basic model in all the other environments to control a single use of a basic object in the repository. A consolidation afterwards could be used for testing the quality of change.
When the model is not correct, the architect while communicate the reason(s) to the designer. The architect makes an export of the model out of the Acceptance database. The designer can import this export file in his Development database and the process starts again. The old model is overwritten by the new one after the import.
The architect will publish the accepted model in the Publication database. He can also mail all the concerned customers on ad hoc or frequent basis. When the client has ARIS Business Publisher installed on the server, all the models in the Publication database can be reached by the intranet from the client. Otherwise, the customers has a license key (as guest) to read only the models in (a part of) the Publication database. Beside this the architect can make a hardcopy of the models by reports and distribute these papers to the customers.
When a current process is changed, the corresponding model in the Publication database must be updated too. On a request of the designer, the architect makes an export file out of the Publication database and import it in the Development database. Sometimes the designer can also import the export file in his development database instead of the architect.
The designer will then update the model, let’s review it by the stakeholder and email the architect to check the model and update the Publication database.
Conclusion
The maintenance of the models and objects in the different projects and environments is simple when everybody knows the way he must work. So, inform the designers and architects before they starts. Inform also the stakeholders so they knows when they will be involved in the maintenance procedure.
However during the use of ARIS, the designers or architects has sometimes unexpected questions. Not only for the content of the models but even about the standards and conventions. More about this topic in a next publication.
Ruud has been active in the ICT sector since 1982 and from 1994 working for Logica Nederland B.V. (Finance, Insurance and HR). He is a senior business consultant and specialised in business process consultancy and architecture. He has knowledge of different BPM-tools like ARIS, Be Informed and Oracle BPA Suite.
Maintenance of the ARIS models and objects.
The maintenance of all the different environments is crucial because a difference in a model between several environments can confuse the modeler and the architect for which one is correct. Thus it is important to follow a good procedure for exporting and maintaining models. The architect could place the version or publication date as a free format text in the model to prevents the confusion about the right version. In figure 1. I show the way I work with the four environments Development, Test, Acceptance and Publication.
Fig. 1. Maintenance procedure
The data transfer between different databases is done by using export files. An export file is created for a model or a group of models from the source database en imported into the target database. The creator of the export file is not always the same person as the importer of the export file.
The procedure for maintaining a model follows the next steps:
– a report with a graph of the new model and corresponding objects.
– the accordance of the stakeholder by mail or on the hard copy.
– all the information the architect needs to import the right model(s) and object(s) to the Acceptance database.
The architect will check the model against the current standards, conventions and completeness of the basic objects. When a model contains a “new basic object”, the architect will discuss with the designer for the reason and need of this object. When accepted, the architect will first create the basic object in the corresponding basic model before he imports the new model in the acceptance database. This new model contains a reference to the new basic object. Normally the designer will change the new model after changing the basic models by the architect. This change must be effected by the architect to the corresponding basic model in all the other environments to control a single use of a basic object in the repository. A consolidation afterwards could be used for testing the quality of change.
When the model is not correct, the architect while communicate the reason(s) to the designer. The architect makes an export of the model out of the Acceptance database. The designer can import this export file in his Development database and the process starts again. The old model is overwritten by the new one after the import.
When a current process is changed, the corresponding model in the Publication database must be updated too. On a request of the designer, the architect makes an export file out of the Publication database and import it in the Development database. Sometimes the designer can also import the export file in his development database instead of the architect.
The designer will then update the model, let’s review it by the stakeholder and email the architect to check the model and update the Publication database.
Conclusion
The maintenance of the models and objects in the different projects and environments is simple when everybody knows the way he must work. So, inform the designers and architects before they starts. Inform also the stakeholders so they knows when they will be involved in the maintenance procedure.
However during the use of ARIS, the designers or architects has sometimes unexpected questions. Not only for the content of the models but even about the standards and conventions. More about this topic in a next publication.
Viewed 676 times by 237 visitors
Related posts:
Ruud has been active in the ICT sector since 1982 and from 1994 working for Logica Nederland B.V. (Finance, Insurance and HR). He is a senior business consultant and specialised in business process consultancy and architecture. He has knowledge of different BPM-tools like ARIS, Be Informed and Oracle BPA Suite.