Business Agility Using Business Process Management and SOA

by Gabriel Bechara

December 2010

Downloads
download-icon13-1 Oracle SOA Suite
Oracle BPM Suite
Oracle WebCenter

Abstract

While mergers and acquisitions have become business as usual, the unification of data and processes is one of the main challenges Enterprise Architects in large organizations must deal with. Process and data silos, which are historically associated with different lines of businesses within one organization, tend to multiply with each merger or acquisition. New silos might even appear within existing lines of businesses, because a global organization might choose to maintain and strengthen specifics related to national preferences to improve its client proximity.

One way to address multiple specifics related to large organizations while maintaining a global, coherent information system is to separate the information system into different areas, with a different IT approach in each area. Nowadays, such areas tend to be the front office, the middle office, and the back office.

This article describes using Business Process Management (BPM) and SOA to improve business agility, enhancing an enterprise's competitiveness in the challenging market of today's globalized economy.

Goal of the Front, Middle, and Back Offices

In the front-office area, large organizations need to have a unified look and feel and the ability to quickly adapt their processes, because proposing new products offerings consists of creating new user interfaces around new processes that are driven by new business opportunities. Large organizations also need to continue addressing the specifics of acquired companies in their middle offices. On the other hand, they might choose to consolidate sustaining functions by using flexible solutions to achieve rationalization and decrease costs in the back office. Overall, large organizations are looking for agility in the front office, reuse in the middle office, and rationalization in the back office.

An example in the banking business consists of the high-level architecture shown in Figure 1.

Figure 1: Example High-Level Architecture for Front, Middle, and Back Offices

The Process-centric Agile Front Office

An agile, flexible front office can be achieved by generating applications that are BPM-oriented. Ideally, Business Process Modeling Notation (BPMN) is used to model new business processes related to new business opportunities. Then, the BPM models are used as starters for implementing the process-driven, composite applications. The processes' user interfaces are then mashed up into a collaborative, user friendly Web 2.0 enterprise portal that inherits all the collaboration capabilities provided by enterprise portals. The ability to refine these processes and their Key Performance Indicators (KPIs) at run time could then be the ultimate step for tuning the processes and their KPIs according to business expectations, before finally exposing them to end users.

This BPM complete life cycle is described in more detail in Figure 2.

Figure 2: BPM Complete Life Cycle

Multiple iterations, in which iterative methodologies are applied, could be done between steps six and nine of Figure 2 or on the whole BPM life cycle for business processes that were previously deployed to end users but need to be adapted to new business needs.

In step nine, the ideal BPM tools would provide the capability of accessing the business process description (metadata) at run time. This enables the business analyst to check that what is deployed conforms to what was designed. If needed, this step would allow the business analyst to modify a process using a Web composer (based on the same process metadata provided by the developer and published in a metadata repository from the development tools), test the modified process, and submit it to the developer through a metadata repository. The Web composition capabilities of the BPM tools could be a step for moving to a BPM-as-a-service approach in a cloud environment.

The BMP tools used for developing the applications guarantee a continuous relation between business processes and the different interfaces generated from the user activities defined in the business processes. This helps keep a strong relationship between business and IT in the front office, which prevents the gap that usually appears after a few iterations of using traditional software development tools. For example, an extract of a payment business process is shown in Figure 3. (This business process is detailed later in this article.)

Figure 3: Example of a Payment Business Process

As you can see in Figure 3, the link between the activity "Enter Payment Details" of the BPMN-modeled process and the screen flow (generated first and adapted after) is related to the human-interaction activity, and the link is always kept up to date thanks to the BPM modeling and implementation tools provided by Oracle Unified Business Process Management Suite 11g.

Middle and Back Offices Expose Reusable Services

The business processes need to interact with the different back ends in the middle or back offices. Thereafter, an Architect would need to check for existing reusable services to support the business user-designed BPMN processes. Those services might be called in automated activities in the BPMN processes or in screen flows of human interaction activities of those processes. Composite or new services could be created when needed.

The ability to access reusable services or create new services is fundamental for getting the most out of BPM. An enterprise governance team composed of architects should have the responsibility to promote reuse and to define when a new or a composite service is needed. This governance team should have a good understanding of the organization's processes and the existing enterprise business services. This team should also have the responsibility to define, apply, and certify projects and services against predefined enterprise services principles. Some principles around reusable services are described in the article What is a Reusable Service?

