Enterprise applications and information systems have became fundamental assets of companies. Companies rely on them to be able to perform business operations. Enterprise information systems can improve the efficiency of businesses through automation of business processes. The objective of almost every company is that the applications it uses should provide comprehensive support for business processes. This means that applications should align with business processes closely.
Although this requirement does not sound very difficult to fulfill, the real-world situation shows us a different picture. Business processes are usually of dynamic nature. Companies have to improve and modify, act in an agile manner, optimize and adapt business processes to their customers, and thus improve the responsiveness of the whole company. Every change and improvement in a business process has to be reflected in the applications that provide support for them. Only companies where applications can be quickly and efficiently adapted to the changing business needs can stay competitive on the global market.
We all know that changing and modifying applications is a difficult job, which requires time. This means that information systems cannot react instantly to changes in business processes—rather they require some time to implement, test, and deploy the modifications. This time is sometimes referred to as the information systems gap time. It is obvious that the information systems gap time should be as short as possible. However, in the real world this is again not always the case. Let us discuss the reasons.
The time required for modifying applications is related to several factors. The most important factor, in addition to the complexity and size of the modification, is the state of the application being modified. If an application has a well-defined architecture and has been constructed keeping in mind future modifications, then it will be easier to modify. However, each modification to the application makes its architecture less robust with respect to future changes. Applications that have been maintained for several years and have gone through many modifications usually do not provide robust architecture anymore (unless they have been refactored constantly). Modifying them is difficult, time consuming, and often results in unexpected errors.
The situation gets even more complicated. Several applications still in use in companies (particularly legacy applications) have not been developed with the objective of providing support for entire business processes. Such applications, often called stovepipe applications, provide support for certain functions or tasks only. For an information system to provide complete support for business processes, it has to be able to use the functionalities of several existing applications in a coordinated and integrated way. This makes the primary objective of information systems—to provide timely, complete, and easy modifiable support for business processes—even more difficult to achieve.
Based on what we have said so far, we can conclude that for efficient automation of business processes through IT we need to:
Provide a standardized way to expose and access the functionality of applications as services.
Provide an enterprise bus infrastructure for communication and management of services, including message interception, routing, transformation, etc.
Provide integration architecture between the various services and existing and newly developed applications used in business processes.
Provide a specialized language for composition of exposed functionalities of applications into business processes.
For many years the software industry has been searching for efficient architectures, technologies, and methods that would make the realization of the above mentioned aspects as simple and as quick as possible. Let us briefly describe each of the four aspects.
The requirement to expose functionalities of applications and access them remotely has resulted in several distributed architectures and middleware products, which emerged over time. The latest distributed architecture, which combines both synchronous and asynchronous communications, is Web Services. Web services are the most suitable distributed architecture for exposing the functionality of applications as services.
The enterprise bus infrastructure for communication and management of services provides answers related to the usage of services in complex enterprise information systems. In such environments support for centralized, declarative, and well-coordinated management of services and their communications is required. Because of existing middleware, the integration of different middleware products and interoperability with web services is required. These features are provided by the Enterprise Service Bus (ESB).
Integration between applications is a well-known topic. This integration is needed because enterprise information systems usually consist of several different applications, which address certain (sometimes isolated) functions and tasks and not whole business processes. Achieving efficient integration is related to the definition and realization of sound integration architectures, which are often very complex, particularly in large companies. Best methods and practices for building integration architectures are today known as Service Oriented Architectures (SOA).
The final aspect is the composition of exposed services of integrated applications into business processes. The most popular, commonly accepted, and specialized language for business process definition is BPEL, the main topic of this book. BPEL promises to acheive the holy grail of enterprise information systems—to provide an environment where business processes can be developed in an easy and efficient manner and quickly adapted to the changing needs of enterprises without too much effort.
The following figure shows the relation between SOA, web services, ESB, and BPEL:
Before starting the discussion on BPEL let us first have a quick look at web services, the enterprise service bus, and SOA.