I am faithful believer when it comes to patterns. SOA patterns, J2EE patterns, and definitely BPM patterns. Patterns greatly help to capture and compartmentalize the existing “best of the breed” knowledge. It is however, tricky to capture the patterns into tooling, to make knowledge contained in patterns easily consumable. This especially true when it comes to BPM patterns, because they encompass different type of patterns. For example one of the types is abstract workflow patterns, which deal with general workflow patterns (like ParallelSplit, SimpleMerge, etc) and have no domain specific information. Other patterns have to deal with specific business connotation, for example ReWork or CheckOut patterns which provide suggested business processes for re-work and check-out activities. Since these activities are often domain or even company specific, tool vendors should be able not only to provide the specific patterns out of the box, but also to give users ability to modify these business patterns to suit their needs. Finally, each company might have their own specific company-wide patterns, therefore there is a need for tooling vendor to support definition of brand new patterns.
If we add the requirement to track the combinations of patterns and their affect on one another both on abstract workflow and business level, this becomes really tricky task.