BPM - Process for the Alert Enterprise

By Richard Douglass March 21, 2006

In the first article in this series, “SOA – The Backbone of the Alert Enterprise,” I made the case that service-oriented architecture (SOA) is part of the arsenal that IT needs to create an Alert Enterprise. An Alert Enterprise has a well-developed capacity to respond to change, react to opportunity and pre-empt risks, and ultimately, helps to drive alignment between IT and lines of business.
It is the orchestration, or business process management (BPM), layer on the SOA software stack where the rubber meets the road: where the business side meets IT. It’s important to note that BPM is not just about piecing together components to create a business process – although that is clearly important – but also about process improvement. The true value of BPM, in fact, is in defining a process-oriented architecture (POA) that links business strategy to execution.
Why is this true? The following statement by Charles H. Fine, professor of operations strategy and supply chain management at MIT’s Sloan School of Management, sums it up well: “Value chain design is the ultimate core competency . . . all competitive advantages are temporary” (Clockspeed – Winning Control in the Age of Temporary Advantage). While competitors can usually get a good idea about other businesses’ products and services, processes are much less visible to competitors and therefore less subject to being easily copied. However, with all the emphasis on “best practices” and benchmarking, even process design can be shared or co-opted in relatively short order. The key then is to be extremely nimble in adapting and improving the way business is conducted. As such, a POA must do for the business what SOA does for IT: create a framework for intelligent reuse of business processes and practices and rapid development of adaptations to those processes. BPM is the tool that plays a major role in providing this capability.

The term POA is not new. However, it has usually been used as a substitute for SOA or as a way to describe technology platforms that support business processes. To be truly process oriented, more attention has to be given to what the non-techies – the line of business folk – need to understand about a process, such as order-to-cash or procurement. As such, a POA is defined by its ability to:- establish process standards- monitor process performance- discern baseline vs. exceptional process behavior
Process Standards: The Building Blocks of Process-Oriented Architecture
There are a number of key elements in establishing a process standard. The first is in describing the basic inputs, outputs and process steps needed to transform the inputs into the desired output. The SCOR (Supply-Chain Operations Reference) model is a good example of this for the supply chain. As a process reference model for supply chain management, it serves as a management tool that enhances communication between parties. It describes supply chains, regardless of their complexity, as process building blocks using a common set of definitions.
Additionally, major business application software such as ERP (Enterprise resource planning) or CRM (customer relationship management) systems have set what amount to de facto standards for various business activities such as order taking, inventory management, shipping and invoicing. There is a push toward common standards as a common way of doing things. With common standards, it becomes easier for everyone to compare processes. The downside of this is that processes can become commoditized. An advantage to the commoditization of processes is that they can be more easily outsourced. In terms of business processes, the main issue with outsourcing is not in striking the initial deal, but in creating a solid foundation that will ensure successful execution of the process, day in and day out. BPM provides this essential framework, and allows organizations to tie together the building blocks of an end-to-end business process.
Monitoring Process Performance
After a process has been defined, it is important to understand how the process will be measured, i.e., what the key performance indicators (KPIs) will be. This is not as easy as it sounds. There is a tendency to either over-measure or measure the wrong things. To make genuine process improvements, it is critical to measure the correct things.
Let’s take a look at an oil refinery as a best practice of monitoring process performance. Oil refineries measure not only the quality and quantity of what comes out of the refinery – gas, diesel, jet fuel, etc. – but they monitor in real time what conditions exist during refining such as temperatures and feed rates.
As demonstrated in the oil refinery example, to learn why good or bad product may be produced, it is of chief importance to understand the conditions that applied during the creation of the output or product.
Much attention has been given to BPM simulation of business processes as a way to examine the impact of a proposed change. While there is a time and place for this, it is often more important to understand how the current process behaves. While this seems intuitive, it is the rare company that truly has this level of insight. Simulation asks, “What will happen if …” whereas current process analysis asks, “What really happens today?” There is little value to be had in addressing the former question if one cannot answer the latter.
Today's world of latent reporting and information, such as batch reports once per week, has created a comfort zone of lax responsiveness by the accountable and responsible personnel in large corporations. Having access to real-time information and corresponding metrics would beg the questions, "Do I want more real-time, up-to-date information to make decisions? What would I do with this real-time information if I had it readily available?”

The best-run companies not only have outcome-based performance measures, as is typical with most business intelligence (BI) tools, but process-based performance measures. They use BPM to identify what needs to be measured throughout the course of the process, whether it is cycle time, volume, variability and so on. And, just as important, they use this real-time process information to pick up the pace and effectiveness of decision making, essentially resetting the metronome of their organization to a faster tempo – not more work, but more productive work.
Process Improvement with BPM: Discerning Baseline and Exceptional Process Behavior
The vast majority of companies, to the extent that they document their business processes at all, use tools such as Visio or PowerPoint to create visual depictions of processes. Because they are merely pictures of the process, and lack any link to the actual systems that comprise the process, they tend to become obsolete and forgotten.

BPM changes this. BPM establishes this vital link between business and IT. BPM establishes process standards and defines key performance measures. But, regrettably, this is where most BPM deployments leave off. And while there are substantial benefits in doing this – faster deployment of new applications and more efficient reuse of existing capabilities – let’s take this to the next step.

What if companies could not only monitor business processes as they are happening, but also learn what is normal, learn what exceptions (or defects, if you will) re-occur? In short, what if businesses could develop a clear picture of baseline behavior and identify patterns of defects or unusual activity? In many – if not most cases – this is far more valuable information than simply simulating what may occur.

Companies are clamoring for improved visibility into their supply chains. This used to mean visibility into things like current inventory balances or having a consistent financial view of what is going on. ERP has largely solved that problem. What large-scale ERP implementations have not solved, but what BPM can solve, is precisely this view into how processes are executed and where exceptions exist. Companies today are drowning in exceptions, and lack the tools to extricate themselves from this sinkhole in a timely, cost-effective way.

Let’s consider two examples where such visibility from BPM can aid process improvement.
First, look at a typical order–to-cash process. To keep it simple, assume there are two basic tiers of customers: a select few strategic customers (perhaps five to 10 that account for 60 percent or more of sales) and then the rest. Does the company have one order-to-cash process or two? What is the business willing to do differently for the strategic customers that it wouldn’t do for the rest? Once the basic strategy in this regard is set, it is important to monitor how the company is actually doing in serving these different customers, and how they behave during the process. Do the non-strategic customers call as often as the strategic ones? What about changes to existing orders? It is important to ensure that non-strategic customers aren’t receiving services for which they have not paid, which requires a deep understanding of ordering and payment patterns. Thus, with BPM, businesses can define an order-to-cash process that is largely the same for all customers, but which has two unique paths for strategic vs. non-strategic customers that might involve more hand-holding for the former and more self-service options for the latter.

Next, let’s consider an OEM that uses contract manufacturers and wants to ensure that service levels are being met. BPM can be used to define a cross-organizational process that can be monitored from start to finish. One of the key concerns companies have with outsourcing is fear that the outsourcing partner is a “black hole” into which the company outsourcing has little visibility. With BPM, along with the proper B2B integration capabilities, the OEM can largely eliminate this fear, and monitor the contract manufacturer’s performance in real time.
Done correctly, BPM can become the rallying point for the alignment of IT and the business. This means thinking about BPM not just as a tool, but as an approach that helps to create a true process-oriented architecture. BPM serves as a disciplined way to rapidly design and deploy new processes, ultimately aiding in continuous process improvement.

