Once the strategy is agreed, the Program Management Office, or equivalent, can determine the sequence of projects that will be used to populate the central repository. A typical project should take no more than three months from start to finish. The initial project will be to gather core information that will be required by all subsequent projects. In the Enterprise Designer framework this core information is defined as:
Who are the Customers?
What are the Products and Services we provide to them?
What are the Critical Processes required to produce these Products and Services?
What are the Critical Elements that drive the Critical Processes?
What are the Key Goals of the Organization?
As you can see, these are all lists of components and they are normally arranged into hierarchies.
In the example above, we see that a type of ProVision® object called a market has been used to describe three major customer groupings: Electricity, Gas and Telecommunications. These major groupings can decompose down further into sub-customer groupings as required. As we create a model and add objects to it, ProVision® updates the object inventory. There is no need to add objects to the object inventory first. We can create them 'on the fly'.
ProVision® provides a toolkit of common objects, such as markets, organizations, processes, elements and goals, out of the box. If necessary, you can create custom objects to extend the standard set or you can rename objects to match your corporate language. For example, in the Enterprise Designer modeling language, we have re-named the Business Domain object and called it Product.
So, before you begin to create more complex models, you need to create lists of the objects that might be required in many different situations.
There are several issues around building lists:
Who is responsible for initially gathering the information?
How do you name objects?
Who ensures that the object is maintained?
Where is the object stored?
What is the publishing process?
How much detail does the object require?
How do you get the information from another system into ProVision®?
How do you prevent duplicate objects and what do you do when you find them?
As you can see, building and maintaining a list is not as easy it might seem at first. Besides the technical issues, there are issues around maintenance, governance and standards. Let's look at these issues more closely.
Many organizations start off with a team of two or three professional modelers. Their background is likely to be business analyst, system architect, business architect, or enterprise architect. They will either have a business process or technical background.
Part of their job is to work with subject matter experts who have the best appreciation of what each list should contain. The subject matter experts will not normally learn how to use ProVision®. One approach is for the modeler to have a conversation with the subject matter expert and extract the relevant information. The problem with this approach is that it transfers ownership from the subject matter expert to the modeler. When changes occur, the modeler may not find out.
The alternative approach is for the modeler to create an Excel spreadsheet template and help the subject matter expert populate the information. The benefit of this approach is that the subject matter expert can maintain the list, using Excel, a tool with which they are familiar. The modeler can then import the list to ProVision® on a regular basis, catching any changes.
Because ProVision® stores an object once, any changes will update instantly in all of the models in which the object appears.
ProVision® does not enforce a naming convention. The organization must define their own and put in place a mechanism by which all users adhere to.
ProVision® offers the option to number objects. These numbers are not part of the object name but appear as if they are. Thus the same object can have different numbers in different models. For example an activity in one model might have the prefix 1.03 in one model and 6.4.1 in another. This can create confusion.
Therefore, we recommend that objects either have no numerical prefix, or the numbers are hard-coded and are part of the object's name. In this way they will appear in a consistent order in any list.
The key point to remember is to treat the number as a unique identifier, not as a sequence number.
The benefit of putting a unique ID at the start of any name is that the text that appears afterwards can change, without it losing its unique character.
For example, imagine that you have an activity object called Undertake Assessment. When you look in the object inventory it will appear with other activities that start with the letter 'u'. If you decide to change its name to Perform Assessment then it will now appear alongside the activities that start with the letter 'p'. Another modeler, unaware of the name change, may not find it. However if you call the activity 36112 Undertake Assessment, you can change it to 36112 Perform Assessment without it changing its position.
The disadvantage of using a numerical prefix is that all objects now appear in numerical order in the object inventory.
We recommend that you have an upfront discussion about the naming convention, document your choice, and ensure that everyone follows the same convention. One compromise that is worth considering is to use number prefixes for all key objects. Individual modelers are not permitted to create new key objects. They can, however, create child objects which do not have a numerical prefix.
This discussion about naming conventions reveals the need for a role that is responsible for managing the central repository. We need to distinguish between the technical and business aspects of this role. If there is a large team then the role might be split. The technical aspects of the role include:
Overall responsibility for defining, explaining and ensuring that the naming convention is followed
Overall responsibility for ensuring that models and objects are kept current
Overall responsibility for defining and managing the publication of models
ProVision® stores information in repositories. Within each repository the modeler can create multiple notebooks, models and objects are created inside notebooks. A metaphor you might use is that a repository is a bookshelf, a notebook is a book on a shelf, a model is a chapter in the book and an object is a word in the chapter.
In a small team, where there are just one or two modelers, the working repository will be stored on a local drive with appropriate backup strategies in place. A static published version might be stored on the corporate intranet.
However, once you start to have larger teams, the recommended approach is to upgrade ProVision® by adding the server-side component Knowledge Exchange®. This enables several different modelers to work together through formal version control procedures. If one person is updating a model, the objects therein are 'checked out' to that person. This prevents other modelers from overwriting changes. Meanwhile, if they need to use the same objects, they can check them out as 'read-only'.
As objects are checked back in, Knowledge Exchange® automatically makes a web version of the current state of the repository. Interested parties can watch the models change over time using Internet Explorer. They can even be given rights to comment on the models and add details, directly from their browser.
Once Knowledge Exchange® is installed it is best to store these lists on the server. The latest version of the application allows the user to store objects remotely on the server and then reference them in the local repository.
We recommend using a three-step process. In the first step the modeler creates a notebook on their local hard disk and builds models. This notebook will contain models and objects that are not for publication. For example, they may sketch a model and discover it is not useful. Once a model is ready for review it is transferred to the QA repository. This is an easy process. If Knowledge Exchange® is not installed the modeler drags the model from one location to the other. If Knowledge Exchange® is installed they check the model into the QA repository and notify the person responsible.
The QA repository administrator reviews the model and determines if it is ready for publication. The stakeholders check the model and either accept it or request changes. Once the model is approved, the QA administrator transfers the model to the Production repository where it is visible to anyone who has been given rights to view it.
The process might look like this:
The bare minimum is the name of the object and its type. There is no requirement to add any further information. To keep objects looking clean and simple onscreen, all the detail is stored in hidden tabs, which can be accessed if required. We recommend that all objects that are published include a short description.
ProVision® supports a number of ways to transfer information and is compliant with standards such as XML. The simplest way to transfer information is to import it from an Excel spreadsheet that has been formatted to comply with the ProVision® data structure. There are a number of wizards which will aid the import process from other products, such as Visio. If these manual and semi-automated methods are not suitable, a developer can create a custom routine which would take information from another system and import/export it automatically. This routine would ensure that the information about the object remains consistent in both places.
It is not always essential to create an object in ProVision®. If the other source is a document or web page, it may be far easier to use the artifact feature. This is essentially a hyperlink. The user clicks the link and it opens up the relevant page. This approach eliminates the need to synchronize the two locations as the external source becomes the master and ProVision® becomes the slave.
Use artifacts to link to manuals, procedures, business rules and similar documents that may be stored on the corporate intranet.
How do you prevent duplicate objects and what do you do when you find them?
If you define a naming convention, and ensure that everyone understands and follows it, you will reduce the chance of duplicate objects. It will still happen. ProVision® treats object names as case sensitive. Thus an organization object called Finance is not the same object as finance or FINANCE. Therefore, your naming convention will need to decide on the correct format to try and reduce duplicates. Activity objects should follow a convention such as [Verb] + [optional adjective] + [Noun].