The Beginnings of a Vocabulary
Several iBPM vendors have their own vernacular for describing their “capabilities”: Cordys/Fujitsu has their “Business Operations Platform”, Pega has their “Situational Layer Cake” and “Build for Change”. However these do not go far enough to help a business user describe how they solve problems in the iBPM platform.
Sure there is BPMN which attempts to give us a working set of building blocks for our process modeling activities. But this again is limited to the notion of modeling processes (visual representation) and does not prescribe the execution of a transaction within that process.
In the “Design Patterns” book, the Gang of Four precede their exploration of each design pattern by categorizing them into meaningful groups. This is a useful approach because it presents the ideas in a top-down fashion, moving through layers of abstraction to provide meaningful context to the underlying patterns.
An interesting sidenote is that Design Patterns need not stand alone and in isolation. Patterns solve for relationships (as described in Post II): what an individual instance can do, how multiple instances work together – including nesting relationships (a pattern might be comprised of several patterns combined together).
Just as in the “Design Pattern Book”, I submit that categories of patterns will help organize the underlying patterns in a way that will be intuitive to business architects and systems architects alike. Further I submit that iBPM design patterns must address both the business functionality provided by the pattern, and specific technical recommendations for practical implementation. Design patterns cannot succeed if they are just vapor-ware.
In subsequent posts I will expand upon a proposed set of Design Pattern categories. I will attempt to describe the intended business impact and the technical challenges which must be overcome within the design pattern.
Please like, share, follow or provide feedback in the comments section below!
PhilD IT Guy 