February 05, 2009, 4:30 PM — Enterprise-wide harmonization is a desirable and ideal target state that fully supports pretty much everything SOA and service-orientation stand for. For those that have achieved such a state, bless your standardized hearts. You have accomplished something that has eluded many others. However, not attaining this state does not mean you cannot successfully adopt SOA.
In some circles it has become common to view an SOA initiative as an all-or-nothing proposition that demands an uncompromising commitment to an enterprise-wide transformation effort. For those that subscribe to this view, it can inspire visions of architects choking at the thought of having to comply to global data models, IT managers losing sleep over having to give up authority over their departments, and rebellious developers being rounded up by the standards police (equipped with industry-standard riot gear, no less).
The misguided association of SOA projects with the infamous "Big Bang" approach is unfortunate. It gives SOA an unwarranted stigma that runs contrary to the very philosophy of service-oriented computing. You are not required to carry out an enterprise-wide adoption of SOA in order to realize its benefits. This is the very reason the Domain Inventory pattern emerged. From a strategic planning perspective, there is (for most organizations) no other pattern as important to fully realizing everything SOA has to offer.
When transitioning toward the adoption of service-orientation, you are responsible for determining the scope of this adoption. As long as it is meaningfully cross-silo, it can realize an extent of the strategic benefits associated with service-oriented computing. In other words, as we just stated: You are not required to carry out an enterprise-wide adoption of SOA in order to realize its benefits. You can establish a domain that represents a manageable segment of your IT enterprise and carry out the adoption within its boundary. Another team within your organization can establish its own domain and carry out its own SOA project independently from yours.
This fundamental concept forms the basis of this pattern, which provides a very real and proven alternative to enterprise-wide adoption.
Within the SOA design patterns catalog, these domains are represented as service inventories – collections of independently standardized, governed and owned services. A service inventory is the real world implementation of what you may have documented in a service catalog or service portfolio. When applying the Domain Inventory pattern, it is assumed that an IT enterprise will have at least two service inventories, each of which is defined and evolved on its own terms. In fact, it is not uncommon for larger organizations to eventually produce dozens of domain inventories.
During a recent podcast interview for the InformIT OnSOA channel, analyst Joe McKendrick asked how this pattern is different from creating "islands of services". In other words, isn't this taking us a step back toward the silo-based, integrated application environments that got us into trouble in the first place? No, it's not. This pattern is about establishing "continents of services", where the scope of each service inventory is defined with an appropriate balance of strategic significance and manageable governance.
