SOA Patterns:Service-Oriented Decomposition

One of the most difficult questions to answer during SOA implementation is how to appropriately define services. An enterprise usually already has a set of applications supporting most of the required business functionality. These applications are implemented using a variety of hardware platforms, operating systems and programming languages. Some of them are stand alone applications, others are integrated using EAI solutions. Some applications are implemented by the enterprise itself and some are implemented by its business partners and are used in the overall processing using B2B solutions. The current application architecture of Orchestra Mortgage  illustrates this common situation.

Adopting a SOA requires definition of services that:

• Support the required business functionality and business processes.
• Align the IT implementations with business functionality.
• Adhere to architectural goals such as performance, scalability, security, and so on.

In other words the services should define the blueprint for the future state of the enterprise architecture. This blueprint should be able to support both the current business goals of the enterprise and provide capablities for future changes. It should provide "traceabilty" between IT and business functionality/capabilities of the enterprise. Finally it should support architectural qualities of the future state IT implementations.

Problem

How do you define enterprise services conforming with the enterprise
architectural goals as well as the enterprise business drivers?

Forces

• Most organizations have large investments in their application portfolios. Due to its large mass the portfolio may have a significant impact on the development of any new enterprise systems.
• It is quite common for the business model to be ill-defined. In many instances the mix of applications added to a company's IT portfolio over time define an ad-hoc business model. This model mirrors the applications rather than the business.
• The enterprise focus considers long term architecture goals. To serve as the foundation for enterprise development, the services must be in alignment with current and future functionality, performance, scalability, security, and so on.
• A set of key business processes lies at the heart of the enterprise functionality. Building these processes requires the ability to easily compose services. This translates into requirement of creation of interoperable and loosely coupled services.
• The location transparency of services bring to the table the challenges of distributed systems. Inter-service exchanges take place over the network. These far calls are radically different than near calls with respect to communication overhead and reliability. De-emphasizing communication and thus lowering the number
  of far calls translates into large-grained services.

Known Uses

• David Parnas articulated eloquently how various decomposition criteria yield solutions whose "flexibility, comprehensibility" and "efficiency" differ significantly.
• IBM's Service-Oriented Modeling, Analysis, and Design (SOMA) is a three-step method for specifying services using goals, decomposition, strategic components and existing systems.
• The OASIS SOA Adoption Blueprints also employ a variant of the Service
  Decomposition pattern.

Related articles:

What"s SOA?