Domain Inventory

How can services be delivered to maximize recomposition when enterprise-wide standardization is not possible?

Problem Establishing an enterprise-wide service inventory may be unmanageable for some enterprises, and attempts to do so may jeopardize the success of the SOA transition as a whole.
Solution Services can grouped into more manageable, domain-specific service inventories, each of which can be independently standardized, governed, and owned.
Application Inventory domain boundaries need to be established and then become the basis for a phased transition.	Impacts Standardization disparity between domain service inventories imposes transformation requirements and reduces the overall benefit potential of the SOA transition.
Principles Standardized Service Contract, Service Abstraction, Service Composability	Architecture Inventory, Enterprise

Table 5.4 – Profile summary for the Domain Inventory pattern.

Problem

In larger environments it can be impractical or even unrealistic for one service inventory blueprint to span the entire enterprise and keep all services in constant alignment. Standardization and governance issues can raise various concerns, most of which tend to be organizational in nature (Figure 5.x).

Figure 5.17 – Common organizational issues that hinder efforts to establish a single, enterprise-wide service inventory.

Solution

Multiple service inventories are created for one enterprise. The scope of each represents a well-defined enterprise domain. Within domains, service inventories are standardized and governed independently (Figure 5.x).

Figure 5.18 – An enterprise with multiple service inventories, each representing a pre-defined domain.

Application

Whether or not to apply this pattern is tied to the question of whether an enterprise-wide service inventory is feasible within a given environment. Many factors (most of which are specific to the organization) weigh in on this decision point. However, some general guidelines are available.

For example, domain service inventories are an appropriate alternative when any of the following supporting factors exist:

•       The implementation environment is a large enterprise without strong executive sponsorship and wide-spread support for the SOA initiative.

•       The enterprise does not have an established, global data representation architecture, and creating one is considered unrealistic.

•       The organization is incapable of changing the complexion of its IT departments in support of a more centralized governance model.

Multi-domain service inventory implementations make some impositions, in that they allow for individual inventories to be standardized differently. This generally results in the need to introduce targeted transformation for cross-domain interoperability as part of the overall enterprise architecture.

However, the application of this pattern can greatly accelerate the adoption of SOA in that an enterprise-wide migration can be delivered in phases that each result in the creation of a manageable service inventory. For some organizations, this pattern provides the only realistic option for applying service-orientation to larger SOA transition efforts.

The key to creating effective domain inventories is to clearly define the domains in advance, thereby establishing an enterprise perspective prior to building any one inventory.

Organizations will often have options as to how the domains are defined. Here are some common examples:

•       Organizational business areas represented by specific IT departments or groups. These business areas would then establish the basis for business domains.

•       Organizational business domains not represented by separate IT departments or groups. These domains can still form the basis of service inventory boundaries, but require cooperation across IT departments.

•       Remote offices, each with its own IT department and development center. This can result in geographical-based domains.

Ideally, domain inventories correspond to enterprise business domains. This allows each inventory to be tuned to and evolve with its corresponding set of business models in full support of the Business-Driven Context pattern.

Impacts

The ultimate benefits associated with achieving a unified, federated enterprise service-oriented architecture are scaled back to whatever extent domain inventories are created.

Transformation requirements that emerge to enable cross-domain data exchange impact the development and design effort of corresponding service compositions and also add performance overhead to their runtime execution.

Relationships

The same design patterns that structure an enterprise-wide inventory will end up structuring an inventory defined via the Domain Inventory pattern (only the scope will be smaller). However, unlike the Enterprise Inventory pattern, the application of this pattern will generally result in the need for transformation patterns, such as Protocol Bridging and Data Model Transformation. The Inventory Endpoint pattern will also play a more prominent role to facilitate inter-domain communication.

Figure 5.19 – The Domain Inventory pattern shares many of the same relationships as the Enterprise Inventory pattern, but introduces some requirements that can be fulfilled by additional patterns more specific to a domain-based environment.

Case Study Example

Case study content is not available on this Web site.