Section 7.2. BPM and the Process-Enabled SOA

7.2. BPM and the Process-Enabled SOA

Having introduced the foundations of BPM and its long-term vision, we now take a closer look at what this means for the SOA architect.

7.2.1. THE PAST: DATA AND FUNCTIONS VERSUS OBJECTS VERSUS SERVICES

This chapter focused on BPM and process-orientation, which comes at the very end of our "enterprise renovation roadmap." We should now step back and look at the origins of SOAs and what can be learned from their evolution.

In the early days of functional programming, data and functionality were strictly separated. With the emergence of object orientation, people began to merge data and functionality into encapsulated, reusable object implementations. This worked particularly well for large, monolithic applications, such as complex graphical user interfaces. In the middle of the 1990s, people started to apply the concepts of object orientation to distributed systems. CORBA and a number of other standards for distributed object computing emerged. However, when applying distributed object technology in large-scale projects, it eventually became clear that this approach had some severe limitations. As a result, Service-Oriented Architectures emerged, with supporting technology platforms such as XML Web services.

So what problems with distributed objects led to the emergence of SOAs? The first problem that we usually cite is the fine level of granularity of distributed objects, which often leads to performance problems due to latency and other issues. An SOA addresses these performance issues by adopting patterns of more coarse-grained objects, which require less frequent interaction between clients and servers, thus reducing the number of network roundtrips, marshalling overhead, and so forth.

However, a second and potentially more critical problem exists: Due to the complicated interaction patterns that result from the fine-grained nature of distributed objects, the reuse of distributed objects became increasingly complex. The complex dependencies between different objects prevented efficient reuse and made these systems very inflexible and hard to maintain because few people really understood these dependencies and the impact that changes to individual objects and their interfaces would have on overall systems.

With SOAs, we take a deliberate step back from the highly complex, fine-grained, highly dependent distributed object models toward less complex, relatively coarse-grained, loosely coupled (i.e., less dependent) component interfaces.

7.2.2. THE FUTURE: CORE BUSINESS LOGIC VERSUS PROCESS CONTROL LOGIC

Rather than revert to a paradigm that separates data and functionality, the SOA should develop an architecture that differentiates between core business logic and process control logic. Both of these concepts comprise data and functionality, although in very different ways. Unfortunately, these concepts are not as clean as the concepts of data and functionality, but we believe that they are still essential for the successful implementation of an SOA-based "enterprise IT renovation roadmap." Let's take a look at each concept using concrete examples.

Core business logic comprises basic data access services, complex calculations, and complex business rules. Data access services represent core business logic because they make core business entities available to different systems. An example is a service that enables different applications to read and update shared customer data. An example of a complex calculation would be the calculation of an insurance premium based on statistical data that is encapsulated by the service. Different processes such as sales, premium adjustment, and risk assessment require this core business logic. It is not always clear whether business rules represent core business logic (residing in a basic service) or whether they should be a direct part of the process logic (e.g., residing in a BPMS or process-centric service). Often, this will depend on the level of complexity of the business rule. The simple rule that "all orders over USD 100,000 must be manually validated" might well be part of the process control logic. However, a complex claims validation engine that incorporates legislative data to check the validity of insurance claims would clearly fall into the category of core business logic.

Related core business logic usually resides in a single service. As we stated before, these services are relatively coarse-grained and loosely coupled (or independent) and do not have complex interfaces (even though they might encapsulate a very complex piece of logic such as a claims validation engine). In particular, services that represent core business logic control their own transactions; they do not participate in externally controlled, potentially long-lived transactions. The interaction with services representing core business logic is usually OLTP-style, based on underlying short-lived transactions. However, services representing core business logic might participate in complex processes "orchestrated" by a BPM or a process-centric service.

Process control logic, on the other hand, has very different characteristics. As discussed at the beginning of this chapter, many processes are dynamic in that they are prone to frequent change and often require complex coordination with the process participants. Often, these processes are related to non-tangible assets, in service industries for example. Other examples include contract management, supply-chain management, sales of complex tailored products, or software outsourcing processes.

Services managing process control logic, such as process-centric services, do not usually have application state such as currency exchange rates, customer data, or airline seat availability. However, they do have state related to the process itself. This process state includes information regarding process participants (people and services), input from participants, the actual position within the process flow, and basic rules. Process-centric services are highly dependent on other services, in particular those services that represent the core business logic. Such services provide the glue to bind the core business services. In particular, process-centric services must coordinate complex activities that can span more than one person, several major business entities, multiple locations, or long periods of time.

The benefits of cleanly separating SOA services (see Figure 7-8) into services containing core business logic (with a potentially long lifetime) and processes containing control logic (with a usually much shorter lifetime) are manifold. In particular, this approach should benefit the overall goal of our "enterprise renovation roadmap," which is increased agility. If the separation is thorough, changes to existing processes and the introduction of new processes should happen relatively smoothly because changes will be limited to services that represent process control. Furthermore, the approach supports the encapsulation of critical stateful codein particular, this means that changing one process does not affect another process. Finally, business logic will be implemented only once, thus helping to reduce redundancies and inconsistencies.

Figure 7-8. A key requirement toward an agile enterprise architecture is that it clearly distinguishes between process control logic and core business logic.

7.2.3. DESIGN IMPLICATIONS FOR SOA ARCHITECTS

Decomposing an SOA into services that represent core business logic and those that represent process control does not simply mean moving back from a distributed object paradigm toward a functional paradigm. Services representing core business logic go far beyond simple data access services. Similarly, process control logic is not limited to pure functionality. Although process control logic does not usually own large amounts of core business data, such as the customer database, it still can manage a lot of internal data, such as user input, input from basic services, and so forth.

The challenge for the SOA architect is to identify and categorize services accordingly, taking many aspects into consideration, including business and process requirements, the existing application landscape, make-versus-buy decisions, resource availability (e.g., development skills), SOA design considerations, and budget constraints. However, if an enterprise is serious about the long-term renovation of its IT landscape, this decomposition process will represent an important cornerstone in the overall process.