In the domain of the service-orientation design paradigm, the Enterprise Inventory is a design pattern by Thomas Erl that answers the question, "How can services be delivered to maximize recomposition?"; the application of this pattern results in a standardized enterprise-wide service inventory[1] that fosters repeated service composition.[2][3]

Rationale

An SOA adoption usually results in multiple set of services built by various teams as part of automating different business processes spread across diverse departmental boundaries. Each project team might be following different set of standards and implementation architectures[3] (for developing services) that are more relevant to the team's short-term goals and requirements. Although the built services might provide enough opportunities for reuse and recomposition within the same business domain, however, when it comes to composing services from different business domains, there tends to be an impedance mismatch requiring some sort of bridging or transformation logic in between these services. In a way, such services result in standalone solutions that defy the basic characteristics of service-orientation i.e. by not being enterprise-centric. Quite often such distributed service delivery efforts result in the development of redundant services as project teams are not aware of each other's requirements.

In order to foster an environment whereby all the services conform to a single set of standards, the Enterprise Inventory design pattern is applied that results in a common service inventory that is based on a service-oriented enterprise architecture.[4] This automatically eliminates any redundancy and paves the way for maximum recomposition of services which could mean development of new solutions with reduced efforts and time.[5]

Usage

Diagram A
Diagram A
Two individual service inventories belonging to two different organizational departments built using different standards and based on different implementation architectures. The shaded services represent redundant services.
Diagram B
Diagram B
A single enterprise-wide inventory built around a common set of standards providing maximum recomposition opportunities and eliminating any redundancies.

As depicted in Diagram A, the services belonging to two different departments, although belonging to the same organization, contain architectural incompatibilities as well as redundancy. An inter-department service composition is not possible until and unless there is some sort of transformation logic introduced in between these services. However, in Diagram B, the application of Enterprise Inventory pattern creates a standardized service inventory that is inherently interoperable.

In order to be sure that all the services that are being built follow the same design standards, as part of the application of this design pattern, a service inventory blueprint[6] needs to be created. Such a blueprint only consists of candidate services containing candidate capabilities. By coming up with such a service inventory blueprint, the overall scope of the potential enterprise-wide service inventory is established. This usually requires the application of the top-down service-oriented analysis.[7]

Apart from the creation of an enterprise inventory, the application of this pattern also requires that a technology architecture based on the current enterprise architecture needs to be documented as well so that the services could be built within the boundaries of such an architecture. Doing so guarantees service interoperability as well as behavioral predictability.

Considerations

As the application of the Enterprise Inventory design pattern requires upfront analysis, it is more suited towards organizations that have IT systems with well established procedures and documentation in place. If it is a fresh SOA initiative then creation of an enterprise-wide inventory would be rather easy and straightforward. Being an enterprise-wide initiative, it would be rather difficult for existing services to be adapted to the new design standards and would incur financial burden as well as require considerable amount of time.

In some circumstances, it might not be feasible to create a single enterprise service inventory because of the sheer size of the organization.[8] This would also mean that governing and maintaining such an inventory might also become impossible as there are simply too many services to govern and maintain. Last but not the least, a host of cultural issues might prevent the adoption of a common enterprise service inventory. This could include hesitance towards giving up control the way projects are developed, reluctance towards adopting design standards that restrict efficient development of projects and extra burden on service developers in terms of keeping track of enterprise-wide standards and to keep a constant check as to what other projects teams are up to in order to avoid any redundancy.

References

  1. ↑ Service Inventory
  2. ↑ "Service Composition". Archived from the original on 2010-03-12. Retrieved 2010-04-05.
  3. 1 2 Wajid khattak.Enterprise Inventory[Online]. Date accessed: 30 April 2010.
  4. ↑ Mauro. et al. Service Oriented Device Integration - An Analysis of SOA Design Patterns. Archived 2011-02-03 at the Wayback Machine [Online], pp.1-10, 2010 43rd Hawaii International Conference on System Sciences, 2010. Date accessed: 5 April 2010.
  5. ↑ Thomas Erl.Introducing SOA Design Patterns[Online]. Date accessed: 5 April 2010.
  6. ↑ Service Inventory Blueprint
  7. ↑ "Top-down vs Bottom-up Deliver Approach". Archived from the original on 2010-05-09. Retrieved 2010-04-05.
  8. ↑ Howard Cohen, Josh Taylor.SOA in the DoD[Online]. Date accessed: 7 April 2010.
This article is issued from Wikipedia. The text is licensed under Creative Commons - Attribution - Sharealike. Additional terms may apply for the media files.