About The Author(s)


Richard Douglass
With twenty years of experience in supply chain management and operations, Richard Douglass joined webMethods as director overseeing the high-tech and discrete manufacturing sectors for the company’s Global Strategic Business Solutions group. Previously, he was a principal consultant for Manufacturing Associates, and an associate partner at Accenture, a global consulting firm.

Business Process Management Notation: Java Graphic Implementation for Today’s BPM World

By Eric Durocher April 13, 2007

Defining any business process today involves two groups of people, the user who identifies what the process must achieve, and the developer who implements the process. Graphical displays are, and have been, a great tool to help this collaboration. It’s much easier to discuss and exchange information using a diagram than a textual representation. Graphical displays are also essential to provide a quick, intuitive feedback on process application monitoring. With the continued growth of the BPM market, vendors realize they must provide a graphical process notation that’s intuitive enough for users, yet powerful enough for developers and technical users to define implementation details. Enter Business Process Management Notation (BPMN), the most promising attempt at defining such a notation. BPMN diagrams look familiar enough to users, but also carry many implementations and advanced diagramming details in the form of graphical annotations and symbols that are necessary for developers. Examples of such advanced diagramming capabilities include complex graphic objects with dynamic decorations, hierarchical swim lanes, expandable and collapsible sub-graphs, and automatic node and link layout. This article explains the tools that are essential in the implementation of BPMN, including data model mapping, composite graphics, styling, sub-graphs, and graph layout. The application illustration will show that implementation of BPMN is difficult and costly to achieve by using the standard Java2D Application Program Interface (API). BPMN solution developers will greatly benefit from the use of powerful tools such as graphic toolkits or diagramming components. Introduction to BPMN The goal of BPMN is to define a standard way to represent BPM diagrams. Figure 1 shows a BPMN diagram; it’s essentially composed of elements representing the tasks, events, and gateways of the process. Tasks have a rectangular border with rounded corners, and contain a label and optional markers showing some properties of the task, like the fact that a task is a loop, for instance. Events have a circular border, which can be a single line, a double line or a thick line, depending on the type of the event. Events also contain an icon that depends on the event type. Gateways represent the “test” points of the process and have a diamond shape. All these elements are connected by flow objects representing transitions or messages between elements of the process. BPMN processes can optionally be organized in pools and lanes: These are rectangular areas that represent logical organization units such as a company or department. BPMN defines other objects, but we won’t describe them here. You can find more information and the latest version of the specification on the BPMN Website. Implementing BPMN in Java Implementing BPMN is a typical situation where software architects face the choice between a homemade solution and external tools. You might decide the Java platform has all you need in terms of graphic functionality to display BPMN diagrams. The Java2D API provides a rich set of drawing features, so why would you need something else? But displaying BPMN diagrams isn’t just drawing shapes and lines on the screen; it involves several techniques and tools that aren’t provided by the Java platform. This is why your BPMN integration will be greatly eased by using an external graphic library. There are two kinds of graphic tools: - Graphic toolkits provide APIs that supplement the basic Java2D drawing APIs and implement a higher-level, object-oriented layer. With a graphic toolkit, you create graphic objects such as rectangles, text or lines. Once these graphic objects are created, the toolkit handles all the background tasks of drawing the graphic objects on the screen, repainting them when necessary (such as when the user scrolls the window or when the application is de-iconified), maintaining the data structures needed to know what object the user clicks in, etc. - Diagramming components go one step further than graphic toolkits. A diagramming component plugs directly to your application’s data and displays it graphically as a diagram, so you need not worry about any graphic API or objects. You need only create and modify your data model; the diagramming component automatically updates the graphic view. We’ll explain how these three strategies (direct use of Java2D, graphic toolkit, and diagramming component) compare in terms of development effort and design. For this, we’ll examine some key features needed to represent and manipulate BPMN diagrams: - Creation and management of the graphic view - Styling - Definition of composite graphic objects to represent BPMN processes, tasks and events - Representation of sub-processes using nested graphs - Automatic layout of diagrams. Here, we consider only pure Java options, so we won’t discuss other implementation choices such as the Eclipse/SWT platform or the .NET platform. Mapping the Data Model to Graphic Objects A BPMN diagram is basically a graph: tasks, events and gateways are the nodes of the graph, and flow objects are the links that connect the nodes. All applications must represent this graph structure in memory. The BPMN standard defines the types and properties of all the BPMN elements and flow objects. Even if the precise implementation of each object is left to each application, all implementations of this BPMN business model are essentially equivalent and the different strategies will only affect the way this business model is translated to a graphic representation. If you choose to use the Java2D API directly to implement BPMN in your application, you must traverse your data model each time the graphic view has to be repainted and issue the necessary Java2D drawing calls to represent each object of the data model. This represents an important development effort, given the number of different object types and combinations of BPMN. In addition, if the data model changes dynamically, it’s difficult to know which part of the drawing has to be repainted, so it’s likely you’ll have to repaint the whole diagram even if the change really affected only a small part of the graphic view. Using a graphic toolkit, you’ll create the graphic objects representing the various BPMN elements and add them to the graphic view container. For each BPMN object (task, event, and so on), you must choose the appropriate graphic object provided by the toolkit (rectangle, circle, and so on), and set its graphic attributes to match the representation defined by the BPMN standard. This is typically done once, when the diagram is loaded. The graphic toolkit then automatically paints these graphic objects on the screen when necessary. Note that you must maintain a mapping between the BPMN business objects and graphic objects because when the state of a BPMN object changes, you must update the corresponding graphic object according to the new state. A diagramming component automatically handles this mapping of the business model to the graphic representation. To plug the diagramming component to your BPMN business model, you must provide two essential pieces of information: - You must write a “bridge” (or connector) that tells the component the nodes and links of the diagram. For BPMN, the nodes will be tasks, events and artifacts, and the links will be the flow objects that connect tasks and events. Writing the bridge is usually a small development task compared to the advantages it brings. - You must also tell the diagramming component how to graphically represent the BPMN elements. This piece of information is called the graphical style. Once the bridge is written and connected to the BPMN business and the styling information has been supplied, the application can forget all about the graphic view. All it must do is create and modify the BPMN business model; the diagramming component will handle all the painting, updating and synchronization tasks necessary to display the diagram in the graphic view. Styling The BPMN specification defines precisely many aspects of the graphic look of BPMN elements. Tasks must be represented by a round rectangle, events must have a circle border and each message type must be represented by a specified icon, and so on. There’s still some freedom, though, to modify this basic, mandatory look to suit each company’s individual needs. For example, BPMN leaves the application developer free to use color instead of black lines, or to place additional icons to identify custom tasks. Styling is a common technique to do this. For example, in the Web world, style sheets are configuration files that define the look of HTML pages by associating fonts, colors and other graphic attributes to HTML elements. Since the style sheet is a configuration file that’s kept separate from the HTML contents, this technique makes it easy for users to modify the look of the page without modifying the HTML document itself. Considering an implementation of BPMN using direct Java2D calls, styling makes no real sense. Since the BPMN objects are drawn directly, using hard-coded Java2D API calls, there’s no realistic way to apply any styling at this stage. Graphic toolkits may or may not support styling as an option. If styling isn’t supported, you must implement it on your own if you want to provide a way to customize some aspects of the look of the BPMN graphic view. For example, the style sheet could be a simple Java property file containing key or value pairs such as: Task.Border.Color : blue. The code that creates the graphic objects would then read this styling information and set the properties of the toolkit objects accordingly. A diagramming component generally provides native support for styling, in one way or another, because the mapping of the data model to graphics must be customizable. For BPMN, two levels of styling should be defined: - The standard BPMN style reflects the BPMN specification. It tells that tasks are represented by a rectangle with rounded corners, that the name of the task is displayed as a label inside the rectangle, and so on. For BPMN, the full styling information is fairly complex, so it’s likely you’ll rely on the vendor of the diagramming component to provide this. - A second (optional) level of style can specify additional graphic information such as colors, fonts, custom icons, and so on. You can use this style to differentiate your BPMN application from other vendors or to define custom objects types. For example, if your application uses a special type of BPMN tasks, you can add your own icon to differentiate these tasks. Composite Graphics Nearly all BPMN elements are composite objects. For example, a BPMN task is, at a minimum, a composition of a rectangle and a text label. Depending on the task type or state, it can contain other elements such as marker icons for loops, parallel tasks, and so on. The end user sees composite graphic objects as one element of the diagram; they can be selected and moved as a whole. But, on the implementation side, they require a strong composition model that can assemble elementary graphic objects into complex ones, and that knows how to place the elements, one relative to the other. In a pure Java2D approach, as usual, you’re on your own. Given a BPMN element to paint, your code has to compute the geometry of each graphic primitive. For example, to draw a BPMN task, you must determine the position and size of the task on the screen, draw the round ed rectangle shape, then compute the position of the text label relative to the border, draw the text, and so on. This is a tedious job, and it doesn’t allow any easy adjustments without modifying the drawing code. Graphic toolkits and diagramming components generally provide some kind of support for composite graphics. Simple tools let you add custom graphic objects that you define through the tool’s API, while more advanced tools let you define complex graphic objects without programming. An important feature to define advanced composite graphic objects is the ability to specify the layout of the composite object. For example, to add an icon to a custom BPMN task defined by your BPM application, you could say the new icon must be placed on the upper-right corner of the task’s boundary. Sub-Processes and Nested Graphs BPMN processes can be nested. A BPMN process can contain a task that’s handled by a sub-process, which can itself contain other sub-processes, and so on. When translating a nested BPMN data model to graphics, nested sub-processes will be represented as nested graphs. Nested graphs are known to be a complex problem in graphic programming. Every access or modification to the graph must take the nesting level into account, and if this isn’t done properly, it might cause performance problems because nesting leads to highly recursive algorithms. There’s no doubt you’ll face these problems while implementing BPMN, using a pure Java2D approach, so the sub-process functionality alone will be an important part of the overall development effort. Most graphic toolkits and diagramming components support nested graphs, so using one of these two approaches will help you handle this problem more easily. In addition, graphic tools often provide advanced functionality such as the ability to expand and collapse sub-processes interactively: This feature makes it much easier to view or edit BPMN processes by hiding the details of individual sub-processes while viewing or working at the top-level process. Automatic Layout Automatic layout is another feature that graphic toolkits or diagramming components provide and that’s essential to improve the usability of a BPMN solution. Automatic layout algorithms fall in two classes: - Node placement algorithms will automatically compute the positions of the nodes, according to the structure of the graph. - Link routing algorithms compute the shapes of the links to prevent links from touching or crossing nodes and to minimize the crossings between links. Link routing algorithms can also reshape links into a sequence of orthogonal segments. Graph layout algorithms are typically used for BPMN diagrams (such as the “hierarchical layout” algorithm); they’re complex algorithms that require in-depth knowledge in graph theory, so graph layout is another critical area where developers will save big development efforts by choosing a graphic toolkit or component as opposed to a “homemade” Java2D approach. Conclusion The BPMN standard is a promising attempt at defining a graphical notation for a business process; integrating BPMN views and editors is becoming an important added value for any BPM solution. The development effort required can be dramatically reduced by the use of a third-party graphic product. Graphic toolkits handle all the low-level painting and drawing tasks as well as features such as nested graphs or automatic graph layout. Moreover, diagramming components automatically handle the connection and synchronization between your BPM data model and your graphic views, so using a diagramming component will significantly reduce the development time. Given all the importance of a powerful graphic tool for the integration of BPMN in BPM solutions, out-of-the-box support for BPMN will become an important differentiator for graphic tool vendors.
Eric Durocher has a Ph.D. in Computer Science and is principal architect for ILOG. He leads the ILOG JViews Diagrammer development team, which includes Stéphane Lizeray and Soyhy Lim, key developers for the JViews BPMN module.

