SOA Pattern (#9): Enterprise Inventory
Like this article? We recommend
Like this article? We recommend
Like this article? We recommend
The Enterprise Inventory design pattern attempts to maximize the reusability and recomposition of services by proposing the development of services based on a single enterprise-wide service inventory.
In today’s competitive market, with ever decreasing IT budgets, agility remains one of the key reasons behind the development of a service-oriented solution. However, in order to be agile, the developed services need to be interoperable, should support the vision of a federated enterprise, be reusable and last, but not the least, need to facilitate repeated composition over multiple development projects. These aforementioned objectives directly relate to the strategic goals of SOA.
Within organizations that either consist of multiple IT departments, or where various development teams are delivering services as part of different projects, the degree to which the service-oriented design principles are applied might differ. This is a key factor in determining to what extent a given service is recomposable. For example, a service to which the Service Abstraction design principle has been applied to a greater extent might not be easily recomposable as compared to the situation where the same principle has been applied to a modest level. Other factors limiting the recomposability of a service include focusing on tactical requirements that result in services built around a specific implementation architecture that might not be compatible with other services built around a different set of tactical requirements. Furthermore, another contributing factor that may have an effect on the usefulness of a service, which negatively impacts the enterprise-centric characteristic of an SOA, is the development of standalone inventory architectures by the individual IT departments belonging to the same organization. Although such inventory architectures might be based on industry standards, they might not be compatible with each other as they were based on the individual needs of the organizational unit to which each IT department belongs. This factor also impacts the interoperability of services across the organization.
The solution to the problems mentioned above lies in the creation of a single enterprise-wide service inventory as advocated by the Enterprise Inventory design pattern. The creation of such an inventory requires the existence of enterprise-wide design standards as well as an enterprise-wide implementation architecture i.e. the service-oriented enterprise architecture. This further leads to the question of how to build such an inventory in the first place. The answer requires conducting top-down service-oriented analysis in order to come up with a set of service candidates known as a service inventory blueprint. Only by having a pool of services in advance can we derive the combined implementation requirements that would form the basis of the service-oriented enterprise architecture. This also helps in determining any limitations within the current service-oriented enterprise architecture that helps in adjusting candidate services accordingly before their design and implementation.
The application of the Enterprise Inventory pattern, in case of an existing SOA, might lead to considerable redesign efforts. For example, in light of the newly formed enterprise-wide standards for the enterprise inventory, it is quite possible that the service contracts may require another round of functional and data standardization efforts. Similarly, if the new design standards require increasing the abstraction level of the existing services, there is a high possibility that the services’ discoverability and recomposability would be reduced. In either case, any dependent service consumers would be adversely affected. This may create the need to provide concurrent contracts by the application of the Concurrent Contracts design pattern until the non-standardized contracts are phased out.
In large organizations the creation of a single service inventory would require considerable governance efforts and might require governance tools if not already in place. Similarly, the maintenance of service registries would also require extra resources, both in terms of time and effort. When applying this design pattern, it is important to consider the different security requirements of all the services within the enterprise inventory, as the underlying service-oriented enterprise architecture needs to support such requirements. A federated SOA can then be developed by ensuring that all services are able to perform their respective security related processing within the boundary of the standardized enterprise-wide security architecture.
Although the Enterprise Inventory design pattern is considered as an alternative to the Domain Inventory design pattern, its true benefits may only be realized when applied cautiously. This can be achieved by planning in advance to tackle its various impacts that may otherwise impede its success.
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).