External source: http://blogs.msdn.com/seinsight/archive/2010/04/22/a-re-introduction-to-patterns.aspx
The recent discussions about Software + Services and Cloud computing have in my mind reemphasized the critical role that patterns play in helping our industry capture proven practices across all disciplines from software architecture, infrastructure architecture through to business architecture.
Patterns and the “Cloud”
While many people look at cloud computing as a major paradigm shift requiring us to think completely differently about how we design our applications, I like to think of cloud computing as establishing a new set of design requirements (a different context) that requires us to select a different set of patterns than we might have chosen in the past.
While the solution design may be different, the patterns you draw from and use in this new solution design have for the most part existed for a long time. For example, many of the patterns that you must now consider when designing a client application that interacts with remote Services provided by third parties with uncertain availability levels have being used for a long time when creating mobile applications where network connectivity could never be guaranteed.
Usually it is about this point in any pattern presentation that I can break the room into two groups of people. Those that are rolling their eyes and claiming that patterns are academic and not useful to folks solving real problems where time is off the essence and the other folks claiming quite the opposite.
Moving forward with this column on SEInsight I am going to attempt to serve both audiences - using this blog to discuss a number of topics relating to creation, evaluation and application of patterns.
We’ll cover patterns from two main perspectives.
Application of patterns:
Why is a pattern different from other forms of guidance?
For this first weeks post I am going to focus on the topic of why a pattern is different from other guidance. This seems extremely timely because there are a large number of books / white papers / guidance hitting the press most of which will confuse the concepts listed below - and leave you no better off when the next major paradigm shift occurs - and leave you feeling like you have to relearn everything you thought you already knew.
When asked what a pattern is the standard answer you will get from a pattern geek is something along these lines:
"A pattern is a proven solution to a problem, described in context"
As a one liner this is reasonable - but it doesn't really help you understand what the qualities of a pattern are that separate them from other forms of guidance - nor does it help you discern a good pattern from a bad pattern.
Considerations when Writing and Reviewing Patterns
Here are a couple of considerations that I look for when writing or reviewing patterns.
Getting Feedback – “WorkShopping” Process
Now there is one last and very important point that separates a pattern from any other content and that is the work shopping process that a pattern should go through before publication. In short a pattern workshop is a usability study whereby a pattern author must silently observe (as if behind a one way mirror) a group of peers walking through the draft of a pattern - listening as their peers attempt to reconcile the description of the pattern statement, the solution and associated tradeoffs against their own experience.
Having been through this process a number of times it is amazing how you as an author might think you have captured the perfect pattern - something that is so elegant that it will surely have the same timeliness as famous patterns such as the Model View Controller pattern has - but as you observe your peers struggling to get past the introduction content you soon realize that many assumptions that you have made don't resonate with your peers.