Customer Reviews

Document Engineering: Analyzing and Designing Documents for Business Informatics and Web Services

5 star:		(3)
4 star:		(1)
3 star:		(1)
2 star:		(1)
1 star:		(0)

 

 

At the end of the day, business success comes down to three things: a product, the market, and the business processes. The business processes consist of people, tools and workflow. You can have a great product in a great market but if you have bad business processes...you can forget about it. Many organizations have tried to implement Six Sigma to ensure highly effective business processes. The key to six sigma is data. Data tells you how effective your processes are. For example, data will tell you things like: how many parts per million are defective, how many invoices per million were inaccurate, how many orders shipped late, how long it takes to execute an order once a contract is signed, how long a customer support rep spent on the phone, etc......Once you have the data, evaluating the problem and recommeding a solution is easy. The hard part however is getting the data. You can either collect the data manually over time or if you have the infrastructure you can collect it electronically through software. Unfortunately if you have to collect the data manually, it takes a long time, effort and money. If you collect data electronically it enables no additional time and provides real time visibility and the ability to implement positive changes on the fly. So how do you go from a manual data collection process to an automated data collection process? That's what this book, Document Engineering, will help you figure out. I have owned this book for about 2 months and it has been on my desk since. I continuously refer to it for insights on how to develop a clear plan on how to implement a data collection infrastructure that will help to more effectively manage business processes.

Component modeling, analysis of information exchanges, and

application services usage patterns are critical areas to focus

on in designing internal and external interfaces exposed by

enterprises, ASPs/SaaS, and other consumer-oriented internet

services. We have many good examples of scalable, evolvable,

easy to integrate and interoperable Web Services API in the

consumer-oriented internet industry currently. The areas

covered in the DOCUMENT ENGINEERING is very relevant to

architects, product managers, developers and technology

executives. I especially found the design patterns and process

discussion helpful. I would recommend this book to anyone

interested in services oriented application platforms, internal

and external enterprise integration to employ in the design

phase since it covers an effective methodology of designing

interfaces based on the document-centric component model.

Zahid Ahmed

San Jose, CA

Document Engineering is a practical exploration of the role documents play in the nexus of contracts that drive modern businesses. The interdisciplinary approach put forward here, taking document engineering out of the realm of pure software engineering, is eye opening and provides some real insight into what it takes to make Service Oriented Architectures work in the real world. This is an absolute must read book for anyone seriously considering developing an XML based document integration strategy.

I really should like this book - it's highly related to what I do and I love my job. There were a number of good nuggets of information and references that I will find useful however I found I had a great deal of trouble reading the actual text - I found it boring. The large print, gaps between the lines and the stretched filled spacing of each line made it difficult to quickly scan paragraphs and grasp the gist of what was being said, even when rereading. The grid diagrams were also problematic - they all had the same look - there was little that was memorable about them. The authors also often used round about wording where more direct statements would have been clearer.

As an experiment I typed a couple of random paragraphs from the text and found that they made a lot more sense. I also showed the text around to some of my co-workers and got the same reactions. Given the title of the book it is somewhat ironic that it should have this kind of a problem, but the book deals with principles for the automated transformation of content, not effective presentation style.

Better editing would have made a better book.

The book is a refreshingly understandable approach to explaining Service Oriented Architecture, Web Services and the Semantic Web. Other texts often drown the reader in hugely verbose XML examples. But here, the authors achieve clarity in discussing the essence of the above concepts. The XML snippets are clear, without being overly long.

You can also see why interoperability issues might inevitably arise in a loosely coupled Web Services environment. Often due to differing semantic meanings attached to the same fields in a common document structure. The book touches upon hard problems of ontologies and how the different meanings might be accomodated in a realistic deployment of distributed Web Services.

I was lured by the title and reviews hoping to get insight on how to generically define large documents that could easily be extended as requirements change and consumed by a wide variety of clients using different arbitrary programming languages. I didn't learn anything new about extensibility, and programming languages are absent from this book.

Instead the book seems to be a somewhat dated look at a high level process for using documents in a service oriented architecture. The calendar example application seems too simple to translate into a more complex real life application. The approach described for "document engineering" is much more reminiscent of waterfall style development approaches rather than lean/agile techniques.

I also found the text very difficult to read; it's very dry.

Perhaps this book is useful for some, but it certainly isn't helpful for everybody.