On a recent road trip my hotel room shower provided an excellent physical example of the poor planning behind many data and tool infrastructures. Don't get me wrong; it was a very nice bathroom. I prefer to stay at Hilton hotels, and this Hampton Inn was quite nice. The bathroom was clean* and looked like a lot of care went into the visual appeal. Each individual component did what it was supposed to do. At first glance, the system looked solid.
The shower stall was spacious -- probably six feet deep, very comfortable.** Here's the problem: the door was at the opposite end from the shower head and taps, and the shower head was fixed in place. There was no way to turn on the water without being blasted immediately.***
Worst shower design ever.
Of course, the system owners can't easily remedy the problem. Relocating the taps is an expensive, laborious process. Changing the shower head is the most likely option, except that the supply pipe from the wall had no threads. And this is a hotel; the change has to be replicated in about 400 locations.
So, the infrastructure and a major delivery system were either not planned together, or not planned with the end user in mind. They do the job, but the user experience is poor. Sound familiar?
Here's the cardinal rule of system planning: you must start with the desired outcome. That's the bare minimum. Really, you need to start with the desired outcome AND some conception of how the system will be extended later, but since many organizations can't even force themselves to start at the desired outcome I'm going to pass right by the concept of extensibility right now...
I can hear many of my ex-colleagues at Microsoft thinking, "We're great now at starting with the desired outcome," to which I say "Bull dookey."**** After 16+ years of seeing systems developed at Microsoft, I'd say these are the most common starting points, in order of frequency:
- We need a data-origination tool! Engineers need to track labor, we need to gather customer feedback, we need to track expenses. Data input, build a tool!
- It's consolidation time. We recognize (for the thousandth time) that we have dozens of non-communicative data systems, based on all these individual tools, and we're going to build (wait for it) a consolidated warehouse! Oh, and our organization has convinced our new leader to fund a new consolidated warehouse, so we're going to ignore the eighteen other consolidated warehouses...
- The new boss wants a better scorecard, and wants it now. We'll just build a cube for that, created some measures, and hell, if there's enough funding, how about a tool to go with it, with some "scrubbed" data? Wait, the measure don't match the calculations from other tools? Bummer.
- We are looking at the desired business outcome and planning the system accordingly. However, time is of the essence. Let's start with (wait for it) a new consolidated warehouse! But this time is different. This time we're going to plan on doing a serious data overhaul some day. No, seriously, we will!
- (We're going to start with the outcomes we need to support, define the insights we'll need to provide that support, define the data structure needed to eventually deliver those insights, and build the tools on that new data structure. We may even take this is as an opportunity to totally redefine some of our key business concepts.)
I put #5 in parentheses because in over 16 years I've rarely seen it happen, despite being the correct approach.
The concept here applies to any business or system, whether it's a single-person sole proprietorship or a corporation with 100,000 employees: when planning your data and tool infrastructure, start with a full set of desired outcomes -- tactical and strategic, internal and customer-facing, immediate need and future-proofing.
As an example, my game company is working on the design of our first online app. We've considered a few features that didn't make the cut for the first version: league play, private instances, and end-user administration, to name a few. However, the data infrastructure includes placeholders for all these concepts. If we choose to implement any of them later, we won't have to patch or overhaul the base system to do so. Thanks for the lesson, Microsoft.
Oh, and to the Hampton Inn: I know you can't do anything about that shower stall tap location, but perhaps you could put a towel hook somewhere near the door?
* Cleanliness is my #1 criteria for a hotel, particularly the bathroom and the bed. I can put up with a lot in the way of noise, price, or lack of customer service, but if the bed looks unclean...I'll sleep in the Canyonero.
** Especially if you've been driving all day and haven't gotten much exercise. The Fitbit Surge is water resistant, so you can get some steps in while showering.
*** I say there was "no way," but that's not quite true. I did think out of the box, but the best immediate solution was to stand on the toilet, reach over the shower wall, and activate the taps. I tested this method and found that at 5'9" I'm about four feet too short to make this work.
**** I don't really say "bull dookey," but I try to keep my blogs family-friendly, so...