Apr 6 ’11

IT Sense: The 80/20 Rule

by Editor in z/Journal

Recently, I participated in a panel discussion on the role of mainframes in cloud computing that featured spokespersons from IBM and CA Technologies as well as technology consumers Al Vazquez from Morgan Stanley and Sam Knutson from GEICO. The event was broadcast to mainframers around the U.S. I won’t go into the details of the panel discussion here, since replays will be available via the Web shortly, but I do want to explain why Al Vazquez became my new best friend.

During breaks, I had a chance to hang out with Vazquez and understand his world a bit better. He’s responsible for serving up information to his financial services company in one of the most frenetic and information-hungry market sectors today. In the course of our conversation, Vazquez made some observations that merit everyone’s consideration. One of these was his spin on the “80/20 rule,” which had to do with application development. 

He observed that a bit of realism might help the IT folks in the back-office regain the trust and respect of the front-office. He said that IT has a tendency to be facilitative; we have a natural desire to please—to say that everything a user wants can be delivered. We like to validate our worth by promising to provide all that the business manager asks for, which—while this may be possible to do technically—often isn’t viable from a budgetary standpoint.  

According to Vazquez, and confirmed by my own experience, the cost for delivering the first 80 percent of the system functionality requested by a business unit is usually a fraction of the price that accrues to delivering the whole shebang. The last 20 percent inevitably requires more development, testing and quality control time, and effort than the rest of the project. 

Vazquez’s words rang very true when he offered that the smart approach was to tell the business folk, “We can deliver eight of the 10 things you want for $50K, but those last two will set you back an additional $250K.” While it may go against the grain to talk in terms of costs, thereby disappointing the user’s dreams and aspirations, the payoff of the strategy is a perception of truthfulness and common sense that might translate into trust from the front-office later.

Trust is a currency whose value has a tendency to fluctuate. Right now, the front office’s trust of internal IT is generally trading at a low. For one thing, the overwhelming noise from the cloud computing aficionados and their echo chambers—especially the subterfuge that it somehow makes internal IT (and its related costs and headaches) just vaporize—is making lots of business folk wary of building anything internally.

Truth be told, mainframes are clouds by definition. They offer standards, security, dynamic provisioning, and a systems management paradigm that drives cost to the bottom line naturally.  None of the distributed systems models for cloud platforms can say this. The x86 server technologies, with their software hypervisors and guest machines, may be an interesting science fair experiment, but their lack of coherent management and common standards make them a “Jenga!” architecture I wouldn’t trust with my mission-critical workload.  

Moreover, I’m increasingly convinced the vendors that are standing up these stacks of hardware and software called “cloud platforms” have little interest in working and playing well together, so there’s no coherent model for combining resources from different suppliers to deliver services in a predictable way. This, in turn, makes most cloud services potentially more expensive for the large enterprise than rolling your own mainframe computing infrastructure internally.

I know this flies in the face of all the reporting about the “cloud revolution” and how it will mitigate IT costs. And it certainly runs contrary to the view that mainframe computing, especially its software, is expensive. Yes, software costs money. Application development costs a lot of money, too, especially those projects based on budgetary promises that can’t be kept. But attacking the problem has less to do with technology than with truth.

The next time someone from the business side of the house asks for an application that can do 10 things, give that person the real scoop on what it will cost to deliver the eight easy things vs. the two really expensive items. He may be disappointed in the short term, but will thank you later.