Patterns have been used in the "conventional" engineering disciplines, such as
civil engineering and mechanical engineering, for years. They first became popularized for use in software
engineering with the publication of [GAM95]. This particular book focused on design patterns, but patterns are
useful at other levels of the software lifecycle, as well.
The following graphic illustrates 12 best practices, which we have couched in patterns format, for building
more robustly-architected SOAs. The pattern definitions can be accessed either using "hot spots" in the
graphic or the links in the "Related Elements" section of this concept. Senior IBM practitioners have used these
best practices to good effect on numerous SOA-related engagements. We offer them here for your consideration and
use. We believe that adopting these practices will enable you to build SOA solutions that are more flexible,
comprehensible, and maintainable.
The patterns do not necessarily stand alone. Many are mutually supporting. Patterns 10
and 11 represent opposing approaches to addressing the same problem, thus they are in opposition to each
other.
Because they affect the most fundamental decisions in the development of a solution, you have to take care when
selecting architectural patterns. Every pattern is based on a specific rationale, or set of assumptions, which should
be described clearly in the pattern documentation. Before selecting and applying the pattern, you have to fully
understand these assumptions and how they will affect your architecture for the SOA you are building.
|