Describing how a company runs its business usually involves describing its business processes. Such processes may include managing supply chains, product lifecycles, customer lifecycles, human resources, and accounting and finance. These processes often represent a company's intellectual property, competitive differentiators, and major innovations. As business conditions change, these processes need to be changed as well.  To be better positioned for success, companies need to quickly leverage these process changes, which includes changing the underlying IT systems.

Let us look at a typical business process lifecycle. Business processes are usually defined by subject matter experts, who are also known as business analysts. Besides documenting processes — either for compliance reasons or to identify ways to improve them — business analysts collaborate with IT to bring process concepts from the drawing table to fruition as products, applications or services.

Traditionally, analysts have used visual tools to model, capture and represent business processes. They typically create these business process diagrams at multiple levels of detail to accurately reflect the business requirements. The IT development team then takes the diagrams and either implements the business logic in procedural code, or redraws the business processes in a business process management and workflow tool. In the process of doing so, the original diagrams quickly get out of sync and irrelevant: that's because implementing a business process requires much deeper understanding and greater detail than what's usually provided by the business process modeling tools. Hence, the implementation ends up only slightly resembling the business analyst's high-level diagrams. As a result, changing and maintaining systems is an extremely difficult and expensive task. To address this problem, CIOs are now focusing on making business process diagrams more meaningful and useful for both business analysts and developers.

Different Ways to Implement Business Processes

There are many ways to implement business processes including using packaged applications. In a code-based approach, the business process is captured as a diagram or process graph in a process modeling tool. Although the analyst creates the high-level process model, the model doesn't map directly to an executable process model, so the programmer must implement the processes based on his understanding of the process model. Processes developed this way are hard to develop and are more error-prone due to the disconnect between the high-level model and the executable process. Further, systems built this way are difficult to change because you must rewrite code to make changes, rather than change a model. It's also hard to get performance metrics at the business level, such as the length of time it takes to provision a DSL line — and without metrics, business people can't get an accurate picture of the state of the business. In addition, changing business policies isn't easy: since policies are hard-coded in application logic, it's impossible to make automated changes.

The alternative to the code-based approach is a model-driven solution that uses BPM systems and Business Process Execution Language (BPEL) technology. The significant increase in the support for BPEL, an industry standard that represents and executes these business processes, bodes well for business. By abstracting the flow logic from the code, BPEL provides a much more business-aligned view of the world. Also, because BPEL uses XML notation, abstracting across tools and technologies is a lot easier. This paves the way for a single, unified metadata approach to representing business processes.

Following the success of BPEL is another standard called Business Process Modeling Notation (BPMN). This specification provides a notation that all business users can easily understand — from the business analysts who initially draft the processes to the application developers who implement those processes. BPMN can also nicely map to BPEL, making it a great candidate to bridge the gap between the business process design and process implementation.

With BPEL and BPMN, a business analyst can use a process modeling tool and build the process using BPMN. BPMN-to-BPEL generation guidelines are well defined. The BPMN process model can automatically generate a BPEL outline along with metadata relating to business rules, process monitoring points, and workflows. You can then manipulate this business flow outline — or at least the BPEL process — in a BPEL-compliant SOA/process development tool to further define and implement the process.

The intermediate logical layer is key here: it captures the process, rules, and workflow logic in metadata, and brings together the analysts who design the processes, the developers who build systems that implement those processes, and the managers who must understand and review process diagrams. It also greatly simplifies communication between analysts and developers, and helps them collaborate more effectively. The layer also forms the basis for a seamless visual modeling experience, from process design through implementation.

The Right Level of Abstraction

It's impractical to think that business analysts will work with the same tools and development environment as the developers implementing the business process. They see the same process differently: the analyst is thinking about flow, cost of resources, and impact analysis, while the developer is thinking about service bindings, partner links, WSDLs, transformation, and exception handling. However, both viewpoints can be represented as a single set of metadata. Figure 1 shows how you can link the business process model (conceptual) to an executable process model (physical design) using an intermediate layer namely the logical design.

Figure 1: BPM Design Model

You can generate a logical design from the business process model by transforming activities to their corresponding artifacts. The logical design consists of a business flow outline (such as BPEL, workflow, logical data objects, or business rules outline), which is a higher-level view of the implementation artifacts. The logical design uses shared metadata that makes sense to all key actors involved in the application lifecycle including the business analyst, the application architect and the developer.

