The Need for Service-Orientation

After repeated generations of traditional distributed solutions, the severity of the previously described problems has been amplified. This is why service-orientation was conceived. It very much represents an evolutionary state in the history of IT in that it combines successful design elements of past approaches with new design elements that leverage conceptual and technology innovation.

The consistent application of the eight design principles we listed earlier results in the widespread proliferation of the corresponding design characteristics:

• increased consistency in how functionality and data is represented
• reduced dependencies between units of solution logic
• reduced awareness of underlying solution logic design and implementation details
• increased opportunities to use a piece of solution logic for multiple purposes
• increased opportunities to combine units of solution logic into different configurations
• increased behavioral predictability
• increased availability and scalability
• increased awareness of available solution logic

When these characteristics exist as real parts of implemented services they establish a common synergy. As a result, the complexion of an enterprise changes as the following distinct qualities are consistently promoted:

Increased Amounts of Agnostic Solution Logic

Within a service-oriented solution units of logic (services) encapsulate functionality not specific to any one application or business process. These services are therefore classified as agnostic and reusable IT assets.

Figure 1 – Business processes are automated by a series of business process-specific services (top layer) that share a pool of business process-agnostic services (bottom layer). These layers correspond to the task, entity, and utility service models described at www.WhatIsSOA.com.

Reduced Amounts of Application-Specific Logic

Increasing the amount of solution logic not specific to any one application or business process decreases the amount of required application-specific logic. This blurs the lines between standalone application environments by reducing the overall quantity of standalone applications. (See the Service-Orientation and the Concept of “Application” page.)

Figure 2 – Business Process A can be automated by either Application A or Service Composition A. The delivery of Application A can result in a body of solution logic that is all specific to and tailored for the business process. Service Composition A would be designed to automate the process with a combination of reusable services and 40% of additional logic specific to the business process.

Reduced Volume of Logic Overall

The overall quantity of solution logic is reduced because the same solution logic is shared and reused to automate multiple business processes, as shown in the following figure.

Figure 3 – The quantity of solution logic shrinks as an enterprise transitions toward a standardized service inventory comprised of “normalized” services.

Inherent Interoperability

Common design characteristics consistently implemented result in solution logic that is naturally aligned. When this carries over to the standardization of service contracts and their underlying data models, a base level of automatic interoperability is achieved across services. (See the Service-Orientation and the Concept of “Integration” page.)

Figure 4 – Services from different parts of a service inventory can be combined into new compositions. If these services are designed to be intrinsically interoperable, the effort to assemble them into new composition configurations is significantly reduced.