Doc Or Die

Samuel Driessen recently asked a very sensible question about the D-O-C-U-M-E-N-T checklist that students in my Document Engineering course use to ensure a complete and consistent approach to analyzing case studies:

I was wondering if the order of the checklist mattered? E.g. shouldn't 'user types' be higher up than 'document types'?

The answer is "of course" … but let me explain. I teach Document Engineering as a set of analysis and design phases that yield implementable models of business processes and the documents they produce and consume to carry them out. We depict the sequence of these phases using a diagram that I often call the "snake" because the different activities are portrayed on it as a winding path that takes different modeling perspectives on some domain in order to understand it at conceptual and physical levels.



In practice different phases get more or less emphasis, depending on the management and strategy decisions that shape the project. Top-down or strategic efforts to align business organization and technology make the activities at the beginning of the path more essential. In contrast, bottom-up and more document-driven projects emphasize the phases near the end of the path. But the "snake" is a good view of the generic approach.

1. In the first phase, "Analyzing the Context of Use," business and task analysis techniques establish the context for a Document Engineering effort by identifying the requirements and rules that must be satisfied.

2. In the next phase, "Analyzing Business Processes and Patterns," we apply business process analysis to identify the information exchange patterns needed to carry out the desired processes, collaborations, and transactions in the context of use. These patterns identify documents that are needed, but only generally as the payload of the transactions. The complete specifications for the documents can't be determined without analyzing existing documents and other information sources.

3. During the next phase, "Document Analysis," we identify a representative set of documents or information sources (including people) and analyze them to harvest all the meaningful information components and business rules that apply.

4. In the "Component Assembly" phase we develop a conceptual model that represents the original information sources as well as new sources and arrangements of information required by the people and processes involved in the business.

5. Finally we move from analysis to the task of designing new document models. In the "Document Assembly" phase, we assemble one or more document models from the component model. If possible we reuse conventional or standard patterns to make the model more general and robust.

6. The new conceptual models we have created for processes and documents can be viewed as specifications for generating code or configuring an application that creates or exchanges new documents. These models represent substantial investments in understanding a context and capturing its requirements in a rigorous way, and using these models to implement a solution in an automated or semiautomated manner exploits those investments to bridge the gap between knowing what to do and actually doing it. In the Implementation phase these conceptual models are encoded using a suitable syntax and schema language to support their physical implementation. This is most likely to be XML, but because of the technology-neutrality of the design phase, the document models can easily be implemented as EDI or ASN.1 messages if necessary.

Ideally, the checklist for analyzing case studies would be a mnemonic that would follow the order of activities in the "snake" diagram. But I couldn't think of one. So if we map the D-O-C-U-M-E-N-T checklist to the snake, it looks something like this:



So yes, Samuel, "user types" comes before "document types." But I couldn't think of a word that had U come before D that would help anyone remember that.

Ride the snake!

-Bob Glushko