If your organizations are building any new operational systems, more than likely they are using object-oriented (OO) techniques. Since, at least on the surface, the object class diagram looks so similar to the entity relationship diagram, application development team members have started questioning why data modeling has to be done for an OO project.

A look back at the similarities between the "old" structured analysis and design (SA&D) technique and the "new" OO approaches illustrates a common attitude towards data. Primarily, both approaches foster the perception that data exists only to support their application. Any data sharing that occurs across application boundaries is almost coincidental, rather than planned.

The first task in both the SA&D and OO project is "draw your boundary", which is typically represented by a context diagram. The scope of the application being developed falls within the context box, while the interactions with external entities (or actor groups in OO terminology) fall outside the box. Only the business processes that fall within the system boundaries is considered. Likewise, only the data that is used by those processes are analyzed.

In the past, this very approach of partitioning applications by business processes resulted in the stove-pipe application portfolio that we now refer to as the "legacy". In the old applications, data was not easily shared because each application designed its data to meet its specific needs. We've already learned that after-the-fact integration of customer data from stove-pipe applications is not a simple effort. Yet, we seem to be continuing the approaches that got us in this mess in the first place with the "new" OO approach. Are we simply building a new legacy using improved programming languages?

So, even though Object Class models and data models look very similar, they are not developed with the same objectives in mind. The object class modeler's loyalty is first and foremost to the application project. And rightfully so! Her objective is to model the business requirements in a manner that best supports her application stakeholders' needs. In the absence of any enterprise model that provides specifications for standard object structures or attributes, the object modeler will design data that is optimized for her application's specific needs. If in the process she creates additional disparate data for the enterprise, that's too bad. Her responsibility is to get the application built.

What data modelers bring to the table is clarity of thought. We know that our business's language is very rich and expressive, but often lacks clarity. Our job is to root out the terms and definitions lurking behind the barrage of business words. We often discover business definitions that have no associated term. Everyone "in the know" understands one another because of the context surrounding the conversation. But taken out of context, the terms or conversation exerts can be meaningless. Furthermore, we are uniquely placed within the organization to be able to specify object classes that are re-useable across the application portfolio. Since, as the organization's data management specialists, we are application independent, we may be the only people in the organization with a true view of the information management needs across the enterprise. We become the cross-line of business experts with respect to what information is required to conduct business, including which business concepts are common across the organization.

So are data models required for an OO application?

If the persistent data store is a relational database, you have no choice. You are constrained by the need to implement sound, relational structures. Techniques exist, that given a well-formed object class model that adheres to the principle of "one fact in one place", can be used in transforming an object model into a normalized data model. The trick is getting that well-formed object class model.