Build Vs. Buy: A Dangerous Lie
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

Register for InformationWeek Newsletters
White Papers
Current Issue
Top IT Trends to Watch in Financial Services
IT pros at banks, investment houses, insurance companies, and other financial services organizations are focused on a range of issues, from peer-to-peer lending to cybersecurity to performance, agility, and compliance. It all matters.
Twitter Feed
InformationWeek Radio
Archived InformationWeek Radio
Join us for a roundup of the top stories on for the week of July 17, 2016. We'll be talking with the editors and correspondents who brought you the top stories of the week to get the "story behind the story."
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.