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. This is partly 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 important for most enterprises. 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. Before discussing how to manage them, we first need to define what they are: "Design Pattern" 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 encapsulate 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 greatest 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 it may also lead to more situations where solution elements are designed out of context with 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:
- 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.
- Come with a standard approach for pattern visualization: Many people like to use UML for this, but there are 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.
- Come up with standard template for pattern description:You'll need to ask yourself 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.
- Standardize your own design terminology: As we all know, there are 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. (For those who are using 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.)
- 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 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.
