SOA Pattern (#3): Domain Inventory
Like this article? We recommend
Like this article? We recommend
Like this article? We recommend
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.
“But wait!” shouts the standards police officer, “Won’t this still lead to integration requirements when services across different domains need to communicate?” Yes, officer, this is true. Traditional integration technologies, such as those that carry out Data Model Transformation, Protocol Bridging, and Data Format Transformation, will need to be enlisted when cross-domain inventory services need to be composed. As with any design pattern, there are consequences to its application, and this is the primary trade-off imposed by Domain Inventory. However, because the application of this pattern can begin as early as the initial project planning stages, these transformation and bridging layers are considered an accepted and expected part of the enterprise technology landscape that is shaped around domain inventories. And because they are anticipated, their impacts can be planned for in advance. This mitigates their demands more effectively than when integration requirements emerge unexpectedly after solutions are delivered (as has been the case with typical silo-based environments).
There are different ways of defining what constitutes the domain of a service inventory. It can be based on anything from zones of authority, to geography, or large-scale legacy environments. The “healthiest” approach is to align domain inventory boundaries with actual business domains. This helps sync the physical macro view of a service-oriented technology enterprise with logical areas or lines of business that may exist, which can greatly facilitate long-term business-technology alignment.
There are also different and creative ways of applying this pattern. For example, domain service inventories can be used to phase SOA adoption into an enterprise over time. There may also be the opportunity to expand or otherwise augment individual domains after their initial definition, allowing for a more evolutionary proliferation of services.
Either way, it is critical to understand the option presented to you by this pattern. Because it makes SOA accessible and attainable to just about any organization, it has become the most popular means of successfully realizing the business value offered by service-oriented computing today.
The SOA Pattern of the Week series is comprised of original content and insights provided to you courtesy of the authors and contributors of the SOAPatterns.org community site and the book “SOA Design Patterns” (Erl et al., ISBN: 0136135161, Prentice Hall, 2009), the latest title in the Prentice Hall Service-Oriented Computing Series from Thomas Erl (www.soabooks.com).