Enterprise Inventory

How can services be delivered to maximize recomposition?

Problem Delivering services independently via different project teams across an enterprise establishes a constant risk of producing inconsistent service and architecture implementations, compromising recomposition opportunities.
Solution Services for multiple solutions can be designed for delivery within a standardized, enterprise-wide inventory architecture wherein they can be freely and repeatedly recomposed.
Application The enterprise service inventory is ideally modeled in advance and enterprise-wide standards are applied to services delivered by different project teams.	Impacts Significant upfront analysis is required to define an enterprise inventory model and numerous organizational impacts result from the subsequent governance requirements.
Principles Standardized Service Contract, Service Abstraction, Service Composability	Architecture Inventory, Enterprise

Table 5.3 – Profile summary for the Enterprise Inventory pattern.

Problem

Throughout an enterprise services can be delivered as part of various on-going development projects. Because each project has its own priorities and goals, services and supporting implementation architectures can easily be designed in isolation, optimized to fulfill tactical requirements.

The result is a collection of potentially disparate service clusters and corresponding technology architectures. The differences in these implementation environments can lead to serious problems when attempting to compose services into new configurations that span the initial architectural boundaries (Figure 5.x).

Figure 5.13 – All services are built with the same vendor platform, but they are delivered via separate projects without taking into account a common architectural boundary.

Solution

A service-oriented enterprise architecture is established to form the basis for enterprise service inventory. Services delivered as part of any project are designed specifically for implementation within the enterprise inventoryÕs supporting architecture, guaranteeing wide-spread consistency.

Figure 5.14 – An enterprise service inventory establishes an enterprise-wide architectural boundary that promotes native interoperability and recomposition among all services.

Application

If the planned enterprise service inventory is significant in scope, then the organization needs to ensure it is capable of carrying out the corresponding SOA transition effort.

Various factors come into play, each of which can require a reduction in scope or an alternative approach:

•       the maturity of available technology for the planned services (especially for services being positioned as highly reusable enterprise resources)

•       the maturity of governance technology platforms required to manage and evolve the service inventory as it is being built and after it is in place

•       the order of magnitude associated with the amount of change and disruption brought on by the transition

•       the amount of legacy environments that are expected to constrain service encapsulation

•       the financial resources required to carry out the transition

•       cultural and political obstacles that may arise as a result of the proposed changes and the required standardization effort

Therefore, the application of this pattern is recommended for the following types of environments:

•       small-to-medium sized organizations with sufficient resources

•       medium-to-large sized organizations with highly controlled environments, a history of enterprise-wide standardization, or with the cultural flexibility to successfully adopt standardization

•       medium-to-large sized organizations that have the resources to build an enterprise service inventory while concurrently operating and maintaining their existing legacy systems

•       new organizations that have no legacy systems and no IT history (and can therefore build an IT enterprise with a clean slate)

The application of this pattern does not result in the creation of physical services. It establishes the concept of an enterprise service inventory for which services are conceptually defined through a planning and analysis effort. Once the scope of the service inventory has been determined, its underlying structure needs to be defined (as per the upcoming Service Abstraction patterns).

Furthermore, a service inventory does not need to encompass an entire enterprise. As stated earlier, its scope needs to be sufficiently meaningful to warrant its creation. The application of this pattern therefore consists of a process that is tied to the creation of a service inventory blueprint that represents however much of the enterprise the organization has chosen to model services for.

All of these considerations tie into the creation of the service inventory blueprint, which typically represents a top-down analysis phase that is completed by iteratively carrying out the service-oriented analysis and service modeling processes.

The following steps provide a suggested process:

1.     Apply the Business-Driven Context pattern in combination with a planning and analysis effort to determine a preliminary scope for the service inventory that appears to be manageable based on the previously listed factors.

2.     Collect all of the necessary enterprise business specifications that document business models and requirements that fall within the scope of the planned inventory (as well as those that are enterprise-wide). These specifications can include business entity models, logical data models, ontologies, taxonomies, business process definitions, and numerous other information and business architecture documents.

3.     Using the enterprise-wide business models collected in Step 2, apply the Entity Abstraction and Process Abstraction patterns to establish a base set of business service layers.

4.     Carry out the service-oriented analysis process iteratively by decomposing business process definitions that fall within the scope of the planned inventory. This results in the definition of service candidates that are continually refined.

See SOAMethodology.com for an example of a top-down process that iterates through the service-oriented analysis stage.

Impacts

To achieve unity across an enterprise-wide service inventory, a large amount of top-down analysis may be required so that service candidates can be modeled and aligned with each other, prior to their actual delivery.

Common issues that challenge the creation of an enterprise service inventory are documented in the Problem section of the Domain Inventory pattern description (because the Domain Inventory pattern provides an alternative approach that addresses many of the concerns associated with the Enterprise Inventory pattern).

Relationships

The Enterprise Inventory pattern establishes an enterprise-wide boundary with a physical structure that is subject to the application of a series of key inventory-related patterns, as shown at the bottom of Figure 5.x. The Inventory Endpoint pattern can further complement this pattern by providing standardized access to external consumers.

Figure 5.15 – The Enterprise Inventory pattern establishes scope, but it relies on other patterns to establish context and structure.

Case Study Example

Case study content is not available on this Web site.