Build Vs. Buy: A Dangerous Lie - InformationWeek
IT Leadership // CIO Insights & Innovation
09:06 AM
Connect Directly
Faster, More Effective Response With Threat Intelligence & Orchestration Playboo
Aug 31, 2017
Finding ways to increase speed, accuracy, and efficiency when responding to threats should be the ...Read More>>

Build Vs. Buy: A Dangerous Lie

IT's eternal debate sidesteps the complexities of a fragile talent ecosystem and creates a vicious cycle that ensures project failure.

There are no good "buy" options. Period. I'm not saying there aren't any good products out there. There are. But given the complexities of fluid business conditions and the peculiarities of the internal processes that support them, the term "off the shelf" is a marketing gimmick.

"Buy" is never just "buy." It's actually "integrate." So is "build," which means they both require similarly skilled engineering talent. Therein lies the dilemma.

Culturally the word "buy" in large IT shops is a not-so-subtle signal of disinvestment in a declining, increasingly commoditized function/department/division. In a field that has grown sensitive to short cycles of obsolescence, that signal creates a powerful, self-perpetuating downward spiral for top engineering talent -- an exodus of ambitious hackers, ever-vigilant about remaining relevant.

The space in decline experiences the opposite of gentrification. The allure of someone else's "build culture" sucks out all the talent that matters, leaving behind non-technical project managers (the overzealous and process-focused) and technical order-takers (under-motivated second- and third-tier engineers). In the Mortal Kombat vernacular, that combo leads to a fatality because that diminished internal team simply can't deliver what the business thinks it's getting "off a shelf."