About The Author(s)

Eric Durocher
Eric Durocher has a Ph.D. in Computer Science and is principal architect for ILOG. He leads the ILOG JViews Diagrammer development team, which includes Stéphane Lizeray and Soyhy Lim, key developers for the JViews BPMN module

Redesigning BPM

What is Business Process Redesign?

Business Process Redesign is "the analysis and design of workflows and processes within and between organizations" (Davenport & Short 1990). Teng et al. (1994) define BPR as "the critical analysis and radical redesign of existing business processes to achieve breakthrough improvements in performance measures."


How Does BPR Differ from TQM?

Teng et al. (1994) note that in recent years, increased attention to business processes is largely due to the TQM (Total Quality Movement). They conclude that TQM and BPR share a cross-functional orientation. Davenport observed that quality specialists tend to focus on incremental change and gradual improvement of processes, while proponents of reengineering often seek radical redesign and drastic improvement of processes.

Davenport (1993) notes that Quality management, often referred to as total quality management (TQM) or continuous improvement, refers to programs and initiatives that emphasize incremental improvement in work processes and outputs over an open-ended period of time. In contrast, Reengineering, also known as business process redesign or process innovation, refers to discrete initiatives that are intended to achieve radically redesigned and improved work processes in a bounded time frame. Contrast between the two is provided by Davenport (1993):





Process Improvement (TQM) versus Process Innovation (BPR)
From Davenport (1993, p. 11)
Improvement Innovation
Level of Change Incremental Radical
Starting Point Existing Process Clean Slate
Frequency of Change One-time/Continuous One-time
Time Required Short Long
Participation Bottom-Up Top-Down
Typical Scope Narrow, within functions Broad, cross-functional
Risk Moderate High
Primary Enabler Statistical Control Information Technology
Type of Change Cultural Cultural/Structural



What is a Business Process?

Davenport & Short (1990) define business process as "a set of logically related tasks performed to achieve a defined business outcome." A process is "a structured, measured set of activities designed to produce a specified output for a particular customer or market. It implies a strong emphasis on how work is done within an organization" (Davenport 1993). In their view processes have two important characteristics: (i) They have customers (internal or external), (ii) They cross organizational boundaries, i.e., they occur across or between organizational subunits. One technique for identifying business processes in an organization is the value chain method proposed by Porter and Millar (1985).

Processes are generally identified in terms of beginning and end points, interfaces, and organization units involved, particularly the customer unit. High Impact processes should have process owners. Examples of processes include: developing a new product; ordering goods from a supplier; creating a marketing plan; processing and paying an insurance claim; etc.

Processes may be defined based on three dimensions (Davenport & Short 1990):

