Welcome!

Thomas Erl

Subscribe to Thomas Erl: eMailAlertsEmail Alerts
Get Thomas Erl via: homepageHomepage mobileMobile rssRSS facebookFacebook twitterTwitter linkedinLinkedIn


Related Topics: Java EE Journal, JBoss Enterprise Middleware, Software AG at SOA World, SOA Best Practices Digest, SOA & WOA Magazine

SOA Best Practices: Article

SOA Pattern of the Week (#3): Domain Inventory

Within the SOA design patterns catalog, these domains are represented as service inventories

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).

More Stories By Thomas Erl

Thomas Erl is a best-selling IT author and founder of Arcitura Education Inc., a global provider of vendor-neutral educational services and certification that encompasses the Cloud Certified Professional (CCP) and SOA Certified Professional (SOACP) programs from CloudSchool.com™ and SOASchool.com® respectively. Thomas has been the world's top-selling service technology author for nearly a decade and is the series editor of the Prentice Hall Service Technology Series from Thomas Erl, as well as the editor of the Service Technology Magazine. With over 175,000 copies in print world-wide, his eight published books have become international bestsellers and have been formally endorsed by senior members of many major IT organizations and academic institutions. To learn more, visit: www.thomaserl.com

More Stories By Herbjorn Wilhelmsen

Herbjorn Wilhelmsen is an Architect and Senior Consultant at Objectware in Stockholm, Sweden. His main focus areas include service-oriented architecture, Web services and business architecture. Herbjörn has many years of industry experience working as a developer, development manager, architect and teacher in several fields of operations, such as telecommunications, marketing, payment industry, health care and public services. He is active as an author in the Prentice Hall Service-Oriented Computing Series from Thomas Erl and has contributed design patterns to SOAPatterns.org. He leads the Business-to-IT group in the Swedish chapter of the International Association of Software Architects, which performs a comparative study of a number of business architecture methodologies. Herbjörn holds a Bachelor of Science from Stockholm University.