State of the art multivendor outsourcing and innovation

This time I don't have a sailing anecdote or context to match the subject, and I believe there is a reason for that. Sailors would never be as silly as us IT folks, that is!

I'm writing about outsourcing and especially innovative approaches to that, which is splitting the service components into solution cards, obtaining the best price points per category by aggressive global sourcing policy, and resulting in nimble, multivendor outsources service and solution teams.

In other words, crews that no sane sailor could ever even imagine. And if you could imagine that - which some people do - you could not implement. Why not, you may say? Well, because unlike an (outsourced) IT organization and service components for that, a crew is literally on the same boat.
 If one has a problem, everyone has a problem. A good crew member is paying attention to problems on your boat - and her boat - and not on something else.
So this time all I can say is that good seamanship is out and all I can talk about is Information Technology. Oh how I wish I was sailing....

In Information Technology tasks are atomic. You ask this party to open your firewall, you ask the other party to assign the IPs to your servers, and you ask for a third party to install your application. And if you have other topics - EMC filer shares, LUNs to set up and iscsi shares to configure - you need to worry about those, too.

This surely is not a problem, if you are able to plan ahead without flaw.

If you happen to try and improve and innovate - what then?

Innovation, as everyone since Thomas Alva Edison knows, is 1% inspiration and 99% perspiration. In IT language -. your original configuration is WRONG.

You'll need to change the Firewall. And you'll want to redo you management IPs. Your application and your SAN and Storage will be, err, WRONG.

Now, every development step is a ticketing process, and if your client did the fashionable thing, these tickets will go to separate groups, and you will definitely not be able to just access the DC and do the job.
No, and that also makes sense, since DC is filled with systems that are under SLA, and ultimately the DC production network is quaranteed by SLA to stay up, and they can't let you touch that.

So the customer gets what the customer ordered. If the customer wanted rapid development and innovation - if the customer needed that! - Well, that is not happening.

This is something I've seen now repeatadly. I've found one cure, and that is elastic cloud computing, which eliminates several manual steps in the process above. If you have experienced good ways to evolve systems rapidly in production data centers - please let me know.

Oh, and if you wanted to change your data center and computing infrastructure to something nimbler - I'd like to hear about your approach there, too.