% fortune -ae paul murphy

Normative issues in the Cocoon strategy

I talked yesterday about using a product set like Apache cocoon to centralize document management in big organizations in order to efficiently deliver organization wide document integration services of the kind possible via the Microsoft Office VBA/OLE and related ecosystem components.

Implicit in this is the idea that having a few people working centrally to provide this kind of capability is better than having a lot of people doing the same thing with desktop software. What I want to do today is defend the notion of "better" in that view.

As an example, consider a company with several hundred people in a particular employment classification whose role includes issuing project completion certifications - but management wants to control their workflow so they can really only do this if the project is actually completed.

In the Windows world you would probably do this by embedding "inteligence" in a Word document so each mandatory project phase is represented by a text block and the information for it gets taken from a server when the document is loaded. On completion, therefore, the whole document loads, your user can sign off, and we're all done.

In a Cocoon world I'd do something broadly similar: construct a generic signoff document, populate it from sub-project detail, and, have the last completion trigger final document creation and forwarding to the employee responsible.

There are, however, some striking differences: the Wintel approach is reactive, the Cocoon approach proactive; in the wintel world the "inteligence" is fundamentally embedded separately in each document; in the Cocoon world the "inteligence" is expressed as one script in one place. Most importantly, the Windows process visualizes the user as someone whose primary role involves assembling the document, while the Cocoon process envisages the user's primary role as one of making a judgement on the basis of a completed document.

The wintel approach seems to offer more freedom since the script can be altered or the document changed before or after completion - and, of course, having this stuff filled in automatically certainly looks more efficient than the old way of getting the data on paper and then typing up the completion notice,

In reality, however, most companies doing this lock out user change - and the apparent improvement over manually entering the whole document is real, but a Cocoon user would tell you that the whole business of having the PC assemble the document is a charade perpetuating the illusion that the old, manual, work process continues to make sense despite technology change.

From an organizational perspective it's obviously going to be cheaper to maintain one set of applications scripts. More importantly, however, it's also better - better in the sense of stronger document security, better in terms of more flexible, auditable, and certain policy enforcement, better with respect to business process efficiency, and better in the critical sense that the Cocoon system decision maker is making a judgement about a document unambigiously prepared by a machine, not about a document he is pretending to himself he assembled himself using his own tools on his own desktop.

Think of the difference this way. Originally stuff like this required a staff of juniors and secretaries who prepared the documents for the Boss's signature. In the Windows world the roles those people carried out were gradually subsumed into the software, ultimately leaving the boss to click the keys or buttons simulating the former process before focusing on the sign-off decsion.

In the Cocoon world the juniors and secretaries are gone too, but the boss's hasn't changed: he orginally got a completed document to sign or not sign, and he still just gets a completed document to sign or not sign.

So fundamentally what does this values conflict inherit in saying the Cocoon result is "better" come down to? I think it comes down to who owns the documents and the workflow. If you think the employees own these, then you can defend the desktop software approach as virtualizing the missing employees, but if you grant that the organization owns these then the virtualization is indefensible - meaning that "better" gets defined relative to organizational benefit and the centralized approach wins on all counts.

Paul Murphy wrote and published The Unix Guide to Defenestration. Murphy is a 25-year veteran of the I.T. consulting industry, specializing in Unix and Unix-related management issues.