When a software development team uses object-oriented technology, the most effective approach to modeling is dominated by object models such as UML Class Diagrams, UML Sequence Diagrams, and UML State Charts. This makes a lot of sense. Object technology is best modeled using object models. Unfortunately, not everyone sees it this way -- particularly data professionals within your organization that are likely to have significant experience on non-object projects but little or no experience with object technology. This difference of opinion, as well as other factors, has led to the "object-data" divide -- the difficulties of object-oriented and data-oriented developers experience when working together.

History of the object-data divide

There are three main reasons why the object-data divide exists:

1. The object revolution started by spurning the data community. Object technology was first adopted by the business community in the late 1980s and early 1990s, just when object-oriented database management systems (OODBMSs) were coming on the market. This lead to the mistaken belief that objects should only use OODBMSs to persist themselves, and therefore both relational databases and data professionals were not needed for object development.
2. Data professionals weren't motivated to work with object developers. Already important in the traditional mainframe and client/server development worlds, data professionals found little need to work with the new object "hotheads" they found popping up everywhere. Up to this point data professionals would create their data schema and application developers would write their program code -- an approach that worked because there wasn't a lot of conceptual overlap between the two tasks. Many data professionals chose to believe that the object paradigm was another fad doomed to fail, or merely another programming technology. But time showed that object development has become the norm, and there is far more to it than just programming.
3. Senior IT management can't tell who is right. The unfortunate reality is that you really need to understand the intimate details of object-oriented development to understand who is right. In this case, it isn't either of the two groups. In most organizations, senior management is often unaware of the problem or, if aware, they are hoping that it will somehow work itself out.

Back to top

Effects of the divide on EJB projects

The object-data divide is a serious problem for most Enterprise JavaBean (EJB) development teams because EJB employs both object and data technologies. EJBs themselves are written using Java, an object-oriented language, but they are typically stored in a relational database such as Oracle or IBM DB2 -- non-object technology. The object-data divide is further compounded by technical challenges using object and relational technologies together, a problem called the "object-relational impedance mismatch." (See the recent tip Mapping objects to relational databases).

When organizations cannot successfully overcome the object-data divide, they often choose to have their object professionals and data professionals work separately in parallel instead of together as a single team. When your object modelers and your data modelers do not work together, you risk having a significant impedance mismatch between your object schema and your data schema. The greater the mismatch in your schemas, the more code you will need to write, test, and maintain to resolve it. You also have code that is likely to run slower than the simple code needed with coordinated schemas.

Another common, even worse, result of being unable to overcome the object-data divide is when the data model drives the development of the object models instead of the other way around. Object-oriented models (UML class diagrams, sequence diagrams, collaboration diagrams, and so on) that are driven by your existing data design rarely reflect what your users actually want. A basic premise of software engineering is that your requirements drive the development of your design models. That is, you don't start at design and work your way back.

Finally, organizations suffering from the object-data divide typically experience increased staff turnover due to frustration of developers because of "all of the politics." When most companies are having difficulties hiring good developers, the last thing you want is to lose someone over a preventable issue.

Resources

• Overcoming the object-data divide on your EJB project, Scott Ambler's follow-up article on the object-data divide
  
  
• Mapping Objects to Relational Databases: What You Need to Know and Why by Scott Ambler
  
  
• Database Glossary (About.com)
  
  
• The Object Primer 2nd Edition by Ambler, S.W. New York: Cambridge University Press, 2001.
  
  
• The Unified Modeling Language Reference Manual by James Rumbaugh, Grady Booch, and Ivar Jacobson. Reading, MA: Addison-Wesley Longman, Inc., 1999.
  
  

About the author

Rate this article

Comments

Back to top

Table of contents

• History of the object-data divide
• Effects of the divide on EJB projects
• Resources
• About the author
• Comments