There are two different workflow models, as follows:
- Process-oriented workflows used to automate processes whose structure is well defined and stable over time, which often coordinate sub-processes executed by machines and which only require minor user involvement (often only in specific cases).
A loan request is an example of a well-defined process, with few hidden surprises. Certain process-oriented workflows may have transactional properties.
- Specific workflows are less directive and are used more to coordinate tasks between users. Their structure is harder to master and may change over time.
In this article we shall be looking most closely at process-oriented workflows, which feature in e-business applications.
The emergence of workflow technology is very closely linked to the history of the electronic imaging industry and computer aided production management. Very early on, this industrial sector realized the advantages that could be gained from automating processes which were hitherto carried out manually and using paper documents. It was the golden age of tools like FileNet or Wang (now Eastman software). But despite the fact that these tools were able to process complex, heavy workflows, market penetration was hindered by their high price tag and complexity, along with the major disruption they caused to the organization of the companies that implemented them. When it came to meeting companies' needs in terms of workflow within e-business architectures, the constraints were simply too great.
- The role of workflow in B2B architectures
The business process is a fundamental notion in e-business architecture. A task (sending a document, triggering a transaction, filling a form…) forms part of the business process with which a workflow is associated, whether the issue is the management of the logistics chain, the marketplace or the exchange of documents between partners. The workflow is made up of tasks which follow routes, with checkpoints represented by rules.
Today, most business processes are automated, but often only partially so. The automation of certain sector-specific processes has been facilitated thanks to the diversity of systems (packaged products, specific developments…) and companies' histories. However, this has made automation of general processes more difficult. Things become even trickier in a B2B context, where integration and security problems are heightened. Overall management of business processes is therefore sometimes carried out manually, which translates into high overheads, slowness, and poor reliability.
There are many workflow tools around, but these are relatively immature when it comes to automating B2B processes. Standards are on the whole stable, whether for infrastructures (J2EE, COM…), middleware (SOAP…), or exchange vocabularies such as RosettaNet or Biztalk.
Process automation can become the focus of specific development, but it is preferable for a tool to be used. Below is a list of important criteria, which must be met by any B2B process automation tool.
- Integration in third-party applications
A business process
is never isolated and is often part of a general application.
From the user angle, the process is managed within an application
context of security and navigation. It is therefore essential
to ensure the workflow tool integrates with the existing architecture,
by opening up its operation in the form of an API.
- Integration with components and middleware The workflow tool for a B2B architecture
coordinates existing sub-processes, which may be components (COM,
EJB…) or middleware (MOM, SMTP for message sending, SOAP or RMI
type RPCs…).
It must therefore be able to integrate existing processes.
The underlying architecture for workflow tools is often an application
server (such as WebLogic Process Integrator, which runs on WebLogic
Server), which is at the forefront of B2B application management.
EAI tools may also form a suitable basis for workflow tools. Their
integration capacities give workflow tools excellent potential
for designing back-office-oriented processes (e.g.: NEON — acquired
by Sybase — EIP, built on a message broker from NEON). However,
the issue of "EAI tool versus application server" for the basic
workflow architecture will become less and less valid, since the
growing tendency is for application servers to integrate their
own EAI tools.
- Visual process development Before a process can be automated, modeling must be carried out. For a workflow tool to be worthy of its title, it must offer a graphical modeling environment to facilitate development and maintenance of workflows by users who are not computer experts. Modeling potential is also a key factor.
- Management of workflow instances The workflow manager must offer a solid environment for deploying and managing workflow instances. The state of a workflow must be persistent in order to handle long-term processes. The workflow manager is subject to the same performance and availability constraints as B2B applications, and reliance on an application server featuring cluster mode is a bonus when it comes to supporting increased workloads and offering good availability. It is also essential to be able to act on workflow instances in order to manage particular cases.
- Management of exchange vocabulary Setting up a workflow engine is the first step in managing B2B processes, so it is important to standardize the vocabulary used for the communication engaged during the process. While XML format would seem to be the most appropriate solution, the choice of definition of XML files (DTD or Schemas) is much more delicate. The alternative solution — defining a proprietary format with one's partners — should be avoided, since it leads to a high level of dependency. The nature of the functional domain concerned is an important focus area if one is to know where to situate the workflow tool. There are a number of initiatives which aim to standardize XML vocabularies so as to prevent too-tight coupling between e-business players. These include:
- RosettaNet, eCO and Biztalk, for industry
- xCBL, for financial transactions and marketplaces
- OBI for purchase management
|
