How Service Oriented Architectures
Enable Business Process Fusion (part I)

by Max Dolgicer

April 2006

In these days of heightened scrutiny of all IT expenditures, we have to constantly ask ourselves what is the contribution of IT to the overall capabilities of the business? Many of the core business processes have already been automated, for example through the implementation of Enterprise Resource Planning (ERP) and Supply Chain Management (SCM) systems. Enhancements are often necessary, but they will only make part of the business run smoother, they will not enable new business capabilities.

Investments in IT can be used to build new applications. However, this typically provides only limited business functions that solve an isolated need of the business. So where is support from IT needed most? Two of the top issues that most enterprises need to address today are the competitive pressure to move towards the Real Time Enterprise (RTE) and enabling business agility as well as adaptability.

The goal of the RTE is to significantly reduce the elapsed time between the moment a business event occurs and the completion of the activities that the business performs in order to respond to the event. A typical example would be a request for an insurance quote, which would normally be processed as part of a nightly batch cycle. In an RTE this request would be processed immediately. Many businesses did not have this requirement five years ago, but today’s competitive pressure is driving them more and more towards the RTE.

It should be noted that the implementation of an RTE in and of itself does not guarantee business agility and adaptability. The RTE is concerned with the speed by which business processes are completed, whereas agility and adaptability are concerned with the time it takes to implement new business processes or to change existing ones in order to react to changing market conditions.

According to Gartner Group, a key ingredient for achieving RTE, agility and adaptability is business process fusion. They provide the following definition for fusion:

“Business process fusion is the transformation of business activities that is achieved by integrating previously autonomous business processes to create a new scope of management capabilities.”

Let’s have a look at what this definition is trying to express. The result of business process fusion is the transformation of business activities, such that they are in line with the principles of the RTE, agility and adaptability. In other words, business activities will be conducted in (near) real time, they are quick to implement and easy to change. This transformation is achieved by integrating multiple, previously isolated business processes that span organizational and management boundaries.

This integration creates a fused process, which binds (physically) loosely connected but (in terms of business) dependent processes. The fused process enables new management capabilities, for example the business can now offer a solution that is a combination of several products and/or services. Other examples include the integration of business processes from price setting over order taking to provisioning in the Telco industry, or in manufacturing, process integration from research to design, construction and marketing.

Fusion and the Service Oriented Architecture (SOA)

How can IT support business process fusion? Fusion requires an IT architecture that goes beyond traditional application silos. The architecture must focus on granular business services rather than large, course grain applications that implement a host of business functions - these are the key issues. Once business logic has been architected in form of services, it is possible to compose these services into fused business processes. This leads us to two important concepts that have gained a lot of popularity lately: Service Oriented Architecture (SOA) and Service Oriented Development of Applications (SODA).

SOA is gaining momentum mainly because it is seen as the key for enterprises to achieve business agility, improved quality of service and lowered total cost of ownership. Over the past two years, most Fortune 1000 companies have started to embrace a SOA approach and apply it opportunistically for either the development of new applications, integration of existing systems or both. Many industry analysts predict that these companies are now ready to take the next step – a more systematic adoption and enforcement of service-oriented practices.

The concept of SOA is not completely new, but may finally have found its time. SOA prescribes loosely coupled business services, minimizing the dependencies between service provider and service requestor. It calls for standard interfaces, standard access protocols, and a separation of interface from implementation. This may all sound familiar – previous technologies such as distributed objects and components were promoting similar ideas. Furthermore, many enterprises have developed Service Oriented Applications using these previous technologies. So what’s SOA all about and why will things be different this time?

Interfaces

Let’s compare the aspects of a service oriented architecture that pre-date the age of Web Services with the approach taken today. A service exposes well defined interfaces and follows the notion of encapsulation, i.e. the service implementation is separate from the interface and therefore hidden from the clients view. Service interfaces are described using a formal mechanism. These aspects of a SOA could be found in the Common Object Request Broker Architecture (CORBA) in form of Interface Definition Language (IDL), as well as in the Distributed Component Object Model (DCOM) in form of Microsoft IDL (MIDL). J2EE also prescribes the concept of well defined interfaces that are exposed to clients by Enterprise Java Beans, albeit without using some kind of IDL.

Although in a purist sense today’s SOA does not mandate the use of a specific implementation technology, from a practical standpoint Web Services are the technology of choice. Here service interfaces are defined using Web Services Definition Language (WSDL), which makes a big difference compared to CORBA, DCOM and J2EE in two ways. First, WSDL has become a universally accepted standard that transcends technology platforms (e.g. Java, C#, Windows, Unix, etc.) as well as the product lines of software vendors, including fierce competitors such as Microsoft and Sun. None of the previous standards has ever reached that status; they have always been isolated solutions, plagued by interoperability and portability problems.

Second, and probably more important, today’s SOA based on Web Services prescribes less rigid and thus less brittle interfaces. Using previous technologies, a small change in the service interface breaks the client who is using the service. This is because we were not really dealing with a service interface, but rather with a calling signature that the client has to follow in order to invoke some method on an object or component. The smallest change in this calling signature would render the call invalid. Furthermore, objects are strongly typed, the types are checked and objects are identified by the calling signatures, for example through class IDs or object IDs. In other words, making this small change would actually create a completely new type of object.

With Web Services it is possible to expand the interface and the client could simply ignore the new elements. For example, if a WSDL for placing an order includes a customer address section, this section could be expanded by adding the customer’s phone number. Since WSDL prescribes a standard, self-describing service invocation format, the client can determine which elements he can process and which he needs to ignore. However, there is a caveat. Web Services are often used with Remote Procedure Call (RPC) style invocations, whereby the client relies on a generated RPC stub that translates the call into a Simple Oriented Access Protocol (SOAP) based message. In that case, changing the interface of the Web Service would require some additional work.

As we can see from this discussion, the service interfaces in a SOA that is based on Web Services have some important qualities that distinguish them from other technologies. They provide flexibility for change, loose coupling between service provider and consumer, as well as technology independence, which fosters a high degree of interoperability and portability. These are all key features for an efficient implementation of fused business processes. If a business process is made up of a number of business services (instead of monolithic applications or rigid objects) that employ those qualities, it is much easier to combine it with other processes in order to create a fused process.