Sunday, January 28, 2007


Document Case Studies With D-O-C-U-M-E-N-T

I'm once again teaching Document Engineering at UC Berkeley. But this year I decided to begin the course with a few weeks of case studies and news stories to give the students more real-world texture in which to ground the abstract principles and design methods. And in addition, this year I came up with a checklist for understanding and describing the stories to encourage a consistent and complete analysis. I confess it is a little goofy to use the eight letters of DOCUMENT as a mnemonic for eight aspects of a case study, but I still remember these sorts of things from high school and college courses and people believe in mnemonics (See this site for a big collection of them) So here goes.


D -- data types and document types

O -- organizational transactions and processes

C -- context (e.g., types of products or services, industry, geography, regulatory considerations)

U -- user types and special user requirements

M -- models, patterns, or standards that apply or that are needed

E -- enterprises and ecosystems (e.g., trading communities, standards bodies)

N -- the needs (business case) driving the enterprise(s)

T -- technology constraints and opportunities

I think the only one of these that might be unfamiliar is the C for context. I'm using it in the sense developed during the ebXML initiative
. about 2000. In my Document Engineering book with Tim McGrath we explain "Context" in Chapter 8 this way:

The ebXML project proposed eight context dimensions.

These can be envisioned as defining a multidimensional "8-space" or coordinate classification system in which millions of different contexts would be distinguished by their values on each dimension.

We can best explain this idea with an example. Consider an export broker buying aircraft fuel in Japan for shipment to Korea. The documents required in this situation would need information appropriate for contexts such as:

Business Process = Procurement

Product Classification = Aircraft Fuel

Industry Classification = Petrochemicals

Geopolitical = Japan

Official Constraints = Export

Business Process Role = Buyer

Business Supporting Role = Intermediary

Each of these values would have associated with it sets of rules that satisfy the requirements for that context dimension, and taken together they would form the set of requirements for the unique situation defined by all eight dimensions. The ebXML architecture further envisions a repository in which these sets of rules are stored and from which they can be retrieved to assemble the document definition needed for any context.

I don't think this idea of "context 8-space" is workable, but it is useful to think of a "context" as a cluster or pattern of high-level requirements and that's the sense I'm using it as the C in the case study checklist.

In any case, the first assignment in my Document Engineering course this semester requires the students to analyze a case study or news story using the D-O-C-U-M-E-N-T checklist. So we'll see if it works and I might ask them if I can post some of their stories and analyses here so you too can help decide how useful this mnemonic is.

-Bob Glushko

Monday, January 15, 2007


Antonio, Your Ships Are Lost -- Don't Borrow from Shylock!

A recent article in the Wall Street Journal (4 January 2007) titled "Global Shippers Play Catch-Up in Information Age" reminded me of Shakespeare's "Merchant of Venice." Antonio is a successful merchant who wants to help his friend Bassanio impress the beautiful and wealthy Portia. Antonio laments that "thou know'st that all my fortunes are at sea" (Act 1, Scene 1, Line 115) and so he borrows money from Shylock to give to Bassanio, but Shylock' terms are a little extreme – if he's not repaid, he will literally take "a pound of flesh" from Antonio.

Antonio's problem, of course, is that even though "he hath an argosy bound to Tropolis, another to the Indies…a third at Mexico, a fourth for England"(Act I, Scene 2, Line 94) he doesn’t know when he borrows the money from Shylock that all his ships have already been lost at sea.

The WSJ article reports that competitive pressures, "just in time" inventory management, and other mandates for efficiency in global supply chains have forced shipping lines to invest heavily in IT and systems for feeding a continuous stream of information about the location and condition of goods to their customers. These tight supply chains can also be brittle, and problems can propagate far from their origin. A ship's late arrival into one port can cause it to miss the high tide, causing another 12-hour delay that affects later deliveries. This might mean that containers of parts needed at a factory two or three ports down the line won't arrive "just in time" and the assembly line shuts down. But with a couple of days notice, the factory can jiggle production to prevent this from happening.

I mentioned some of this tracking technology in a previous posting about "The Box," but this WSJ story added the new twist that customers can now send messages that respond to the alerts coming from ship containers. For example, the color and ripeness of bananas -- which are green and hard when they are loaded on ships -- depends critically on their storage temperature in transit. The banana buyers can remotely adjust the container temperature if necessary to accommodate changes in the delivery schedule.

Poor Antonio -- if his ships had the new IT and systems that are described in the WSJ story, he would have known that he couldn’t repay Shylock and wouldn’t have entered into such a dreadful contract. Of course, we've all made bets and bad choices that better information would have made seem as foolish when we considered them as they did in hindsight.

-Bob Glushko

Wednesday, January 10, 2007


Disrupting Business Models with Document Assembly

A recent paper by Darryl Mountain in the International Journal of Law and Information Technology (doi:10.1093/ijlit/eal019) argues that document assembly software has the potential to radically disrupt the business models of law firms.

Document assembly software has been around for a pretty long time because the idea is simple -- if a document type has a defined structure into which variable content is poured, "standard" or "conforming" document instances can be created by eliciting that variable content from the "author."

We're all used to this for transactional document types like order forms, where the "variable content" is highly prescribed yet simple, like the name, address, quantities, and credit card numbers we enter in web shopping forms. So "document assembly" as a product category is usually reserved for narrative document types, where the variable content is more likely to be unstructured text that defines terms and conditions for document types like business contracts, wills, and divorces. Document assembly software contains a rules editor, and the logic in the rules then drive an interactive or wizard-like questionnaire that collects the needed content. Companies like HotDocs and Rapidocs are typical examples.

Mountain points out that the cost of creating a legal document depends on the amount of legal expertise embodied in it, so the additional effort to abstract and formalize the authoring process to enable interactive/automated document assembly wouldn't be justified if the document type weren't used often. But the web changes this tradeoff, because now the document type can be made available to vastly more people. We're in a Google-driven web culture where "good enough" free or low-priced services can quickly drive out services of higher cost and quality (anyone used Lexis-Nexis for tracking news lately? -- it is better than Google news but...).

So there's the disruption -- lawyers who bill by the hour have no incentive to become more efficient. And law firms that invest in document assembly and price legal documents according to their value to clients can radically undercut those that don’t adopt document assembly software.

Mountain points out that the only thing saving the "by the hour" document creators is the lack of client awareness of document assembly technology. We are willing to pay renovation contractors by the hour, but we insist that they use power tools and would never hire one who wanted to do things the old, slow, manual way. Eventually people will figure out that their lawyers ought to use computers to assemble documents and make them discard their yellow pads.

-Bob Glushko

This page is powered by Blogger. Isn't yours?