Updated: Updated: Strategy
Buy, unless you have to build
Enterprise IT is generally a “buy over build” environment: if you can buy a piece of software, a service, or a piece of advice, then in most cases you get a lower risk and better economics than doing it yourself. This logic applies to most standard software like HR, finance, or general ERP software, and virtually all hardware, unless you happen to be in that business.
Following this logic, enterprises outsource much of their IT work, for example by having System Integrators build those applications that are unique to the business, or by having them customize and integrate off-the-shelf solutions. Infrastructure and operations outsourcing are also common, originally moving to large system houses, but nowadays increasingly to cloud providers who run hardware and networks infrastructure for the enterprise.
Outsourcing isn’t limited to technical processes, though. Wikipedia defines outsourcing as “an agreement in which one company hires another company to be responsible for an existing internal activity.” Peter Drucker advised enterprises to “do what you do best and outsource the rest”, so now most companies outsource their training, call center, janitorial services, the cafeteria, expense handling, logistics, and many more odds and ends.
Many people will also have had some negative experiences with outsourcing. I believe that there’s a lot to learn from daily life, such as observing the relationship between transaction handling strategies and throughput in the coffee shop. My most recent experience was with an outsourced expense processing center which rejected a $5000 travel claim because it contained a $24 lunch, for which I only had a credit card receipt and not the itemized receipt that would detail how a simple Thai curry and an iced tea comes to $24 in downtown San Francisco. I am sure the ensuing e-mail spat cost my employer a lot more than the $24. I never got my lunch money.
Don’t put the source out with the contract
According to Wikipedia the term “outsourcing” came from “outside resourcing”, meaning you procure resources from the outside. Enterprises should think carefully about what it considers a worthwhile “resource” to outsource. Electricity is an easy one - you wouldn’t want to build your own power station. Other’s aren’t as black-and-white.
Many enterprise elements aren’t simple “resources”, but core assets. I’d place your IT vision and strategy in that group. If you outsource those, you’ve essentially outsourced thinking, which I consider a most questionable exercise.
Here are things that I highly recommend keeping in house:
Keeping the Strategy
Where your business and your IT is heading and what strategic bets you are making is what defines your business and distinguishes it from any other. Yes, it’s worthwhile getting input and advice from strategic consultancies, or to run some benchmarking against other industry players. Based on this information you need to define your strategy, though. And that business strategy should be a key input into your IT strategy, which subsequently should also be defined and owned in house.
If you let externals or vendors define the strategy, you’ll be surprised how well their products fit “your” strategy… Your own strategy has to be the benchmark against which you measure products and services that you buy. Without that baseline, your IT management will resemble kids running down the supermarket aisle, tossing whatever they like into the cart. Come to think of it, I have seen more than one IT that does resemble such a shopping cart…
Having helping hands is great - you’ll never have all the skills and resources you need. But you need to own and understand the result of the work, regardless whether done in house or externally. Transparency should be a key aspect of any outsourcing agreement - where’s all the source code, vital metrics, which server is running which workload, etc? Coincidentally, cloud platforms can help quite a bit here as full automation makes it easier to get accurate machine inventories and configurations.
Ideally, you employ external parties as a source of skill that is absorbed by your own teams. I advice my clients that if they outsource development, they should own and operate the full build and deployment tool chain. Not only does this avoid duplication, it also allows the enterprise to have full transparency of the work being performed. Cloud-based tool chains makes this a lot easier than in the past.
To cut cost, outsourcing contracts often limit changes the client is allowed to make. Being limited in options can be one of the most expensive aspects of IT. Giving up control for short-term savings is about the worst thing you can do in times of rapid change - see Architecture: Selling Options. In this context, I like Philip Brittan’s analogy in his blog post about optionality (ht Jean-Francois Landreau):
You sometimes ‘sell options’ in business as well as buy them. For example, when you outsource, you are effectively selling an option to the outsourcer. You collect some form of savings (Premium) from the outsourcer. The outsourcer now ‘owns’ an option which will pay off if they can deliver the service for even lower cost than they are charging for it.
As we know, uncertainty drives up the value of an option, so be careful about selling it for too cheap!