Q: Let's set some context for this discussion about dynamic documents. First, why do documents matter? What's their value in a business setting?
A: Documents are really the standard user experience for a lot of business activities today. Documents are how information is shared and how knowledge is transferred between people. And they have characteristics that make them uniquely suited to many business processes.
First, documents are portable. Among other things, you can attach a document to an email, associate it with a workflow, upload it to a team room, download it locally, or print it. Next, documents are persistent. They exist over a period of time, and they act as a business record.
And probably most important, documents provide very rich context. They bring together disparate pieces of information and make them cohesive--a single consumable artifact that people can understand. They allow information to stand alone.
On the downside, documents tend to be static. They are snapshots in time. The information contained within a document is typically a static version of dynamic information. So, what you see when you open a document is not necessarily the most authoritative version of the truth.
Q: What exactly do you mean by dynamic documents?
A: I mean documents that maintain the benefits and overcome the limitations we just discussed. Dynamic documents provide a portable, persistent and contextual user experience, but the information is always up-to-date.
If you think about traditional business applications--for example, ERP, supply-chain management, customer-relationship management--the information that you access within these applications is dynamic, interactive and authoritative. You can count on this information to be more or less an authoritative version of the truth. But it completely lacks the portability, rich context, and persistence that you find with a document user experience.
The dynamic document is nothing more than these two worlds coming together, providing the portability, context, and persistence of the document-centric user experience together with the dynamic and interactive information that you typically find within business applications. The document itself becomes the application.
Q: Can you tell us how that's different from the traditional notion of XML publishing?
A: In the world of XML publishing, you're assembling documents and deliverables based on reusable XML components. That helps you streamline and accelerate the creation of new documents and also accelerate the implementation of change. It's a much more efficient way to implement changes in the process of publishing documents. But the reality is that the document as published, even in that context, is a static artifact. It's still a snapshot in time.
Dynamic documents essentially come to life by preserving persistent links to various sources of record. As the sources of record change, the document itself changes. You don't have to republish the document. It's a live application. What you see in the document reflects the changing nature of the information on the back end.
Q: Couldn't you accomplish the same or similar things via portal?
A: Sometimes, but not always. Remember, the document-centric user experience uniquely lends itself to many different business processes. And the "on the glass" portal style user experience is often just a poor substitute for the portability, persistence, and rich context of a document.
Of course, aggregating disparate pieces of information on the glass within a portal-style user experience is suitable for various heads-down processes and a limited view of the world. But it won't work when you need to take that information and share it with people and make it part of a collaborative process. In that case, documents are the only suitable solution, the only suitable user experience and paradigm for sharing that information. A portal just wouldn't do the trick.
Q: You're saying documents are very Web 2.0. Can you speak to some applications of this?
A: I like to think of it in terms of usage patterns, and there are three usage patterns for dynamic documents that are worth talking about.
The first pattern is information sharing, the one-to-many paradigm of disseminating information to various distributed personnel. For example, within aerospace and defense, there's a class of documents called Interactive Electronic Technical Manuals (IETM). These are very complex, very large technical manuals that represent all the standard methods and procedures for maintaining aircraft.
The challenge with publishing these documents is they're drawing on many different sources of record--both structured information and unstructured information. Because of this complexity, the documents are very quickly out-of-date. When one data element changes, the whole document needs to be republished which makes it difficult to keep these documents up-to-date.
The dynamic document allows an IETM to be delivered as a live application. It has the portability, the persistence, the rich context of a document, but the information it contains is always up-to-date. It's a direct authoritative reflection of all of those enterprise systems.
Another dynamic document advantage is that application logic is embedded within the document itself, so the dynamic document becomes semantically aware of its environment. It knows who the user is, what their role is, where it is in a process. The document can even interact with its environment and render the appropriate view of information based on some environmental conditions.
For example, say a real-time fault is detected in an aircraft. The fault could actually ping the document and cause the document to serve up a different view of information based on the fault that's detected. In turn, the maintenance crew can go out and start picking parts and preparing to make the fix when the plane lands.
The second usage pattern addresses collaborative processes, applying the same concept to situations where people need to make decisions or perform some sort of doc prep process. This could be for a merger or acquisition, an IPO, a private placement within financial services, or any document-centric collaboration.
Let's take the example of a sales and operations planning process. On a quarterly or monthly basis, a cross-functional team makes decisions about how to optimize supply and demand and which projects to invest in and which ones to disinvest in. The process is typically based on reports pulled from ERP, supply chain, inventory, and other enterprise systems. And these static and disconnected documents become the basis for making these decisions.
The problem is that the information in the reports is quickly out-of-date, and people end up spending half or more of their time reconciling and validating the information in these reports and documents. They never quite know if they're looking at an authoritative view of the business. Meanwhile, dynamic documents ensure that information is always up-to-date.
The third usage pattern is document process transformation, which is about transactions driving document renditions and document renditions driving transactions.
Any kind of business process flow today has isolated silos of automation, which are highly tuned transactional phases of the process. They're very efficient and require no human intervention. Everything's reduced down to a transaction. But then you have manual gaps between these silos where people need to get involved, and these tend to be very document-centric. Document process transformation is about stitching together these silos of automation by creating dynamic document flows that allow transactions to create document renditions that people can interact with. Then, the document renditions are reduced down to transactions again to populate back-end processes within automated systems. The overall business process becomes a much more streamlined, straight through and efficient process with higher throughput and reduced cycle time.
Q: Can you give us a scenario, a day-to-day business practice where document process transformation might come into play?
A: One scenario that generates a lot of interest is loan applications. When someone applies for a loan at a bank, the front-end of the process looks like a form which the bank uses to capture information about the applicant. Some of that information can be distilled down to a transaction and handled automatically by a back-end system. Other information needs to be served up as a set of document renditions because people need to intervene. They need to review it and make a judgment about whether to approve or to reject the loan.
In the front-end of the process, the dynamic document looks like a form. It passes off some of the information to the back-end system for transactional handling. And it serves up a series of dynamic renditions based on what that person in the process needs to see. The dynamic document morphs as it goes from step to step to step in the process, showing a completely different view of information.
Ultimately, the loan is approved or rejected, and the information is extracted from the doc set and pulled down to the back-end system that kicks off a back-end process like the account opening procedure, which is handled automatically. It can also then serve a traditional publishing pipeline. Information could be extracted from the doc set to serve the creation of a custom correspondence, for example, an acknowledgement letter back to the customer letting them know that the loan has been approved.
Q: Can you give us a few pointers on how an enterprise might get started with dynamic documents today?
A: Foundational to this notion of dynamic documents is XML. So, companies need to start thinking about how to modernize their authoring process. They need to think about moving away from traditional, monolithic document authoring and moving toward creating content based on XML and reusable components. To the extent that you're creating your content as XML, it becomes more richly described, more widely accessible, more appropriate to the creation of dynamic documents as well as a key input into your other line of business applications.
Jake Sorofman is senior vice president of marketing and business development North America and EMEA for JustSystems. Contact Jake at firstname.lastname@example.org.