Underlying Services – Architecture for Existing and Acquired Resources

Most organizations expect to reuse their existing or externally provided systems as the primary resources to support their Service Architecture. Now that most operating environments and packaged applications have been ‘service enabled’, using such resources in the Service Architecture is technically straightforward. However, the native Services provided by these disparate resources will probably have inconsistent specifications, business taxonomy and business information models. Using them directly in the Service Architecture will probably compromise SOA goals. The report we have published considers where the Services provided by existing and acquired resources fit into the layered Service Architecture and how constraints and compromises can be minimized.

Appendix A1 of the CBDI-SAE Meta Model V2.0 identifies nine Service Architecture layers. It is a policy decision for organizations as to which layers they actually want to use. However, there are four basic service layers we would expect to see in all instances of Service Architecture.

• The core functionality is delivered by the Core Business Services. Each Core Business Service is based on a major business type identified in a Business Type Model. Some people may think of these as ‘Entity or Domain Services’.
• The Process Services then orchestrate these Core Business Services to deliver a specific business process.
• In turn, both these service types may use Utility Services that provide common business or technical utility functions, such as Address Formatting or Authentication.
• Finally, the Underlying Service layer classifies those Services which are provided by the existing systems or packaged applications, but which have inconsistent information models that are not based on the Business Type Model.

The Service Specification Architecture then assigns instances of services their respective place in the layered architecture and shows the dependencies between them. The Service Specification Architecture is then used as the basis for the Service Implementation Architecture where the Automation Units that provide the implementation for the Services are identified.

A natural question to ask is, why can’t an existing or external resource just be the Automation Unit or Implementation of the Core Business Service? Why is it delegated to a different layer? After all, as stated most organizations will want to use these resources as providers in their Service Architecture as these will contain the operational data required.
However, there are many challenges to doing this, especially if you want to deliver the agility promises of SOA.

Hence this report looks at those challenges and how they are overcome by using the layered Service Architecture.

The report also identifies policies and techniques for identifying, creating and consuming Underlying Services.

See Underlying Services – Architecture for Existing and Acquired Resources (subscription required)