My colleagues and I  recently attempted to define a set of processes that would support the requirements of the services management standard, ISO 20000-1, which captures best practices like the ITIL (Information Technology Infrastructure Library). The supporting standard, ISO 20000-4, is a process reference model, which is a set of processes defined at a very high abstract level, capturing the essential elements so that any organisation can adapt them to their particular circumstances.

Two other process reference models have been developed for software development, ISO 12207, and systems development, ISO 15288. So we have precedent process reference models, a set of requirements that must be met by the process reference model, and several willing and experienced standards developers. Should have been easy task to develop another process standard for services management, right? It wasn’t and the reasons why are likely to be repeated in many organisations over the next few years.

The problem that we didn’t expect is that processes, like software, need some sort of architecture so that the processes, their attributes of interest and the relationship between them can be developed. Software and systems developers are so used to developing architectures; to breaking the problem down into major responsibilities and so we never thought this would be a major problem. It seemed obvious that there should be some processes looking after the management responsibilities and organising the other processes; some processes concerned with getting things done and others providing specific services to all the other processes. That should be obvious to people accustomed to thinking that way. But it wasn’t obvious to everyone how the requirements should map to processes and how the processes should interact.

This scenario will play out in many organisations in the near future as more and more enterprises try to solve the problem of what value they offer to the market and how they realise that value. Solving this general problem has been the subject of many popular books about business process engineering. Although it may seem that nothing much has changed, in fact quite a lot has. One of the main changes has been that what was the smallest unit of organisation, the project, has broken down further so that now the smallest unit is the process. Projects are carried out through a series of processes and each process can be provided internally, externally, by consultants, by contractors, by blended teams, in this country, in another country and who knows what else. Muddling through, as we have done so far, is unlikely to avoid many of the pitfalls of this complex environment. A sound body of knowledge about processes will help, starting with the means to reason about process. Part of that reasoning will probably be labelled Process Architecture, for want of a better term.

Processes have been compared to software, but Leon Osterweil, the person who first did so, was very concerned that the analogy would be taken too far. It has and it is probably time to address the limits of the analogy which largely arise because software is performed by a computer, and therefore does what it is told, whereas processes are performed by people who do whatever is required by the circumstances. Yes, there are some processes that are performed by people that could equally be performed by computer but let us not get bogged down there. There are many processes that require human intellect to make sense of the situation, decide what to do then perform a selection of actions in a specific way to produce specific outcome suited to those precise conditions. Computer programs aren’t suited to such variability and it is fruitless to pursue the idea that everything can somehow be turned into some sort of well controlled procedure.

Out of this comes the idea that there will always be a need to reason with and about processes. We cannot (yet) expect everything to be mechanistic and so we need some concept of a Process Architecture to provide humans context and coordination for our processes.