Templates Frameworks and Patterns, Oh My!

Scott Francis
Next Post
Previous Post
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”.  
  • AmotzM

    Frameworks can be high level business framework, or case management framework, into which you “bolt in” business specific components. As such, they reduce complexity of business solutions, not increase it.

    Within a well architected BPMS framework templates shorten the way to solution implementation, reduce cost and complexity.

    Done right both are very valuable.

    • I hear what you’re saying, but with respect to John’s post I think you’re missing the point:  Frameworks are useful to *technical* people, but not so much to the occasional programmer – the business, precisely because they require too much technical know-how.

      Regarding templates… they tend to be less work for a single implementation cycle IF (and only if) the template already well-describes your situation.  Typically as you step outside the boundaries of the template, it not only doesn’t cover it but you have to do extra work to make the template and your customizations play nice together.

      The second (common) issue with templates, is that once you change it (build solution on it), you own it.  It isn’t maintained as product – so new versions of the template will not be backward or forward compatible.  Moreover, the template code may make use of APIs or functionality that is not generally available at the time. Once you squeeze the toothpaste out, it is hard to put it back in the tube!

      This is why using a template, which sometimes looks like a big shortcut, feels like “manning the equipment” instead of equipping the man. 

      • You have to color my thoughts through my un-ashamed advocacy of “Rights for the Occasional Programmer”…

        When we deliver “80%” solutions, it’s usually “the top 20%” that folks have to build out – better tools for doing that would be swell… But also consider the “80%” solutions where all you have to do is connect “the bottom 20%” – better tools for doing that would also be swell.

        But of course the reality is that when the 80% is delivered you often have to “fill in blanks” all over the place with no help or guidance.  If that’s not rude, I don’t know what is ;-)

      • I like your definition of rude :)