The worlds of document publishing and application development are converging. Traditionally, publishing processes focused on static documents in print, PDF, HTML, and other formats. While the Web introduced rich media formats, this only provided a more compelling multidimensional rendering of static information.

The reality is that business depends on dynamic data, and static documents only provide a snapshot in time. Users who need the most current information possible must go to the source – the business applications and other systems of record. This sort of “on-the-glass” user experience is fine for some business processes, but other business processes are document centric, depending on the persistence and rich context that a document format uniquely provides. This has forced users to copy and paste data into documents, breaking the link to the sources of record and freezing the data in time.

Traditionally, the choice has been between live data without context -- or context without live data. But another choice is emerging: the document as the application. Here, the persistence and context of a document converge with the dynamism and interactivity of a business application. This will be a fundamental change in how we think about documents and a transformation to document-centric business processes.

Why Documents Matter

Unlike portal-style business applications, documents persist as self-contained artifacts. They present a fully contextual view into information, which is organized with a deliberate intent and purpose. Many business processes are document-centric. For information workers, documents transfer knowledge and communicate information when it must stand alone.

Business applications provide some degree of context for data, but they’re not persistent. The stateless views they present are fleeting and episodic, which makes portal-style business applications a poor substitute for many processes.

Consider the example of a technical manual for maintaining the hydraulic system of a commercial airliner or the standard operating procedures for powering down a nuclear power plant. These are both examples of information that must be conveyed in the context and with the persistence of a document, yet these documents are subject to ongoing change, as complex arrays of data within sources of record are updated. Putting inaccurate or out-of-date information in the hands of the end consumer can lead to rework or redesign costs, launch delays, regulatory noncompliance, or worse.

From Data and Documents…

Data and documents have generally been isolated from one another. Data is stored in relational databases, mainframe systems, and data warehouses. Documents are kept in content management systems, shared file servers, and local drives.

Data is structured and empirical. It tends to focus on the “what” of business -- financial information, inventory, etc. Documents are unstructured and contextual. They focus on the “why” and the “how” of business -- manuals, policies, reports, analysis, etc.

Of course, business is done at the intersection of “what,” “why” and “how” -- where fact meets context -- and more organizations are moving toward that intersection, seeking ways to unify their data and documents.

Enterprise Information Integration (EII) and other middleware technologies can sometimes federate access to data and documents -- side by side -- as part of a unified application. While an improvement, this solution fails to address data that is actually part of the document content and must be viewed within the document itself.

Take, for example, a technical field service manual for complex capital equipment or a recipe for a chemical compound. These documents include data found outside of the document, in relational databases and other sources. Viewing data and documents side by side is better than nothing, but the logical user experience is in the document itself.

…to Data in Documents

Data and document convergence must transcend data and documents to allow for data in documents, the essence of the document-as-application.

The document-as-application is fundamentally different from today’s XML-based authoring. While organizations can rapidly propagate change to unstructured documents via XML-based authoring, the data that originates in structured databases has no native connection to documents. With the document-as-application, structured data in documents has direct, persistent links back to its native sources, ensuring the documents and the systems of record are always in sync.

Moreover, the document-as-application enables a new level of interactivity. Beyond inline edits, comments, or workflow processes, users can interact with documents as if they were business applications, e.g., performing queries, transactions, calculations, etc., against backend data sources and live enterprise information. All of this interaction takes place within the document, thereby maintaining context and persistence. Teams and workgroups can share and collaborate on the document -- e-mail it, associate it with a workflow -- without ever breaking the connection to this live data.

Organizations have never had this sort of interactivity within documents. The tradeoff has always been between the business application’s live data and interactivity, and the document’s persistence and context. But that is changing as the worlds of documents and business applications collide and the document-as-application emerges.