Robert J. Glushko

1. 1 of 48
Document Engineering
STC-PMC 2007
17 March 2007
Robert J. Glushko
glushko@ischool.berkeley.edu

2. 2 of 48
Plan for Today's Lecture
Document Engineering in the News
The Data vs Document Divide
Documents and Processes -- Yin and Yang
Design Patterns in Document Engineering
Synthesizing Four Modeling Approaches

3. 3 of 48
Who Is This Guy?
Adjunct Professor at UC Berkeley "Information School" since 2002
(www.sims.berkeley.edu/~glushko/)
Came to Berkeley from Silicon Valley; founded or co-founded 3
companies in 1990s
Hypertext Engineering
Passage Systems
Veo -> Commerce One

4. 4 of 48
What Is Document Engineering?
A methodology for specifying, designing, and deploying the information
models and repositories that enable document-centric applications
A synthesis of information and systems analysis, business process
modeling, electronic publishing, and service-oriented architecture
It has much in common with Information Architecture, but extends its
scope beyond web site and web application design

5. 5 of 48
Intel, Wal-Mart and others Push Electronic
Health Records

6. 6 of 48
Tsunami Aid Delayed by Incomplete
Shipping & Customs Documents

7. 7 of 48
Salesforce.com Connects its Front End to
Back Ends

8. 8 of 48
Global Shippers Give Customers Real-Time
Cargo Info

9. 9 of 48
FedEx Kinko's Announces Web-based
Printing, Tracking Services

10. 10 of 48
Law Firm Business Models Disrupted by
Document Assembly Software

11. 11 of 48
The Common Themes in These News Items
Enormous opportunities for transforming legacy documents and
processes
New business processes are created / coordinated / choreographed
via the management and exchange of electronic documents
Standards / patterns for documents and business processes are
essential
Information technology and business processes are co-evolving

12. 12 of 48
Is THIS a Typical Document?

13. 13 of 48
Or is THIS a Typical Document?

14. 14 of 48
Or Maybe THIS is a Typical Document?

15. 15 of 48
Contrasting Methodologies for Documents
and Data
Documents and data have had two different disciplines or methods of
analysis that have had little intersection
Document-centric analysis
Data-centric analysis

16. 16 of 48
Document Analysis
Documents are Artifacts or Renditions that combine content, structure
and appearance
The goal of document analysis is a model of a document's content and
structure that is separate from its presentational characteristics
This model of the document and those in its equivalence class is called
a markup language or document schema or document type

17. 17 of 48
Data-Centric Analysis
Goal is to understand and describe the properties and relationships
between information components or objects.
This understanding is represented in conceptual models that organize
the components efficiently to support a broad range of contexts or
applications.
The conceptual model is also typically called a schema, but this is
generally meant to be a "database schema" rather than a "document
schema"

18. 18 of 48
The Data vs. Documents Divide

19. 19 of 48
But A Catalog Is Data (Document)

20. 20 of 48
And a Reference Book is Document (Data)

21. 21 of 48
So it's a Continuum: The Document Type
Spectrum

22. 22 of 48
Can There Be A Bridge?

23. 23 of 48
Spanning the Data/Document Divide
Document Engineering harmonizes the terminology and emphasizes
what they have in common rather than highlighting their differences
Identifying the presentational, content, and structural components and
defining their relationships to each other
Identifying "good" content components
Designing, describing, and organizing components to facilitate their
reuse
Assembling hierarchical document models that organize components
according to the requirements of a specific context for information
exchange

24. 24 of 48
And Business Processes Involve The Entire
Spectrum of Documents

25. 25 of 48
How Should We Understand the
Relationships Between Documents and
Processes?
Business activities involve documents and the processes that produce
and consume them
By understanding the information in the documents, we learn what
kinds of processes are possible
By understanding the processes, we learn what kinds of information
are needed

26. 26 of 48
A Process-Centric Depiction

27. 27 of 48
A Document-Centric Depiction

28. 28 of 48
So How Can We Understand
Documents/Data/Processes In a Systematic
Way?
A focus on processes progressively refines a broadly scoped
description of business activities
"Making it all work" from a business perspective
Inherently a "top down" approach
A focus on documents and data emphasizes the information objects
and flows in a domain and the requirements for implementing a system
in it:
"Making it all work" from a technical perspective
Inherently a "bottom up" approach

