Return to Home Page

The public review of the manuscript for "SOA Design Patterns" has concluded !
Thank you to all that participated. 234 reviews were received and over 30 new patterns have been contributed,
increasing the size of this book by over 50%. The second draft of the manuscript is currently in development.

About the Public Review
    History
    Podcasts (audio)
    Notification
    Submit Feedback
    Contribute a Proven Pattern
    Contribute a Candidate Pattern
    Acknowledgements
    Press Release

Introduction to SOA Types & Design Patterns
    The Architecture of
Service-Orientation
    Understanding SOA
Design Patterns

SOA Design Patterns
    Basic Service Inventory Design Pattern Language
    Architectural Design Patterns
    Basic Service Design
Pattern Language
    Service Design Patterns
    Common Compound
Design Patterns

Additional Resources
    View Entire TOC
    Symbol Legend
    Master Pattern List
(by category)
    Candidate Design Patterns
    Design Patterns Publications
    Download SOA Principles Poster (PDF)

About the Book



SOA Design Patterns
by Thomas Erl

For more information visit: www.soapatterns.com

Related Publications


Read the article "Introducing SOA Design Patterns" from the
June 2008 SOA World Magazine (High-Res PDF).

PLEASE NOTE

The content on this page is from the first draft of the manuscript for the upcoming book "SOA Design Patterns" by Thomas Erl. This version of the manuscript was authored in September, 2007. Since then, the manuscript has undergone significant content and structural changes as a result of an industry-wide review in which hundreds of SOA practitioners participated in addition to SOA vendors and experts from the design patterns community.

You are welcome to use the information on this page for research purposes, but you should assume that most of it will change in the final release of the "SOA Design Patterns" book.

Note also, that as a result of an industry-wide call for participation from December 2007 to February 2008, over 30 new design patterns have been contributed to this book. As they become finalized and are incorporated by the author, concise descriptions will be published on this site, and full descriptions with examples will be made available in the final, printed book.

Due to the volume of new content and changes, the release of the "SOA Design Patterns" book has been postponed to October, 2008. To learn more about the book, visit www.soapatterns.com. To be notified of updates to this site, use the notification form.

Chapter 5: Basic Service Inventory Design Pattern Language

Home > Chapter 5 Overview > 5.2 Inventory Boundary Design Patterns > Enterprise Inventory

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.

Prev | Next
The Prentice Hall Service-Oriented Computing Series from Thomas Erl
Home    SOA Books    SOA Magazine    What is SOA?    SOA Principles    SOA Methodology    SOA Glossary Copyright © 2007-2008
SOA Systems Inc.