Document Engineering: A Logical Career Move For Some Business Content Pros
By Lisa Woods, Senior Collaboration Consultant at Allegient
It’s exciting when the state-of-the art in several disciplines gives rise to a brand new one. And it’s thrilling to watch someone extrapolate concepts from one arena to another in a way that makes connections jump out as if they were obvious all along. It’s like magic.
Authors Robert Glushko and Tim McGrath perform such a conjuring feat in their new book, “Document Engineering; Analyzing and Designing Documents for Business Informatics and Web Services”. This practical guide synergizes old ideas about software design with new thinking in content management, enterprise collaboration, data modelling, and business process analysis to define document engineering as both a philosophy and a profession. Glushko and McGrath not only make the case for document engineering, but lay out a flexible approach and toolset that can help the practitioner get there. And along the way they use one of my favorite business concepts–patterns–in lieu of the frustrating One Size (fits no one, actually) fundamentalist attitude that usually plagues books pushing business methodologies.
A “document” is here a set of information assembled for a (business) purpose; Document Engineering involves deconstructing, modeling and assembling documents in a way that facilitates information exchange across systems and enterprises while maintaining implementation-agnostic components for reuse. The document engineering mindset and iterative approach described by McGrath and Glushko emphasizes the importance of examining document content in context(s), representing documents and processes via models that illuminate various facets of use, and leveraging the results to produce conceptual models that don’t change when the technology does, as well as implementable document assemblies that can be enabled using (particularly) XML and web services.
It’s been apparent for some time that substantial cross-pollination was possible and desirable across the fields of information architecture, user interface design, database design and business process reengineering; Document Engineering is the logical career evolution for many business and systems analysts who, like myself, actively look to apply geekery (e.g. data modeling) as well as soft skills (e.g. negotiating) to the task of facilitating data exchange and designing business systems that enable rather than define how this occurs.
About Lisa Woods
Lisa Woods is a Senior Collaboration Consultant at Allegient and has a special interest in facilitating organic growth of collaboration tools in the context of defined business processes (in other words, improving user adoption of tools like SharePoint to get things done). Contact Lisa at lwoods@allegient.com
Similar Posts:
- Tech Writers: Are You A Future Document Engineer?
- [Profile] Bob Glushko Educates Future Knowledge Workers About Document Engineering
- The Document as Application: The Convergence of Document Publishing and Application Development
Lisa: I bought this book with every intention of reading it, after being completely blown away by Bob’s presentation at DocTrain West. His depth of study and insight into the art of the transaction was engaging, and on some levels, even refreshing.
The title “Document Engineering” is a misnomer, especially because as you said, every record used for information transfer is considered a document. In his examples the document isn’t the be-all end-all as we TCs have long thought. Rather, they are as transitory as post-it notes, and to succeed in this venture we must tread into the waters of usability engineering at the same time.
Sadly, the rampant typos in my copy made me put the book down for a moment, in which time a variety of work projects lined up to occupy my time and take me further from the material, even though I am interested in the concept. I can see from your synopsis that all that good stuff is just ahead of my bookmark. And so I shall carry on.
Thank you for your review, because it inspires me to let the typos be like creative spice that enhances the flavour of the meat, rather than a peculiar taste that I have to force down in order to be a good example to my kids.
Too brief an article for me to get the full gist; will get the book. One of the things I’ve long evangelized to my legal clients is to adhere to contracts that are standard in text, formatting, naming conventions. You’d be surprised at how many lawyers at the same companies and firms still build their drafts in Microsoft Word, rather than using a form-based approach. As a result, after contracts are executed, they are saddled with a task they rarely follow through on: Extracting the metadata relating to their contractual agreements. Lawyers: Metadata should be extracted during the document authoring phase—that’s a document engineering feat you will appreciate.
Nice review. Your review gives a very clear picture of the book and I am interested. I will read this book very soon.