One of my favorite stories from many stints as a manager was the direct-report with deadline problems who we sent to an expensive, full-day time-management seminar to try to help her get her life and work schedule under control.
She thought it was a great idea; a way to learn techniques to make her life less stressful and her work more consistent.
She left halfway through the seminar because she couldn't afford the time to finish it without being late on projects she'd accepted since having scheduled the seminar.
The only reason I tell that story (the histrionics of which make it a lot funnier in person) is that no one I know still remembers Catch-22 as anything but a kind of stale old story about a ridiculously hidebound organization and a guy who couldn't get something done because of a rule that he couldn't do it unless it had already been done.
Which is fine if you're writing an English Lit. essay, but not the kind of thing that makes for useful revelations at work.
Revelations like: if the adage (and Gartner report) is correct in estimating that 80 percent of the work and budget of the average IT shop goes to "keep the lights on" legacy apps, routine maintenance and support, then only 20 percent of the total resources of IT will be available for all the other projects users are clamoring to have done.
That means – even if migrating many of your legacy apps to the cloud will save a lot of money, a lot of time in management and ongoing development, and make end users happy by improving performance, making the legacies available from anywhere and adding features the apps never had before – that many IT shops will never get around to doing that migration because they're too busy splitting the meager 20 percent of their available time among the 25 or 30 projects users are demanding be finished right away.
This according to "The Great Cloud Blockage," a blog entry from Ben Kepes, a tech investor, consultant and business developer who has written extensively on the business implications of both cloud computing and the business of providing cloud services while working with RackSpace, CloudAve and a range of other SAAS and cloud companies over the years. **
His post came out of a roundtable discussion on enterprise cloud adoption that included the VP of strategy from Salesforce, cloud architect at Netflix and former manager of global systems at Bechtel.
The conclusion that the migration of legacy apps to the cloud face a "Catch-22" not only because IT often can't spare the effort to make the migration happen, but often can't justify the cost because bean counters look at total historical cost of the legacy systems compared to the additional cost of a new cloud system.
The right way to look at it, Kepes writes, is that cloud based systems typically cost less, even though their cost per transaction (or other unit of measurement) is higher. Even with a higher per-unit cost, fewer units are being used, so the total cost is lower.
That's Cloudonomics Law No. 1, btw, but it's one that both CFOs and CIOs ignore. CFOs believe in the value of per-unit cost measurements; CIOs don't know enough about accounting or finance to challenge their assumptions.
Cloudonomics Law No. 5, btw, is that the fixed costs (the 80 percent that keep IT from doing more than keeping the lights on) come down with the number of units of work. So a cloud company like Amazon will be able to build an infrastructure capable of handling far more transactions than any mid-sized company and most large ones, simply because of the economies of scale that come with volume purchases of hardware, software licenses and network bandwidth.
So, even companies paying a higher per-unit cost to an outside cloud provider than they would pay doing it in-house, is paying less that it would if it built the same cloud system itself.
Combine the two and it's clear that the Catch-22 is more an illusion caused by inertia than a real barrier in cost/benefit analyses of either work-hours available or budget being spent.
The trump to all this is that business units recognize that IT is stuck in a rut, but often credit it simply to being the kind of uncreative, unambitious fringe player that stays in a rut because it's safer there.
Business units, swelled with ambition, pride and the desire to embrace ad hoc'ery for the opportunities it brings (and, tell the truth, to keep from being bored spending all day selling things) go off and buy cloud services or SAAS apps or whatever other external IT services they think will help them get ahead, often without consulting IT.
That causes a lot of problems for IT in the short term, and for the business units in the long term, because IT loses control of the data security, application reliability and information-asset awareness for which it is responsible.
Business units, meanwhile, end up disappointed with the performance of cloud providers, mainly because they don't know how to write a contract with good outsourcing and SLA conventions, let alone know how to maintain that relationship.
That's the real Catch-22 – everyone ends up frustrated and performing poorly because their focus on the skills they bring to the table and satisfying their own need for performance-review-enhancing Goals to list makes the operation of the whole company less effective, damages their careers and fortunes in the long run and never does achieve the savings in cost and efficiencies in workflow and time they hoped would set the stage for other improvements.
Not a great situation. Too bad they couldn't have stayed for the rest of that seminar on cloud management; they might have figured out what tools they could use to solve the problem, not just what terminology they could use to best describe it.
** [Note: In the original version of this blog entry I mistakenly credited Kepes with co-authoring Cloudonomics, a term coined by top HP exec Joe Weinman, who also created a multidisciplinary framework to analyze the economics and effect of the cloud, has had a wide enough impact in the development of the cloud, written widely enough about cloud and Cloudonomics, modeled many of its effects and published enough academic papers about cloud computing to make it extremely difficult to attribute origination of the Cloudonomic school of thought to anyone else. The feat was accomplished with no assistance whatsoever by your humble author, who offers his apologies for making so unlikely a mistake.]