Monday, September 17, 2018

How to talk to your manager about Semantic Debt

There's a long post still coming, but for the last three weeks I've been busy with (a) a fruitless bowhunting trip, (b) a book proposal and (b) a stunning flu that left me and my family lolling around the house like indolent aristocrats.  Even the dog is embarassed.  So I haven't had a chance to get the matrix I promised filled in.

But there's some detail we can add to our matrix that's both useful, topical and untheoretical:

I often try out my architectural thoughts on a friend who functions as a one-person data warehouse team wherever she goes.  She's capable of doing anything from the moment someone says they want one to the moment she hands you the keys, but she'd really rather not do even most of it anymore, because its done better with other people's help.  She doesn't feel a lot of need for architecture in Data Warehousing because she's already pretty good at it, and happy to ignore it as well if its dumb.  Since most projects end up going down a couple of different paths, ones that anyone who's done more than once can start to recognize, there's only a couple of ways to start and proceed that avoid those parts of the process.  She generally replies to my thoughts, if they're bad ones, with polite silence.  If they're good ones but possibly not doable in the three-month cycle her strategic timeline has been reduced to, she replies with some combination of encouragement and practical concern.  She'll say something along the lines of "very interesting Dave but why should I care?"  (It doesn't sound as mean when she says it.)  And her practical concern with semantic debt is: OK let's say this is the right way to describe the problem.  How do you convince someone to do something about it?  If there's a project going overboard right now that you could save if you did the right thing (and if what I'm saying is the right thing to do), then what would you say to people to get them to do the right thing?

This gets to the heart of any big-picture problem in data management: No one believes they've got a problem (except for the data management people) until suddenly they've got it.  Every data management challenge is going fine until it ends up in the emergency room.  Almost everything in data management appears to be a sudden failure that last for twelve months. 

I've been thinking about my friend's concern for a while, as I keep expanding the framework.  How do you convince an organization that there's consequences to bad data management?

One way to do it is to predict what will happen if they get it wrong.  That may not be the best approach, but its a start.  So here we go.  I'm going to go through the matrix and give you consequences for each cell.  That is, if you've got semantic assets in Sudden failure with Type 3 debt, what happens to you?  So here's a first cut, with some very specific examples.



I've put a Google Sheets version here.

No comments:

Post a Comment

The point of this blog

Welcome to the beginning of the film

In the twenty-plus years I've worked in data management I've spent a lot of time having some version of the following conversati...

Top 3 Posts