The purpose of a process model
If you are of the formal persuasion, you may first want to scroll down this page a bit for a definition of the term process. If you can live with a bit of uncertainty, read on, you’ll get there eventually and then you can go back and read this again. Life must not be so linear!
The ultimate purpose of the process models discussed here is to create an operations manual or more generally, a process support application, which is a more capable extension of an operations manual. A process support application should support the execution of processes in various ways:
- Provide instructions as to when, in what order, and by whom (what role) the activities within a process should be executed.
- Support adaptation of the (standard) process to the actual circumstances.
- Provide access to the information items used, created, and modified in the process.
- Provide access to the process execution status.
- Automate applicable parts of the process.
As the most basic type of process support application is the operations manual, a fundamental requirement is that we shall be able to at least create a decent operations manual from the process model.
The process support application created from the process model and adapted for a particular real-world instance of a process is here called process support instance.
Model vs reality
Any model, such as a process model, is a simplification of the reality (otherwise it would be the reality) and is designed to describe a selected subset of aspects of that reality. An example is a regular road map (not a product road map but a good old-fashioned road map) which is designed to show the road network for motorists but not for instance the current weather (this may change though with the new electronic navigators).
When selecting modeling elements such as process and role (just to mention a couple of plausible candidates) for our process modeling notation, we need to decide which aspects of the reality we want to represent in the model and what types of relations they may have with each other. Given a certain set of modeling elements, some aspects of reality will be easy to describe while others will be harder to describe. Adding modeling elements makes it possible to make more accurate models but at the cost of added complexity for both the designer of the model and the user of the model. We, as often is the case, need a good trade-off between accuracy and complexity and a small set of intuitive modeling elements. I you like algebra you might want to say that we need an orthogonal set of modeling elements that span up the model space. In practice this means that we only want to put what we intuitively consider one piece of information in one place in the model. This is a little bit like choosing between a Cartesian and a polar coordinate system. If you are navigating an aircraft, then you probably prefer the polar coordinate system as direction and speed are the interesting parameters. If you’re designing a house, then the Cartesian coordinate system would probably be your choice.
I will refer to the selected set of modeling elements and the rules for using them a (process) meta-model. For more on meta-models, see Wikipedia on meta-modeling.
All too often creative processes such as product design have been described with an inappropriate meta-model resulting in a linear description of the workflow (the set of activities in the process), not taking into account the need for shorter and longer iterations, rework and the occasional ad-hoc activity. This is particularly true for flow-oriented modeling languages such as IDEF0.
The simple solution proposed here is not to impose order and sequence where there is none in reality, but to still describe (and sometimes prescribe) the various atomary activities that are performed in the real-world process, potentially in a non-predictable and non-prescribable order.
Requirements on the process meta-model
I have gone through the trouble of creating a new meta-model for describing operations even though several have already been proposed. The problem I have with most, if not all, the existing meta-models is that they use the process or workflow as the main concept. Activities must belong to workflows in order to exist. This works for repetitive workflows but makes it harder to model creative processes and methods such as software development. I have tried to capture this starting point of mine in the following short list of requirements on meta-models.
- It shall provide accurate and intuitive modeling of both repetitive (routine) workflows such as the handling of customer support tickets and more “intellectual” kind of workflows such as the design of a piece of software.
- It shall encourage the design of efficient processes.
- It should support consistency checks of the model, e.g. that an element that is referred to from and other element actually exists.
- It shall support the generation of an aesthetically appealing operations manual.
- It shall support integration to, and automatic generation of, databases for storing process instance data such as input and output information items and process (instance) status.
- It shall have no more than 7 basic modeling elements. (It is often said that a human being can keep around 7 “things” in her head at the same time.)
- It shall support extensions to the set of modeling elements within the modeling language itself.
Basic modeling elements
So far I’ve been throwing around words such as process and workflow rather carelessly, as if the meaning of these words was self-evident. I acknowledge that it’s not. So here are the definitions you’ve been waiting for. The icons associated with each element are the icons used in the graphical presentation of the process models.
|A collection of roles, items, workflows, events, objectives, databases, and general information (see below for descriptions of each of these modeling elements). In a process, input items are transformed to output items or output objectives by roles, using workflows and databases. Note that this definition of a process is more inclusive than the more common “a systematic series of actions directed to some end” or similar. According to my definition a process is really a whole (small or large) enterprise or a “mini-factory” with all that is needed for it to function properly. The customary definition of a process is what I here call a workflow.|
|A piece of information or tangible such as a document, model, database record, executable, source code file, hardware etc. that is either needed as input or created or modified in a process. The Item may contain several item versions.|
|Something that is produced in a process but is not a tangible item such as a document or a piece of hardware. An example would be “happy customer” or “answer questions within 24 hours”.|
|A set of responsibilities and their associated authorities. A role is performed by an individual or a group. A role typically requires a certain skills profile.|
|An ordered or semi-ordered set of activities and decisions.|
|A system for storing information items such as documents, helpdesk tickets, various records etc. A database can be implemented as a software application but can also be a manual, paper-based, systems such as a set of binders.|
|Something that happens that we need to react to in the operations described by the process model. An example would be the event “new customer complaint”. Such an event would typically trigger a complaint handling workflow.|
|Any type of information that doesn’t fit into any of the above categories.|
1, 2, 3, … ok, that was 8 modeling elements, not 7, but I claim that the last one (information) doesn’t really count as it is only used for information that doesn’t fit into the other 7 categories. That’s a lame argument I know but it’ll have to do until I come up with something better…
When designing a process model it is often useful to structure the model in a hierarchy. To support such structuring, every modeling element above has its plural counterpart. Several instances of the modeling element process may for example be aggregated hierarchically under one instance of the modeling element processes. The plural forms of the modeling elements have their own icons like this:
|I’m sure you get the picture(s).|
The fine print of the modeling elements
The modeling elements would not be awfully useful if they only consisted of a name and an icon. For a role we would for instance probably want to know details such as responsibilities, authorities and skills associated with that role. For a workflow we may want to know which detailed activities the workflow consists of and which roles that are involved in performing the workflow.
For each modeling element above we therefore need a sub-structure of modeling elements.
|An activity can be associated 1:1 with any of the modeling elements above but is usually associated with items or objectives. The modeling element with which the activity is associated becomes the object (in a grammatical sense) of the activity. A trivial example is the activity open associated with a modeling element of the type Document. Activities may, but don’t have to, be associated with a workflow (see below). If an activity is associated with a workflow then the workflow puts additional restrictions as to in what sequence the activity can be performed. If the activity isn’t associated with a workflow, then it can typically be performed at any time and be part of any sequence of activities.|
|Attributes hold the state of the modeling element instance. Attributes correspond to what is sometimes called “metadata” in document management systems or product data management systems. Attributes may be static or dynamic. Static attributes have the same value over many instances of the modeling element whereas dynamic attributes have unique values for each instance of the modeling element.|
|A rule is an explicit description of a rule or a restriction that must be fulfilled of e.g. regulatory reasons. An example might be that the design documentation for a medical device must be kept for a certain period, given by regulations. Rules are static attributes with the “rule” stereotype. Rules can be associated with any of the basic modeling elements described above such as items, objectives, workflows and roles.|
|An association (a relationship) between two modeling elements represented by a line between the modeling elements. The meaning of the association is given by the two names of the association, one in each end. In this example the association for instance means that the workflow Analyze change request is performed by the role System analyst. The inverse of this is expressed by the other name of the association: The System analyst performs the workflow Analyze change request. This meta-model does not mandate any particular names for associations but it is recommended that a standard set of names is adopted for clarity.|
|This is a special kind of association meaning that the origin of the arrow is a specialization of the modeling element that the arrow is pointing at. In other words, the “origin” object has all the features of the “target” object and them some. In this particular example we can infer that a document has all the features of an information item (and them some most likely). An other way of stating this relationship is to say that the document is kind of an information item.|
Variations of the basic modeling elements
It may be useful to add specializations of the basic modeling elements. A typical organization may for instance use many different types of items, each managed in a different way and therefore requiring their own entry in the operations manual. Examples of such variations of the modeling element item are document, source code, hardware, and record. Items may furthermore have different levels of formality. Some may need formal approval while some may not. Some may in addition need a formal go-ahead before any modifications to the item can be done.
Some common variations are described below.
- Information item
- A container of information such as a document, a database record, or a source code file.
- A physical hardware item such as a server or an electronic control unit. The specifications for such a hardware item are usually contained in an information item such as a document (see below).
- An executable piece of software, either a complete application or a component for building applications.
- An information item that is either an electronic document (OpenOffice, Word, PDF etc.) or a paper document. A document typically needs formal approval by a designated role.
- Source code
- Source code.
- Written evidence of that the process model has been adhered to. Examples are document review records (proving that documents have been reviewed according to a defined document management process) and test records (proving that tests have been performed according to a defined test process).
- Controlled item
- Modification of a controlled item requires prior approval of such modification, e.g. in the form of an approved change request.
- A specialization of an objective in which the objective is described in terms of sub-objectives (checkpoints) that need to be checked before the objective is fulfilled.
Tying it all together
Hopefully we now have all the building blocks to describe the operations of an organization, specifically those “creative” processes that are too often described in a linear manner which doesn’t do justice to the complex ordering of tasks in such a process. Let’s look at a few examples to see how far our modeling elements take us.
The classic document-in, document-out view
|Diagram showing associations between a workflow, its input items, its output items and the role(s) involved in the workflow.|
We call this type of diagram an association diagram because it shows associations(relationships) between modeling elements. More specifically, the diagram says that the workflow Analyze change request requires as input an information item of type Change request. It is performed by the role System analyst and it modifies a Use case and a Supplementary requirements (specification).
Note that the association diagram can be used to illustrate any types of relationships between modeling elements. We could for instance have a diagram centered around a role illustrating which workflow the role is involved in or which documents the role is responsible for. In a typical setting just a few diagram patterns are used for simplicity and clarity.
Note that we are talking generalities in the models. What we’re really saying is that in a typical process information items of the type Change request are required as input to processes of the type Analyze change request. In the real world process instance you would have Change request #28392 that is fed as input to the Analyze change request in project Better Widget. Those of you familiar with object oriented programming recognize this as the duality between class and object.
The details of an item
As shown above, item is the generic class of objects that are, yes, objects. Examples are information items such as documents and database records and hardware items such as servers.
The largest “detail” of an information item is of course the actual information, the information contents, be it a requirement description, a design specification or a piece of source code.
In addition to the contents, we often wish to keep track of other details about the information item such as its status (draft, released, etc), its author, whether it is approved or not and so on. This type of detailed information is often called metadata. In this modeling approach we store metadata in attributes which can be seen as placeholders for such information.
Depending on the degree of support offered by the Process Support Application we may or may not be able to store the values of the contents or the metadata in the the PSA itself. The information items may reside in a separate document management system or other database. Such a situation may be viewed in two different ways: Either the databases are considered loosely connected parts of the PSA in which case also the instance information is stored in the PSA, or we can say that that the PSA only describes what the instance data shall look like but doesn’t actually store such data. Or to be more exact, the PSA describes the dynamic attributes but stores the static attributes.
Other items such as servers have other types of metadata such as model and vendor and no information content (in the sense that information items have information content) but the same principles apply.
Some metadata vary across instances of a modeling element whereas others stay the same. The author of a document varies for instance from document to document. The instructions for creating the document probably doesn’t vary from document to document. We call the first type of attributes dynamic attributes and the second kind static attributes.
Now we come to the part of this modeling approach that may be hardest to understand for people without a background in object oriented software engineering as the inspiration comes from there. For each information item we wish to describe the activities that are related to the information item. Trivial activities are Create, Approve, Review, Obsolete (verb) etc. These are all part of the information item’s life cycle and may vary between different information item types.
The more common alternative is to describe such activities (only) as parts of a workflow diagram and make information references from the activity to the item(s) to which it is associated. We instead consider the activity tightly connected to its information item and compile sequences of activities into workflows if need be for added clarity or prescription of a certain sequence of activities, i.e. that a document (a kind of an information item) needs to be Reviewed before it can be Approved.
There are a couple of advantages with associating activities primarily with items rather than with workflows:
- All activities need not belong to a workflow. Some engineering activities for instance can not be described in the linear description language of a workflow diagram. The exact sequence of activities that lead to a completed design specification can for instance often be neither prescribed nor described exactly. But we may still know what activities (in any order) that are required to create a complete design specification.
- If it is hard to find an item or an objective (see below) to which an activity can be associated then the existence of that activity can be questioned. This modeling approach thus encourages design of efficient processes with a minimal set of activities.
The details of a role
Basically all modeling elements (process, item, role, etc) have the same potential substructure described with diagrams, attributes and activities. Roles typically have at least the following static attributes:
- Accountabilities (Responsibilites): What the role is accountable for in the organization. Typical examples of attribute values include “budget” and “project time plan”.
- Authorities: What the role has authority to decide upon. Examples are “resource allocations within budget” and “initiate new development projects”.
- Skills: A list of crucial skills needed for the role. An example is “knowledge of the Medical Device Directive”.
The details of a workflow
The main purpose of the workflow is to prescribe a sequence of activities (that in turn are defined in association with items). This is typically done in the form of an activity diagram (see figure to the right). Each activity in the activity diagram corresponds to a defined activity (see above) that is typically associated to an item or an objective. Note that some activities may not belong to a workflow while some may belong to one or several workflows. When an activity is part of an intellectual workflow that is not repeatable it is not useful nor even possible to depict the workflow in a simple sequence. As already hinted above, one of the strengths of the meta-model described here is that it does not assume that all combinations of operations (activities) can or should be represented by a simple sequential diagram.