How can IT compete with SaaS? Ask your mechanic

To understand the conflict between commercial cloud providers and internal IT, you need look no further than Jiffy Lube and its impact on traditional automobile repair services. What Jiffy Lube did was cherry-pick the types of service that are most frequent and that require the smallest investments in equipment, parts, and training, offering them for much less than their full-service competitors could manage, given their much higher overhead.

Sounds cloudish, doesn’t it? Because what cloud providers don’t have to concern themselves with is IT’s central challenge: integration. The integration coin and its flip side — maintaining a coherent enterprise technical architecture — are what correspond to the extra equipment, parts, and training that full-service mechanics have to support with higher prices than Jiffy Lube has to charge for an oil change, Midas has to charge for mufflers, and Tires Plus has to charge for those rubber things that wrap around your wheels.

IT disintegration all over again

The Jiffy-Lubeness of going outside IT isn’t new. Long before the cloud raised its foggy head, business departments, frustrated by their inability to get projects approved by the IT steering committee on which they sat, chose the Jiffy Lube alternative by contracting with an outside developer to build or install what they wanted. It wasn’t uncommon for the new system to be built with development tools that hadn’t appeared in the company before and to run on hardware and an operating system that were new to the data center — assuming they were placed in the data center and not in someone’s work cubicle.

Business departments, lacking IT expertise, often neglected to mention any need to integrate the new system into anything else in the enterprise in their requirements and, therefore, in the contracts they signed. That occurred to them much later, close to deployment. That’s when the developer asked what the procedure was to place the new servers in the data center and to connect them to the company’s network. It’s also when the development team started to mention the data flows into and out of the system, as well as asking about the in-house systems that were to provide and accept these data flows.

I’m not being entirely fair to outside developers. In many cases they suggested involving IT much earlier in the process. Between the department head not wanting to raise any red flags before it had to and knowing IT had no spare capacity to devote to the project anyway, IT involvement kept being deferred until there was no way to delay it any longer.

IT did its best, scratching together just enough staff time to make sure the new technology could physically co-exist with production systems without blowing anything up or creating unacceptable security holes; wrote ad hoc batch file extracts and transaction loaders to handle the new data flows; and otherwise got the blame for delaying a project that had otherwise met all of its milestones.

Then, the outside developer went away, leaving IT to maintain the mess — which is why I was able to predict with such confidence last week that when it comes to NoSQL, the exact same thing will happen.

Business integration goes beyond tech

Integrating technology is hard enough. It’s nothing but shelfware if it isn’t put to productive use. Whether it’s fair or not doesn’t matter; most businesses, being unenlightened, blame IT when shelfware happens.

Back in the day, when a business department contracted with an outside developer, the one blessing IT could count on was that the developer would be blamed if the resulting software turned into shelfware. The same is true now, when business departments sign contracts with SaaS vendors: If the SaaS solution turns out to be shelfware, IT won’t have been anywhere near the problem. In other words, if blame avoidance is your highest aspiration, the cloud is for you.

If, on the other hand, you want good things to happen in the business, consider that even when a business department signs on for a SaaS solution and makes it work, it only works inside the departmental boundary — which is fine if all your company’s business processes are so well-behaved that they never venture beyond the authority of a single business manager.

Actually, it isn’t fine, because even if that’s so, it often turns out that the functionality a business department needs is already available as unused features, possibly in an unused module, of an application the company already licenses. Well-run IT organizations, complete with well-defined and well-managed executive relationships, are in a position to have that conversation before the business department goes outside. The rest are accustomed to griping that the conversation never took place, never realizing that solving this particular problem is easily within their reach. All they have to do is reach out, and it’s solved.

Learning from mechanics

Somewhere in this tangled metaphor is an idea IT can use: SaaS is attractive to at least some business departments. Why is it attractive? They write a check and get working software quickly.

The check isn’t actually any smaller than what the company would end up paying for anything else, but it’s paid as an operating expense (opex) rather than capital (capex). This means the business department doesn’t have to go through the capital approval process — an experience that should be but hasn’t yet been banned by the Geneva Conventions. Because it comes in through the browser with no IT involvement, the business department doesn’t have to go, hat in hand, to the IT steering committee for approval either.

This simplicity, mostly manifested through the avoidance of committees, turns out to be sufficiently attractive to overcome the disadvantages — namely, that any customization has to be handled by the business department, and that integration comes in the form of manual rekeying. If it didn’t, the IT steering committee would have to be involved after all, as would IT’s cumbersome regression testing regime.

There’s no single solution for fixing this, of course. Exactly how you make dealing with IT as easy as dealing with a SaaS vendor will depend on the specifics of your company’s capex and IT steering committees, as well as your willingness to isolate the new system enough to forgo regression testing.

Now that you’re clear about the root cause, though, at least you know where to look.