5 Steps to Mastering 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. 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.

jigsaw_puzzleDesign 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:

  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 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.
  3. 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.
  4. 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.)
  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 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.

Related Links

Comments

  1. BY kevin says:

    Increase the speed of the design process???? My real world experience suggests the opposite. While I agree that design patterns can be useful, they most certainly do not speed the design process–they typically slow it down. Developers (and architects) spend a lot more time dealing with the design pattern itself, rather than spending that time on actually addressing the development task.

    • BY Stephen Lahanas says:

      Hi Kevin, well if you’re dealing with a small team located in one place that may be the case – at first. However there are a couple of things to consider: 1 – many teams are spread out across multiple locations and communication is a big problem. Patterns help to clarify design expectations. 2 – Once a pattern is documented and the code properly managed, then the next time around a lot of time will be saved if it is determined that the pattern can be reused.

      One of the biggest problems in IT that I’ve experienced over the years is the long-term cost of quick and dirty (e.g. undocumented or poorly documented) solutions. This scenario tends to explode costs down the line but of course since folks don’t have to deal with the impacts of it up front it’s hard to argue against ‘code it now.’ You would be hard pressed to find a house or building anywhere without blueprints or any kind of electrical system without schematics – yet vast numbers of IT systems are so poorly documented that it becomes difficult to maintain them and even more problematic to replace them. Patterns help solve that problem and help to unify teams. The key to ensuring that analysis or architecture doesn’t become a drag on projects is to fully integrate those activities into the cradle to grave process…

Post a Comment

Your email address will not be published. Required fields are marked *

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>