| XML
Publishing
COBOL
Reshaping
Services
Semantic
WS
Programming Specs
WS-BPEL
Tools
Eclipse SOA
X-Registry
|
|
 |
The Document as Application
By Jake Sorofman
|
1 2 Next>>
The Convergence of Document Publishing and Application Development
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.
1 2 Next>>
|
|
|
