Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

Document Engineering

1,327 views

Published on

Robert J. Glushko

Published in: Technology, Business
  • Be the first to comment

  • Be the first to like this

Document Engineering

  1. 1. 1 of 48Document EngineeringSTC-PMC 200717 March 2007Robert J. Glushkoglushko@ischool.berkeley.edu
  2. 2. 2 of 48Plan for Todays LectureDocument Engineering in the NewsThe Data vs Document DivideDocuments and Processes -- Yin and YangDesign Patterns in Document EngineeringSynthesizing Four Modeling Approaches
  3. 3. 3 of 48Who 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 3companies in 1990sHypertext EngineeringPassage SystemsVeo -> Commerce One
  4. 4. 4 of 48What Is Document Engineering?A methodology for specifying, designing, and deploying the informationmodels and repositories that enable document-centric applicationsA synthesis of information and systems analysis, business processmodeling, electronic publishing, and service-oriented architectureIt has much in common with Information Architecture, but extends itsscope beyond web site and web application design
  5. 5. 5 of 48Intel, Wal-Mart and others Push ElectronicHealth Records
  6. 6. 6 of 48Tsunami Aid Delayed by IncompleteShipping & Customs Documents
  7. 7. 7 of 48Salesforce.com Connects its Front End toBack Ends
  8. 8. 8 of 48Global Shippers Give Customers Real-TimeCargo Info
  9. 9. 9 of 48FedEx Kinkos Announces Web-basedPrinting, Tracking Services
  10. 10. 10 of 48Law Firm Business Models Disrupted byDocument Assembly Software
  11. 11. 11 of 48The Common Themes in These News ItemsEnormous opportunities for transforming legacy documents andprocessesNew business processes are created / coordinated / choreographedvia the management and exchange of electronic documentsStandards / patterns for documents and business processes areessentialInformation technology and business processes are co-evolving
  12. 12. 12 of 48Is THIS a Typical Document?
  13. 13. 13 of 48Or is THIS a Typical Document?
  14. 14. 14 of 48Or Maybe THIS is a Typical Document?
  15. 15. 15 of 48Contrasting Methodologies for Documentsand DataDocuments and data have had two different disciplines or methods ofanalysis that have had little intersectionDocument-centric analysisData-centric analysis
  16. 16. 16 of 48Document AnalysisDocuments are Artifacts or Renditions that combine content, structureand appearanceThe goal of document analysis is a model of a documents content andstructure that is separate from its presentational characteristicsThis model of the document and those in its equivalence class is calleda markup language or document schema or document type
  17. 17. 17 of 48Data-Centric AnalysisGoal is to understand and describe the properties and relationshipsbetween information components or objects.This understanding is represented in conceptual models that organizethe components efficiently to support a broad range of contexts orapplications.The conceptual model is also typically called a schema, but this isgenerally meant to be a "database schema" rather than a "documentschema"
  18. 18. 18 of 48The Data vs. Documents Divide
  19. 19. 19 of 48But A Catalog Is Data (Document)
  20. 20. 20 of 48And a Reference Book is Document (Data)
  21. 21. 21 of 48So its a Continuum: The Document TypeSpectrum
  22. 22. 22 of 48Can There Be A Bridge?
  23. 23. 23 of 48Spanning the Data/Document DivideDocument Engineering harmonizes the terminology and emphasizeswhat they have in common rather than highlighting their differencesIdentifying the presentational, content, and structural components anddefining their relationships to each otherIdentifying "good" content componentsDesigning, describing, and organizing components to facilitate theirreuseAssembling hierarchical document models that organize componentsaccording to the requirements of a specific context for informationexchange
  24. 24. 24 of 48And Business Processes Involve The EntireSpectrum of Documents
  25. 25. 25 of 48How Should We Understand theRelationships Between Documents andProcesses?Business activities involve documents and the processes that produceand consume themBy understanding the information in the documents, we learn whatkinds of processes are possibleBy understanding the processes, we learn what kinds of informationare needed
  26. 26. 26 of 48A Process-Centric Depiction
  27. 27. 27 of 48A Document-Centric Depiction
  28. 28. 28 of 48So How Can We UnderstandDocuments/Data/Processes In a SystematicWay?A focus on processes progressively refines a broadly scopeddescription of business activities"Making it all work" from a business perspectiveInherently a "top down" approachA focus on documents and data emphasizes the information objectsand flows in a domain and the requirements for implementing a systemin it:"Making it all work" from a technical perspectiveInherently a "bottom up" approach
  29. 29. 29 of 48Documents and Processes -- Yin and Yang
  30. 30. 30 of 48Design Patterns in Document EngineeringThe essence of Document Engineering is its systematic approach fordiscovering and exploiting the relationships between patterns ofdifferent typesBusiness model or organizational patternsBusiness process patternsBusiness information patterns
  31. 31. 31 of 48Document Exchange PatternsBusinesses have long dealt with each other by exchanging documentsWe use concepts like "supply chains" and "distribution channels" asmetaphors for the coordinated or choreographed flow of informationand materials/products between businessesThese are complex patterns composed from the document exchangepatternThe processes that comprise these patterns are "glued together" byoverlapping information components in the documents
  32. 32. 32 of 48Document Exchange (Physical Model)
  33. 33. 33 of 48Document Exchange (Conceptual Model)
  34. 34. 34 of 48The Drop Shipment PatternCustomer selects a book from an online bookstoreCustomer pays with credit cardBook arrives via express shipper two days later
  35. 35. 35 of 48The Virtual Store as ChoreographedDocument Exchanges
  36. 36. 36 of 48Overlapping Information Models in theVirtual Store
  37. 37. 37 of 48Patterns in the "Model Matrix"
  38. 38. 38 of 48"Meeting in the Middle"To "bridge the gap between strategy and implementation" we needmodels that "meet in the middle"Reaching the middle from the top down ensures that a business modelis feasibleReaching the middle from the bottom up ensures that we are designingand optimizing the activities that add the most value
  39. 39. 39 of 48"Meeting in the Middle" -- 4 ModelingApproaches
  40. 40. 40 of 48The Document Engineering Approach
  41. 41. 41 of 48So Document Engineering Isnt About XMLXML is a useful technology for Document Engineering, but using XMLdoesnt make you a document engineerThe best thing about XML is the ease with which you can create a newvocabulary for a particular type of documentXML is just the syntax in which we encode document models... whatreally matters is how we modeled the documents
  42. 42. 42 of 48Creating Models is Easy, But CreatingGOOD Models is HardThe worst thing about XML is the same as the best thing – the easewith which you can create a new vocabularyNo way around the classical problems of classification and naming weknow from philosophy, linguistics, cognitive psychology, andinformation scienceXML is NOT "self-describing"There are often multiple vocabularies for the same or related domainsand especially for the common information models that are used inmore than one domain
  43. 43. 43 of 48A Checklist for Describing Projects andCase StudiesD -- data types and document typesO -- organizational processesC -- context (types of products or services, industry, geography,regulatory considerations)U -- user types and special user requirementsM -- models, patterns, or standards that applyE -- enterprises and eco systems (e.g., trading communities, standardsbodies)N -- the needs (business case) driving the enterprise(s)T -- technology constraints and opportunities
  44. 44. 44 of 48D-O-C-U-M-E-N-T in the DocumentEngineering Approach
  45. 45. 45 of 48Summary: Document Engineerings BigIdeas"Document Engineering" is evolving as a synthesis of information andsystems analysis, business process modeling, electronic publishing,and service-oriented architectureBest practices in Document Engineering require the reuse ofinformation and process patternsBusiness activity always involves both "narrative" and "transactional"documents – so analysis and design methods must span this"Document Type Spectrum"
  46. 46. 46 of 48Document Engineering - The Book
  47. 47. 47 of 48AcknowledgmentsMuch of this material comes from a book called DocumentEngineering: Modeling for Business Informatics and Web Services byRobert Glushko & Tim McGrathThree years of students at the University of California, Berkeley havecontributed to its development through courses and research projectswith the first authorThe methodology has been significantly refined through its use by thelibrary content team of the Universal Business Language initiative, ledby the second author
  48. 48. 48 of 48But Wait, Theres MoreIm easy to find: just "google" Glushko and you find me and the rocketguyFrom my home page you can locate the syllabus and lecture notes for"Document Engineering and Information Architecture" course at UCBerkeleyYou can also find my "Doc or Die" blog where I occasionally post about"Document Engineering in the News" or "Semantics in the Wild" storiesTHANKS FOR INVITING ME

×