Document Engineering
0 likes1,477 views
Document Engineering is a methodology that spans information analysis, business process modeling, electronic publishing, and service-oriented architecture. It focuses on reusing information and process patterns when analyzing and designing systems involving documents. As business activity always involves both transactional and narrative documents, analysis methods must consider documents across the full "Document Type Spectrum". Document Engineering emphasizes creating good models by understanding the relationships between organizational processes, business information, and document exchange patterns.
Document Engineering
- 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