. Entities: Processes take place between organizational entities. They could be Interorganizational (e.g. EDI, i.e., Electronic Data Interchange), Interfunctional or Interpersonal (e.g. CSCW, i.e., Computer Supported Cooperative Work).

. Objects: Processes result in manipulation of objects. These objects could be Physical or Informational.

. Activities: Processes could involve two types of activities: Managerial (e.g. develop a budget) and Operational (e.g. fill a customer order).

What are the Myths about BPR Created by the Popular Literature?

The popular management literature has created more myth than practical methodology reengineering. The concept of BPR has been with us since about 1990, however it is widely misunderstood and has been equated to downsizing, client/server computing, quality, ABC, and several other management nostrums of the past several years. Based on interviews and conversations with more than 200 companies, and 35 reengineering initiatives, Davenport & Stoddard (1994) identify seven reengineering myths.

. The Myth of Reengineering Novelty: Reengineering, although about familiar concepts, is new in that these concepts are combined in a new synthesis. These key components have never been together before.

. The Myth of the Clean Slate: Regardless of Hammer's (1990) exhortation: "Don't automate, obliterate!" clean slate change is rarely found in practice. Or, as Davenport and Stoddard (1994) state: A "blank sheet of paper" used in design usually requires a "blank check" for implementation. Hence, a more affordable approach for most companies is to use Clean Slate Design which entails a detailed vision for a process without concern for the existing environment. However, the implementation is done over several phased projects. Also supported by preliminary findings of Stoddard & Jarvenpaa 1995: their findings ran contrary to Hammer (1990): "although reengineering can deliver radical designs, it does not necessarily promise a revolutionary approach to change. Moreover, a revolutionary change process might not be feasible given the risk and cost of revolutionary tactics."

. The Myth of Information Systems Leadership: In contrast to the much touted leadership role, Information Systems (IS) is generally viewed as a partner within a cross- functional team that is generally headed by a non-IS project leader and a non-IS business sponsor who have better control over the processes that are being redesigned.

. The Myth of Reengineering vs. Quality: Unlike Hammer & Champy's (1993) call for all out "radical change," most companies have a portfolio of approaches to organizational change including reengineering, continuous improvement, incremental approaches, and restructuring techniques.

. The Myth of Top-Down Design: The implementation and execution of the redesigned processes depends upon those who do the work. Hence, the participation, and more importantly, acceptance and ownership, at the grass roots level is essential for successful BPR.

. The Myth of Reengineering vs. Transformation: BPR is a process that contributes to organizational transformation (OT), however it is not synonymous with transformation. OT is defined as, "Profound, fundamental changes in thought and actions, which create an irreversible discontinuity in the experience of a system" (Adams 1984). OT is generally about the emergence of a new belief system and necessarily involves reframing, which is a discontinuous change in the organization's or group's shared meaning or culture. It also involves broad changes in other organizational dimensions besides the work processes: such as organizational structure, strategy, and business capabilities.

. The Myth of Reengineering's Permanence: Davenport & Stoddard (1994) speculate that reengineering has peaked in the US in 1994 and would probably become integrated with much broader organizational phenomena: such as another synthesis of ideas that includes the precepts of reengineering; its integration into existing change methods; or its combination with quality and other process-oriented improvement approaches into an integrated process management approach.

What is the Relation between BPR & Information Technology?

Hammer (1990) considers information technology (IT) as the key enabler of BPR which he considers as "radical change." He prescribes the use of IT to challenge the assumptions inherent in the work processes that have existed since long before the advent of modern computer and communications technology. He argues that at the heart of reengineering is the notion of "discontinuous thinking -- or recognizing and breaking away from the outdated rules and fundamental assumptions underlying operations... These rules of work design are based on assumptions about technology, people, and organizational goals that no longer hold." He suggests the following "principles of reengineering": (a) Organize around outcomes, not tasks; (b) Have those who use the output of the process perform the process; (c) Subsume information processing work into the real work that produces the information; (d) Treat geographically dispersed resources as though they were centralized; (e) Link parallel activities instead of integrating their results; (f) Put the decision point where the work is performed, and build control into the process; and (g) Capture information once and at the source.

Davenport & Short (1990) argue that BPR requires taking a broader view of both IT and business activity, and of the relationships between them. IT should be viewed as more than an automating or mechanizing force: to fundamentally reshape the way business is done.

Business activities should be viewed as more than a collection of individual or even functional tasks: in a process view for maximizing effectiveness. IT and BPR have recursive relationship. IT capabilities should support business processes, and business processes should be in terms of the capabilities IT can provide. Davenport & Short (1990) refer to this broadened, recursive view of IT and BPR as the new industrial engineering.

Business processes represent a new approach to coordination across the firm; IT's promise -- and its ultimate impact -- is to be the most powerful tool for reducing the costs of coordination (Davenport & Short 1990). Davenport & Short (1990) outline the following capabilities that reflect the roles that IT can play in BPR: Transactional, Geographical, Automatical, Analytical, Informational, Sequential, Knowledge Management, Tracking, and Disintermediation.

Teng et al. (1994) argue that the way related functions participate in a process - - i.e., the functional coupling of a process -- can be differentiated along two dimensions: degree of mediation and degree of collaboration. They define the Degree of Mediation of the process as the extent of sequential flow of input and output among participating functions. They define the Degree of Collaboration of the process is the extent of information exchange and mutual adjustment among functions when participating in the same process. In their framework, information technology is instrumental in Reducing the Degree of Mediation and Enhancing the Degree of Collaboration. Also, innovative uses of IT would inevitably lead many firms to develop new, coordination-intensive structures, enabling them to coordinate their activities in ways that were not possible before. Such coordination-intensive structures may raise the organization's capabilities and responsiveness, leading to potential strategic advantages.

What is the Role of the IS Function in BPR?

Although, BPR has its roots in IT management, it is primarily a Business Initiative that has broad consequences in terms of satisfying the needs of customers and the firm's other constituents (Davenport & Stoddard 1994). The IS group may need to play a behind-the-scenes advocacy role, convincing senior management of the power offered by IT and process redesign. It would also need to incorporate the skills of process measurement, analysis, and redesign. The CIGNA IS group had to develop a new set of basic values that reflected a change in focus from technology to a focus on business processes and results (Caron et al. 1994). The specific business divisions led the BPR initiatives; IS groups served as partners in enabling the radical changes.

Is there a BPR Methodology?

Davenport and Short (1990) prescribe a five-step approach to BPR:

. Develop the Business Vision and Process Objectives: BPR is driven by a business vision which implies specific business objectives such as Cost Reduction, Time Reduction, Output Quality improvement, QWL (Quality of Work Life)/Learning/Empowerment. (cf: Shared Vision of Senge 1990, Ikujiro & Nonaka 1995).

. Identify the Processes to be Redesigned: Most firms use the High- Impact approach which focuses on the most important processes or those that conflict most with the business vision. Lesser number of firms use the Exhaustive approach that attempts to identify all the processes within an organization and then prioritize them in order of redesign urgency.

. Understand and Measure the Existing Processes: For avoiding the repeating of old mistakes and for providing a baseline for future improvements.

. Identify IT Levers: Awareness of IT capabilities can and should influence process design.

