A Tale of Two RADs: Parallels in BPM Workflows and Document Automation Templates

At the core of BPM suites is a RAD (Rapid Application Development) workflow engine that enables the translation of real-world business processes into process-driven software applications, commonly referred to as workflows. Put another way, a workflow is an automated business process. Document assembly engines are a different type of RAD having a much more specific purpose: automating the process of gathering matter-specific information and using it to generate a custom document or set of documents. In a real sense, the work product of a document assembly engine—commonly referred to as a document assembly template— is itself a process-driven application. Beyond this basic similarity, though, other parallels exist between workflow engines and document automation engines.

Volatility of Document Assembly and BPM Applications

The catalyst behind all RAD-development engines is volatility. Some types of applications are simply so volatile—meaning they need to be modified so often—that it doesn’t make sense to hard code them in some type of compiled language, such as C++ or C#, both of which have the power and flexibility to handle almost any type of programming task but which also lack the nimble factor inherent to RADs.

Legal instruments, such as contracts, insurance forms, wills/trusts, etc. are notoriously unstable—every time a governing body meets, the laws governing the documents could change. Consequently, hard-coding an application to generate a legal document would be folly, even in a scripting language, such as Visual Basic for Applications (VBA) or Visual Studio for Applications (VSTO), both of which are commonly used to build automation characteristics into MS Word and WordPerfect documents. This reality—the instability of legal documents—gave way to RAD platforms designed specifically to automate legal documentation.

Just as legal documents are unstable, so also are an enterprise’s workflows, which are as fragile as a company’s own internal policies and labor force. For example, a governing board in a bank could decide that it no longer wanted to issue home loans to high risk candidates. This single decision could force the bank to make major revisions to a number of its workflows. Likewise, an employee within the bank, whose involvement with home mortgages is critical, could need to go on emergency leave, requiring all workflow items that would normally come across her desk to be rerouted to someone else’s desk. Just as with legal documentation, the volatile nature of enterprise workflows spawned RAD platforms to simplify the process, a group that includes Metastorm, K2, Pega Systems, Oracle, SAP, and a long list of others.

The bottom line, here, is this: Sophisticated software with a highly predictable, long service life can safely be built in a compiled language. In contrast, volatile applications are best built on a RAD platform.

Simple vs. Complex RAD Applications

Paradoxically, simple process-driven applications (even those that are inherently unstable) could be safely built with a heavy-lifting, compiled language or, possibly a scripting language, such as Visual Basic. For example, a simple MS Word-based non-disclosure agreement having maybe one or two optional clauses could be automated with VBA or VSTO since the resulting template would be very simple to maintain, although deploying even a simple VB template would require the development of significant functionality that would be common to RAD platforms dedicated to document automation Likewise, a simple workflow, involving just two or three easy steps, may safely be hard coded, so long as an enterprise doesn’t mind dedicating a software engineer to the building and maintenance of the workflow. Note that software engineers regularly use RAD platforms. But many RAD platforms, such as workflow engines and document assembly platforms can easily be mastered by non software engineers.

In contrast, complex, volatile applications are best built on a RAD platform. Consider, for example, a sophisticated contract used by a government agency when commissioning road construction. Such an instrument would not only be volatile, but would best be automated by a content expert, rather than a software engineer. Likewise, a large enterprise needing to deploy powerful, complex workflows that would certainly need regular maintenance would certainly be best served by a RAD platform.

Transaction Ready = 100% Automated

While small organizations might be attracted to RAD platforms that bill themselves as “simple” or “easy to learn and use,” large organizations virtually always see simplicity as a siren’s song, the reason being the need to fully automate a process, be it a workflow or the generation of a document set. Take, for example, a global bank having thousands of loan officers generating millions of legally binding documents, many of which could be highly complex. Aside from the time/cost savings of automating the production of such documents, the more compelling issue for such a bank would likely be risk mitigation, which can only come if the bank’s document generation system produces transaction-ready instruments. Put another way, the bank can’t afford to have loan officers or other staff making manual edits to legally binding documentation sets—it’s human interaction that creates exposure.

In the case of workflows, large enterprises are likely to have lengthy, sophisticated processes. A workflow that would accommodate only a percentage of the total cases it needed to handle would fairly quickly be abandoned in favor of the old, un-automated approach, would need to remain in place and functional, given that the automated version isn’t 100% reliable.

“Peas and Carrots”