IT Operations — Usual Musing

While waiting impatiently for the next season of The Man in the High Castle, I've been re-watching Game of Thrones. Given that HBO has put off the final season by a year, and George R. R. Martin is now tentatively scheduled to deliver the final books sometime in the year 2030, I'm picking up a few of the tidbits that I missed the first time around.

A great example came up sometime in Season Six. Strife in the Greyjoy household! Uncle Euron comes home, murders his brother, and assumes kingship of the Iron Islands. Theon and Yarra, his niece and nephew, steal the best ships from the Iron Fleet and sail away, presumably with a significant number of the island warriors.

Uncle Euron is undeterred, however. He holds forth with a rousing, inspirational speech, which ends with, "Build me a 1,000 ships, and I'll <something something something about conquering the world.>"

Um, say again? Build 1,000 ships?

Yep. Euron commands all hands on deck. Every man felling trees, cutting lumber, and banging ships together. Every woman stitching sails and weaving rope. Apparently it's just that easy. Time is a bit murky in the GoT world, but it's certainly only weeks or months before Euron is sailing with a massive armada that decimates Yarra's fleet.*

It occurred to me that I've actually seen this episode many times, and not just on HBO. Operations, and BI in particular, are often the subject of the "Let's just dive in and do it in no time!" mentality. We've got a business problem that we didn't anticipate. Someone thought of a major new initiative while showering. Or worse, someone attended a workshop, saw some cool data visualizations that a vendor spent months building in the app they're trying to sell, and wants something similar in the ecosystem -- tomorrow.

"Build me 1,000 KPIs, and I'll give you the Seven Kingdoms!"

Here's the problem: building a ship isn't that easy. There are plenty of skilled trades involved in shipbuilding, and even with motivation provided by leadership's "can do" attitude**, the application of massive manpower rarely makes up for the correct skill and experience. One hundred foot soldiers can't significantly speed up the proper shaping of a keel, and if the keel is faulty, the ship is ineffective.

Likewise, a dozen vendors who know nothing of your business and data can't slap a quality BI infrastructure together overnight. So, how about pouring on the labor from the opposite direction? Open up the BI platform to those who have the business knowledge, if not the technical skill. After all, your account managers, team managers, and sales folk can just pick up some data skills with an hour on Lynda.com, right?***

There's a big difference between using a tool daily and having the skills necessary to build the tool. Most sailors spend a great deal of time onboard a ship, one might expect, and they're probably aware that it's supposed to float. Put them in charge of building one, and it'll probably have as auspicious a career as the CSS Neuse.****

Of course, you may be thinking that this is a terrible analogy because Euron Greyjoy's team DID finish 1,000 ships in virtually no time, smashed the Iron Fleet, and captured a bunch of key enemy leaders. Don't forget -- Game of Thrones is fiction. And fantasy. Reality would have made that subplot would have made that subplot a bit anti-climactic, when Euron's armada set forth and promptly sank.

Strong leadership hires strong specialists, then paves the way for those specialists to do a quality job. Cut corners and throw wrongly skilled labor at your projects, and you may as well wait for the dragons to fly in and save the day.

* I'm not apologizing for "spoiling" an episode that's been out for over a year.

** Or the motivation provided by Uncle Greyjoy's "do it or die" attitude.

*** I also don't believe that 1,000 monkeys on 1,000 typewriters will recreate the works of Shakespeare. However, they probably could come up with the NFL's rules on what constitutes a catch.

**** It's an interesting story. Look it up; you can thank me later.

Apparently it's going to be business intelligence week on my blog, since this entry on my fifth rule of business intelligence makes three in a row* on the subject. This time, I'm going to give you the rule right up front: documentation must be a requirement of BI development, not an option.

This might seem like a no-brainer -- if you've never worked in an actual IT or operations department.

In a decidedly non-scientific method of evaluation,** I'm going to hazard a guess that documentation is considered a "nice to have" in about 99% of BI (and general IT) operations. More specifically, documentation is an activity that leadership and management teams typically refuse to budget time for, yet lament the lack of when things aren't so clear later. The strongest adherence to a culture of good documentation tends to be found in project management, but there's far more to documentation than just the project charter, Gantt charts, and status reports.

On the developer-facing side you've got data source, acquisition, and transformation information. Development standards, style guides, platform strategy and history, data governance, retention policies, and relationship models. Facing the end user, you've got business rules references, metric and KPI guides, subject overviews, and access policies. And that's just a short list -- there are far more subjects that need quality documentation in order for your data to become a usable information asset.

Predictability is one of the major focal points as a BI matures. Every stakeholder wants to know when his or her request*** will be ready. The BI team and vendor resources grow more rigorous about organizing development into sprints, performing VROMs, and predicting the number of hours for each task. And that prediction rarely includes thorough, high-quality documentation.

After all, time is money, and it's bad enough the world has to wait 20 person-hours for that next customer satisfaction report. Two more hours for governance and documentation?**** If we just forego those activities on the next ten projects, we could accomplish an additional project in the "time saved!" We'll come back and document everything when we have some "breathing room."

Breathing room, of course, tends to occur on the 20th of Never.

Even in the one-man show of my NFL analysis I keep a rudimentary set of documentation. A field name that seems quite descriptive today can be ambiguous in a very short time of non-use. The couple of minutes I spend tracking notes in OneNote or Excel are time better spent than an hour of reverse-engineering my code later, or worse, sharing incorrect analysis because I forgot a definition.

Rudimentary, sure, but sufficient for preventing mistakes and saving time in future development.

Ever wonder why the FDA requires ingredients to be listed on food packaging? It's so you can understand what's in your food, and avoid making bad decisions. Sure, people still make plenty of bad dietary decisions, but with better information, they have a better chance of making a good decision. No one ever looks at a Cheeto and says, "Wow, a bag of these will help me lose weight!"

In BI, lack of documentation or low-quality documentation precipitates significant mistakes. A developer can create a new measure with an incorrect calculation. Stakeholders can waste time debating results because their definitions of KPIs differs. Incorrect information can be issued publicly, or to external customers.

The solution is simple. Change the culture of your organization such that proper documentation is part of the development process. Budget the time and resources to include documentation activities. Don't allow the process to be put off until that non-extant breathing room appears. And once that high-quality meta-information is available, try reading the side of the package every once in a while.

* That's right, a perfect 5 for 7!

** I.e., my gut feel after 20 years in this discipline.

*** Keep in mind that each stakeholder's current request is always the most crucial, make-or-break-our-business request in the history of the company. And Earth itself.

**** Next you're going to be demanding bathroom breaks!