To Outsource IT, or Not to Outsource IT? That is the Question.

Sharing IT stories is the backbone of Cisco on Cisco, and architecture is the backbone of IT. What happens when you outsource ALL of your IT, including the architecture? Sure, it may sound like a good idea, and there definitely are positive aspects to outsourcing some parts of IT; but when you lose control of your architecture, IT becomes slow and outdated. In the video below I share how I respond to this common question of whether or not it is a good idea to outsource IT – the good, the bad, and the very ugly.

And the moral of this story:  Outsource anything in IT – except architecture

Why?

There’s nothing wrong with outsourcing some parts of IT.  IT costs are growing.  Despite the drop in unit cost of traditional IT infrastructure and services, corporate IT costs continue to grow. Most companies find it hard to compete without adding new IT services every year that enable new business capabilities. Outsourcing is an attractive way to control and possibly reduce IT costs.

Cisco IT has outsourced a lot of our monitoring and management services.  We’ve  also outsourced most of our physical infrastructure upgrade and break/fix work around the world. The key to successful outsourcing is good vendor management:

Selecting the right service vendors;

Creating clear and stringent performance metrics that you both measure to drive the exact behavior you want;

Signing mutually beneficial contracts that reward your vendor when they succeed AND when you need to change the IT architecture and change the rules of the game.

(I’ll talk about some ways to improve vendor management in a changing environment in another blog.)

But I’ve met with several companies who have outsourced their IT architecture, and it always ends the same sad way—a stagnant IT infrastructure that works fine for the first few years, but gradually becomes more fragile, more unreliable, and less capable of supporting new technologies or responding to new business demands. Outsourcing contracts which give architectural responsibility to the service provider encourages them to sweat the original infrastructure assets until they rust.

It makes sense. It costs money to keep track of new business needs and new technology opportunities.  It requires a close partnership and understanding of your business to upgrade the right infrastructure in the right way. And it costs even more money to test, validate, and upgrade infrastructure around the world, to stock the spare parts, and to train your support staff to learn how to support your employees during outages.  Outsourced IT providers have no motivation to carry that burden, so they don’t include that in their contracts. And unwary corporate finance teams are so entranced by the low cost of outsourcing all of IT that they fail to see the value of architectural change.

If a company becomes trapped in that fully outsourced contract, and finds their IT frozen in time from that point forward, there are not many easy fixes.  I don’t have any good advice – aside from “don’t do that in the first place” – beyond waiting for a good time to renegotiate the contract and recover your architecture process from the provider.  (And then to renegotiate the remaining management and support contracts to support future infrastructure change).

Once you have control of your IT architecture again, there are a lot of options to improve the existing architectural process.  IT architects are frequently blamed for developing new designs that:

Are too expensive,

Require huge one-time investments in upgrades,

Leave the business with little idea what they’re actually getting for their money, and,

Are often divorced from actual business needs, and more tied to the latest shiny technology.

This is not a failure of IT architecture, but of the relationship between IT and the business, and fixing it requires work on both sides.  (But, unfortunately, mostly it requires a lot of IT work.)  I’ll explain more about how Cisco IT has improved its architectural and infrastructure upgrade processes in future blogs.