. Design and Build a Prototype of the New Process: The actual design should not be viewed as the end of the BPR process. Rather, it should be viewed as a prototype, with successive iterations. The metaphor of prototype aligns the BPR approach with quick delivery of results, and the involvement and satisfaction of customers.

BPR: All or Nothing?: Insights from CIGNA

At CIGNA BPR meant "breakthrough innovation focused on customer needs" (Caron et al. 1994). BPR was essentially driven by the senior management's strategic planning process that had concluded that the mix of business in its portfolio needed to change. It was viewed as a vehicle to realign strategy, operations, and systems to deliver significantly increased financial results. Caron et al. (1994) argue that the real life story of BPR at CIGNA represents a contrast to the general prescriptions of "radical" "all-or-nothing" organizational transformation. At CIGNA, BPR started out as an experimental pilot. The knowledge from the success of this initiative was disseminated for implementing other BPR projects. The BPR initiative was sustained "from the bottom up, with learning transferred "across."" At CIGNA, the prerequisite for BPR success was a corporate environment that promotes learning, especially learning from failure. Although, the process was initiated from the top, the ownership was moved down to the people who actually had to implement the changes and were affected by those changes. The BPR effort took into consideration the differences in management cultures in different countries. The BPR initiative started at the operational levels and was later moved to "higher forms" (strategic) of reengineering over time.

Why BPR Projects Fail? What Can be Done about it?

70% of the BPR projects fail. Biggest obstacles that reengineering faces are: (i) Lack of sustained management commitment and leadership; (ii) Unrealistic scope and expectations; and (iii) Resistance to Change.

Based on the BPR consultants' interviews, Bashein et al. (1994) outline the positive preconditions for BPR success as: Senior Management Commitment and Sponsorship; Realistic Expectations; Empowered and Collaborative Workers; Strategic Context of Growth and Expansion; Shared Vision; Sound Management Practices; Appropriate People Participating Full-Time (cf: CIGNA: BPR as a way of life); and Sufficient Budget. They also identify negative preconditions related to BPR as: The Wrong Sponsor; A "Do It to Me" Attitude; Cost-Cutting Focus; and, Narrow Technical Focus. The negative preconditions relating to the Organization include: Unsound Financial Condition; Too Many Projects Under Way; Fear and Lack of Optimism; and, Animosity Toward and By IS and Human Resource (HR) Specialists. To turn around negative conditions, firms should: Do Something Smaller First (CIGNA's pilot); Conduct Personal Transformation (CIGNA's change of mindset); and Get IS and HR Involved (CIGNA's CIO initiated the change and HR factors were given due emphasis).

King (1994) views the primary reason of BPR failure as overemphasis on the tactical aspects and the strategic dimensions being compromised. He notes that most failures of reengineering are attributable to the process being viewed and applied at a tactical, rather than strategic, levels. He discusses that there are important strategic dimensions to BPR, notably, Developing and Prioritizing Objectives; Defining the Process Structure and Assumptions; Identifying Trade-Offs Between Processes; Identifying New Product and Market Opportunities; Coordinating the Reengineering Effort; and, Developing a Human Resources Strategy. He concludes that the ultimate success of BPR depends on the people who do it and on how well they can be motivated to be creative and to apply their detailed knowledge to the redesign of business processes (cf: Davenport & Stoddard 1994, Markus et al. 1994).

Where is BPR Headed?

Over the last few years, the reengineering concept has evolved from a "radical change" to account for the contextual realism (Caron et. al 1994, Earl 1994), and to reconcile with more incremental process change methods such as TQM, towards a broader, yet more comprehensive process management concept (Davenport 1995).

Based upon a theoretical analysis and survey of literature relevant to reengineering, Kettinger & Grover (1995) outline some propositions to guide future inquiry into the phenomenon of BPR. Their propositions center around the concepts of knowledge management, employee empowerment, adoption of new IT's, and a shared vision. Earl et al. (1995) have proposed a "process alignment model" that comprises four lenses of enquiry: process, strategy, MIS (Management Information Systems, and change management and control, and used it for developing an inductive taxonomy of BPR strategies. Malhotra (1996) has developed the key emphasis on these issues based primarily on an integrative synthesis of the recent literature from organization theory, organization control, strategy, and MIS.

King (1994) believes that although the current fadism of BPR may end, however, process reengineering, in some form or known by some other name (cf: Davenport & Stoddard 1994) would be of enduring importance.

LATEST ARTICLE ON BPM

Two Out of Three Ain't Bad - Business process management takes aim at the triad of business change
Darwin Magazine


What if, at the conclusion of a meeting between the senior executives of two companies, the new alliance they had just formed could be implemented within days after each side returned to their respective offices? What if the world's most common excuse — "The IT department says it will take 18 months to implement" — was no longer heard?

Agility has been on the agenda of companies for quite some time, but inflexible technology and the lack of an ability to manage business processes has hampered efforts to achieve it. Now, however, it's time to remember the venerable proverb: "Be careful what you wish for, because you just might get it." [link to article]


BPM’s Underpinning: The Pi Paradigm
ebizq.net

BPM is rapidly proving popular, since it gives businesspeople control over the processes that make their companies tick. And it doesn’t hurt a bit that BPM is a winner in the ROI arena, according to BPM experts and champions Howard Smith and Peter Fingar. At the very heart of BPM is “an obscure mathematical theory” called Pi Calculus, literally an award-winner. Here, Smith and Fingar explain what Pi Calculus is, and how it forms the foundation for the hot phenomenon known as BPM: [link to article]

BPM's Third Wave
BPTrends.com

The first wave of business-process management, outlined in Fredrick Taylor's theory of management in the 1920s, suggested that processes were implicit in work practices, tucked away in policy manuals. Process management was called "methods and procedures analysis."

The second wave, ushered in over the past decade, suggested that processes could be manually reengineered through a one-time activity. Changes were made, but essentially cast in concrete in software, such as the feature-rich but rigid ERP applications. Even with document-centered workflow added to financial-management systems, for example, these applications rarely gave business managers full control over the process life cycle.

The third wave of BPM enables companies and workers to create and optimize new business processes on the fly. Change is the primary design goal. Through agile business processes, value chains can be monitored and continuously improved. The third wave is not business-process reengineering, enterprise application integration, workflow management, or another packaged application-it's the synthesis and extension of all these technologies and techniques into a unified whole. The third wave of BPM becomes a new foundation upon which to build sustainable competitive advantage. [link to article] [download as PDF]

IBM and Microsoft Messing with Process Standards?
ebizq.net

Consider carpentry as a field of human activity. “Hammering,” “sawing,” “screwing,” and “measuring,” using “hammers,” “saws,” “nails,” “screws,” “screwdrivers,” “glue guns,” “levels,” “measuring tapes,” and “carpenter’s pencils”: these words form a vocabulary describing the operations that can be performed in this field, and the means for carrying them out. Now consider business processes as a field of human activity. Processes, process data, activities, messages, rules, computation, process branching, compensating activities, exceptions, sequences, joins, splits, operations, assignments, transformations, schedules, rules and time constraints: These similarly form part of a vocabulary describing the operations that can be performed in the field of BPM. [link to article]


Don't Bridge the Business IT Divide: Obliterate it!
EAIJournal

This article examines the often uneasy relationship between business and technology and concludes that a new wave of BPM solutions will make talk of a divide appear anachronistic. From now on, BPM is THE enterprise application, while traditional applications will merely play a supporting role. [link to article] [download PDF]

