1 April 1995.

The Object-Oriented Enterprise:
Making Corporate Information Systems Work

by Rob Mattison, with Michael J. Sipolt
McGraw-Hill, Tab Books, 1995.

This work has been quite frustrating to review. The authors present a large volume of concepts, covering object-oriented (OO) design methodologies, OO programming, OO databases and transaction processing in an easy-to read, breezy, nearly breathless style. The coverage ranges from issues of enterprise management to code for the layout of graphical user interfaces in specific languages. The OO approaches are compared with alternative design, programming, and database approaches. The authors express a great number of valuable insights, and conveys tidbits as well as concepts that have potential to benefit readers who can apply them.

Then why the frustration? The style, throughout, is that of a sequence of after-dinner speeches. The table of contents lists 494 topics for 372 pages of text. The typical topic is introduced and completed within about a dozen sentences, a blessing after dinner, but unfulfilling as a main course. At most, broad brush arguments are provided to substantiate the statements. The reader is exhorted to be a hero: "Embracing object technology ... is only the beginning of the struggle" (p.78), but mere flag-waving is inadequate to win a war. Battles and wars can be lost due to inattention to detail, and here is where the material falls short. Concepts are used inconsistently to bolster the arguments: C++ is a second generation language (2GL) on page 149, while plain C was a 3GL on page 138. References are often circular, and at times require insider's knowledge: an {\sl ordered collection} is twice explained as being like a VSAM ESDS structure (p.66, 181), but such a {\sl Entry-Sequenced} structure is cited in the index as an ordered collection, with references to the same pages. Given the exhortative style, it is not surprising that there are also a fair number of factual and historical errors. They matter little in terms of the points being made, but reduce the overall impact for readers in-the-know on some subtopic.

The authors, while being fair, do express preferences. As a design methodology Booch seems to win out over Rumbaugh and Yourdon because it reaches deeper into programming details. No methodology is found to be adequate, and no alternative is proposed, although it is made clear having any disciplined design method is much better than having none. IBM's SOM is favored as a middleware architecture, although Microsoft's OLE is given considerable exposure. For programming, the Smalltalk approach to object-orientation is preferred over the C++ approach. A small worked-out example in the appendices supports that argument, but its scale is inadequate to allow us to draw enterprise-wide conclusions. Semantic databases are preferred over either object or relational alternatives, but again less than half a page is devoted to them.

The latter half of the book discusses interoperation of the variety of OO and legacy technologies. It is clear that most interactions will not be smooth today, and desirable features of the OO paradigm, as encapsulation and use of standard libraries, must be given up in enterprise-wide interoperating systems. The preferred approaches of the authors already fail to interoperate. Problems of small, autonomous legacy systems are presented, as well as those particular to mainframes. The authors have imposed a constraint on their work, namely to limit themselves to existing approaches, which makes it impossible to sketch an inspiring future for interoperation.

Should you read this book? Yes, for its insights and its breadth; but to apply these arguments within your enterprise expect to analyze these technologies with respect to your specific situation, resources, and long-term objectives. No, if you cannot stand incompleteness. imprecision, or inconsistencies. It can whet your appetite, but will not satisfy a craving for a hearty meal.

Gio Wiederhold, Stanford Un.