A decade ago few people dealing with code were interested in business processes. That’s no longer the case. Due to a variety of reasons many developers discuss processes in one form or another. Some want to understand the business process that the appplication they’re building implements. Others want to grok the coordination of the services comprising their SOA. Yet others leverage workflow engines to implement the flow of pages in web applications (i.e., page flow).
A large fraction of these folks assume that processes always involve activities and their sequencing. Right? Wrong! Just because the workflow/orchetsration/coordination/etc. engine they picked to implement your process revolves around activities doesn’t mean that that’s the only way to think about a process. There are many instances when representing a process as a set of activities is unfeasible. Consider for example a web-based shoppping site: at any point you can perform one out of many activities: add something to your shopping cart; remove something from your cart; checkout; update your profile; save the cart for another visit; and so on. How would you represent somethig like this with activities?
What’s missing is the process model, something that not many newcomers are aware of. In a nutshell the process model provides the set of abstractions, relationships, and constraints that allows people to define processes. Several process models are available, each of which is suitable for a particular class of problems.
The most popular process model is activity-based. Its abstractions represent the activities performed as part of the process (or the states between these activities). This model is suitable when the process can be described through activities. It is also easy to understand because the activities resemble the elements of structural programming. However, as the web-based shopping example illustrates, sometimes it’s cumbersome to express a process as a set of activites.
Another process model uses conversations among participants as the fundamental abstraction. This model has its roots in social sciences and was pioneered by Terry Winograd (a computer scientist) and Fernando Flores (a philosopher). Together they founded Action Technologies, a company that in the mid-1980s built the first workflow system employing a conversation-based process model). Winograd and Flores describe the ideas behind their Business Interaction Model and ActionWorks in Understanding Computers and Cognition. Anyone serious about workflow ought to read their book.
A third process model uses the artifact produced as the process unfolds as its key abstraction. Though not as popular as the activity-based process model the artifact is well suited for representing processes where at any point one out of many actions are possible, such as an e-commerce Web site. The work of Richard Hull and Jianwen Su (among others) focuses on this process model. AT&T’s Vortex workflow system represents a research prototype built around the artifact-based process model.
I’m sure there are other process models, including hybrid ones that combine some of the above. Unfortunately the literature is scarce in this area. In addition, the increasing popularity of the activity-based process model (mostly because people don’t know any better) will only bury the other models even deeper.