Coordination, coordination, coordination
Darwin Magazine


In his landmark book, Process Innovation, Thomas Davenport defined a process as follows: Simply a structured, measured set of activities designed to produce a specified output for a particular customer or market. It implies a strong emphasis upon how work is done within an enterprise, in contrast to a product focus's emphasis on what. A process is thus a specific ordering of work activities across time and place, with a beginning, an end, and clearly identified inputs and outputs: a structure for action. This definition, although helpful, hardly begins to explain the true nature of collaborative and transactional business processes. At the very least, the word "coordination" is missing. Our definition: A business process is the complete and dynamically coordinated set of collaborative and transactional activities that deliver value to customers. [link to article]

Business Process Management From Now On
ebizq.net

The evolution of IT to what ebizQ columnists Howard Smith and Peter Fingar herald as the era of business process management systems came in distinct, logical steps, each built on the shortcomings of its predecessor. Here, Smith and Fingar trace those steps and in so doing, show why they feel so strongly that this era was worth waiting for. [link to article]

The Third Wave: Where will all this lead?
Darwin Magazine

Change occurs at many levels within an organization. Some change takes place on a grand scale, some on a small scale. Some change is gradual, some radical. Employees come and go, teams morph and take on new roles, existing processes evolve, new processes are introduced and the company responds to the market by honing its products and services to expand its market share. Change is everywhere. [link to article]

Tearing Down 20th Century Stovepipes With 21st Century BPM
ebizq.net

A not-so-funny thing happens when business users try to complete tasks or projects: the very applications created to help them do their jobs, get in the way. That’s because applications are, by-and-large, recluses, isolated from other software. The result? Those same users have to come up with workarounds to circumvent the obstacles put up by the applications, which slows down everyone and thing. Even EAI And B2Bi don’t respond to changing conditions and business processes. The solution, according to Howard Smith and Peter Fingar in their latest column for ebizQ? BPM, which enables the technology to change as needs do, offering the ultimate in helpful flexibility and connectivity. [link to article]


Business Processes: From Reengineering to Management
Darwin Magazine

Over a decade ago, two articles, one published in the Sloan Management Review in June of 1990 by Thomas Davenport and another in the Harvard Business Review in July of 1990 by Michael Hammer, reported on the growing wave of process innovation and radical business process change. Back then, established companies were in uncertain economic times and feeling great pain. They were besieged by better, faster and cheaper competitors from emerging markets. Globalization had been set in motion and there was no turning back—change was brewing but few could envision a solution that did not involve abandoning the past. [link to article]


The Humble Yet Mighty Business Process
Darwin Magazine

This is a column about business processes and their management, the intricate, dynamic, ever-changing manifestations of the economic activity of companies. Today, companies are looking for secrets, skills and tools that will enable them to create and mesh together business processes that are so outstanding that customers will pay to use them, time and time again. [link to article]

BPM’s Third Wave: From Modeling to Management
ebizq.net

In a research note dated December 5, 1997, the Gartner Group identified "Nine Reasons Why IS Organizations Do Not Do BPM." At the time, "BPM" referred to business process modeling rather than business process management. All that has changed. Today, process modeling tool vendors are forming alliances with companies that supply platforms for Business Process Management. [link to article]

BPM’s Third Wave: Build To Adapt, Not Just To Last
ebizq.net

While the vision of business process management or BPM is not new, existing theories and systems have not been able to cope with the reality of business processes - until now. Analysts report that BPM may provide the greatest return on investment of any software category on the market today. BPM gives companies the ability to cut operational costs at a time when the economic downturn makes it increasingly difficult to boost revenues. [link to article]


The Next Fifty Years
Darwin Magazine

For the past fifty years, computers have been seen as "data machines." But the demands of the new business process management are taking IT in another direction.

Back in the 1950s there was the myth of the great thinking machine. Later, the myth of MIS, the management information system, rose up to replace it. The reality, however, is that to this day, computers are record-keeping machines, not management machines. They can take in, chew up and spit out trillions of bytes of data, but where is the management insight, the actionable information needed in context, in real time at all levels of automated and human decision-making? The methods, techniques and mindset of IT today remain fixated on data—on its capture, storage and retrieval.

However, business processes of all shapes and sizes are the focus of management attention today—management wants to overcome the great "business-IT divide" and gain control over business processes. [link to article, or download PDF].

A New Path To Business Process Management - Not Just A Fad
Optimize Magazine - Business Leadership


Don't mistake BPM for the next killer app or fashionable new business theory. It's a foundation upon which companies can depend as surely as they depend on database management. BPM is based in mathematics, including Pi-calculus, the mathematics of computation that underpins dynamic, mobile processes.

On today's battleground for economic growth, corporate sustainability, and process innovation, companies like General Electric, with its Digitization Initiative, are chasing the goal of 100% digitization of front-room—not just back-office—business processes. They're seeking hyper-efficiency and the agility needed to make course corrections in days and weeks, rather than months and years.

Companies that recognize the power of business-process management are arming themselves with capabilities for digitally deploying, managing, and representing processes on a scale previously unimaginable. They are discovering that traditional application development is no longer the prerequisite for process implementation since the BPMS can deploy new process designs in one step, directly and immediately—and include any other applications within the process design if required. [download PDF]


New BPM Book Promises to Obliterate the Business-IT Divide
Computer Sciences Corporation

A revolution in the way enterprises use information technology for competitive advantage is on the horizon, according to the new book Business Process Management: The Third Wave. Co-authored by CSC's European CTO Howard Smith and noted industry expert Peter Fingar, the book details breakthroughs in process management thinking that promise to deliver significant business benefits.

The book describes the past, present and future of Business Process Management (BPM) and states that today a fundamental shift in business infrastructure services is taking place - from stovepipe applications and associated "data processing," to dynamic connected processes and associated "process processing." What this means is that the lag time between management intent and execution will be greatly reduced, as well as enabling the creation and manipulation of a raft of new processes, never before explicitly supported by IT automation. [link to article]

Making Business Processes Manageable
WebServices Journal
What hat has surprised everyone in the last few years is how challenging it has been to actually do e-business. One of the reasons why this is so is that companies have found it difficult to manage their business processes, especially when they stretch across multiple systems, software applications, companies, and countries. That s about to change. [download PDF]


Integrated Value Chain, Here's What You Need to Know
Internet World
The Business Process Modeling Language (BPML) is the next frontier destined to give companies competitive advantage in managaing their value chain relationships. Large companies currently spend more than 30 percent of their IT budgets integrating their business applications under the banner of enterprise application integration (EAI), trying to get their internal act together for yet another step, business-to-business integration (B2Bi). Why are they going to all this effort and expense? They are tying together fragments of their stovepipe applications to create end-to-end, multi-company business processes those activities that bring ultimate value to customers. It is indeed the entire value chain, not a single company, that delivers the goods or services. Value chain management is now clearly recognized as the next frontier for gaining new productivity and competitive advantage. If end-to-end business processes are the focus of internal and cross-company integration, why not deal directly with the "business process" instead of "applications?" [download PDF]


Business Process Management Systems
Internet World
Business process innovation and improvement are now recognized as the paths to huge gains in productivity something companies are desperately seeking in the current down-turned economy. Unfortunately, our current software architectures and application development methods pose technical hurdles that block the execution of the Business Process Management (BPM) vision they simply were not designed to take companies beyond where they are today. Undaunted by current limitations, resourceful business and technology thinkers and doers have been busy charting a new path to productivity and pushing the technology envelope by placing business processes, their representation, and surrounding software architecture on center stage in the world of information technology. [download PDF]


