John Reynolds, commenting on Sandy Kemsley's blog, where she was writing about Shell's BPM success story:
Note that Sandy's tale mentions Templates, but it doesn't say a thing about Frameworks... and to me that's very significant...
As a Professional Programmer, my life revolved around Frameworks (OWL, MFC, Struts, Spring, etc.)? Each of these Frameworks provided a wonderfully powerful foundation on which I could build my custom applications.? I simply can't imagine life as a Professional Programmer without programming Frameworks.
Pardon me for over-simplifying, but a Framework is something that "you bolt pieces on to".? The Framework provides the internal structure of your program, and you can build many diverse and wonderful programs on top of any really good Framework.
If you are an Occasional Business Programmer you've probably found that Frameworks aren't quite what you're looking for.? Frameworks are really powerful and really flexible - but all that power and flexibility comes at a price - you really have to know what you're doing to use them.
I think the narrower interpretation of the word Template is useful to the "Occasional Business Programmer".? Of course from a technical point of view, most of what gets pitched in the BPM industry as "templates" are really Frameworks, using the definitions John uses above.? And Frameworks, as such, are problematic.? They require not only being an expert on underlying BPM technologies, but also on the APIs (programming interfaces) of the Framework itself.? For people that are more than occasional programmers, patterns will help more than frameworks - as they'll apply to more situations.? Borrowing from a Navy Seals slogan, I think patterns "equip the man", whereas with Frameworks tempt one to "man the equipment".