Lessons Learned: The Importance of Pattern Based Thinking
In my last blog, I wrote about the importance of using abstraction in IT, and how its’ power has grown over the last several decades. One of the most significant advances in abstraction has been the use of patterns to describe various structural and behavioral models throughout IT. These models include architectural, data, design and process patterns, among others. When consulting with a wide variety of clients, my colleagues and I have found that the use isn’t as prevalent as we have come to expect, so I’d like to shed some light on what patterns mean to the IT disciplines.
Implicitly, we humans employ patterns in our everyday lives. We recognize patterns of musical style and can assign it to a genre (e.g. Jazz, Rock, and Baroque); or we can look at certain iconic styles of architecture and provide layman’s terms to a set of styles (e.g. Queen Anne or Federalist). We perform this categorization almost without thinking. In some cases, we use it as a guide for purchases (e.g. conveying a type of vehicle we wish to buy).
This power of abstraction allows us to convey a large set of attributes with the simple utterance of a phrase. This power to transmit a knowledge set and its implicit assumptions is quite powerful. In the 1970’s, a building architect named Christopher Alexander wrote two groundbreaking books titled: A Pattern Language- Towns, Buildings and Construction and The Timeless Way of Building. He codified what he had learned over decades of design so that problems encountered in the architectural and construction process could be characterized. The pattern language he created was a tool to facilitate solution creation for recurring problems. It had a lot of power, but was essentially ignored by the building industry. In the 1990’s, however, people in the software industry did take notice, and in 1995 a groundbreaking work for software, titled Design Patterns, emerged and took the software industry by storm.
My first reaction when browsing this book back then was: “finally someone articulated what I was sensing for a long time.” As pattern books exploded in the ensuing years, one author contacted Christopher Alexander and told him about the impact he made. In a forward to a software patterns book, Alexander stated that he was stunned at the reach it had achieved even as his own industry largely ignored his work.
My colleagues and I have used IT patterns extensively because of its power to convey so much information in such a compact form. We have been able to codify a collection of patterns (functional, data, storage, application, deployment, etc.) and have plans for several more categories.
We have found that working in patterns allows problem solvers to get to the essence of an implementation without getting bogged down into the details. While details are important in some discussions, they need to be exposed in layers that make sense. In the case of application patterns and fitness for a cloud implementation, it makes more sense to work with patterns that describe application structure and behavior first. For example, most of our clients can easily contrast the requirements between ERP, CRM, and eCommerce applications. They can speak effectively about the different quality thresholds of availability, transaction volumes, and concurrent usage for each without getting tangled up in the nuances of Joe’s vs. Sally’s applications. This approach is similar to how we would contrast the idealized listening environments for Classic Rock vs. Renaissance Choral Music.
Patterns can be assigned qualities that define how they can be implemented. These qualities are not “fuzzy;” they can have specific values that act as construction guidelines and constraints. Qualities will be a blog topic in a later installment.
The Key Lesson Learned After All This Time
In IT, patterns are used in design and construction both implicitly or explicitly. When used implicitly, they tend to lack structure and comprehensibility. Instead, patterns emerge in an ad-hoc fashion, much like how a shanty town is formed.
When patterns are used properly they provide considerable value to an organization, including cost reduction, increased velocity of delivery and risk reduction.
Patterns reduce complexity, while highlighting commonality of function, making it easier to design sustainable systems. This leads to more effective innovation, more effective reuse of solved problems, and better knowledge transfer through the conveyance of more consumable information.
Patterns can be expressed in layers of abstraction, which can include architectural, application, functional, data, coding, etc. This facilitates conversations between stakeholders at the proper level of abstraction. It also facilitates construction or migration due to the predefined and pre-integrated design components available.
As always, I am eager to hear your feedback.