Is Logical Data Model Signoff Logical?

A few organizations have a culture that promotes physical sign off of project documents that indicate their completion.  The company can then be comfortable that interested parties have approved the requirements, the design and so forth.  This can include the logical data model.  The development team can then feel comfortable that it is serving the business interests and go full steam ahead into the physical data model with no looking back.  What a relief, right?!  What could be a better indication of approval than a physical signature?

The biggest problem is not in the exertion for obtaining the signatures for the model, which can be exhausting, even when the signatories have been warmed up ahead of time to the impending need for signature.   The bigger issue is in the fact is that the development teams involved – modeling and programming – can act henceforth as if the model is not just signed off, but final.  The signature is a CYA measure and gives modelers a false illusion that their work is done. 

This false sense of security with the signature only puts up barriers to the ongoing communication that is required.  It forces downstream parties (developers, release managers, quality assurance, information technology support, users, etc.) to deal with aspects of the model that are subpar.  Given that models are generally developed in design or development phases that are pre-quality assurance and other forms of pre-production testing, there could be hesitancy to update the model during these phases. 

Application code cannot be ‘signed off’ like a data model.  Sure, the code design document can be signed off, but not the code itself.  It is understood that it will change.  Why not the data model?

I have never seen a data model that was done, only ones that people thought, for a short time, and at peril, were done.  Modeling is never done.  As the most leverageable component of the information architecture, from which all other work is based, it is essential to get it right.  If you get the data model correct, the data has a much higher chance of having quality.  Get the data model wrong and you spawn innumerable downstream workarounds and organization gyrations which run cover for the model shortcomings. 

But getting it right is only accomplished when you are allowed to accommodate new learnings about the model through production and beyond.  The first part of ‘getting it right’ is ‘getting it’.  You have to have a model to ‘get’.  As a modeler, you have to deliver a work product and cannot wait for exhaustive requirements collection.  Business cycles do not wait and corporation patience has worn thin for long cycles which lack progressive deliverables.  Hence, the model will need updating long after the born-on date.

Signature implies finality. It limits ongoing conversation with the participating parties to requirements.  Like one twitter list I’ve found myself on (id: @williammcknight) is named “People who need to pick up the phone more and get some more sun”, data modelers need to pick up the phone more (I’ll spare comment on the ‘more sun’).  Ongoing conversation with the requirement parties is essential.  Asking for signature is a way to choke off the communication.  It is actually easier to get signature than it is to create the relationship with the business that is required for model success.  Hence, many use signatures as a shortcut – a ‘task’ that can be checked off instead of attempting a difficult-to-measure relationship.

One counter to this criticism of signatures of the model is that you can get them with the caveat that there still may be change.  To this I would ask ‘why would someone bother with signing a work in progress? ‘

A typical ‘signature’ environment would look like this:

Day 1: Signature obtained on logical data model at the end of development, model and corresponding code goes into quality assurance  

Days 2 – 10: Most is well with the testing, though there are some code updates; modelers start their next project!

Days 11 - 20: Testers and developers see where the model could be updated, but avoid asking because model change is supposedly taboo so they just make code changes and make the best of it

Days 21 - 30: Testers and developers have been working 12 hour days to keep the testing on schedule and ‘work around’ the data model shortcomings until the dam breaks open and the torches are lit for the modelers (the visual here is old Dracula movies with villagers brandishing torches)

Days 31 - 40: The modelers are called off their new project and brought back in to fix the model.

Day 41: The result is a mix of last-minute, half-job model fixes and ignored model fixes worked around by code lines that are 1.5 X what they could be (and the modelers’ new project falling behind)

A non-signature environment would look like this:

Day 1: End of development, model and corresponding code goes into quality assurance 

Day 2 – 10: Working together, modelers and coders make small model changes in response to quality assurance and keep the code tight

Days 11 – 20: Continued working together, modelers and coders make small model changes in response to quality assurance and keep the code tight

Day 21: Throughout the 20 days, there was never a panic, nor were there workarounds; appropriate changes made to code and model; the result is a well-done model and tight code

What do you think?  Can you maintain the necessary communication and updates after a signature has been granted?  Or should the model truly be locked down?