Business doesn't ask for utility computing, part 2

Bob Warfield (of the stealth mode company, SmoothScan) called me out on the admittedly flippant argument I put out for IT ownership of infrastructure strategy and architecture. I made this argument specifically in the face of business units (and even hosting clients) who are extremely resistant to sharing "their" servers with anyone. Bob's response is insightful, probably exactly how BUs will respond, and deserves a careful response.

IT is a service organization. (Translation: You work for us, and we're more mission critical than you are. You are replaceable by VAR/SIs and by SaaS. Be careful when getting uppity with us.)

Damn straight. We are a service organization, and as such our sole purpose of costing our enterprise money is to meet your functional and service level requirements in the most cost effective way possible.

However, your statement does not explain why you shouldn't share servers. If we demonstrate conclusively that we can better meet your service levels at a lower cost with virtualization and/or utility computing, clearly it is in the financial interest of the company for you to pursue the concept further. In the same vein, if you can prove that you can get the business functionality you need for cheaper through a SaaS solution, we should help you make that happen.

You have not always met your SLA's and delivered your projects on time and on budget. In fact, there is at least one major nightmare project on everyone's mind at any time. (Hey, it's software, what else is new, it wasn't our fault, part of it is business' fault beacuse of how they spec'd their requirements and then failed to deliver, yada, yada. But, fair or not, IT gets the blame. IT has more glass on its house than anyone.)

We completely agree--IT has often failed to deliver (or been party to delivery failures). However, because we are focusing on infrastructure issues, let's let the SOA guys describe how they will mitigate software delivery failures.

There are two key forms of project failures for IT infrastructure:

1. Failing to acquire, install, configure and provision hardware in a timely fashion
2. Failing to meet agreed upon SLAs when operating that hardware and their software payloads.

Assuming we physically receive the hardware in a timely fashion, we then must use automation to greatly reduce the cost of getting new systems up and running quickly. Whether or not systems are shared by business units, this need is there.

In fact, because we are utilizing resource pooling in a utility computing model, it will often be possible to provision your software without requiring you to wait for any associated hardware. Want to get a quick beta marketing program up and running in a matter of hours? Give us the binaries and we will find capacity for it today. We'll determine the need to add additional capacity to the system later, once we see trends in overall infrastructure demand.

As far as service levels go, response to violations have to be automated. No more waiting for someone to respond to a pager call--if a server dies in the middle of the night, SLAuto systems must quickly restart or replace the failed system. With automation involved in meeting your SLA needs on shared systems, we aim to remove the dependency on "human time" and the limits of siloed resources, which are what was killing us before.

BTW, our new friend (insert name of Enterprise Software Sales Guy) has told us all about these topics, so we're knowledgeable too, and we think you ought to listen to us. (Very dangerous game for the Enterprise Sales guy, but if IT already shut him down, this is exactly how they'll play it in many cases because they have nothing to lose.)

Again, unless Mr. Enterprise Software Sales Guy was selling you something that manages infrastructure (in which case, why do you care?), what he is selling doesn't impact the decision of why or why not to share servers with other business units in an IT utility. If he is telling you it does matter, he'd better be able to demonstrate how his product will beat the ROI we are projecting from utility computing. Oh, and that is a BIG number.

We still remember those times when you put the needs and requirements of your own organization ahead of our business needs. You wouldn't choose the app we wanted because it didn't fit your "standards". The app you did choose stinks and our competitors, who use the app we wanted, are now running rings around us. (Yep, it happens. I've seen IT frequently choose an inferior or even unacceptable app because they didn't care and had the power to ram it down the business' throats. When it blew up, IT either lost credibility or the business suffered depending on how the culture worked. This happens at all kinds of companies, large and small, successful or not.)

In my earlier example, I made it clear that you have the right to push as much as you want for functionality and aesthetics. Applications are the point where both originate, and we fully support your demands that we not make your application decisions for you (but hope we can make them with you). However, architecture is a different story, and infrastructure architecture is about as far removed from functionality and aesthetics as you can get (except in relation to service levels, but we already covered that). Again, if we deliver the functionality you want at the service levels you require in the most cost efficient way reasonably possible, then you shouldn't care.

Oh, and by the way, we take full responsibility of reporting to you the SLA compliance levels and associated cost of infrastructure as we move forward, so you can determine on your own if we are really achieving our goal. Of course, that might come in the form of a bill...

The core of Phil's comment boils down to the following:

You won't wean the business from sticking their nose into IT's business so long as these cultural factors persist. Earning the write to be a trusted deliverer carries with it the responsibility to be trustworthy.

Have you been trustworthy?

If not, even if it wasn't your fault, consider a more consensus oriented approach. After all, the speeches described above boil down to "do it because I say so". I try to avoid that with my kids where possible, and it is possible almost 100% of the time.

To that I reply "mea culpa". I was stating my case in a much less friendly tone than I would in real life to make my point. You are right that all business relationships must (ideally) be consensus driven. However, in the end the cost savings driven by a multi-tenant approach (be it utility computing, virtualization or SaaS) can't be achieved if each business unit demands owning its own server.

One last thing: it has been my experience in the last year or two that business units are much more open to sharing infrastructure within a company. As long as data security is maintained, business application owners are most concerned about the same things IT is--delivering required functionality at required service levels for as little cost as possible.

Sharing infrastructure with another company, however, is an entirely different story.