The fundamental tenet of this approach is to abstract the activities and notations defined by the business user in BPMN and provide the necessary tools to map those abstract activities to specific BPEL constructs. BPMN objects have a rich set of attributes that make them easy to map to BPEL. The skeletal BPEL process output from the process modeling tool generally consists of details such as process steps, decision points and participants. Further enrichment is required, including binding to heterogeneous systems, supporting synchronous and asynchronous message exchange patterns, transforming data and schema, coordinating activity flow, managing exceptions, handling non-deterministic events, defining compensating transactions, and managing version control. BPEL provides a rich and yet simple abstraction for addressing these requirements by adding implementation details on top of the BPMN model. The two can thus be used together to bridge the gap between the analyst and the developer.

Example: A Loan Application Flow

Consider the following example of a loan flow process deployed at a loan broker. The broker accepts a request from a client, performs a credit check with an external service, and routes the application to two loan agencies. After receiving two offers, the better offer is selected and the customer is notified. We'll show how you can automate this business process with available solutions based on SOA and Web services principles using BPMN and BPEL.  

In our example, the business analyst has worked with the company's business teams (such as marketing, product, and corporate) to create the basic requirements for the loan flow business process. Instead of defining these in a static diagram, the analyst can use an out-of-the-box visually rich tool to define business processes using BPMN notation. By using a model-driven approach to build a flow, the task is simple and intuitive; however, the BPMN specification also supports complex business processes. Figure 2 describes the BPMN representation of the loan flow process.

Figure 2: The loan flow process in a business process modeling tool using BPMN

Once the business analyst is satisfied with the higher-level representation of the business process, he could generate a partial logical design out of it (i.e. outline views of the execution artifacts like BPEL, human tasks and rules, etc.). The partial logical design is then extended using the implementation tool by the developer or the application architect. The logical view helps you design better processes because this is still an abstract view and you do not need to specify implementation details as shown in figure 3.

Figure 3: The loan flow process using the logical view in the implementation tool

The abstract nodes let you provide an abstraction between the activities and the implementation. This is the beauty of the approach: specializing a node (for example, making the Get Credit Rating a invocation) doesn't affect the logical view. The developer understands that this must be implemented as a PartnerLink in BPEL and binds it to the WSDL provided by the service (as shown in figure 4), but the analyst doesn't see this level of detail. The logical view doesn't show the underlying implementation details; these often change and shouldn't affect the overall representation of the business process. However, if the developer changes the process flow, the analyst can see the changes by inspecting the metadata in the logical layer — without seeing the details that don't concern him.

Figure 4: Implementation view

Because you're operating from the same metadata, you can create a new set of activities in the Implementation view as shown in figure 5. The developer can set properties in the Implementation view such that these activities can be made visible in the logical view or the business analyst view.

Figure 5: Adding activities in the Implementation view

Keeping Model and Code in Sync

One problem with business analysis tools that are tied to code generation tools is that developers typically take what's produced from these tools and change it during implementation. This means the business analyst's view of the business process is in fact not what the developer ends up implementing. The process model and the implementation become out of sync, which means that there is no single common and accurate definition of business processes that developers and business analysts can share.

Using the above approach, the logical layer is the single source of truth that captures both the high-level process and references to the implementation details. This eliminates the need to manually sync the process model and the implementation. It's also much easier to make changes since the model that the business analyst sees is identical to the model that was implemented.

Summary

The idea that business analysts and developers will work collaboratively in the future isn't a new one. However, the advent of standards such as BPEL and BPMN has helped make such a collaboration happen. The key is to recognize the difference between the two perspectives — business and IT — and treat it as such. For example, many activities in a business process don't even have corresponding execution artifacts — they're purely manual tasks. Software vendors still have a lot of work to do in order to bridge this gap, and this calls for much collaboration in the industry. The approach we've suggested is to build on established standards such as BPEL and BPMN and introduce a shared metadata concept. This logical design layer acts as an intermediary between the high-level business model and the implementation model. The result is a reduced gap between business and IT, which lets everyone respond more quickly to changing business requirements and processes.

Key Business Benefits

• Reduce time to market for deploying business processes that require tighter collaboration between business and IT.

• Enable easier and more rapid change to business processes through synchronization of the business model with the execution model.

• Gain visibility into in flight business process with added business context, and enable easier process optimization based on actual process statistics from the running business process.

Key Technical Benefits

• Use unified metadata representation for analysis (conceptual) and implementation (physical) view.

• Address the “round trip engineering” problem so that the business model remains in sync with the actual implemented processes.

• Enable better collaboration with business and IT.

About Devesh Sharma and John Deeb

Devesh Sharma is a senior principal product manager for Oracle Fusion Middleware. His areas of focus include Business Process Management, SOA and Applications Integration. He is also driving Oracle's strategy for Process Modeling and Simulation tools.

John Deeb is a director of product management for Oracle Fusion Middleware. His areas of focus include enterprise integration, BPM and BAM.