Workflows and Workflow Management Systems

Information technology is seen as a means by which a business can achieve agility and competitiveness. Although information technology has numerous beneficial effects on a typical enterprise, perhaps the most potent means of applying information technology is to use it to directly manage business processes through workflow management systems.

A workflow management system provides the business analyst with a view of the processes that the business currently operates, and allows the analyst to manage those processes according to the enterprise's business direction and changing market conditions. Under the covers, the workflow system is a dependable (and usually distributed) computing system that ensures the proper flow of information and resources to people or infrastructure that undertakes the actual work.

Workflow systems have been in existence for some time now and have generally served the enterprises in which they have been deployed well, though they have never been widely deployed across enterprises to build the much-vaunted virtual enterprise. The lack of virtual enterprises can be attributed in part to the fact that the underlying technology has failed to deliver the kind of interoperability needed to successfully run such an endeavor. However, with the advent of Web services, the kind of interoperability issues that prevented previous workflow systems from scaling up to inter-enterprise scenarios will disappear and will thus open the opportunity for inter-enterprise workflows.


In the absence of a workflow management system, coordinating the interactions between resources in a business is often a task which an application developer must choreograph. The developer understands which systems need to be controlled by the application and in what order, and writes code accordingly. Once complete, this piece of software constitutes a whole or a part of a business process, and its behavior can (in theory at least) be executed time and again to produce the same result.

While this is fine in a static, unchanging world it is not an approach that adapts well to changing business conditions. The manual development of new application code each time a new business process has to be created, or an existing business process refined, means that a business-level analyst will have to seek the assistance of a software developer to help codify the new scenarios. Even from this common scenario, it is clear that there are business benefits to be had by deploying workflow management systems, and there may be significant penalties in terms of human labor and agility to not deploying those systems.

To alleviate such difficulties and to ensure that business processes can evolve rapidly as conditions change, many enterprises have deployed workflow management systems that business-level analysts can use to create and maintain processes with a business (not technology) focus. When a business process has been captured in a form suitable for processing by a workflow management system, it becomes known as a workflow.

In effect, a workflow management system is a computing system that allows business processes to be automated by encoding them as workflows (adding value in terms of efficiency) and makes it easier to codify rules for when things go wrong (adding value in terms of reliability and ease of management). In the most abstract sense, these workflow systems tie together three orthogonal aspects of enterprises, namely business processes, human resources and information technology as we see in Figure 6-4 below.[1]

[1] Adapted from "Production Workflow: Concepts and Techniques" by Frank Leymann and Dieter Roller, Prentice-Hall 2000.

Figure 6-4. The workflow matrix.


The process logic aspect of the workflow matrix is the codification (in a means suitable for the underlying workflow management system) of the underlying business process into a workflow. This workflow is a logical representation of the physical business process that will be executed to produce some end result (e.g., a motor vehicle, an answered telephone query, a sale of an item of merchandise).

The process layer is supported by the human resource side of the matrix that allocates people to certain aspects of the process, in accordance with the company's organization (which takes into account the availability and skills of its workforce). Individuals with the correct skills and roles for a particular part of a process are selected by the workflow to help perform that part of the process (e.g., a fitter to glaze vehicle windows is allocated during the fit windows part of vehicle assembly).

The third aspect of the workflow matrix is the information technology resource associated with each part of a workflow in our domain, the Web service that provides the functionality for a particular task. This may include almost anything from individual programs (like word processing) required to complete a task the right way to sophisticated computer-aided engineering systems in high-end manufacturing plants.

The union of these three aspects determines the schedule a specific person or persons may use to complete a specific part of the process using specific resources at some time determined by the workflow management system. When we bear in mind that the workflow management system may be coordinating several hundred or even thousands of such tasks simultaneously, we can begin to get an idea of just how complex and robust such systems must be.

Workflow Management Systems Drawbacks

Though it might seem that modern workflow management systems are at the core of many enterprise information systems, there is a downside. Since most workflow management systems were developed before the advent of Web services, each workflow management system tended to be built on proprietary and largely non-interoperable technology.

While this isn't a drawback within the confines of an individual enterprise, if we recall the notion of the virtual enterprise where processes span companies with apparent ease, we begin to unearth a less enticing side to current systems. Given their proprietary nature, and the fact that there are a number of vendors in the market space each with its own distinct offering, it is entirely possible that two enterprises that would like to create a virtual enterprise to execute some business process will find a stumbling block in the integration of their two different workflow management systems. Of course, you will find protagonists of these systems claiming that it can be done using traditional middleware technology and some goodwill and effort on both sides. However, there is no guarantee that this will be economical, since by their very nature virtual enterprises are temporary, and if an enterprise's gain in partnering is overshadowed by its costs in setting up that partnership, then there is a compelling argument to be made against putting the necessary investment in place. If you happen to be a powerful and important enough customer to your suppliers, you may be able to mandate which workflow management system they install and use to ensure interoperability with your own systems. However, this tends to make for long-lived virtual enterprises and may reduce business agility as a result.

Web Services and Workflow

Web services are the industry's prime candidate for enabling interoperability. Given the broad acceptance of Web services standards and their widespread support by vendors, they have become a natural choice for integration work both within and between enterprises. This platform has set the scene for truly dynamic virtual enterprises where partners can interact with one another's systems via standard protocols without having to worry about the underlying (and possibly completely different) systems that implement the functionality.

The notion of running workflows over such an interoperable system is clearly attractive. We can benefit from all of the useful features that workflow management systems provide but gain (compared to traditional workflow management systems) interoperability with pretty much any party that we want to do business with. The computing vendors have themselves been quick to notice this market opportunity and a number of proposed Web services workflow standards have made their way into the public domain, with the front runner being Business Process Execution Language or BPEL from IBM, Microsoft and BEA.

Developing Enterprise Web Services. An Architect's Guide
Developing Enterprise Web Services: An Architects Guide: An Architects Guide
ISBN: 0131401602
EAN: 2147483647
Year: 2003
Pages: 141

Similar book on Amazon © 2008-2017.
If you may any questions please contact us: