Agile Data Design – August 2012

In my lectures on Business Data Management, I’ve often told the story of the Fairwind. The Fairwind was a New England lobster boat, which set sail from Cape Cod in November of 1980 for a week’s fishing on the Grand Bank. They had, of course, checked the National Weather Service forecast before they left; storms had been reported in the North Atlantic, but no storm activity was forecast for the area in which they were fishing. To their dismay,they sailed directly into a fierce gale, with 100 mile per hour winds and 60 foot waves. The Fairwind, with a crew of three, sank in the gale; a fourth fisherman, Gary Brown, was swept from his boat, Sea Fever.

It was later discovered that one of the NOAA’s weather buoys in the North Atlantic wasn’t working; weather predictions were being made based on the input from nine weather buoys, not ten. The input from the 10th buoy could have made all the difference in ensuring an accurate prediction of the storm, a fact that was cited when a U.S. District Court awarded a $1.2 million judgment to the families of the victims.1

I’ve been thinking about the Fairwind story for another reason this week: I’ve lost two long-time friends this week, one in Texas and one in Utah. In both cases, I had been out of touch with them for at least a year; in both cases, my friends had been struggling with serious issues I’d been unaware of. I had let the opportunity to stay involved in their lives slip away; now that opportunity is gone forever.

When we in Data Management talk about data quality, we are almost always referring to the quality of the data we have; we rarely think about data quality in terms of the data we need, and don’t have. When we converse with someone, we usually focus our attention on what has been said,not on what might have been left unsaid. So we need to pause, from time to time, and remember that what is left unsaid is often more critical, from an information standpoint, than what has been said.

To put this another way, we really need to focus on information, rather than data. I’m a huge John Zachman fan (I have a signed copy of his Framework hanging in my office); nevertheless, I have always been disappointed that the “What” column in his Framework focuses on Data, rather than Information. Rather than compiling “a list of things (entities) important to the business”, we should be asking more fundamental questions: What is it that the business really wants(or needs) to know? What information, if they had had it even a few weeks earlier, might have made all the difference to the business? What information is currently lacking that is impeding decision-making and effective action? What organizational, social, political or behavioral obstacles are impeding the free exchange of information across the business? It’s not only the data we don’t have that hurts us; it’s what we don’t know,and need to know.

And what we know does us no good, until and unless the information we have is acted upon. Remember the minivan craze of the 1980s? GM didn’t produce a minivan until after Chrysler and other competitors had launched their best-selling models, even though they had market research indicating that minivans could be commercially successful.  Ford produced its Windstar minivan with only one driver-side door, even though its market research indicated that a second driver-side door would appeal to consumers. After the success of Chrysler’s minivan (which had a second door), Ford had to take its minivan back to the drawing board, and GM decided to integrate market research into its product development process. It’s not only the information we lack that hurts us; it’s the information we have that isn’t acted upon.

So let’s take some time to reflect on the information voids in our own lives, and in the lives of those we care about. Hug your kids. Say “I love you” to your spouse or partner. Get in touch with a long-lost friend, family member, or colleague. Smile at a total stranger. Life is short, and fleeting. And, as the crew of the Fairwind could tell us, that which is left unsaid can be the difference between success and disaster.

NOTE: I’d like to make this a dialogue, so please feel free to email questions, comments and concerns to me. Thanks for reading!

Reference: 

  1. Spokane Chronicle, August 12, 1985, page A1.

Share this post

Larry Burns

Larry Burns

Larry Burns has worked in IT for more than 40 years as a data architect, database developer, DBA, data modeler, application developer, consultant, and teacher. He holds a B.S. in Mathematics from the University of Washington, and a Master’s degree in Software Engineering from Seattle University. He most recently worked for a global Fortune 200 company as a Data and BI Architect and Data Engineer (i.e., data modeler). He contributed material on Database Development and Database Operations Management to the first edition of DAMA International’s Data Management Body of Knowledge (DAMA-DMBOK) and is a former instructor and advisor in the certificate program for Data Resource Management at the University of Washington in Seattle. He has written numerous articles for TDAN.com and DMReview.com and is the author of Building the Agile Database (Technics Publications LLC, 2011), Growing Business Intelligence (Technics Publications LLC, 2016), and Data Model Storytelling (Technics Publications LLC, 2021).

scroll to top