For Project Managers (PM): Why You Need An O/R Persistence Layer
You have a set of technologies that you are planning to use on
your project and have a high-level project-plan based on time, scope, resources
and strategic organisation technologies. All of a sudden you start hearing
mutterings about Hibernate, iBATIS, impedence mismatch, object/relational
mapping. Every few days the noise gets louder. Then one-day the lead
developer/architect on the project comes to you and says we need to use an O/R
persistence technology. You ask why and recall that you didn't have to do this
on previous projects.
Why Your Architect Is Correct:
Relational databases are tabular. Languages such as Java and C# are
object-oriented. This means that entity-relationship models implemented in
relational databases such as Oracle and object models implemented in languages
such as Java maintain entities, relationships and state in different types of
models. Therefore, when storing/retrieving data to/from a relational database a
mapping needs to be performed. In the OO world you have inheritance,
polymorphism and higher levels of granularity that have no counterpart in a
relational system. In addition, you have many-many relationships and different
notions of identity.
The next most common question asked by the PM is "why can't we make the two
models the same so that no mapping is required ?" Well we can make the
models the same but mapping will still be required. In addition by going down
this route you will take away the benefits of using object-orientation and this
will lead to an object model that is harder for developers to utilise and
maintain. i.e. it will be more buggy and will decrease communication between
your team and the business as the real-world business-model is diluted. You
want to aim for a rich domain model that is understandable by business users
(trained in UML to some extent), analysts and developers and that represents
real-world entities as close as possible. i.e. Your risks of capturing the
correct requirements and modelling them are increased by using a relational
model in your OO model. Both models can start from the same OO logical model
and then implement the concepts using the implementations best practise.
At this stage, most PM's say "can we not do all this in the database using
stored procedures". Well yes you can but you will increase the
resources you require and the amount of work that needs to be done. Consider
that you will require someone to define the interface between the stored
procedures and the Java layer - this is the same person that would perform the
mapping using an O/R persistence tool but you've just doubled their workload in
this area as they now to write a set of data transfer objects that pass data to
and from the stored procedure layer. In addition, you'll need to resource
writing and testing the stored procedures and add new dependencies in your plan
on this work completing before the Java layer can talk to the database. And
don't forget to add a task for integrating the Java layer with the stored
procedures. I've seen a financial institution in London go down this route as
they tried to deliver quicker by performing more tasks in parallel. Setting
aside the technical aspects, it is a perception that does not add up when you
walk it through. In addition, new and changing requirements can now have double
the impact. Don't get me wrong, there will always be some functionality that is
best-performed using stored procedures even in an OO world, but you need to
look to your architect and their non-functional requirements for this.
The typical PM response will be "but how will this help my project ?".
It will help to deliver quicker, with less complexity, and with reduced risk
than by not having the technology. The system will be more maintainable. Your
architect may look to code-generation of the object model and persistence layer
to increase this on larger projects.
PM: "How much will it cost?". The most popular object/relational
technology is called Hibernate and its free. You can buy support. In addition,
the next release of J2EE is going down this route.
Still not sure? Try breaking your plan up so that you show how much time is
spent developing the persistence layer. Now go show this to your architect and
ask for metrics on how this can be delivered quicker using an O/R mapping
Project managers are a dime a dozen. Most are average and know how to use MS
Project and Excel. Once in a while you come across some excellent project
managers. The best I've worked with have a technical incline using the
technologies available on the project, deep business knowledge and good
Good developers and architects that care and can deliver on time are very rare.
If you find one, learning to trust their guidance and expertise is one of the
most effective things you can do to deliver your project successfully. This is
part of being a good leader (which most project managers are not).
It also has the effect of keeping the architect/developer happy which is important as the longer
they are on your project the greater the chances of you delivering to plan.
Jack Welch: "Empower, delegate, get out
of the way"