The Next 50 Years: A Brief
Internet World
There is something worng with IT. something dreadfully wrong that goes all the way back to the beginning, to the advent of business computing in the 1950s. For the past 50 years, computers have been data machines providing systems-of-record that record the after-the-fact results of business activity. [download PDF]


The New MBA Curriculum
Internet World
While e-commerce and e-business monikers may have been M.B.A. marketing ploys, the real "e" is e-process. BPM, along with hands-on automated tools and live case studies, should be integrated into the core curriculum, including courses on operations management, managerial accounting, marketing and production management. [link to article]

Business Process Management in the Finance Sector

Leveraging the power of processes for profit

Introduction

It is vital for financial services companies to ensure the rapid implementation of new processes to meet speed-to-market, service quality and compliance requirements.

This has to be done against a background of increased complexity. Financial institutions today combine a wide range of product and service offerings, across banking, insurance and asset management. They operate in global and cross border markets. They have increasingly sophisticated and mobile customer bases. Increased regulatory vigilance and new corporate governance rules have the potential to add new layers of complexity and cost. And there continues to be consolidation, merger and acquisition in the sector.

For all these reasons the effective management of complexity and change is a key determinant of future success. Those who automate and streamline their operations most effectively will gain significant advantage. Integration is now more than ever the key to efficiency, enabling lower transaction costs and increased sales volumes. This is true for capital markets, for retail financial services, and for the corporate sector.

An integrated approach to business processes allows products, processes, systems, data and the applications that underpin them to evolve quickly. Whether it’s providing a loan, setting up an insurance policy, or executing an investment instruction, optimising the sale-to-fulfilment process will always win new business, cement customer loyalty, and reduce costs. Lack of integration across lending, payments and trading, on the other hand, simply presents competitors who are more efficient with a huge profit opportunity.

Integration and process optimisation not only has to extend across the enterprise, but must also embrace third parties who often supply key components of today’s complex, multi-instrument financial products. A mortgage offer for example will typically involve underwriters, insurers, the customer’s bank, credit reference agencies and others, as well as internal approval, accounting, collections, credit control, risk management, commission payment, incentive management, and business intelligence processes. Improve all the connections between all the elements of a transaction and performance automatically improves.

The problem is that established financial organisations still have numerous, disparate, proprietary backoffice systems which cannot keep pace. These limit the capabilities of even the most advanced front-end systems. The remodeling and implementation of new processes to meet the demands of dynamic change are severely constrained.
There are three objectives to aim for:

• driving greater efficiency and value from existing systems and processes

• managing the risks associated with dynamic change

• achieving greater visibility and flexibility across complex operations

In this document we describe an approach to process management which delivers those aims.

We explore an integration layer that leverages the power of the latest business process execution tools, enabling business analysts and application developers to bridge the current process execution gap. We look at how this tool will allow the efficient re-use of existing process components and the applications that support them, to create new, more efficient processes, utilising a free flow of data and collaboration between all internal and external parties to a transaction.

At last financial institutions have a solution that allows them to cater for and anticipate change, allowing far greater operational and marketplace efficiency, while meeting regulatory and governance requirements.

Bridging the process execution gap

Traditional BPM systems have been designed to manage macro-level processes across multiple applications through hard coding or by use of proprietary tools. This involves teams of developers writing code within one application, which hands off the process to another application. So, on the one hand there’s a business analyst doing the actual process design, and on the other hand there’s a development team which undertakes the coding.

Therefore if a persistent difficulty remains there is still a gap to bridge between process modelling and IT provisioning to deliver new processes. No matter how powerful the resources on either side of the chasm, new or modified processes simply cannot be executed quickly enough to meet business need.

Closing this business process execution gap will be a key determinant of future enterprise success, because it supports the crucial ingredients of business velocity and agility.

As a Senior Executive at a leading health insurer recently commented during a conference on the issue:

“With compliance issues and corporate changes, we’re making process changes every four or five weeks.”

Such comments allude to the need for an extended time-frame to move from process design to process execution in order to gain real competitive disadvantage. But as this executive also commented, the execution of processes typically takes months rather than weeks:

“Right now it’s all done by coding. We are under the gun to deliver.”

In capital markets, the need to execute a new or adapted instrument can involve process change deadlines of days or even hours. Being able to assemble the building blocks of a new trade by treating processes such as pricing, settlement, reporting, reconciliation as commodities, allows a fast-moving trading floor to be even more responsive to the requirements of the market.

So making better connections, and closing the process execution gap, is key to every kind of financial service company.

Opening the BPEL conversation

On one side of the chasm there is the business need (and the process to satisfy it) as modeled by the business analyst. On the other side of the chasm is the application development resource needed to deliver a system solution.

The key is to create a conversation between the two sides. For a conversation to make sense you need a common language. The emerging standard for that language of process execution is BPEL - Business Process Execution Language.

BPEL allows an organisation to treat processes and the applications that underpin them as utilities: to define,translate and transpose a business process, and make the applications which Web Services expose available to build a new process. Using the BPEL tools within Oracle Business Process Manager allows an organisation to effectively orchestrate (or manage) Web Services and the integration architecture as a whole. A recent Forrester Research note crystallises why BPEL moves the integration story forward so significantly:

“BPEL will provide not only a way to integrate applications, but also a way to create services from them and put them into business processes”.

Just as HTML allows content to make sense and to be published and used by anyone who has a web browser, BPEL allows processes to make sense, and for new processes to be planned, developed and deployed with exactly the same universal simplicity and ease of use.

As Gartner recently commented:

“BPEL will emerge as the leading industry standard for Web service orchestration and coordination of business processes.”

More for less

For financial service companies with entrenched legacy systems, and departmental silos based around proprietary or highly specialised applications, the opportunity offered by BPEL has one other major advantage: it does not add more software to the inventory.

In fact, it enables the organisation to get more from its existing investment in applications and processes. Not only more value in terms of more process development potential, but more competitive benefit from faster time to market for new products and services through more effective service provisioning. Before we look at how Oracle business process management solutions enable BPEL to deliver on its promise, let’s examine an illustration in more detail.

Example of advanced integration in action

Let’s take the example of a loan procurement application implemented by a company named “AutoLoan.” Through its online portal, AutoLoan offers loans to consumers who apply for financing of used car purchases. The AutoLoan application will leverage several trading partners who provide the actual financing as well as existing information systems and legacy applications for customer information, credit ratings, etc.

In addition, AutoLoan needs the system to support interactions with people, such as customer service representatives.

The standards emerging around Web service orchestration such as SOAP, WSDL, XML Schema and BPEL enable AutoLoan to address their integration and business process management requirements in a vendor independent fashion.

It also makes sense for AutoLoan to build their system with a loosely coupled, service-oriented architecture so that they will be able to get the efficiency of highly integrated systems while minimising the cost, time and resources required to build and maintain them.

Using a BPEL approach allows AutoLoan to model this business process very quickly, connecting together the applications and partners that support it, and to deploy the process directly. They can then test and refine this business process more effectively. Finally using BPEL they can monitor the effectiveness of this process, and draw intelligence from the information running through it. In other words they obtain real time business intelligence to refine the process and validate it.

