The last post concluded by considering the need to get input from different interest groups when designing systems for existing or new applications.  When we have a data modelling assignment, we often discuss requirements with a limited set of contacts within the client company.  Data modelling is considered a little too arcane for most people, and so many of our discussions are with those considered experts within the client organisation.  The downside of this is that we lose diversity of input.  If you like, our information has been pre-digested for us, and all we get is one person’s summary.  The information is presented to us almost as if it is holy writ, but here’s the rub: it may be wrong.

When someone else does the work of condensing and combining the input of many people into a single answer, you have to make a choice: do you rely on their work or not?  And what a difficult decision that is!  If you are called to do data modelling, your customers may not be pleased if you start to intrude on their work of job definition.  But can you do the job properly without doing this to some extent?

Foundations

An easy way to look at data modelling is to think of the foundation of a building.  If the foundation is bad or inadequate, all of the work built on the foundation will be useless.  It may take months or years for this to become completely clear, but in the end, the quality of the foundation will show, and nothing can be done to fix it once the building work begins to cover the foundations.  From time to time you may see buildings with areas where large cracks have been “fixed”, or where special bolts have been added to hold the two sides of a building together.  You may see a fairly new freeway with lanes closed while attempts are made to fix the pavement in order to cover up a basic failure in the preparation of the foundation.

The important message to get across to a customer is that data modelling is like this.  If the modelling is done badly, it may simply be impossible to fix the resulting problems.  In an extreme engineering example, a house may sink into the quicksand it was built on, and the only option will be to start building again in a different place.  Sometimes software tries to solve insoluble problems, and some situations cannot be modelled in a way that will provide a workable result.  At times, the complexity is such that it will overrun any attempt to simplify or optimise.  Just imagine trying to model the human body and the interactions of all its constituent chemical parts.

I have gone on about this at length because there is an important lesson to learn: if you are going to depend on someone else to make the step from user input to problem definition, you may end up building a foundation in quicksand.

More advisors

My advice is to seek input from more people.  If one person is meant to be feeding you all of the answers, discuss with them where they got the information from.  You may find that they just made it all up.  If so, you need to get input from many more people.  Or you may find that they have already spoken to many different people and done their professional best to synthesise and categorise.  If so, make sure that you spend some time with people who provided different input.  Make sure that your assessment of that input agrees with the situation as it has been presented to you.  You need to sample the inputs and do your best to make sure that the data you are being given is coherent and fits with the inputs you can check on.  That is your job.

If you rely on one person, your success depends entirely on theirs.  If they are wrong, you can never be right and the foundation you build will be compromised.  Get input and advice from many people, because if you do that, you can be confident of success.  As the proverb says:

“Without counsel plans fail, but with many advisers they succeed.”

Proverbs 15:22