The Process Patterns Resource Page
Home  |  Articles  |  Books  |  Podcasts  |  Contact Us  |  Mailing List  |  Site Map

Frequently Asked Question – What are Process Patterns?

My definition for a pattern, and there are many out there so don’t get your knickers in a knot if it isn’t the one that you felt was the "official" one, is that a pattern is a description of a general solution to a common problem or issue from which a detailed solution to a specific problem may be determined (see also: James Coplien's definition and The Software Patterns Criteria). Software development patterns come in many flavors, including but not limited to analysis patterns, design patterns, organizational patterns, and process patterns. A process pattern is a pattern which describes a proven, successful approach and/or series of actions for developing software. I would argue that process patterns and organizational patterns go hand in hand, and that there are at least three types of process patterns that we are interested in.

Just as there are process patterns, there are also process antipatterns. An antipattern describes an approach to solving a common problem, an approach that in time proves to be wrong or highly ineffective. As you would expect, a process antipattern describes an approach and/or series of actions for developing software that is proven to be ineffective and often detrimental to your organization.

Frequently Asked Question – What Books Are Available?

Frequently Asked Question – What is the History of Process Patterns?

The concept of process patterns, and organizational patterns in general, was first introduced at the 1994 PLoP'94 conference. Jim Coplien’s paper "A Generative Development-Process Pattern Language" presented at conference and published in Pattern Languages of Program Design (Addison Wesley Longman, Inc. 1995, eds. Coplien & Schmidt) is a key "first" paper in process patterns, as are the rest of the papers presented at that conference. Since then the organizational patterns community has grown, with further presentations at PLoP conferences as well as printed and online papers and books being written. The key goal of this web page is to present a centralized source of information about the process patterns portion of this work.

A general history of patterns.

 

Frequently Asked Question – What Types of Process Patterns Exist?

As I indicate in my books, Process Patterns and More Process Patterns, I believe that there are at least three types of process patterns. In order of increasing scale they are:

1. Task process patterns. This type of process pattern depicts the detailed steps to perform a specific task, such as the Technical Review and Reuse First process patterns.
2. Stage process patterns. This type of process pattern depicts the steps, which are often performed iteratively, of a single project stage. A stage process pattern is presented for each project stage such as the Program and Rework stages.
3. Phase process patterns. This type of process pattern depicts the interactions between the stage process patterns for a single project phase, such as the Initiate and Delivery phases.

Taxonomies for organizational patterns are discussed below.

Frequently Asked Question – What are Organizational Patterns?

There is a growing body of patterns called organizational patterns, the key resource page for which is Jim Coplien’s Organizational Patterns site which describes proven, successful approaches for organizing and managing people involved with the software process. Organizational patterns and process patterns go hand in hand and should be used together.

Kaul proposes to use the three dimensions – Structure, Process, and Behavior – presented in Gamma (1995) as a taxonomy for organizational patterns. Kaul believes that structural organizational patterns would cover established patterns of interacting and coordinating technological and human structure of an organization, covering much of the same ground as does organization structure and some management patterns. Process organization patterns would be patterns relating to information flow, communication, and decision making within organizations, covering the same ground as my process patterns and some management patterns once again. Finally, behavioral organizational patterns deal with delegation within organizations, covering the same ground as role and some management patterns.

Cusik also proposes a taxonomy for organizational patterns, specifying (but not defining it seems) three types: process, project risk, and organization. His process type appears to map reasonably well to mine, project risk seems to be a subset of my management type, and his organization type seems to encompass my organizational structure type, role type, and part of my management type.

Why is a taxonomy important? I suspect that different types of patterns will require different approaches to documenting them. For example, I believe that when you are documenting a phase or stage process pattern that it is valid to indicate potential metrics that may be collected when performing that process, as well as potential risks that may need to be mitigated. Would this be true of role patterns? Probably not. Different types of patterns, different (but consistent) ways to document them.

References for this section:

Gamma, E., Helm, R., Johnson, R., Vlissides, J. (1995). Design Patterns – Elements of Reusable Object-Oriented Software. Reading, MA: Addison-Wesley Publishing Company.

How To Document A Process Pattern

I believe that there is a need to combine the existing work in process patterns, well defined (yet still evolving) within the patterns community, with that of the existing process improvement community. The implication is the need for a format/template that both communities understand and agree to. In that light, immediately below is one way that a process pattern can be documented and following that I have included links to what others have to say on the subject.

Process Pattern Format:

Name. Provide a concise, strong name for the pattern, such as Program or Reuse First.

Intent. Describe the process pattern in one or two paragraphs, providing if applicable a graphical description of the process pattern. Common graphical notations applied to process patterns include, but is not limited to, flow charts, process diagrams, UML activity diagrams, and data-flow diagrams.

Type. Indicate if it is a Task, Stage, or Phase process pattern.

Initial Context. Indicate the situation to which the pattern solution applies, and if applicable the entry conditions that must be true before the process may begin.

Solution. Describe in detail how to perform the steps/activities of the process pattern. You may also choose, particularly for phase and stage process patterns, to describe management, quality assurance, and risk management issues, as well as indicate potential metrics to collect when working the process.

Resulting Context. Indicate the situation/context which will result from performing the process pattern solution, including if applicable the conditions that must be true for the process to be considered complete.

Related Patterns. Indicate the other patterns that this pattern is composed of, is a part of, or is associated to.

Known Uses/Examples. Indicate where/how the process pattern has been applied in use. For example, the Technical Review task process pattern can be applied to the management of peer reviews, code reviews, model reviews, and management reviews..

If you are writing a single process pattern, and hopefully publishing it to share with the rest of us, then I would suggest that you follow this format to the letter. If you are strictly writing a reference book or reference web site, presumably a collection of process patterns, then I would also follow this format or one close to it. If you are writing a process improvement-oriented book, as I did, you might choose to get a little more lenient in your approach. You’ll note that in my book I followed this format, for the most part, for phase and stage process patterns, but was much less systematic for task process patterns. It was simply a matter of usability. I could just have easily written a very structured reference manual (yes, Process Patterns can and should be used as a reference manual) but it wouldn’t have flowed as nicely and it wouldn’t be as usable to its readers. My advice is to do what you think is best for your readership, that the format described above is merely a good suggestion.

Process Improvement and Process-Related Resources

•  Agile Data Home Page
• Agile Modeling (AM) Home Page
• Agile Unified Process (AUP)
•   Enterprise Unified Process (EUP) ^TM
• My Patterns Writings

Copyright © 1998-2006 Scott W. Ambler Last updated: December 14, 2006 Agile Data (AD)  |  Agile Modeling (AM)  |  Agile Unified Process (AUP)  |  Enterprise Unified Process (EUP)