Note that this example requires both integration of existing functionality and new application development. It incorporates both internet/B2B (business to business) style integration and intranet/A2A (application to application) integration.

Implementing the system requires AutoLoan to integrate disparate developer skills, methodologies and infrastructures into a maintainable application.

The approach - using Web services as a standard service interface and BPEL for process orchestration – works equally well for enterprise-wide intranet-based integration or for collaboration beyond the organisation.

Key issues for financial services organisations seeking to leverage a

process-centric approach

• Extract functionality efficiently using web services

• Reduce the set up costs of new processes

• Bring new services to market as quickly as possible

• Increase standardisation and interoperability

• Enhance application reliability

• Ensure security

A vision of more effective process delivery

If business analysts can leverage the power of BPEL by operating a dashboard to control activities and create a new business process on their own desktop, they will be more productive and the business will be more agile. If at the same time if a developer can rapidly implement a new service using the building blocks of existing processes which have already been published as web services, or using other components and metadata within the Service Oriented Architecture, they will be able to deliver against demanding time and cost targets.

The challenge for financial services organisations is rapidly leverage their own applications, systems and processes, and also those of trading partners and customers, to bring about business process optimisation.

And as The Web Services Journal recently reported: “Oracle Business Process Manager is a very strong option formeeting this need.”

Oracle BPM supports each stage of the process optimisation lifecycle:

It provides business analysts with a GUI console to model new processes, referencing existing Web Services and applications.

This standard process model can then be run directly on any Application Server using the Process Manager Console. The process can thus be monitored, refined and re-run quickly and effectively

Business Process Management also allows the developer community to manage or ‘orchestrate’ the Web Services already being developed and which are available within and beyond the enterprise. Until now, these have been ‘hard wired’ together using traditional coding techniques.

The benefits are clear:

• Far shorter timescales to delivering and running processes

• Closing the communication gap between the business and IT

• Delivering a single consistent view of the process that both business and developers can understand

• Effectively orchestrating integration between services and applications within the enterprise.

The largest prize is that by adopting this approach to integration, organisations can start to understand their processes and applications far better. They gain visibility of the resources they need, of the efficiency of processes, and of the dependencies and constraints that make or break process effectiveness.

Finally organisations can start to track information flows within transactions and services, responding to events, applying current information to historic overviews, and delivering true real-time business intelligence.

Oracle BPM is the only solution of its kind that is completely application server agnostic: it simply provides a thin management layer above your existing server, minimising the need for new investment in infrastructure.

Conclusion

Success in highly competitive global financial services markets comes to those who are differentiated by virtue of their ability to innovate with new products, services and alliances, characterised by their speed to market, their responsiveness to change, their capacity to reduce costs, their excellence of customer service, and their control of risk and uncertainty.

Process execution underpins all those ambitions.

A process-centric approach to developing the business and its underlying information management systems and applications will pay immediate dividends. Performance will improve. Costs will drop. Profits will rise. Modelling and delivering new or modified processes becomes a single integrated corporate task. This is because there is a common standard language – BPEL – to support a unified conversation between the business need and the business solution. It ensures that delays and costs are slashed, while services and business activities in front and back office are optimised.

Oracle Business Process Manager is a key to winning the benefits of process execution speed and differentiation. Oracle BPM is itself unique. It is a completely open, server-agnostic technology. Unlike every other offering that requires additional infrastructure investment, it links seamlessly with your current web services and SOA approach to accelerate your business, to ensure you lead the pace in a dynamic, fast moving world.

Beyond the Basics: Emerging Web Services Standards for Business Process Management

By Kelli Wiseth

Basic Web services are now able to provide core capabilities such as integration of heterogeneous applications and data, interoperability across disparate platforms, and reuse of business functionality in large part because the standards have matured—and they continue to mature. In addition, the Web Services-Interoperability organization doesn't produce any standards but, rather, codifies the sets of standards produced through OASIS or the W3C and how they should be used. The WS-I publishes guidelines ("profiles"), conformance tests, and other tools to help not only vendors but also Web services implementers ensure that the business services they build will be interoperable with others, regardless of the underlying implementation platform—Java or .NET, for example.

The WS-I's Basic Profile 1.0 (released in August 2003) specifies a set of standards and versions, such as HTTP 1.1, SOAP 1.1, WSDL 1.1, and XML 1.0, as well as usage for a basic Web service. For example, a Web service can make the contract under which it operates available in a variety of ways, but the Basic Profile 1.0 states, "The instance must be described using a WSDL 1.1 service description, by a UDDI binding template, or both." Security and reliability are the next two profiles being developed.

The WS-I is gaining strength, says Gartner's Whit Andrews, and Gartner clients are increasingly turning to the WS-I to help ensure that they create successful Web services. Oracle's Mike Lehmann, principal product manager for Oracle Application Server Containers for J2EE, concurs that Oracle customers and developers are also taking the WS-I seriously.

Furthermore, as basic Web services have taken hold in the enterprise, the demand for higher-order functionality is increasing. "We're starting to see that the more organizations have success with basic Web services, the more they begin to see the need for Web services security, Web services management, BPEL—the higher-level enterprise Web service standards," says Lehmann. "They're getting successful with the basic Web services, and they're ready to go to the next step."

Ultimately, the next several steps will lead to two broad types of process management that are complementary: the intra enterprise notion of "orchestration" and the enterprise-to-enterprise notion of "choreography." Orchestration covers the realm of a private process (or "private workflow") and ties together multiple Web services to build an executable process, typically internal to a company, says Lehmann. For example, a business process for handling a purchase order could require interaction between an inventory system, a credit service, and a shipping service. Choreography operates at a higher, public process level, says Lehmann, and is "tackling how different businesses can define which message exchange patterns they will engage in before implementing the corresponding internal process."

Here are some of the emerging standards that will facilitate or support such scenarios:

Business Process Execution Language (BPEL) is an XML-based workflow definition language, like XML 1.0, XML Schema, and WSDL, that defines a set of constructs for implementing executable business processes that support interaction between Web services—in other words, BPEL is a language for internal process automation (a.k.a. orchestration).

Web Services Composite Application Framework (WS-CAF) broadly encompasses all areas required to handle transactions, including transaction context, coordination, lifecycle, and message delivery. WS-CAF will complement Web services orchestration and choreography technologies, including BPEL (among others), and will also work with existing Web services specifications such as WS-Security and WS-Reliability.

WS-Security was formally approved by OASIS in April of this year and provides specifications for SOAP, X.509, and Username token profiles. Oracle is building a WS-Security implementation into the next release of Oracle Application Server 10g and also integrating it into Oracle JDeveloper 10g and the management console.

WS-Reliability will provide a generic, open model for ensuring reliable message delivery—the ability to guarantee message delivery to software applications (either Web services or Web service client applications) with a chosen quality-of-service (QoS) level for Web services.

Web Services Distributed Management (WSDM, pronounced "wisdom") is a vendor- and implementation-independent management infrastructure designed to treat heterogeneous Web services as manageable resources. A Web services implementation that supports WSDM will provide a set of Web services and operations for configuration, monitoring, and other management tasks.

---

Kelli Wiseth (kelli@alameda-tech-lab.com) is technology director at Alameda Tech Lab and Research Center (alameda-tech-lab.com).