[Don't get too comfortable in middle management -- instead, flatten the org. Read Career Advice From The Future.]

Note that I can't stand those three words: off the shelf. They're classic marketing misdirection, implying, "What could be simpler? You have a can opener, right? Well, we sell cans!" Mmmm… deeeelish!

The problem, of course, is that the flight of engineering talent from your "buy" organization means that you don't have a can opener. If you're lucky, you have a hammer, and it's somewhere out in Chennai. Most orgs-in-decline don't even have that. They just have to learn to eat the can.

Enter senior management
The decline plays out predictably. That ripe smell of flop sweat, even before the buy engagement starts, causes senior management to overcompensate and hire an army of external professional servicers. But it's already too late because the home team is no longer strong enough to support those occupying forces.

Ever-diligent about project optics (and their own career paths), senior management pivots and starts talking about the need for talent upgrades. Hilarities ensue, because it was their framing of the space as a commodity function that essentially caused its accelerated decline -- a self-fulfilling prophecy.

And that is why the perennial build-versus-buy discussions are so dangerous. Sunsets lead to darkness faster and more chaotically than anyone expects.

The counterargument -- because it's all really about talent, not whether you build or buy -- is that your best people should focus on your company's core competency, the areas that differentiate your product or service. But putting your top talent exclusively on strategic competencies means that they're being supported by your middlers and low performers, essentially giving your gladiators paper swords.

A good example -- for which I'm sure I'll get hate mail -- is Human Resources IT. How can I say this politely? The market isn't flooded with world-class engineering talent with a depth of HR IT experience. Management's default buy options, i.e., PeopleSoft/Taleo, guarantee that this space remains IT's talent backwater. This is ridiculous (this is me backpedaling) given the role that talent plays in the success of every business.

If you want a larger, divisional example, think about the credit crisis. Over the last five years, Big (in its many shapes and forms) finally figured out that its home loan units are money pits. Most of the IT shops that support them have intentionally and systematically phased out builds in favor of buys. Is it an overstatement to say that no self-respecting engineer aspires to work in mortgage tech? Just slightly.

If you thought your home purchasing experience was bad before 2007, you obviously haven't bought a home recently. I have, and being a good corporate citizen, I used Big. I'm not making this up. I had to apologize to my mother for how badly she was treated. My mother! Yes, I'm equating that experience with the quality of technology delivered in those shops.

What departments (and divisions) fail to understand is that on top of all the talent issues, buying off-the-shelf software means that their business processes have to be re-engineered to align with their buy's available features. Tail wagging dog, and ultimately more disruptive and expensive.

1 of 2
Comment  | 
Print  | 
More Insights
Newest First  |  Oldest First  |  Threaded View
<<   <   Page 3 / 3
User Rank: Apprentice
1/31/2014 | 3:33:29 PM
Re: Does everyone need to build?
Really great pros vs. cons for the Build / Buy decision, too many companies have gone to the 'buy' options, since it is cheaper. Unless the 'buy' is for your specific business, where the decision can be considered reasonable, for a 'flatter' more generic business solution may well require so many business process actions, as to serriously affect their future.


There are no great decisions for this topic, I go for the 'build' side, but then I 'build' our system for our customers, a very specific industry vertical, but that can be very expensive.

User Rank: Author
1/31/2014 | 3:22:18 PM
I've seen a number of companies look at this "build" question anew around mobile -- there was no off the shelf "buy" option for the app they wanted to do, so it came down to build in house or outsource for the development. A number of companies that had been doing in-house build work found they could shift their dev talent to mobile with just a bit of specialized outsourced resources, but others had to go entirely outsourced app dev. For the all-outsourced crowd, as those mobile apps became a critical customer-facing platform, they had to hire a team capable of supporting and refining that mobile app.
IW Pick
User Rank: Apprentice
1/31/2014 | 2:45:56 PM
Buy v Build
Loved your column
I was a life long "buy" guy - years of ERP and other package implementation (PwC)/analysis (Gartner) etc
My innovation work in the last few years and books as a result have moved me much more into the build column. Most vendors are delivering horizontal. over hyped products that deliver little base value, forget industry specific functionality or competitive advantage.  
A recent book I helped write - The Digital Enterprise - had me interview some of the biggest brands in the world - Daimler, GE, Coke, Standard Chartered, Allianz, Statoil etc. Striking how few mentioned any of the better known IT vendors as part of their innovation efforts. Most of their buy is for back office and infrastructure IT and at increasingly commoditized pricing. 
Vinnie Mirchandani

User Rank: Moderator
1/31/2014 | 2:05:43 PM
The line is hard to draw, and risks are hard to evaluate
We all buy software. We buy operating systems, databases, dev environments, and custom controls.

So, it is a lie to say that we should build everything in-house. The trick is to achieve a balance.

Some businesses do without IT at all. My doctor's office for instance. They bought off the shelf patient mgt software and they are ok.

What I think is never spelled out is how to asess the risks of buying software.

Loosing talant is only one aspect of it. Those risks are many. Vendor lock-in when your vendor can jack up the licence fees knowing full well that you are stuck with them. The price of inefficiencies of the standard sorftware. The price of your vendor abandoning your product or going out of business. The price your inability to integrate one vendor's software with another's. The price of your data being unavailable to you - all you can see are results of queries - but may be if you had all the data, you could get more value out of it.

It is too hard to put a dollar value to all these 'what if's. It is so much easier to look at the IT budget and compare it to the stated price of the software, and say - too high.

In finance, it is long understood that risk has dollar value. It is time to apply the same philosophy to It projects.
User Rank: Ninja
1/31/2014 | 1:57:18 PM
Re: Does everyone need to build?
I think this discussion is probably framed more at large businesses, where "inhouse IT team" may mean hundreds of people. But in SMBs where I've spent my career developing, much of it as the only developer, the description of "non income producing" is just not adequate. Every dollar the company doesn't have spend buying something (or spending on expensive outside help) ends up on that same bottom line. If you write systems which make it possible to hire less people thru efficiency, produce better products thru timely information when it is needed, and make it easier for your customers to do business with you than someone else, how is that non income producing?

Take a look at the ecosystem around the IBM midrange server now called i5 (formally AS400). You almost never see that environment without a "build" mindset behind it. The platform is just so productive, you don't need many inhouse people to achieve amazing systems. Doesn't mean you may not have a ERP system to integrate around, most do. But they usually have the talent to complete the integration with the business, fill in gaps and keep support cost to an obsolute minimum.

This article hits very close to home at my current company, a global business with 20+ business units around the world. Most were acquired, so for years they had decentralized model, each unit had their own system solutions. They have tried twice to implement common ERP at units, once in late 90's with BPCS and currently with Microsoft's AX. But they never had the inhouse talent to pull it off, used outsiders who got it "running" enough to collect their money and then left. No continuous improvement cycle was in place to keep integrating it thru the business. Only a couple of sites made it work, and that was because they had inhouse people who took ownership, could actually write code and integrate.

That is how I got where I am now, was brought in as contractor on the first BPCS effort at this unit. I spent first few years as contactor, filling gaps and making the software support the business, instead of other way around. Eventually I came inhouse with them and continued those efforts. We are now so effective that they can't even put AX in here, you can't build a business case. The only other unit in that category is a unit with $20 million SAP install with inhouse support team. Every other unit did not have inhouse talent, and every one is failing again with AX. Mgmt has actually placed further rollout of AX on hold, they have not come close to an effective ontime, on budget implementation yet.

As Coverlet says, talent is the key. And the only to make sure you have it is to hire it and keep it. Whether it is cost effective to have one hundred people like that is a whole different discussion.
User Rank: Apprentice
1/31/2014 | 12:46:02 PM
Buy before build - a spelling metaphor
Remember this?  "i" before "e" except after "c" or when sounded like "a" as in neighbor or weigh

I propose:  Buy before Build except after workflow modifications rejected or when integration is a core competency.

I agree it's not Buy versus Build, but an IT shop needs some aspect of defining who they are going to be in order to attract and retain the right talent based on that definition.  It's disengenous to advertise to recruits that a team will build things if they typically buy and integrate.
IW Pick
User Rank: Strategist
1/31/2014 | 12:25:45 PM
Re: Does everyone need to build?
The last paragraph actually says it all: ""Can our business model accommodate the risks and long-term investment that comes with managing an in-house software development cycle?". For most organizations, for most develpoment, the obvious answer is "No" - in fact, when organizations need to rationalize their workforce costs, they look very hard at personnel whose purpose is to maintain non-income generating activity. The only in-house software development that makes any sense is proprietary IP that defines their business advantage, and that cannot be obtained off the shelf. Everything else really needs to be off the shelf.
User Rank: Strategist
1/31/2014 | 12:21:53 PM
Re: Does everyone need to build?
Great question Rob.  One that I'd love to hear other people's thoughts around.  

Big's experience doesn't differentiate between bringing BMC in with a long list of needed tweaks (using ITSM as an example) and asking a cloud provider like ServiceNow to make a million changes to their offering.  I'm not Mr. ITSM so it's an example.  But in both cases, the ask of the vendor is essentially "please make your chocolate appreciate our peanut butter (internal processes)." 

So there's little difference from a talent perspective.  Both cases see a flight of build talent which ultimately impacts the delivery.

Everyone understands that large SAP or Peoplesoft implementations are complex and I'd even say high risk.  But what's missing from that conversation is the inhouse talent perspective.  And specifically the downward spiral mentioned in the piece.
Lorna Garey
Lorna Garey,
User Rank: Author
1/31/2014 | 10:27:18 AM
Just ask the end users
You know, the ones curled under their desks in a fetal position after spending a few hours in Kronos.
User Rank: Author
1/31/2014 | 10:21:51 AM
Does everyone need to build?
So what do you make of the movement to cloud services, Coverlet? Are IT organizations further ceding their "build" chops and becoming mere service brokers and integrators? The Facebooks and the Goldman Sachs's of the world can afford the internal engineering talent for a range of applications and infrastructure that yield competitive advantage, but not every company is in that position. 
<<   <   Page 3 / 3
How Enterprises Are Attacking the IT Security Enterprise
How Enterprises Are Attacking the IT Security Enterprise
To learn more about what organizations are doing to tackle attacks and threats we surveyed a group of 300 IT and infosec professionals to find out what their biggest IT security challenges are and what they're doing to defend against today's threats. Download the report to see what they're saying.
Register for InformationWeek Newsletters
White Papers
Current Issue
IT Strategies to Conquer the Cloud
Chances are your organization is adopting cloud computing in one way or another -- or in multiple ways. Understanding the skills you need and how cloud affects IT operations and networking will help you adapt.
Twitter Feed
Sponsored Live Streaming Video
Everything You've Been Told About Mobility Is Wrong
Attend this video symposium with Sean Wisdom, Global Director of Mobility Solutions, and learn about how you can harness powerful new products to mobilize your business potential.
Flash Poll