For example, consider a hammer. It's a tool designed to solve a specific problem. Furthermore, it's a proven design that has been field tested and validated for decades. Of course, it's so commonplace now that we take the hammer for granted. But imagine if there were design solutions as useful and successful as the hammer that we could apply to the design of our IT systems.

For architects and developers building new solutions (especially when working with modern technologies), designs patterns can be lifesavers. Each can provide a pearl of wisdom that not only helps solve problems as they occur, but can help you design your systems to avoid problems that are likely to occur in the future. As a result, design patterns can save time and money and can further increase the overall robustness and effectiveness of a given system. And, as an added bonus, you don't need to hire expensive consultants to get them; you just need to buy a book and invest some study time.

Design patterns have been widely adopted over the years and each major programming or computing discipline has assembled its own "pattern catalog." The best patterns are those that are documented after a technology platform has matured to a reasonable extent and many pioneering efforts have gone through various cycles of trial and error to determine what techniques and approaches do truly work better than others.

The fact that a design pattern catalog for SOA has now emerged is testament to the level of maturity that SOA has attained. Since SOA first emerged a few years ago, many projects have come and gone, and collections of best practices, pitfalls, and methodologies have been produced and proposed by various practitioners and vendors. SOA design patterns essentially leverage all of this information and synthesize it into a set of design solutions that are consistently documented in a formal catalog.

A great example is associated with determining the appropriate scope of a service-oriented architecture. Many past projects attempted to adopt SOA on an enterprise-wide basis, viewing SOA as an all-or-nothing proposition. In some environments, this can succeed, especially when there's strong support from management. However, more often than not, the odds are against you. Cultural and organizational issues have been difficult and sometimes even impossible to overcome when attempting a wholesale transition toward SOA. Hence we have a very important problem that needs to be solved.