As I See It: Goldilocks and the Zen of IT

All right kids, grab your blankies and pillows, get comfy, and I’ll tell you the story of Goldilocks, the IT Zen masters, and the three migration options. Once upon a time, there was a CEO everyone called Goldilocks because she had curly blond hair and the people in her company suffered from a paucity of imagination. Goldilocks had a problem. Her enterprise system was toooo old, her employees were toooo inefficient; and, if things didn’t change soon, her annual bonus was going to be toooo small.

Goldi had two migration choices and both were real bears. There was the “big bang” approach, where some vendor drops a lot of very expensive hardware and software in your lap, and upsets just about everything and everybody. But that approach was toooo risky.

Or, she could try the “incremental” approach, where aging components are gradually replaced, and archaic software is converted one application at a time. But that approach was toooo slow.

Squirming on the horns of her dilemma, she headed (as best she could for someone squirming on horns) for the nearest bar–eh, I meant to say salad bar, kids–where, as luck would have it, she ran into two very bright guys. She knew right away they were bright because they wore “I’m Ivy League Educated” buttons on their Tommy Hilfiger sweaters. And they could see right away that Goldi was upset, so they did what bright guys do when they see a distressed CEO, they introduced themselves as consultants. Their names were David Upton and Bradley Staats, and they sat crunching croutons while patiently listening to her lament. When she was through, they nodded knowingly and told her there was a third migration option: they called it the “path-based” approach.

That sounded very Zen to Goldi, but how Zen could two guys with wing-tips actually be?

Goldi chewed a carrot thoughtfully, wondering where her path would lead. She knew that going through a lengthy system conversion is like buying a new car only to discover that when you finally take possession, the car is two years old. So much effort was required to install an enterprise system that by the time the last application was launched, the business environment had in all likelihood changed, and the solution was already well on the way to being obsolete.

And those pesky users! Always falling off the path, changing their minds, demanding new features after they’d already signed off on all the features they could possibly need if they worked to be 100 (which many of them would have to do since Goldi spent down their pension fund some years ago). Users were always complaining, and, if you couldn’t give them what they wanted fast enough, they’d lose interest and orphan your system before it was even operational. It didn’t take much to convince Goldi that “technical problems were almost never the reason that new IT systems flopped. Human problems were.” Yeah, those humans, Goldi thought morosely, the cause of all her business problems. Come to think of it, they were the cause of her personal problems too, but that’s a story for when you kids grow up.

In a moment of blinding clarity, Goldi understood that being one with IT required maintaining “focus on foreseeable business objectives, not the existing environment.” Otherwise, Upton and Staats, warned, you’d just be “paving. . . the old dirt paths.”

That sounded Zen-like too, but the old path was worn and she needed to replace it with a four-lane highway. It all seemed too complicated and she again began to despair, when their next remark confirmed Goldi’s growing suspicion that Upton and Staats were really IT mystics without yoga mats.

You must “strive for extreme simplicity,” they said.

Goldi was momentarily confused. Wasn’t striving for simplicity an oxymoron? Like toiling for leisure. But that was the Zen-like beauty of their approach. Ideally, they said, enterprise system design should be limited to a single platform, a single operating system, and just one network protocol. Mainframes “were expensive and difficult to keep up,” said her companions, showing a strong grasp of the obvious. The annual cost of maintaining them “is 15 percent to 20 percent of the original purchase cost.” They said a Japanese bank had simplified from a mainframe to a server-based platform and saved “$40 million in expenses annually.” And they had other great ideas for simplifying and saving money. Like “installing two Internet connections from two different providers” for connectivity that was more reliable than a leased line at one-tenth the cost. Goldi looked at her lettuce, which reminded her of her bonus, and smiled. She breathed in simplicity. If she simplified enough, she could probably get rid of half her IT staff. A soothing thought if ever she had one.

Packaged software was problematic, Upton and Staats said, because you “often end up adapting the business to the technology.” Yes, they admitted, best practices are sometimes embedded in packaged software, but more often than not “managers sacrifice idiosyncratic, competitively powerful capabilities that the system could make possible because developing them would add to the time and cost of carrying out an already expensive time-intensive project.” Goldi didn’t know exactly what all that meant, but that’s the way it was with Zen: First there is an idiosyncratic, competitively powerful capability; then there is no idiosyncratic, competitively powerful capability.

True “modularity, not just modules,” Upton and Staats advised, would allow her to “build solutions to local problems without disturbing the global system.” This, they said, required “clearly specified interfaces so that development work can take place within any one module without affecting the others.” Like her modular shoe tree, she could always add another pair without disturbing the rest.

But what could she do about those annoying users? Sure, they clamor for new technology, but then vapor lock when it comes to learning something new. Could she trust them to embrace a new system? But again, Upton and Staats had the answer. “Offer an interface, or screen format, that is similar to that of the old system.” It just might work. After all, her users weren’t all that bright, maybe they wouldn’t notice. Not knowing. It was so Zen. As Cheng-Tao Ke said: “Ignorance is in reality the Buddha nature.”

To be truly useful, Upton and Staats concluded, a major IT system has to be a launching pad for future strategies and new functions. No longer is rolling out a system the equivalent of building a warehouse, they warned–just because you’ve built it, doesn’t mean you’re done. Nor is the object to build “cathedrals,” which are “costly, take a great deal of time, and deliver value only when the project is completed.” Today’s perpetually changing business environment requires something akin to mobile chapels, adaptable to the particular faith embedded in each unique business function.

Goldi had a lot to think about, but already she was feeling much better. She could fool the users, meld business and IT strategies, go modular, embrace simplicity, and salvage her bonus. She thanked her companions for their good counsel, and quickly headed back to work before they could hand her an invoice. When Goldi walked past the data center, she smiled. While the “big bang” approach was tooo risky, and the “incremental” approach was tooo slow, the “path-based” approach was juuust right.

And that, kids, is the function of Zen in IT.

For a more lucid and detailed elaboration of the author’s ideas, which have nothing to do with Zen or Goldilocks, see the March 2008 issue of Harvard Business Review.

                     Post this story to del.icio.us
               Post this story to Digg
    Post this story to Slashdot