While talking with a client yesterday I failed to articulate clearly the difference between templates and patterns.
In fact, they represent two methods of problem solving:
- A template is a standard solution for a certain type of tasks. E.g. when I’m going to conclude a partnership agreement I pick up the appropriate template and it becomes a zero version of the document.
- A pattern prinicipally is a standard solution too, but it is used creatively on the basis of a “problem shape” rather than problem’s formal type. Unlike templates, patterns may come with a positive (”how to do”) or negative sign (”how better not to do”).
Vague enough, right? Trying to make it simple, I found an analogy in chess:
- Debuts are templates: learn them and use them, chessbooks plot the game 20 moves ahead from the initial position.
- Typical combinations of the middle game are patterns. E.g. fork is a pattern: if you can see an opportuntiy then use it or threaten to do so. Two rooks on the same vertical is a pattern too while two pawns is an antipattern: try to avoid such a position if possible. But no chessbook contains instructions how to make a fork starting from the initial position.
With regard to business processes, sometimes a business process model is called a process template. Process instances are created from templates about the same way as zero version of the document in the example above.
The second meaning of the term “template” is a typical, standard process model. A vendor or consultant develops a process model on the basis of previous experience and then offers it to prospective customers. Supposedly the customer will be able to use it with small customization, saving efforts in comparison with a development from scratch.
For example, my company Business Console successfully implemented a BPM solution targeting a sales process executed through geographically distributed offices and now we offer it as a template, i.e. a starting point of a BPM project to companies that manufacture and install plastic windows, metal doors, custom-made furniture etc.
Pattern in BPM is a typical process fragment of typical way of communication between processes (some examples).
One may ask: which one is more usefull? My opinion it’s a pattern:
- Templates are specific (one process - one template), patterns are universal. A good pattern can be used in a variety of business processes regardless of the industry.
- A practical benefit of using a template may be less than expected. It usually covers the happy path only and the devil is in details - various workarounds, escalations and exceptions.
- The effect of using the right pattern can be large. For example, there was a case in our practice when the process plotted at 6 A4 sheets glued side-by-side was reduced to the elegant design with just 15 activities by using the right pattern.
- The value of the antipattern is its ability to preserve you from mistakes. The price of a mistake is unlimited in theory and sometimes it’s really big in practice.
Another reason of my skepticism towards templates is the fact that in case of BPM we are targeting continuous improvement, not one-time automation. Templates, by definition, can be applied only once: during initial modeling. The ability to use patterns will remain open forever. It’s quite possible that after discovering a new pattern you will look at the processes you designed from a different perspective and will find a way to improve and/or simplify them.
While I agree that there are two distinct concepts here, trying to separate them by the use of words “template” and “pattern’ is, I think, a mistake. Lifting our noses out of the mire of IT we would see that these words are synonyms with a long use as equivalents in fields such as engineering and fitting with your use of ‘template’. Unfortunately, I cannot think of a suitable alternative for pattern!
David
Thank you for valuable input. I’m not a native speaker and can’t judge on these two terms usage in English. So it’s better to clarify each time “let’s call a template this and a pattern that”. OK then.
Luckily for us, in Russian they are two distinct terms. “Pattern” was borrowed from English not long ago. There were “behaviour patterns”, patterns in image recognition and now we also have “design patterns”.
Anatoly - this is an interesting post.
While the distinction seems subtle, it is important. I, too, have been skeptical of templates (though I have, at times, seen them work well). But it is hard for many people to understand how valuable design patterns are if it doesn’t mean that they can just “copy-n-paste and edit” the pattern as if it were template. Ie, the “re-use” in the design pattern is knowing well how to solve a problem with a pattern that has been proven over time to be a good one. The “re-use” of a template is using existing code with some additional configuration or editing, in my view.
The observer pattern is often one that you can explain to people - the template isn’t that useful because you don’t know exactly what the technical underpinnings of the pattern are (webservice? jms? db trigger? other? ) but the concept is highly re-usable. Notification patterns in general are good examples, I think, for the non-technical audience.
After using Lombardi for many years, I finally spend some time with a Pega expert… and I finally “got” the difference - It’s related to the difference between patterns and templates that you’ve outlined.
Pega has many vertical market Frameworks - very much like your Templates. These are “80%” solutions… Fill in or customize the remaining “20%” and you are done.
Lombardi doesn’t have any “Templates”… but there are several “Patterns” that we tend to follow time and time again.
For example, I frequently find myself following a “Hierarchical Approval Pattern” or a “Parallel Approval Pattern” or a combination of the two.
I think of patterns as proven approaches… When I hear the business person describe the process, I think to myself “Ah… I can use pattern X”.
I think of template/frameworks as being purchase differentiators - “We’re in the banking industry, and are processes are pretty standard banking processes”. If you’ve got a good banking template, you have a big competitive advantage.
John
Interesting point. Frameworks and templates have are similar by nature but for me they differ in scale. A template refers to a single process while a framework should cover all processes of the given industry, more or less.
Design patterns are for engineers and templates are for business people. If you are an engineer then a pattern is for you! For a business person? Forget it! A template does neither have to be an end-to-end process nor rigid. A rigid template is definitely worse than a set of good reusable design patterns. But what if templates:
a) can be created by business users by simple assembly,
b) are organized in understandable goals and subgoals that can be linked,
c) contain EVERYTHING that makes the process executable,
d) can be added to a process at any time,
e) can be modified where authorized and necessary at runtime,
f) allows the user to react to unepxected events by adding tasks, performers or goals,
g) are guided and controlled by policies, rules and constraints,
h) and finally, template modifications are reusable by other business users again?
At this point in time design patterns become definitely the lesser choice. A business user now has several times the creative and expressive power over an engineer fumbling with his large library of desgn patterns. The business user works in real-time at real business problems while the engineer is in the dug-in-trenches of process theory! I ask you, which is the better?
Max
Thank you for the passionate and much-promising input. Can you give an example of such template? A name, target business and few characteristics by your choice but not just a silent hyperlink, please.
I’m confused by your note about the end-to-end process: it’s what creates value for business, everything else is secondary. What’s your point?
A.B.
100% agree with “.. Lifting our noses out of the mire of IT we would see that these words are synonyms with a long use as equivalents in fields such as engineering and fitting with your use of ‘template’.
Еще есть “гуру” от ИТ, которые умудряются разделять термины “услуга” и “сервис” - которые так вообще, одно - перевод другого заимствованного слова. Конечно, мы имеем право придумывать свои термины сколько нам влезет (до тех пор, пока не забываем их определить) в рамках любой предметной области, но зачем плодить сущности без надобности?