Enterprise Inventory
Encyclopedia
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 that fosters repeated service composition.
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 (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. 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.
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 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.
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.
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. 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.
Service-orientation
Service-orientation is a design paradigm to build computer software in the form of services. Like other design paradigms , service-orientation provides a governing approach to automate business logic as distributed systems...
design paradigm
Design paradigm
The term Design paradigm derives from the rather ambiguous idea of paradigm originating in Sociology of Science, which carries at least two main meanings:...
, the Enterprise Inventory is a design pattern
Design pattern (computer science)
In software engineering, a design pattern is a general reusable solution to a commonly occurring problem within a given context in software design. A design pattern is not a finished design that can be transformed directly into code. It is a description or template for how to solve a problem that...
by Thomas Erl
Thomas Erl
Thomas Erl is a Canadian author, and public speaker known as a major contributor in the fields of service-oriented architecture, service-orientation and cloud computing.- Biography :...
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 that fosters repeated service composition.
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 (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. 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.
Usage
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 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.
Apart from the creation of an enterprise inventory, the application of this pattern also requires that a technology architecture based on the current enterprise
Enterprise architecture
An enterprise architecture is a rigorous description of the structure of an enterprise, which comprises enterprise components , the externally visible properties of those components, and the relationships between them...
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. 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.