For example, a pattern such as Domain Inventory will be used repeatedly within the same IT environment (once for each domain). In fact, it can actually establish the foundation of your overall SOA strategy. Therefore, you better be pretty sure it's what you want for the long-term. One of its primary impacts is that it does introduce the need for transformation technologies. Because domain service inventories represent collections of services that are independently owned and governed, they will also tend to be independently standardized. This generally restricts the benefits of native compatibility and interoperability to the domain. When you need to begin connecting services across domains, you now have to overcome their disparity by incorporating brokers.

This may seem reminiscent of the EAI era where integration was the default solution to business change; however, this is actually not the case. As long as the scope of the domains are meaningful, this pattern can help any organization take a big step toward service-orientation as long as you consider the long-term impacts and plan for them.

Of course, we've just scratched the surface of SOA design patterns. Domain Inventory is one of nearly a hundred patterns that are being published this fall after three years in development and with the support and participation of hundreds of SOA professionals.

In Part 2 of this article series we'll take a closer look at some more SOA design patterns and we'll discuss how they can be applied together as part of pattern application sequences.