Benefits of a business-centric SOA

The advent of Web services has publicized the importance of an open communications framework. As a result, most IT professionals are at a stage where they acknowledge the relevance of Web services technologies.

As we've established previously, the majority of Web services currently being built are, more or less, a mixture of application and business services. These types of hybrid services are attractive because, with minimal effort, they fulfill immediate requirements with clear ROI benefits. The proliferation of hybrid services is the result of the bottom-up approach having become so commonplace. They provide an immediate means for all past forms of application architecture to take part in the open Web services communications framework.

Business services, on the other hand, often need some justification. Many still resistor are even unaware ofthe benefits of introducing service-oriented principles into the domain of business analysis. It is easy to ignore service-oriented business modeling and simply focus on service-orientation as it applies to technology and technical architecture. The common rationale for this approach is that whatever business processes need to be automated can be divided up into physical Web services as required.

Many of the characteristics of contemporary SOA we listed in Chapter 3 can still be attained without the use of business services. Though it may appear that you are saving yourself a load of work by taking this path, the apparent benefits are superficial. There are very good reasons for taking the time to model and build business services. In this section we list a series of benefits for incorporating service-orientation into the business process level.

11.2.1. Business services build agility into business models

Service-orientation brings to business process models a structure that can significantly improve the flexibility and agility with which processes can be remodeled in response to changes. When properly designed, business services can establish a highly responsive information technology environment; responsive in that changes in an organization's business areas can be efficiently accommodated through re-composition of both a business process and its supporting technology architecture (as expressed by the application services layer).

As business-driven as SOAs are, there are often real world restrictions (infrastructure, security constraints, budget constraints) that require the technology side to push back. This can shift the burden of adaptation over to the business process models. This type of agility requirement can be met by the business service layer, as it allows business services to adjust to requirement changes originating from an organization's technical environments.

In other words, applying service layer abstraction to both business and technology ends establishes the potential for an enterprise to achieve a form of two-way agility (Figure 11.2).

Figure 11.2. Changes originating in the business logic domain are accommodated by the application logic domain and vice versa.

 

11.2.2. Business services prepare a process for orchestration

Whether or not you will be moving to an orchestration-based service-oriented environment anytime soon, it is becoming increasingly important to be ready for this transition. Orchestration brings with it concepts that, when implemented, lie at the core of SOA. Therefore, modeling current processes so that they eventually can be more easily migrated to an orchestration-driven environment is recommended.

11.2.3. Business services enable reuse

The creation of a business service layer promotes reuse in both business and application services, as follows:

• By modeling business logic as distinct services with explicit boundaries, business process-level reuse can be achieved. Atomic sub-process logic or even entire processes can be reused as part of other process logic or as part of a compound process (which translates into a service composition in its own right).
• By taking the time to properly align business models with business service representation, the resulting business service layer ends up freeing the entire application service layer from assuming task or activity-specific processing functions. This allows application services to be positioned as and to evolve into pure, reusable utility services that facilitate business services across solution boundaries.

11.2.4. Only business services can realize the service-oriented enterprise

Business service modeling marries the principles of service-orientation with an organization's business model. The resulting perspective can clearly express how services relate to and embody the fulfillment of business requirements.

Applying business services forces an organization to view and reinterpret business knowledge in a service-oriented manner. Altering the perspective of how business processes can be structured, partitioned, and modeled is an essential step to achieving an environment in which service-orientation is standardized, successfully consistent, and naturally commonplace.

Though the business services layer may accurately represent a corporate business model upon implementation, it will become outdated once new and revised business requirements emerge. As long as it is kept in relative alignment with the current state of business models, it will continue to serve as a valuable view of the enterprisevaluable because it does not exist in abstract but in an implemented and operational form.

Case Study

As mentioned earlier, RailCo has decided to structure its SOA around a services layer consisting of separate business and application sub-layers. Given that it does not have extensive business requirements, these layers will not contain many services. However, the important aspect of this initial project is that it will define an architecture that accommodates additional services and solutions.

As part of its analysis, RailCo has identified the following benefits of investing in extensible business services:

• Business services can be modeled in such a manner that they perform common functions for non-specific service requestors. This will allow RailCo to fulfill its first requirement of making its services available for online transactions with multiple customers.
• A separation of business and application logic will allow RailCo to wrap its legacy accounting system in one or more services. This will allow it to establish an application services layer initially consisting of an application service that will be reusable to task-specific business services.
• RailCo's second requirement also can be fulfilled by adding a service to represent the contact management system. Integration can then be achieved by again reusing the service that encapsulates the accounting service.

At this stage, RailCo simply is listing potential benefits that can be met by introducing services it has not yet even modeled.

SUMMARY OF KEY POINTS

• Investing in a separate business service layer builds agility into an SOA by abstracting business and application logic domains, allowing them to evolve independently, and adapting to each other's changes.
• Business services prepare an SOA for orchestration and promote reuse of both business process and application logic through careful encapsulation and abstraction.
• Business services are key to fulfilling an enterprise-wide standardization of service-orientation.