At one of Sun’s Bay Area campuses, the buildings are oriented in a half circle. The cafeteria (and a couple other buildings) are dotted in the center of the half circle, which leaves our employees walking around a curved path to go from one end of the campus to the other. Despite the best intentions of the people who designed the campus, our folks etch straight paths in the lawns to save 10 or 20 paces they’d otherwise spend on the curved concrete path. And if you find yourself walking back and forth across campus, 10 or 20 paces multiplied by a few trips does, in fact, add up.
Now there are two ways to look at the problem of dirt paths. One would be to put up a sign, and vector people to the concrete path. Just being honest, this would fail at Sun. The sign would end up being a blog topic (and likely hung as a prize in someone’s office), and the paths would end up as mud pits. The more practical approach would be to pave the dirt walkway, and just admit that convenience is more powerful than elegant design. So that’s exactly what we did, paved the paths. Don’t fight convenience.
Now that’s not to suggest convenience always yields the right answer – a point made plain to me when I took my 2 year old to get his hair cut this past weekend. He wasn’t particularly happy about the ordeal, and the only thing that seemed to calm him down was my sitting in the haircutter’s chair with him on my lap. Midway through his haircut, the pleasant but frenzied woman cutting his hair asked if I’d like mine cut. Foolishly, thinking “how convenient!”, I consented.
I now face a minimum of 60 awkward hair days, and the tradeoff wasn’t a good one. Live and learn.
IT organizations, like walkers on our campuses or me at Kid Cuts face decisions based on convenience all the time. And they, like me, often live with the consequences (for typically far longer than 60 days). And in talking about the standardization of IT infrastructure, from grids to our Java Enterprise System to Solaris, I’ve seen a range of decisions in the face of convenience that are worth noting.
A few examples:
I was recently with a customer in the retail industry that continues to run its own private Linux distribution. The distro was developed a couple years ago, by a team that stepped off the beaten path for good reason (at the time) – that same development team now owns maintaining the distro, and making decisions about whether to replace it. As time has moved on, the customer has found no major ISV willing to certify to their private distro (without a check, that is – we declined the opportunity to port our Identity engines), and the team involved has found themselves buried with support obligations – driving more resource requirements while the parent company is looking to prune costs. I’ve seen a number of companies in this predicament (a few on Wall Street, btw).
My view, in this instance, is the “private distro” mud path should be paved with a commercial product, on the assumption Sun, Red Hat or Microsoft will all outinvest and outsupport the dedicated team – and bring with them a bevy of already certified ISV’s. But neither the team, nor their management, will hear any of this. “Our OS costs less than Solaris, it’s free.” Right, free like a puppy.
Consider another example – a packaged goods company deploying a large scale enterprise application, that failed to resist the tempation to customize their implementation. Their customization looked convenient (the end users will get “exactly what they want”) – but such customization actually ends up creating bad hair days for CIO’s (and CFO’s) that linger for years. As with the custom distro, a custom SAP or Siebel or Amdocs deployment is vastly more expensive to support than a “standard” off the shelf implementation. The short cut, even paved over with a “commercial off the shelf” product, stays pretty muddy.
Now contrast this with true network service offerings. How much do you customize EBay? Or PayPal? Or MLB.com? Or your Cingular phone service? Not at all. Which brings me to our grid.
As you’ll recall, we announced $1/cpu-hr offering a few weeks ago. At this point, we’ve had the benefit of talking to a large spectrum of grid opportunities. And it’s becoming obvious that there are two sets of customers. The first set is eager and willing to listen to the concept of using infrastructure as a service. They quickly move to architecture and security as areas of primary focus. Once there, we get on with finding immediate applications to leverage the grid, and we start a proof of concept. These folks understand the power of convenience – our grid offers our customers an ability to use our computers, our capital, our networking, our storage, our operating system, electricity, real estate, HVAC and administrative automation. Which is far more economically and strategically convenient than building your own grid. Especially when the time comes to walk away if plans change. Truly on demand, implies truly off demand.
Now the next set of customers starts their interaction with us in a different way. “We build our own grids, we’ve done the math, and it costs us less than $1/cpu-hr.” Now, I recognize this may not ingratiate Sun to a segment of the marketplace, but many of the folks who present that position are actually responsible for the creation, maintenance and support of in-house grids. The always unasked question in these dialogs is, “does your calculation include your salary?” More often than not, it doesn’t. And even that’s not the totality of the equation – if you add in the real estate costs of housing your own grid, the electricity costs to keep it running, the costs of securing it, insuring it, administering it – I could go on and on. These costs, from among those convinced they’re operating at below $1/cpu-hr, are in every situation I’ve encountered, left off the tab.
Now it’s an emotional issue, no doubt. And it’s one the entire industry will inevitably grapple with, as we move toward enterprise application service providers such as Hewitt/Exult, toward commercial service providers (like eBay’s partner storefronts), toward pre-built (vs. custom built) operating systems or enterprise software – all in all, the standardization of IT will only truly occur when the IT industry makes it more convenient – and when enterprise IT culture evolves to recognize it. At home, we’ve all realized using network services like weather.com is by far more convenient than running a server farm.
At work, I’d say we – the IT industry, and IT culture, have a ways to go.