Service-Oriented Architecture

Business processes integrate systems, partners, and people to achieve key strategic and operations objectives. Examples of business processes include getting and filling orders, processing invoices, reconciling shipping notices and received goods and processing insurance claims and loan applications. The Holy Grail of enterprise computing is adaptive business processes that can be defined, refined, and optimized to respond to changing business environments, government regulations and competitive pressures. This vision has followed us through the evolution of mainframes, Management Information Systems (MIS), packaged applications, J2EE-based application platforms, business process management systems (BPMS) and now, Service Oriented Architectures (SOA). We are getting there!

Many solutions exist for designing and deploying business processes. Some are derived from proprietary BPMSs or workflow engines; others have been built as process execution engines for Web Services and SOA, and are usually based on the Business Process Execution Language (BPEL) for Web Services. All of these solutions have a common goal: to support the business process lifecycle from modeling and design to implementation and monitoring, and then back to design. Full lifecycle support enables continuous process improvement. Being able to iterate continually through the process lifecycle is called closed loop. Systems that support this are called closed-loop business process management or closed-loop BPM solutions.

Large enterprise software vendors offer closed-loop BPM solutions, while niche vendors offer point solutions that tackle part of the cycle, such as modeling. But can you put together best-of-breed tools from multiple software vendors without spending a lot of time integrating them? In other words, are there any interoperable standards-based tools that support the business process lifecycle? The good news is that with standards such as BPEL and Business Process Modeling Notation (BPMN) you can implement standards-based, closed-loop BPM.

BPEL - a standard, portable language for orchestrating services into end-to-end business processes - builds on a decade of progress in business process management, workflow, and integration technologies. It's built from the ground up around XML and Web Services and is supported on both the Microsoft .NET and Java platforms. BPMN, as an amalgamation of best practices in the business process modeling community, provides a simple, standard means of communicating process information to key stakeholders.

THE BUSINESS PROCESS LIFECYCLE

The business process lifecycle consists of the following steps:

• Model and Simulate: Business process owners create a high-level design of the tasks to be done and a list of the required resources. This is usually done graphically using a drawing package such as Microsoft Visio or a proper modeling tool such as Popkin's System Architect. The modeling tool may also be used to perform optional simulation steps during which hypothetical scenarios are run to identify critical paths and bottlenecks.
• Implement and Deploy/Execute: Developers convert the business process definitions into an executable process model linking systems, APIs, and people through workflows. The resulting executable process is then deployed to a BPEL or BPM engine for execution.
• Monitor and Optimize: Deployed business processes are monitored to measure key performance indicators and other metrics. Process throughput and utilization metrics can be fed into a simulation tool to derive the optimal execution mode by using real data (e.g. historical).

This cycle is shown in Figure 1.

Designing and Deploying Processes

There are many ways to implement business processes (including using packaged applications that, for the sake of brevity, we won't discuss here). Figure 2 shows the spectrum of possible approaches for process design and deployment as well as the level of automation and flexibility offered by each approach. The obvious Procedural Code-based Solution (far left) uses SOA and Web Services but uses a development tool to write procedural code. The ideal 100% Standards-based Solution (far right) is a flexible, adaptable solution. Other approaches fall in between.

Obvious Solution: Procedural Code-Based Approach

How do you model, implement, and deploy business processes using a procedural approach? The choices are reasonably clear. The business analyst models the system using a modeling tool (for example, in UML), and the programmer incorporates existing services and develops new ones with J2EE. Although the analyst creates a high-level process model, it doesn't map directly to an executable process model, so the programmer has to implement the processes based on his understanding of the process model. Processes built in this way are hard to develop and error-prone because of the disconnect between the high level model and the completed process.

Further, systems built this way are difficult to change because you have to rewrite code. It's also hard to get performance metrics at the business level, such as the length of time it takes to ship an order - but these metrics are important to business managers. Without them, they are left "blind" to the real state of the business. Besides, changing business policies isn't easy since policies are hard-coded in application logic, making automated change impossible.

Ideal Solution: Process Modeling using BPMN, Implementation using BPEL

So what does the ideal solution for modeling, implementing, and executing a business process look like? The ideal solution models business processes using BPMN and implements and executes them using BPEL. A business analyst can use a business-process modeling tool (such as Popkin's System Architect) and then export the process model as BPEL. This can then be imported into a BPEL-compliant SOA/process development tool (such as BPEL Designer in Oracle JDeveloper 10g) to define and implement the process further.

BPMN, developed by the Business Process Modeling Initiative (BPMI.org), provides a notation that all business users can easily use and understand. These users include business analysts who model business processes, technical developers who build systems that implement those processes, and managers who must understand and review process diagrams.

Some key BPMN features include:

• Pools and lanes: These entities are used to demarcate processes, participants, and systems. They help build multi-level process diagrams.
• Events and activities: Events are used to represent something that happens in the course of the business; they usually have a cause and effect. Activities are work that's done - either a single task or a set of tasks (sub-process).
• Sequence flows and message flows: These indicate the order in which activities are done and identify messages exchanged between entities. Associations are used to attach text and other artifacts to flow objects.
• Model message and control: These data objects model how documents, data, and other objects are used and updated during a process flow.

BPMN objects have a rich set of attributes that enables easy mapping to BPEL. The skeletal BPEL process output from the modeling tool generally consists of process scopes, invoke/receive activities, and partner links to the appropriate services. Further work is required by the programmer, 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 yet simple abstraction for addressing these requirements by adding implementation details on top of the BPMN model.

Add Your Feedback

In order to post a comment you need to be registered and logged in.

Register | Log in

Please wait while we process your request...