What You Need to Know About Workflow

by Bruce Silver

The editor of Transform Magazine recently asked me to describe the difference between "Web content management workflow" and the workflow used in other forms of enterprise content management, and whether you could use Web publishing workflows to manage other business processes.

The question sent me back ten years to when workflow technology was young and exciting, and the presumed answer to any office productivity problem you might have. In those early days, workflow software was sold as a one-size-fits-all process automation toolkit. On closer inspection, each vendor's offering seemed to be narrowly oriented to a distinct type of business process. Some focused on highly structured high-volume document processing and case management. Other tool kits were designed for ad hoc project team collaboration, and still others were aimed at routine administrative tasks like expense reporting and vacation requests.

All of these tools had in common the same fundamental functional elements of workflow: "routes" (a flow map), "roles" (for task assignment and security) and "rules" (enforcing standard policies and procedures). But were they really interchangeable? Not on your life!

Sure, you could dummy up an insurance claims processing workflow using a collaborative or administrative workflow tool — vendors did it all the time at trade shows — but you couldn't deploy it in a real environment. It turned out that while workflow concepts were broadly applicable, each individual workflow tool really addressed just a narrow class of business processes. In those days, most workflow vendors simply didn't know what they didn't know.

Fast-forward to today. Except for emerging e-business applications, workflow isn't sold as a programmer's toolkit any more. Today, packaged applications handle most common business processes, and workflow is a built-in feature. For example, Web content management is such an application (plus a bit of infrastructure — the content repository). The business process managed by the application is specifically that of maintaining a Web site. It includes content submission, review and revision, approval, notification, page assembly, format conversion and rendition generation, and staging for Web deployment. The built-in workflow functionality is dedicated to that business process. While the application provides common workflow constructs such as queues, rule-based routing, deadlines and role-based access control, it doesn't usually expose them to be used for some other business process.

The business processes managed by traditional document management software, such as technical document publication, is not too different. Instead of the page assembly and formatting used in Web content management, it might have special document assembly requirements, and instead of staging for Web deployment it might trigger some back office business process. At a conceptual level, the steps in the process are quite similar to Web content management.

Even so, seemingly minor differences between these applications can be critically important. In Web content management, for example, the "unit of work" routed by the workflow is a fragment of a page — perhaps just a graphic, or a bit of code — while in traditional document management it is a multipage document. The Web content fragment could be linked into hundreds of different Web pages on the site, and each of those parent pages might have different owners, business rules, formatting requirements, and so forth. Thus, a change in such a fragment could spawn hundreds of parallel page assembly, notification, and review/approval paths in the workflow, one for each Web page that includes the fragment. This effect creates a higher scalability requirement for the Web content management workflow engine than is typically found in traditional document management.

"Document processing," such as that provided by imaging-based case management, represents a third class of content-driven business processes and a very different kind of workflow, including special requirements for queuing and work distribution, mass storage and enterprise data integration. Once custom-developed, today these applications also are being offered as packaged applications, layered on an appropriate document repository and workflow engine.

What's confusing for users is that as content management vendors begin to describe their repositories as "enterprise infrastructure" — embracing the diverse requirements of Web content, revisable documents and production imaging — there is an implicit suggestion that workflow provided by those vendors now also can be used as one-size-fits-all infrastructure. That's simply not so.

While the enterprise infrastructure approach is fine for content repositories, users still need to view workflow as a set of application-specific features, not a single enterprise-wide service layer. Vendors who promise more than that probably still don't know what they don't know.

Bruce Silver (brsilver@earthlink.net) is president of Bruce Silver Associates, Aptos, CA, 831-685-8803. Reports are available at www.brsilver.com.