The author wishes to thank colleagues who have contributed to the ideas in this paper, in particular Tim Huckvale. The work has its roots in research undertaken by Clive Roberts (now of Co-ordination Systems Limited) and myself, which itself was based on work by Anatol Holt, to whom I extend my thanks.© Deloitte & Touche Consulting Group.A re-engineering proof process architecture 233(2) Almost as importantly, the designer needs a way of deciding what are the processes in the first place and how they fit together when the world is "running".Both of these concerns are answered by STRIM®, an approach to process design, modelling and analysis that has been developed and used in a great many situations and industries. STRIM®, as described in Ould (1995), concentrates on the first, process-level question: how can we most revealingly model a process? This paper describes how STRIM® has now been extended to cover the second question: what are the real processes and what are their dynamic relationships? I shall use the term process architecture to refer to a definition of the processes within an organization and the dynamic relationships between them. By the end of the paper I shall have given a very precise meaning to the term. Does it matter?Why is getting the process architecture right so important? There are several urgent reasons.An inappropriate division of organizational activity into processes can easily lead to unnecessarily complex designs or models. There is a lesson from software development: when we design software modules we look for high "cohesion" and low "coupling"; when modelling the real world, if we break a process into two along a natural "fault line" we will get fewer broken connections. We want to exploit any cohesion present in the real world. Our aim must be to find those natural fault lines.If re-engineering is being considered, a bad initial division can at best obscure the possibility of a radical change to a process and at worst lead to the local optimization of part-processes but overall pessimization of the total process. This is especially true if we arbitrarily break things into pieces in a sequence and call each piece a "process", something that is all too often done.People (especially those of us with software engineering backgrounds) have a natural desire to decompose a process into successively smaller subprocesses, in other words to draw up a hierarchical structure. The observation followed by STRIM® is that the world is rarely constructed in such a neat way and that the processes in an organization are more likely to be connected in a network than to be contained in one another. The danger of thinking hierarchically cannot be over-emphasized. To draw a diagram such as the one in Figure 1 is not to prepare a process architecture. Does it mean to say, as the diagram implies, that one process is the "sum" of four others? Where in the diagram are the dynamic relationships between processes represented? It is, after all, the dynamic relationships that are crucial to an understanding of h...

Piecemeal identification, development, and support of an organisation's processes may lead to problems: first, it may be difficult to identify which processes should be supported, and, second, it is unlikely that processes developed piecemeal will either optimise the achievement of an organisation's objectives, or work well together. One solution involves identifying and modelling an organisation's process architecture, and then using it to develop and subsequently support the constituent processes. However, this solution leads to a new challenge: a number of different types of process architecture method have been proposed, but it is not clear which should be used in a given situation. To address this challenge, the article outlines a framework for classifying, evaluating, and comparing process architectures. Following the work of Rolland et al.(1998), the proposed framework considers process architecture methods from four different views: contents, form, purpose, and lifecycle. To partially validate the framework, it was used to classify and evaluate Riva (Ould 2005), a particular process architecture method. The result of this application of the framework suggests how it might be refined. It could then be used for comparing other process architecture methods. Such a comparative analysis should help practitioners choose between process architecture methods.

The designer of a software system, like the architect of a building, needs to be aware of the construction techniques available and to choose the ones that are the most appropriate. This book provides the implementer of software systems with a guide to 25 different techniques for the complete development processes, from system definition through design and into production. The techniques are described against a common background of the traditional development path, its activities and deliverable items. In addition the concepts of metrics and indicators are introduced as tools for both technical and managerial monitoring and control of progress and quality. The book is intended to widen the mental toolkit of system developers and their managers, and will also introduce students of computer science to the practical side of software development. With its wide-ranging treatment of the techniques available and the practical guidance it offers, it will prove an important and valuable work.

No abstract

No abstract