First things first – I am fully aware that I wrote in my first post of this series that I would be putting out 2 of these per week…and here it is, like 6 weeks later, and I am just now getting to the second post.  I have been sidetracked, at least for the purposes of this series, by revenue-generating (or at least potentially revenue generating) activities.  In fact, if you are a baseball fan, feel free to check out one of my most exciting potentially revenue-generating activities at MLBGeeks.com.  If you are a college basketball fan, you can check out another thing I have been working on, The RPI Bracket.

Enough about my other pursuits – let’s get back to these Implicit Documents, whatever the heck they are.  Just to make sure that we continue on the same path every step along the way, let’s bring up the table of contents from the first post in the series (Step 0 of 10).

• Step 0: Welcome and Outline
• Step 1: Setting the Table – Background Information, Technology Levelsetting and Real-world Applications
• Step 2: High-Level Solution Design
• Step 3: Development Environment Set-up
• Step 4: Data Warehouse and Dimensional Model
• Step 5: Making Time – Working with the Time Dimension
• Step 6: Rapid Application Development in SharePoint – Just an Introduction
• Step 7: Using BDC Columns
• Step 8: Building the Microsoft Word Template
• Step 9: Bringing it All Together – Document Generation
• Step 10: Reporting and Auditing

So, let’s get right into the meat of this post, shall we?

Background Information

For years, I have been dreaming about the concept of a knowledge management paradigm whereby a document consists of nothing more than a series of references or pointers to something smaller than the document itself.  The totality of all of those references makes up the document itself – just a bunch of data points and that’s it. 

Like I said, I have been thinking about this for years, but until I started thinking of it in terms of the 2007 version of the Microsoft Office platform, I would always think of it, sigh and resign myself to the fact that I would never have, or want to have, the 500 hours necessary to code something from scratch.  With all of the integration points of the current Microsoft Office system, it should take a lot less time to show something simple enough that it won’t take forever yet complex enough that it will show the capabilities.

One other item of background information – while this kind of technology has existed for a while, and while people like me have been thinking about it for several years, there is basically one group of people that are currently delaying some of the cool things that technology can provide us in the Knoweldge Management field – and those people are…auditors.  It seems like there is still a reluctance in the auditor community to accept a document that doesn’t really exist.  Until there is a standard software package that can do this will completely validated predicable performance, then the auditors will continue to require something more concrete.

Technology Levelsetting

So, the first thing I would like to address here is – what is an implicit document and how is it different from some of the other things we may have heard about already, like a “virtual document” or a “compound document?”  Let’s accomplish this with some simple definitions.

Virtual Documents.  For the purposes of this exercise, virtual documents are documents that are generated on demand, based on user input.  There is another concept of a virtual document in Documentum, but it is in essence similar to the compound document that will be discussed below…merely a document that can contain other documents.  Virtual documents have existed for quite some time, and basically most of the web pages you ever look at are probably, at least to some extent, a virtual document.  The content in your browser is generated by some code or script that runs on the server, which grabs some content from a back-end database or other source, formats the content and then displays it for you to see.

Compound Documents. Compound docs are normally a “regular text document” that also contains non-text elements, such as spreadsheets, pictures, digital media features, etc.  Well-known technologies for compound documents are Object Linking and Embedding (OLE) from Microsoft and Bonobo by Ximian.  While compound documents are a generally pretty cool concept and the Microsoft Office 2007 system has allowed a great many possibilities, they are just not quite enough in and of themselves, because they are, in terms of what we want to do here, limited by the fact that they are documents that have been already created within a software program, such as Microsoft Word.  Therefore, they contain intrinsic information that cannot be used by other documents, which is not acceptable in this paradigm.

Implicit Documents. Implicit documents are a collection of references to the various parts that make up the document.  Every component of the document is contained elsewhere, referenced by one or more documents in the centralized knowledge management system, and the documents themselves are generated only when required.  Through the use of metadata and robust processes, the collection of information and documents can be integrated tightly.  Take the example of some boilerplate text like a legal disclaimer that is present within 100 different documents within the knowledge management system.  When the legal disclaimer is updated, all 100 documents are updated automatically, merely by having the reference to the boilerplate text in their data structure.  Additionally, if the boilerplate text was deemed to be important enough, within the metadata and the processes, each of the 100 documents could be automatically generated, version incremented to the next major or minor version (such logic also contained in the metadata and processes), and saved in the appropriate repository(ies).

With this concept of implicit documents, there are a few basic rules that we will use as we make our way through the exercise:

1. Implicit documents can contain no intrinsic information regarding document content, only references to external data sources.
2. Implicit documents also contain metadata that will be used to classify the document within the system, as well as sift, sort and shuffle the document in relation to the other documents within the knowledge management repository.
3. The generation of documents will be accomplished either programmatically or through administrator-level access only.

Real-world Applications

Among the myriad of potential real-world applications for this technology is the centralized knowledge management system itself.  Other, smaller applications include:

• Corporate Policies and Procedures Repository.  The same principles of an entire knowledge management system based on implicit document apply, but there would only be a couple of different content types, so there will be a high level of overlap between the documents and items of content.
• Contracts Repository.  Each contract will contain references to all of the appropriate legal boilerplate text, as well as anything specific to the document itself, such as information about the client and the internal business unit assigned to perform the work outlined in the contract.  Using the high level of integration of the Microsoft Office system, the client could be a reference to a centralized CRM system, the business unit could be a reference to a centralized corporate structure (org chart), and the legal boilerplate text could be a link to the officially published versions of such text on the legal department’s internal team site.

Hopefully, this background information has provided you with enough information to see the possibilities.  As we get deeper into the exercise, I am sure that we might come back to revisit this module and add / clarify a few things. 

Please stay tuned for the next installment, where we will present a high-level solution design for our exercise.  While I have not yet decided on the specifics, I am leaning toward building a Corporate Policies and Procedures Repository, as discussed in the “Real-world Applications” section above.