Repository Management Structure/Best Practice

Julie,

We structured our process repository according to a standard process classification framework, rather than trying to align the repository with an architectural or enterprise view.

We use the APQC process classification framework, see: http://www.apqc.org/process-classification-framework\, but there are many other process classification frameworks you could consider using.

Regards,

Anton

Hi Anton,

Thanks for your response! Regarding process framework, we already have one in place (COBIT - Control Objectives for Information and Related Technologies). My question is from a repository management perspective...how do you structure project folders when projects are complete (between development and master libraries)? And how do you manage between projects to develop models and then aligning them to the process framework?

Regards,

Julie

This varies some depending on how you are organizaed and your level of maturity but genreal guidelines are:

You need a minimum of 3 separate areas to store models and objects:

1) Approved Models - this area is for models that have gone through whatever governance process you have in place and been approved. It should be read only except for the person or group that is migrating models after approval. When working models have been approved they move into this space.

2) Library Models and Objects - Objects that are re-used across multiple models, and some additonal models to organize them, are stored in this space. Usually it is broken down by type of object and sometimes by Enterprise Architecture area if yo are using an EA Framework. This area is also rad only except for whoever owns/adminsters each type of object.

3) Project/Working models - these are for work-in-progress models for projects or to-be state models. Generally, models get copied into this space (assuming they already exist). Work is conducted to change them and put them through the approval process and then they get moved into the Approved models space. Note that you have to move all objects that are in scope into the work space as well. This area is updateable by the project team and usually read-only for everyone else, sometimes not by other project teams depending on how you feel about sharing unapproved objects.

As project teams work they will likely create new objects. As these objects get created ARIS will put them in the folder of the model as they are created. At some point, either a stage gate or at the end of the project, the "owner" of the objects will review the newly created and modified models and objects and determine whether to approve them and move them into one of the other areas, rename and combine with something that already exists, or reject them and help the project to develop them correclty. The last case will hopefully not occur often if you are involving the right people in the project. For instance, if a project is going to involve rolling out new software hoepfully the Application Architect and the Infrastructure Architect are directly involved in the project to make sure those models and objects get built out properly.

The first two areas are generally in the same database. The project/ working models may be in the same database or separate ones. There are pros and cons to each approach. Some will create a new database for each project and that works too, although this makes it very difficult to share work-in-progress across teams if you want to do that.

You will probably also want one or more "play" databases where advanced users can play around with model types and objects types and changes to filters can be tested.

The biggest thing to remember is that permissions are set at the folder level in ARIS so you have to design a folder structure that will allow you to control access to models and objects in line with your governance structure.

Rick

Hi,  

Sorry for ressurecting an older thread.  We are investigating implementing a very similair structure to what you describe here, Rick.  

How do you envisage handling reuseble processes in the library?  I get how all the non structure objects can be in a library but am having difficulty in understanding how a "piece of process" that could be reusable e.g. capture an application form vs. the easier to get applications, positions etc.  I'm thinking that you could create a library of reusable processes similar to those for applications and positions but am not sure.  Also, some insight as to how this will affect process levels will be useful.

Thanks