A Pattern is no Best Practice yet!

A pattern, the universal and fundamental concept in any of the "architecture" disciplines, offers a well-specified solution to a common, recurring problem. That is what much of the literature, charting the many useful patterns, asserts and the community of architects commonly evangelizes.

From there, many infer that the body of documented patterns represents a body of knowledge for best practice and hence the thinking is almost, if not entirely, over. For every problem that you encounter, look up an appropriate pattern, combine all those patterns and there is your solution.

It is an approach that I repeatedly take notice of, especially in the area of software architecture and service-oriented architecture in particular.

Unfortunately that approach shows inadvertent reasoning. Moreover, repeatedly, particularly service-oriented architectures appear to be inherently and deeply flawed as results of such an approach.

While patterns do represent solutions to common, recurring problems, there are a number of additional considerations to take into account that are repeatedly forgotten:

• For any "one" problem, there is not just "one" appropriate pattern. In fact, usually multiple alternatives are available.
• While a pattern may represent a solution to a problem with advantages over other available solutions, it also comes with disadvantages, or better said trade-offs. Each pattern! So when wondering if a particular pattern is appropriate, the right answer is: "It depends". To evaluate the appropriateness, you actually need a comprehensive understanding of the "whole" problem in the aspects that count as the most-significant "quality" requirements.
• Combining patterns which is necessary to create a system, thereby in fact realizing more coarse-grained composite patterns, may no longer offer a solution with all the advantages as a whole or with the advantages that were envisaged. The combination may result in a situation wherein one pattern eradicates the benefits that another one should provide.

Actually, a pattern already represents a composition itself. It represents a particular structure that impacts multiple qualities ("*ilities"), both positively and negatively. Always! Those qualities emerge from applying structural tactics.

For example, the next figure (source: Software Engineering Institute) shows the tactics that benefit modifiability:

However, each of the above modifiability tactics impede other qualities. For example, using an intermediary benefits modifiability but at the same time also means increasing overhead which is the opposite to do when one wants to optimize performance:

Hence one can observe that one single pattern always combines different tactics with different implications to different qualities.

When one should actually prefer to trade-off performance for modifiability and go for an introduction of an intermediary, there is still the opportunity to use different tactics to compensate for some of the loss by introducing caching at the intermediary, which is a form of the maintain multiple copies tactic.

An example list of well-known patterns and the tactics for modifiability that they apply is shown in the next table:

While the pattern literature already represents a great resource for architects, it does not represent a replacement for thorough understanding, analysis and design. That need is actually why organisations do need architects that maintain such an understanding and the skills to create successful architecture designs.

Some architects promise impeccable quality with regard to their architecture designs. In the real world, it points to a lack of understanding with regard to the nature of quality. At best, architecture design is always a considerate exercise in trading off between qualities.