Interesting reading….

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.

Two Audiences

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.

Concepts:

• Patterns vs. guidance. Why is a pattern different from other guidance?
• Vision for patterns. Who is this Christopher Alexander guy anyway and what was his vision for patterns and pattern languages
• Resources. Resources on software patterns.
• Best Practices when writing patterns. Hints for pattern authors
• Visual Notation. We’ll cover a a visual notation for patterns and how it’s useful
• Pattern Combination. Combining patterns together to solve systematic issues
• Reference Architectures. The role that reference architectures play prescribing combinations of patterns for specific scenarios

Application of patterns:

• Draft patterns for feedback. Myself and member of my team are going to start posting "draft" patterns for you to review and provide feedback
• Virtual Workshops. We are going to attempt to host some virtual pattern workshops for members of the field / public to participate in
• Pattern use in p&p. Talk about the role that patterns played in the p&p software factories

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.

• Actual Solution. A pattern describes an actual solution to a problem - it isn't just an abstract principle
• Based on Proven experience. The solution is based on proven experience - ie it is something that has been tried, tested and refined over a number of solutions at a number of different organizations
• Platform Independent. The solution is described in a platform independent manner - ie independent of implementation - hence it is durable. This would allow the same logical solution to be considered regardless of what version of a platform you are running on, or potentially even what platform you are running on.
  • Note that the pattern on its own may not be useful to many folks - which is why many pattern guides will have a separate piece of guidance demonstrating how to implement that pattern on a specific platform - thus increasing the relevance and applicability for that pattern.
  • patterns & practices used to call these implementation patterns - I personally think a "How To" style of document is sufficient.
• Include Tradeoffs. Patterns should include architectural tradeoffs that you must consider when selecting the pattern
  • The forces that steer you towards using the pattern or away from using the pattern
  • Benefits and considerations that you must consider if you do apply the pattern
  • Relationships to other patterns that might be good substitutes or might well be used in addition to this pattern
• Atomic. Patterns are also typically atomic - following the Single Responsibility principle. If you see a pattern solving a number of problems it is usually a sign that the pattern should have been split into multiple patterns.
• Named. And of course the pattern has a name, that if well thought out will establish a vocabulary for our industry.

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.