Taming Virtual Taskmasters
Smartcards Get Smarter
Taming Virtual Taskmasters
Workflow software can help complex business processes run smoothly,
but it is hindered by incompatibilities among brands.
Standards proposed by IBM could simplify operations within, and even between, companies.
By Gary Taubes
BEFORE COMPUTERS, IT might simply have been called a flow chart. It's the path a piece of work follows as it flows through an organization. And we're all familiar with it. Fill out a mortgage loan application, for example, and watch what happens. Your form might first be routed to a clerk, who will make sure you've filled it out properly. If so, it moves on: perhaps to a credit bureau that will look at your credit history, and then -- depending on your credit -- to an engineer who will inspect the property you want to buy. And so it goes, through the entire process, until you finally get that letter saying your application has been approved, or rejected.
This kind of business process used to be done by hand and mail and messengers. Now the business of an enterprise flows between people and computers, and the programs that control the process are known as workflow management systems. They have become ubiquitous in modern organizations, but that's just the beginning. With the growth of the Internet, there is now a demand for work to flow across boundaries, from geographically diverse locations -- for electronic commerce, for instance, and "supply-chain management," in which manufacturers are linked electronically to suppliers, advertisers and customers. To accomplish that, protocols and standards must be developed to allow workflow technologies to communicate and flourish on the Internet.
Last summer, IBM researchers led by Jarir Chaar, manager of the workflow technologies and applications group at the Thomas J. Watson Research Center -- together with colleagues from IBM's software group -- proposed a set of standards that have now become the model for workflow technologies across the Net. With such standards in place, the work of organizations will be able to flow freely, whether it all takes place in one location or everywhere at once. Chaar and his colleagues secured the backing of more than 20 companies for their set of standards, now known as the Joint Flow Proposal.
ISLANDS OF AUTOMATION
When first introduced, workflow systems -- like IBM's own FlowMark® system -- suffered from a common problem of the computer age: virtually every company, if not every department in every company, had its own workflow software. "Each department was an island of automation," says Chaar. "Within the same enterprise, it was not uncommon to see multiple workflow systems on the same floor, all of them incompatible, so that work could not flow between them."
In August of 1993, two dozen of the world's major corporations spurred the formation of a Workflow Management Coalition (WfMC), a nonprofit international organization of workflow vendors, customers and analysts with the charter to address that problem. The WfMC published the reference model for workflow standards, a set of interfaces that would allow different workflow technologies to exchange information and work together within an enterprise. "This model is an architecture that specifies the various major components that a workflow management system needs," says Chaar, "and specifies the interfaces between these components."
To understand how it all works, imagine the workflow management system as a program that governs the business processes of a firm and runs on the firm's network of computers. The management system encompasses a set of tools that will help capture, execute and monitor the business process.
Overall management is the responsibility of a component called the workflow engine that coordinates the flow of tasks to all the parties, both human and computer, that perform the work. Each party is then tied into its own "worklist," which resides on one of the computers, or nodes, of the network. The worklist in turn accesses its assigned tasks through a workflow "client." As work is completed, the workflow engine decides what tasks must be done next, and by whom, and then locates the parties through a directory service.
The problem with the WfMC reference model, says Chaar, is that it is overly complicated. Each workflow engine, for instance, maintains three different types of interactions with its world. There are "push" interfaces, through which the engine will push tasks to other engines; an engine that does mortgage processing might push credit checks off to an engine designed for that purpose. There are "pull" interfaces, through which workflow clients pull their next assignments from the engine. And then there may be "synchronous" or "asynchronous" interfaces, through which the engine might load and execute an application program, such as a word processor, as needed.
These three kinds of interfaces make it easy for a workflow engine to micromanage a business process within a network, but they can be highly inefficient when it comes to working across networks. A client working with multiple workflow engines -- say, a mortgage officer who deals with different loan services -- has to keep connections open with all those different engines. "Imagine if you have to keep 10 windows open on your computer simultaneously," says Chaar. "Not only will it slow down your computer, but it's confusing."
TOWARD A SINGLE INTERFACE
In 1997, yet another coalition of computer companies got into the act. This was the Object Management Group (OMG), consisting of firms selling business "object" technologies. You can think of business objects, says Chaar, as self-contained programs that might include everything needed to perform a certain function, including the workflow system. "For
instance," he explains, "a business object for a mortgage application would involve not just data -- such as the credit report and the results of the engineer's inspection -- but also the methods and programs that are needed to make decisions on when to grant a loan."
The OMG, says Chaar, was in the process of defining how best to create an infrastructure that would support the use of business objects over distributed networks like the Internet, when they realized that workflow was an essential component of business objects. What was needed was new Internet protocols to support that component. So it was that the new Joint Flow
Proposal, led by IBM and supported by 18 other OMG members, came into being. Supporters include DEC, EDS, FileNet, Fujita, Hitachi, Oracle, Siemens and Xerox.
The proposal takes what Chaar calls a "network-centric" approach to workflow. Rather than delegating work through three different interfaces, the new standards allow for one interface. In the new standards, the workflow engine is push only. This makes the world of workflow much like
email is now. It will lessen the load carried by the workflow servers and increase the independence of the workflow engines and the humans that do the work.
"This is essential for interorganizational collaboration," says Chaar. "We can work together, and we have a contract that manages our relationship. But each of us is independent. We like to do our own work in our own way. As long as we comply with the contract, we don't need to micromanage each other's work. In the old way, the server micromanaged everything. Everything else around it was basically dumb." Now the workflow engines just decide what tasks need to be executed and which people can execute them, then push the tasks to those people's worklists.
DOWNLOAD FROM ANYWHERE
"The people connect to the worklist in the same way we connect to our mailboxes," says Chaar. "You get a message in your mailbox during the night, and when you connect in the morning, it's there. Your worklist gets populated whenever you're assigned a task -- and you can download it from anywhere, because you don't have to maintain a connection."
In other words, the new standards will make working at home or in the field a lot easier. "The mortgage company's inspection engineer, while still on the road, can pull his next assignment from his worklist and go straight to that house," says Chaar.
The Joint Workflow Proposal was approved by the Object Management Group in late July. "This shows how quickly theoretical ideas can move from the drawing board to standards, and even to products," says Chaar.
Workflow Team Members: Jarir Chaar, Santunu Paul, Edwin Park, Marc-Thomas Schmidt.
Smartcards Get Smarter
SMARTCARDS, CREDIT-CARD-SIZE devices that store personal information on a small, highly secure silicon chip, have any number of possible uses. But to live up to their potential, the cards must work with a variety of business and consumer devices, ranging from PCs and network computers to point-of-sale terminals and handheld devices. To enable such interoperability, the OpenCard Consortium, an industry working group that includes IBM, has introduced new Java-based middleware called the OpenCard Framework 1.0 reference implementation. Developed at IBM's Zurich Research Laboratory, it is the only smartcard middleware to allow the same Java application to interact with different smartcards through different card readers on a wide variety of platforms.
By providing common and standard interfaces for functions offered by cards and card readers, and by hiding the differences between cards that come from different vendors and issuers, the new framework is lowering the barriers to the wider use of smartcards. The framework also allows cards to be used with readers compatible with the existing Personal Computer/Smart Card (PC/SC) 1.0 standard, which is designed for Windows® and thus lacks the cross-platform benefits of Java.
"Internet-based services in general and electronic commerce in particular will
increasingly depend on smartcards to ensure
authenticity, integrity and privacy," observes
Reto Hermann, a researcher at the Zurich
Research Laboratory. "The need to make such services widely accessible was our main motivation
for developing the OpenCard middleware and making it freely available."
The OpenCard Framework 1.0
reference implementation can be downloaded from http://www.opencard.org.
-- Katherine Silberger