29. 29 of 48
Documents and Processes -- Yin and Yang

30. 30 of 48
Design Patterns in Document Engineering
The essence of Document Engineering is its systematic approach for
discovering and exploiting the relationships between patterns of
different types
Business model or organizational patterns
Business process patterns
Business information patterns

31. 31 of 48
Document Exchange Patterns
Businesses have long dealt with each other by exchanging documents
We use concepts like "supply chains" and "distribution channels" as
metaphors for the coordinated or choreographed flow of information
and materials/products between businesses
These are complex patterns composed from the document exchange
pattern
The processes that comprise these patterns are "glued together" by
overlapping information components in the documents

32. 32 of 48
Document Exchange (Physical Model)

33. 33 of 48
Document Exchange (Conceptual Model)

34. 34 of 48
The Drop Shipment Pattern
Customer selects a book from an online bookstore
Customer pays with credit card
Book arrives via express shipper two days later

35. 35 of 48
The Virtual Store as Choreographed
Document Exchanges

36. 36 of 48
Overlapping Information Models in the
Virtual Store

37. 37 of 48
Patterns in the "Model Matrix"

38. 38 of 48
"Meeting in the Middle"
To "bridge the gap between strategy and implementation" we need
models that "meet in the middle"
Reaching the middle from the top down ensures that a business model
is feasible
Reaching the middle from the bottom up ensures that we are designing
and optimizing the activities that add the most value

39. 39 of 48
"Meeting in the Middle" -- 4 Modeling
Approaches

40. 40 of 48
The Document Engineering Approach

41. 41 of 48
So Document Engineering Isn't About XML
XML is a useful technology for Document Engineering, but using XML
doesn't make you a document engineer
The best thing about XML is the ease with which you can create a new
vocabulary for a particular type of document
XML is just the syntax in which we encode document models... what
really matters is how we modeled the documents

42. 42 of 48
Creating Models is Easy, But Creating
GOOD Models is Hard
The worst thing about XML is the same as the best thing – the ease
with which you can create a new vocabulary
No way around the classical problems of classification and naming we
know from philosophy, linguistics, cognitive psychology, and
information science
XML is NOT "self-describing"
There are often multiple vocabularies for the same or related domains
and especially for the common information models that are used in
more than one domain

43. 43 of 48
A Checklist for Describing Projects and
Case Studies
D -- data types and document types
O -- organizational processes
C -- context (types of products or services, industry, geography,
regulatory considerations)
U -- user types and special user requirements
M -- models, patterns, or standards that apply
E -- enterprises and eco systems (e.g., trading communities, standards
bodies)
N -- the needs (business case) driving the enterprise(s)
T -- technology constraints and opportunities

44. 44 of 48
D-O-C-U-M-E-N-T in the Document
Engineering Approach

45. 45 of 48
Summary: Document Engineering's Big
Ideas
"Document Engineering" is evolving as a synthesis of information and
systems analysis, business process modeling, electronic publishing,
and service-oriented architecture
Best practices in Document Engineering require the reuse of
information and process patterns
Business activity always involves both "narrative" and "transactional"
documents – so analysis and design methods must span this
"Document Type Spectrum"

46. 46 of 48
Document Engineering - The Book

47. 47 of 48
Acknowledgments
Much of this material comes from a book called Document
Engineering: Modeling for Business Informatics and Web Services by
Robert Glushko & Tim McGrath
Three years of students at the University of California, Berkeley have
contributed to its development through courses and research projects
with the first author
The methodology has been significantly refined through its use by the
library content team of the Universal Business Language initiative, led
by the second author

48. 48 of 48
But Wait, There's More
I'm easy to find: just "google" Glushko and you find me and the rocket
guy
From my home page you can locate the syllabus and lecture notes for
"Document Engineering and Information Architecture" course at UC
Berkeley
You can also find my "Doc or Die" blog where I occasionally post about
"Document Engineering in the News" or "Semantics in the Wild" stories
THANKS FOR INVITING ME