Accessing the middle and back offices should preferably be done through an enterprise services mediator to guarantee decoupling of the middle and back offices from the service producers. The decoupling between the front office and the middle and back offices provides the ability for adding middle-office applications after a new acquisition or replacing back-office applications without impacting the front-office processes.

Achieving agility in the front office depends on the capability of the front-office applications to easily address the back and middle offices when needed. Using a top-down approach, tactically mixed with a bottom-up approach used for identifying existing applications and services, helps provide reusable services for addressing the middle-office applications or the back-office applications. Those reusable services can then be reused from BPM tools, because they were first identified starting from enterprise processes using a top-down approach, and they should have the correct granularity for reuse in the front-office processes.

Several enterprise architecture frameworks (such as The Open Group Architecture Framework [TOGAF], which covers business, data, application, and technology architectures) can help identify existing and new building blocks. In the article An Introduction to Enterprise Architecture, I describe a simplified, top-down approach for enterprise architecture in the context of service-oriented architecture (SOA), focusing on a methodology for defining a roadmap from a current state to a target.

In that article, I referred to the business processes as being enterprise-level processes, which are modeled on the enterprise business process plan and used to identify reusable enterprise business services. In that same article, I also referred to a unified canonical data domain model as a way to provide a common language using a common data model to promote reuse. I come back to the definition of the unified canonical data model later in this article.

As a reminder, the plans described in the top-down approach are shown Figure 4. In this diagram, additional details have been added to the applications plan related to the BPM Web 2.0-driven front office as a mean for providing the agility required in this area.

Figure 4: Plans Described in the Top-Down Approach

Using BPM tools to develop the front-office applications provides agility and adaptability and reduces time to market for new offerings. The relationship between the processes defined by the business (on the business plan) and the implementation of the processes (on the application plan) are maintained because all user-activity screen flows are related to the business processes that originated from the business strategy. In addition to this augmented agility on the applications plan, it would also be interesting to provide corresponding agility on the technical plan for the deployment of the business services and the data.

The ability to scale out the platforms on the top of which the business services are deployed certainly accelerates the process of deploying new business processes. The new business processes that rely on existing business services augment the use of business services and may induce scaling out the platforms that support those business services. Related to this, cloud computing platforms should be considered, since Platform as a Service (PaaS) computing provides dynamic scale-out and application provisioning capabilities. PaaS technologies are available from Oracle for middleware and databases.

The Domain Data Model as Support for the Enterprise Processes

In the article An Introduction to Enterprise Architecture, I frequently referred to "the canonical data models" or the "domain UML models" that should be understood by the entire organization, used in the reusable enterprises services, and exposed through the service infrastructure.

The front-office enterprise-level processes span different silos within a global organization and need to consume common services in their activities. Those services used (and reused) globally should share a common data model. This data, which represents the business entities (entities of the UML domain model or business objects), might have different data representations in the different silos of an organization. Thus, it is important to unify the data representation at the enterprise level because this data is needed by enterprise-wide processes.

There might be different use cases for data model unification. One case consists of having the same business entity stored in different back ends. If we take, for example, the client of a bank, data about this client might be stored in an ERP system, in the accounting system, in a CRM system, and so on.

Another use case deals with the same type of data with multiple representations, one per country. For example, this is the case when a bank extends its presence abroad to multiple countries by acquiring several smaller banks, as shown in Figure 5.

Figure 5: Use Case for a Global Bank

Even if the global bank has a single software application that holds all clients' data for all banks (and that is rarely the case, especially if a bank needs to deal with different branches that are distributed in different countries, each of which has its own regulatory and accounting rules), you still might need to deal with different versions of the same application or with modules that do not apply the same business rules depending on their localization (potentially rendering different data models). Within this context, being able to have a unified view of the data certainly helps when implementing processes that span across all the silos of an organization.

Example: International Payments Within a Global Bank

Let's take, for example, the use case of an international payment. Figure 6 is generated using Oracle Unified Business Process Management Suite 11g.

Figure 6: Use Case for International Payment

This payment process consists of the following:

The payment information for the local client is entered. This is done locally by a local clerk at one of the banks belonging to the group.
Approval and validation rules are defined and applied globally for all banks that belong to the group by calling an automated approval rules service.
When additional approval steps are required, manual approval screen flows should be provided and accessed through a work list used by the approvals line of business.
International payments are checked and completed (correspondent and intermediary banks, loro and nostro account, and so on) within a common specialized international payment unit for all the banks of the group.
Accounting is done by calling a unified multiplan general ledger application.

Note: This case can be more complicated in a real-world scenario. The process and the data model exposed later are intentionally simplified.

Designing the Canonical Domain Data Model for the International Payments Example

The payment process should use a unified representation of the payment and the client data needed for this process in its different activities. Some parts of this data are needed centrally for approval and authorization controls, some parts are needed centrally for the payment and accounting (provided you have unified multiplan accounting), and some parts are needed when entering payment information such as the client details. Some of the client details might come from different data sources depending on the localization of the bank and its legacy systems.

A simplified UML representation of the entities involved for this type of operation is shown in Figure 7 (the real case is much more complex).

bechara-business-agility-fig07
Figure 7: Simplified UML Diagram

This model could be considered as a canonical domain model for the payment and client data if it has the ability to contain the necessary elements needed for unifying the data representation of those entities that are used globally throughout the organization.

The UML representation of the payment canonical domain data model could be mapped to XML to provide the physical support for the data when it is exposed through a reusable enterprise business service and used in a business process. XML schemas can also be used directly for conceiving those models using design tools, as shown in Figure 8.

Figure 8: XML Schema

Note: External keys, not represented in the previous diagram, may need to be added to link the canonical domain model to the different physical models. Another option is to use reference tables for key mapping. Creating those models requires guidance, because some important considerations should be taken, such as the extensibility and the versioning of those models. A few vendors include in their offering prebuilt data models based on industry reference models. In the Application Integration Architecture (AIA) Foundation Pack, Oracle provides a set of application-independent enterprise business objects (domain canonical data models). These models outline best practices in specific industries and are designed for extensibility. For more information, see the white paper Oracle Application Integration Architecture Enterprise Business Objects (EBO) Concepts -- Concepts, Structure, Terminologies and Design Rules.

Ideally, the XML representation of the payment canonical domain data model, and other data models such as the client canonical domain data model described previously in this article, are directly used in the business processes. Thereafter, an ideal BPM tool should offer the ability to import XML schemas in the business catalog for reuse in BPMN processes, as shown in the Figure 9.

Figure 9: Importing XML Schemas

The Architecture Supporting the International Payments Example

Figure 10 describes the architecture that supports this process with respect to the different principles presented in this article.

Figure 10: Supporting Architecture

The architecture diagram shows the decoupling between the front-office processes and the middle and back offices. It also shows the reuse being done through services by exposing a canonical domain data model through enterprise business services. The integration layer handles complex interactions between applications of the middle and back offices. Complex automated integration between back-end applications should be separated from the BPMN business processes.

Complex automated application-to-application interactions are usually handled using Business Process Execution Language (BPEL) integration processes. BPEL integration processes deal with many technical details that should be hidden from the BPMN business processes. The BPEL integration process could be then be invoked from automated activities in the BPMN business processes. Figure 11 shows this in more detail.

Figure 11: Integration Process

Conclusion

Using BPM coupled with SOA helps you to achieve agility in the front office, reuse in the middle office, and rationalization in the back office. BPM augments an enterprise's capacity for providing new product offerings and enhances an enterprise's competitiveness in the challenging market of today's globalized economy. Therefore, it is imperative that an enterprise choose the right BPM products and tools to support this agility.

This article has shown some of the functionality that is essential for BPM products, such as the following:

The ability for the business user to model processes using BPMN business-oriented modeling
The ability for the developer to use those BPMN models for implementing the processes
The ability to keep a clear separation between BPMN business processes and fine-grained integration processes
The ability for the process design tool to generate for the user activities human interfaces that are based on an extensible, flexible, and proven development framework
The ability to integrate the generated user interfaces in a Web 2.0 portal that provides document sharing, collaboration capabilities, and social computing around and in the processes
The ability for the business to share process models with developers using a common repository for accelerated agile development
The ability for business processes to use reference data models that are related to industries or designed by the enterprise and shared in a common repository

Products and Services

Solutions

Downloads

Store

Support

Training

Partners

About

Oracle Technology Network