Introducing Design Patterns

Design Patterns are an important part of software engineering today, but what many folks don't realize is how ubiquitous they are becoming within the full spectrum of IT activities. Part of the reason this is the case is due to the flexible nature of Patterns.  Mastering Design Patterns is a critical part now of most IT Architects' roles and from a larger perspective is also becoming increasingly import for most enterprises.

Before discussing how to manage Design Patterns, we first need to define what they are:

Design Pattern - This represents a description and (usually) a visualization of some specific aspect of a larger design solution. Patterns can employ standard or non-standard notation and may or may not be used as Enterprise Architecture (EA) artifacts. The most important characteristic of a Pattern is that it encapsulates at least one significant design principle. Patterns are usually combined to produce comprehensive solutions.  Patterns can also be used as code "templates/stubs" to facilitate rapid development of applications and services. 

Beyond this basic definition, Patterns can mean many things to many different types of IT specialists. For example, Cyber Security experts can manage Patterns as mechanisms for modeling Threat behaviors. Network Engineers can view combinations of Data Center layouts and hosting configurations as Patterns. Data Architects could, if they wished, view prototypical Conceptual Models as Patterns and in fact a Canonical Model could be considered a specific type of Data Pattern applied across multiple enterprises. This sounds a little strange perhaps because many people associate the concept of Patterns with Object Oriented Programming and the original Gang of Four book of OOD patterns. Yet, there is nothing that explicitly states anywhere that Patterns have to be limited to application design (Object-Oriented or otherwise).

The flexibility of the Design pattern is simultaneously both its greatest asset and drawback.  It's an asset because it allows architects, developers and engineers the flexibility to define re-usable solutions for common design challenges. It's a drawback because it tends to promote decentralized management (or perhaps no management at all) of design artifacts and may also lead to more situations where solution elements are designed out of context of one another.  So how do we manage something that is flexible, effective yet often disruptive? Here are five suggestions for how to master Design Patterns:

1. Create your own Design Pattern Taxonomy - Keep in mind that there is no standard approach from industry as to how an organization (or individual) ought to manage patterns (unless of course you wish to blend it with your EA approach and integrate them within one of several EA Frameworks). So what's being recommended here is to create a taxonomy of the types of Design Patterns you think you may need. This might include application patterns, data patterns, UI patterns etc. - whatever makes sense.

2. Come with a Standard approach for Pattern Visualization - Many people like to use UML for this but quite frankly there's some design problems that UML isn't so great in representing. The benefit of using UML is that it should make alignment with your ALM easier (in most cases).

3. Come up with Standard Template for Pattern Description - You'll need to ask yourself here just how much information is required. While this shouldn't become a huge specification you will need to provide enough information so folks not involved in the original design won't have to come back and ask what you really meant.

4. Standardize your own Design Terminology - As we all know there's many ways to describe the same thing. Building a glossary that can support all of the Design Patterns you may create will come in handy for you and your enterprise. (again for those who are already utilizing an EA approach you can probably borrow from that or at least make sure that any Patterns not managed as part of the EA share common terminology).

5. Align your Design Patterns with your ALM / SDLC - This is perhaps the most important of the five recommendations. The majority of enterprises are already working with some sort of Application Lifecycle Management methodology. Often times ad hoc Design Patterns don't get "baked in" to the ALM. This can lead to much confusion and generally makes the overall design approach somewhat less efficient than it might otherwise be.

Design Patterns are meant to accomplish three critical things:

• Increase the speed of the design process.
• Ensure that lessons learned are adopted.
• Reduce overall costs by finding ways for certain capabilities to be reused. 

Actively managing Design Patterns helps to ensure that all three goals can be achieved.

Copyright 2014,  Stephen Lahanas

#ITarchitectureJournal
#StephenLahanas
#Semantech-Inc