We use cookies and other similar technologies (Cookies) to enhance your experience and to provide you with relevant content and ads. By using our website, you are agreeing to the use of Cookies. You can change your settings at any time. Cookie Policy.
Start a Discussion

What key methods do you use for applying design patterns in BPM?

Vote 0 Votes
From this Scott Francis blog, Design Patterns in BPM - Lost Cause, that discusses Janette Wong's talk at CASCON about all the hard work still required to make a design pattern actually executable -- in particular with respect to role-based task assignment: So what are some of the best ways you've found for making design patterns work?

13 Replies

| Add a Reply
  • I don't believe in rigid, reusable processes and therefore not in process design patterns. What I know does work is to organize the processes in templates to fulfill particular goals and subgoals. Is a template a pattern? Maybe.

    But that template must include the goals, the metrics, boundary rules, content, data mapping and user interactions. Work is assigned by skill profile or business role. A flowchart design pattern is not really helpful because one still has to do all the other process coding and it is unlikely that it fits as-is.

    A goal-oriented process template as we use it in ACM does not enforce execution and the template is completely ADAPTIVE meaning can be changed during runtime and the changes are reusable in future executions. Innvoation is built right into the process.

    As these goal-oriented templates are not designed upfront but assembled on the fly, the question of designing standard patterns becomes irrelevant.

  • I have to say that after many years of trying to build intelligent maps, and using design patterns to identify processes, I have found that design patterns work wonderfully well for only a small amount of processes. These are simply and highly repetative processes, ones that are easy enough to indentify and use any form of flow diagram tool to map.

    If we are looking at more complex situations, or different approaches in the way we work, so working more as a team rather than individuals within a "production line", then you will need a more flexible and adaptive approach to work in general. In such cases, design patterns are a lost cause - you simply will never be able to map out all the permitations of work, and if you could, it would shortly change, making your process map outdated...

  • Peter, thanks for the reference, I'm flattered :)

    I think we have to define pattern vs. template. A pattern is not a rigid, reusable process. It is a diagnostic/identification tool - so that you can recognize quickly when a set of requirements match up (roughly) to a pattern, and be confident that the pattern represents good design rather than bad design (anti-patterns).

    Wikipedia has a good writeup of computer science software patterns: http://en.wikipedia.org/wiki/Design_pattern_%28computer_science%29
    Some of them are relate-able to BPM, but most aren't. Specifically behavioral and concurrency patterns might be interesting.

    But the point is - these patterns aren't coded. They're conceptual.

    For example. The HashMap implementation in Java is great, and I'll probably never (almost never) need to write my own implementation of a HashMap. It is configurable, tweakable, etc. But I need to know WHEN I should use a Hash Map, and that's where design patterns come into play.

    What Max describes - it does sound like a template. A highly configurable/adaptable template. And that's great. Without understanding the details of the software it is based on, I can't judge whether it truly makes design patterns irrelevant. I've yet to see process templates (to date) that do this, but I wouldn't say it isn't possible.

    From Max' response, I feel that he's equating a pattern with a fixed implementation of something (code and all)... but that isn't the operating definition that I, Sandy, nor Anatoly were working with. In fact, a pattern doesn't have any code pre-written. A pattern is conceptual, not concrete.

    But if you understand good software design patterns, you can write better software more quickly, and with more confidence. If you understand good process design patterns, you can implement better processes more quickly, and with more confidence...

    The journey Janette described is understanding the patterns that apply to the requirements, and then doing the implementation to make that pattern a real, running process (concrete implementation). The pattern didn't ship with implementation baked in.

    It is (not quite) analogous to a software interface vs. a concrete implementation. Whereas most people think of templates as either an abstract class (some implementation provided), or a concrete class that can be further refined/configured/etc. But which also (necessarily) brings along some implementation assumptions and baggage.

  • I believe in tools that worked in practice. For this reason I like patterns. Unfortunately some of them e.g. some “workflow patternsâ€? are a bit difficult for the users. So, I collected about 20 practical patterns (simple and advanced) in my book and in my blog http://improving-bpm-systems.blogspot.com/search/label/practical%20process%20patterns

    I would like to be able to construct a business process (a template or an instance on on-a-fly) from small process fragments (similar to the chess game in which we have standard combinations). Some of them will be predefined in a library of process patterns, some of them have to be created on demand. (More about this in http://improving-bpm-systems.blogspot.com/2010/04/let-us-architect-use-of-existing.html).

    For me, the closest match to patterns are macro-commands which we had in assemblers at run-time. Of course, now we need them at design time.


  • Design patterns are the essence of engineering skill. Any kind of engineering, whether it's architecture (in traditional sence), industrial design, software engineering, database engineering or process engineering.

    Good java develpeer applies patterns all the time. More professional he is, more naturally he does; a good professional does it almost unconcious: he/she looks at the problem and got the key solution within a minute. We design databases by applying various patterns: master-detail, object-history, object-transaction etc.

    Process engineering didn't reach that level of maturity yet, but this discussion is a good indication of the progress.

    And yes indeed patterns aren't templates.

    But classic workflow patterns are far from what process engineering really needs. They are a usefull tool to asses tools - no more, no less.

    They are process equivalents of programming language constructs: do-while, do-until, foreach... do you see a huge difference between these and object-oriented programming design patterns? I'm trying to find equivalents of the latter for business processes and I trust Alexander does the same.

    Getting back to the original question - there is no "method" for applying patterns IMHO. You just "get" it. Or not. Or not yet. The key word for a pattern is "recognition".

  • Anatoly, once again I think you've explained it perfectly. I was just saying to someone else that a "pattern" example is knowing you need to use a steeper roof in cold climates to keep the snow from building up (and caving in the roof).

    As well, I think your explanation of what the "workflow patterns" do is exactly right - they were just designed as a completeness test for vendor tools, not as an aid for "good process design" for consultants (or others).

    I think the learning of how to apply process design patterns falls into the category of a craft, passed down from more experienced to less experienced people, shared amongst colleagues, etc. Not everyone has an equal skill or knack for pattern recognition, but everyone can improve upon it by studying up.

  • Experienced process designers / optimization experts are good at one thing: identifying patterns in the situations they face on the ground. That's what a good Solution Architect is really "good" at while designing systems, and that's what a good engineer is good at while designing a solution to a problem.

    So, experts don't really need patterns for reference. They, based on experience - if good at sharing the knowledge - can document the patterns that make them the best in their field. Those documented patterns, in turn, can be used by lesser experiences practitioners to replicate those successes.

    In that sense, I see a lot of meaning in the way Anatoly has dealt with the question. It's about recognition of patterns - sometimes by experience, sometimes by reference.

    As for Patterns v/s templates: if done well, templates "could" be the concrete implementation of an abstract patterns. But, in case of templates, the objective is tilted toward productivity and reuse, and not necessarily toward process design/optimization.

  • A new understanding of patterns value came to me after BPMN classes I gave recently: they provide the "A-ha!" effect on students. There is much to do for all of us but this is the way to go to make process engineering a mature discipline.

    The current maturity level of process design is similar to those of database design 20-25 years ago: there were good enough commercial DBPMS at that time, good guidelines (3NF) and some really good implementations but my God, I've seen a lot of terrible designs, too. And people were disputing angrily about whether DBMS are really necessary - much like current debates about BPM(S).

    To be honest, are there many examples of solid process design around? Vacation requests, employee onboarding... how can we expect it to be taken seriously by business?

    How about order-to-cash end-to-end process? We did it at our classes for a beverage distribution business (students have choosen the processes from their business practice) and it was very exciting. Yet I didn't see neigher templates nor patterns for things like this in vendors or consultants portfolios. OK, may be they just don't publish it, but frankly I doubt they have much to hide.

  • Hi all,
    I've been working both on software engineering (where design patterns have basically redefined the entire discipline) and in web and BP design.

    My two cents on this issue:
    I think to patterns as reusable design solutions to known problems. The concept is a very abstract one.. actually, as you may know they have been first used in architecture (meaning bricks and concrete, not software :-) See: http://en.wikipedia.org/wiki/Christopher_Alexander ).

    I agree with Scott on the purposes of patterns and on the fact that they don't really induce a fixed implementation
    [As a side note: I think the Hashmap example, while it makes your point, is already too detailed to be called a sw pattern, that's already a design solution.]
    However, while in software engineering I see patterns as usable in every setting, I agree with Andrew that in BPM they can be useful for composition of rather standard processes only. This is not so bad, since I would say that a large percentage of processes may fall in this category. Anyway, for sure ACM is not a field where a see an easy application of patterns, since ACM addresses a set of problems that are inherently not codifiable a priori (and on this I'm in line with Max).

    In the academia van der Aalst and others have codified a fairly complete set of workflow patterns ( http://www.workflowpatterns.com/ ), which are a useful tool for some purposes (e.g., comparing the expressive power of different workflow languages), but I'm not sure they are nearly as useful for actual BP design within industrial scenarios (honestly, I haven't seen anybody using them in this way; have you?).

    As a concluding remark, I'm not really sure about what is the real difference between a pattern and a template. Here is my (possibly simplistic) interpretation (opinions and criticisms are welcome): a pattern is a simple solution to a small problem, that composed together with others can contribute to a solution of a complex problem; a template is a complete solution which is completely configurable for being adapted to different context and therefore address similar situations.

  • I think that some business oriented BPM with little IT background will confuse pattern and template. Like those that say BPM = BPMS.

    Thus and like some people said a template (the dangerous concept some will start saying is a pattern) is a complete reusable solution that can be implemented whatever process. Example: an approval process, with approval request, approval/rejection task, ... this great to speed up process automation, but cannot fix completely the process problem a company is facing.

    A process pattern is a solution to resolve a specific business problem is a way of acting (the way people will execute things - independently if it use workflow patterns - petri nets whatever), the relationships and the outcome to be achieved. Is an abstract concept and I don't know if it can be used out of a company culture, process architecture, company organization. Seems to me that it can be a dangerous concept if people will try to use whatever problem/company people are dealing with, like a template!

  • Anatoly made the most important point: "Design patterns are the essence of engineering skill."

    Therefore BPMS are today about software engineering but not about solving business problems. If there is the need for design patterns to be able to use BPMN productively then it is for engineers and NOT for business users.

    BPM is ONLY about solving business problems for business people and ideally IT should set up the technology and get out of the way and not having to supply design patterns! But the need for a costly and slow BPM governance bureaucrady shows very clearly that this is not the case.

    A template could be assembled from process fragments using some design patterns, and thus templates could be called a methodology for using design patterns. I would not want to put such a restriction on the business. If some things are reused heavily because the work well then they might be a design pattern, but not being engineers the business people wouldn't bother to call it that.

    For an adaptive approach templates are not created by someone outside the business. The business users themselves create business goal-oriented templates on the fly and reuse them in parts or whole as they see fit. IT, internal or external BPM consultants have nothing to do with it. Additionally is a process template not just a flow but a complex assembly of data, content, events, rules, roles/skills all linked into a business goal context.

    PS: ACM is just an area where applying an adaptible process approach is more accepted than by the usual suspects in BPMS.

  • Max

    I appreciate your quote but you missed the context: I was talking about process engineering wich is different from software egnineering.

    The mission of a BPM professional a.k.a. process engineer is to fill the gap between business and IT. Does this gap really exist? Well it's the matter of personal experience; from my perspective the gap does exist and something should be done about it.

    I can't agree that BPM is ONLY about solving business problems - if that was the case then what would be the difference between BPM and business? Forget about processes and go managing businesses, now!

    BPM isn't a software engineering either. BPM professional's competencse spans from business to IT, overlapping both domains so that he/she can communicate to both sides freely but not to the extent to fully cover them.

    Whether it'd be predefined processes or adaptive ones is a secondary issue. Generally speaking, there is room for both. A company that outsourced all routine operations overseas and focused on creative work would be more interested in adaptive things but it also means that outsoursers would be more interested in repeatable things.

  • In my opinion, there is no easy answer for this question. The best answer lies is the context in which BPM (straight-through, work flow, event driven, case driven, etc.) is implemented within an organization. There are low-level normative design patterns that have defined semantics and rationale, such as split patterns, join patterns, sequencing, etc. (On a side note, a good resource for such low-level normative design patterns is http://workflowpatterns.com/). On the other hand, there are high-level design patterns that could be generalized or domain specified for collaboration patterns that articulate how organizations and their partners should interact. What our company provides, for example, is pattern identification and dynamic process mapping (or an invocation framework) where organizations and partners can build or recognize patterns on the fly.

Add a Reply

Recently Commented On

Monthly Archives