Data Governance Blog

Mayan Date Stamps

The other night on NOVA, there was a fascinating special; Cracking the Mayan Code. http://www.pbs.org/wgbh/nova/mayacode/ What made it so fascinating, and relevant to this blog, was the fact the key to unlocking the written Mayan language was the standard method they used for recording events. Their standard to recording numbers and ultimately timestamps provided the key needed to unravel the remainder of the glyphs.

I could relate to the archeologists scouring the ancient sites and what was recorded in stone, since as a report analyst I’ve often scratched my head trying to decipher the meaning the data record on hard drives in the data center. While modern data analysts have the advantage of knowing that a field is a date/time data type, the meaning and definition of the rest of the data may remain a mystery due to the lack of a data dictionary, or due to inconsistencies within the data itself. The lack of standardization prevents the analyst from decoding the meaning in the data.

This became very real to me with a project I worked on to deliver near real-time reports. The project requirements stated the workflow milestones needed to be recorded with the date and time of the events. The developer implemented just as the requirements stated and the testers validated that they were correct. Then we went live. We discovered some actions were ending at times before they started which totally threw off our reporting. We overlooked that the workflow would be completed by teams across time zones. The step may start in Florida but be finished by someone in Texas.

We missed a standard element of a timestamp, location relative to Greenwich. See while we normally express time in hours, minutes, and seconds, the time zone is implied to be the one we are in when we say the time of day. After the “duh” moment, I started looking at other data in our systems. There was no mark or field to indicate what time zone was associated with the time.

It was then that I realized we are continuously and wastefully redefining the date-time stamp each and every time we need one. We were not pulling from a standard. Then I looked at other data; customer name, account, etc… There were as many variations as there were applications. Again, the organization was continuously reinventing the fields on the fly. Never did the company, define once and reuse many.

Now not counting computer languages, I’m good to speak one language fluently and one other acceptably (but I can order beer and wine in six!). Why do we expect an IT department to fluently handle over 20 languages (data models)? Is it a wonder that changes take forever and we often misinterpret data? Each corporation has created their own little United Nations of data and until they decide to begin to standardize and reduce the number of data models deployed they will keep struggling to rein in the total cost of ownership.

__________________________________________________________

Thanks for stopping by. My writing is intended to take a lighter look at Data Governance, and toss in some pragmatic advice along the way.  If you are interested in more information on how to implement Data Governance in your organization, please contact me via LinkedIn or the email address below.

Regards,
Tom Jesionowski

LinkedIn Profile