| Read more about this book |
(For more resources on this subject, see here.)
Recently, I had a meeting with the directors of a major household brand. They had just finished completing a strategic review of the business, which had been signed off by the board. They had numerous stakeholders to satisfy, and naturally the final result was a compromise, which was reached after months of meetings. I was with an experienced business coach who asked the CEO, “So, how will you know if you have succeeded?”. The CEO had difficulty in answering the question. One of his senior managers in the room jumped to his rescue: “Oh, we are working out what we want to measure. We have agreed on some of the measures, but haven’t yet put any numbers against them.”
The coach asked: “How do people in the organization feel about the new strategy?”
The manager replied saying, “It’s a good question. There are a lot of people who feel that it was a waste of time and they just want to get back to the real work. We have a team of very passionate and committed people, but they see strategy as navel gazing.”
We realized that the strategy was doomed. It seems logical to define the goals and then identify the measures. In practice, it is often easier to do it the other way round, even though that is counter-intuitive. First, define the measures of success and then articulate these measures as goals. The employees were right to be dubious.
There are various ways to create, read, update, and delete information. These solutions fall into two major approaches—drawing and modeling. Drawing is still the approach adopted by many organizations because it is cheaper. Most companies that have considered using ProVision® have Microsoft Visio installed on every user desktop. As far as a project manager is concerned, Visio is a free resource. The project manager doesn’t need to ask for funds, and if they do, then the manager will ask why they aren’t using Visio. This article explains the limitations of drawing and why modeling is best practice and essential to support a sustainable strategy. The reader can use this information to make their business case compelling and get the funds that they need to do the job properly. Areas covered also include:
- The benefits of moving to a central repository. (What needs to be stored and how users can access it.)
- Are we building architecture or doing design? (The importance of language in getting your message across.)
- Better decisions now. (The purpose and notion of good enough architecture.)
- ProVision® and Metastorm BPM. (Is this Metastorm’s unique selling point?)
The benefits of moving to a central repository
It is important to understand the difference between a drawing tool and a visual relational database such as ProVision®. The outputs can look identical. Because drawing tools are so much cheaper, why would you invest in ProVision®?
There are a number of drawing packages available, Microsoft Visio is the key player in this market. It is a drawing package that is optimized for business diagrams. Modelers can select pre-built stencils to create models rapidly. As Visio is often installed already, it is the tool of choice of many business analysts.
Designed to scale
If all you need to do is visually represent an aspect of a business, then there is nothing wrong with Visio. However, its limitations soon become apparent. To understand the key differences, I need to explain some basic concepts about ProVision®. These concepts are the reason why you can manage hundreds of models in ProVision®. It has been designed to scale. The core concepts are:
- Object
- Link
- Model
- Notebook/File
- Repository
Object
ProVision® uses objects to represent business concepts. Everything you see—a role, system, process, or a goal is an object. Every object has a name and an icon. After that, it is up to you how much more detail you want to add. All objects can have associations with other objects. These associations will vary, according to the type of object.
Link
A link is a special type of object. It is displayed as a line that connects two objects. You can modify the way the line displays, that is, change its color, thickness, or arrow shape. Links appear in their own area in the object inventory. Some types of link can have a payload (a deliverable) and events associated with them. For example, the link between two activities is called a workflow link. This link can display the deliverable that is passed as an output from one activity to the other. It can also display the event that triggers the deliverable. Both deliverables and events are optional. In many cases, it is obvious what the deliverable or event would be. To distinguish between an event and a deliverable, ProVision® places the name of the event inside double quotation marks.
In the example shown in the following figure, once the event named “Model ready to review” is triggered, the deliverable called Draft Model becomes the input for the Review Model activity:
Model
A model is a special kind of object that contains other objects. Every model must have an object that is designated as the subject of the model. ProVision® provides three types of model—hierarchical, non-hierarchical, and navigator. Hierarchical models typically allow only one object type to appear. For example, a Systems model can be used to create only the hierarchical relationships of systems. No other object type can be added. Even if you create a custom object, you will not be permitted to add it to a hierarchical model.
Non-hierarchical models permit more than one object type to appear, so that you can show predefined relationships other than parent-child relationships between these objects. For example, a Systems Interaction model will allow you to demonstrate relationships between systems and hardware.
The Navigator model is a special model that you can use when you are unable to express the relationships that you want using one of the other model types. You can use virtually any object type on a Navigator model. This is both its strength and weakness. As any object can be used, you can become overwhelmed by the choices. The Navigator model is the only model type that allows you to display models as well as objects. By default, these display as thumbnails of the full model. In the following example, a Navigator model shows a thumbnail of the Approval Process workflow model. The subject of the workflow model is the activity called Approval Process. It has been placed to the right to demonstrate the difference.
The Navigator model has one more purpose. You can use it to visually express indirect relationships. For example, a goal may be realized by delivering a product or service to a customer group. The product requires processes. Each process decomposes down into a series of activities, some of which might require certain computer systems to be in a running state. There is no direct relationship between the goal and the computer system. There is an indirect relationship, which you can visualize using a Navigator model.
Notebook and file
Objects, links, and models are stored in Notebooks. If you think of a Notebook as a physical book, then the models are equivalent to chapters. Each model tells a story. Inside each story, there are words. Objects are equivalent to words. Links create phrases.
Several Notebooks can be stored together. They share a common modeling language that changes the look and feel of objects, links, and models. Other than that, each Notebook is independent. So, it is possible to have two objects in different notebooks that have the same name and type but are completely different. Objects and models can be dragged from one Notebook to another. You can save a Notebook under a different name and thus use the first Notebook as a template for the second.
A File is the logical equivalent of a Notebook. The main difference is that a File can be saved anywhere on a computer and then e-mailed or copied onto a memory stick for transfer. So, Files are used to share and exchange Notebooks with other users.
Only one Repository can be open at any one time. Only one Notebook can be open within the Repository. In the example shown in the next diagram, the Sample Repository appears in bold writing to highlight that it is open. Also, the PackT Notebook has a different icon to distinguish that it is the Notebook being viewed.
Repository
All Notebooks are stored in Repositories. A Repository can contain many Notebooks (in practice most users would be unlikely to have more than 50, and typically around 10). The modeling language is associated with a Repository, and once it is made the default language, it changes the names, look and feel of all objects, links, and models, irrespective of which Notebook they are in. In the following example, the Sample Repository is bold to indicate that it is open. The POC Repository has a world icon to represent that it is stored on a remote server and accessed via Knowledge Exchange®. By contrast, local Repositories have a pyramid icon.
Now that you have understood these basic concepts, let’s see how ProVision® varies from a drawing package such as Visio.
