Strategic CIO // Executive Insights & Innovation
Commentary
1/31/2014
09:06 AM
Connect Directly
Twitter
RSS
E-Mail
100%
0%

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.

Previous
1 of 2
Next
Comment  | 
Print  | 
More Insights
Comments
Newest First  |  Oldest First  |  Threaded View
Page 1 / 3   >   >>
petey
50%
50%
petey,
User Rank: Strategist
2/7/2014 | 10:02:48 AM
Re: Go ahead, buy it
I'm saying they are becoming increasingly obsolete because of the current business model is cheap and fast AND the products on the shelf are getting much better.
RobPreston
50%
50%
RobPreston,
User Rank: Author
2/7/2014 | 9:42:06 AM
Re: Go ahead, buy it
So you're saying that most IT organizations are support and procurement organizations--they offer their companies no competitive advantage? Sounds like those kinds of organizations are prime outsourcing fodder...classic cost centers.
petey
50%
50%
petey,
User Rank: Strategist
2/7/2014 | 9:38:42 AM
Re: Go ahead, buy it
With due respect, I could not disagree more. Most business IT staffs were never intended and do not have the same development skill sets as say a software co. like oracle or MS. They are support organizations. Why invest in such a specialized development endeavor when you can buy off the shelf? Granted there may be exceptions to the rule but generally I believe the purchase gives you complete flexibility in terms of leveraging the staff support resources without the headaches of redesigning the platform based upon changing business practices. We agree to disagree and this topic will always be a great source of needed discussion in today's world of shrinking budgets and increased demand for more stuff.
RobPreston
50%
50%
RobPreston,
User Rank: Author
2/7/2014 | 9:09:15 AM
Re: Go ahead, buy it
That analogy doesn't hold up under scrutiny. It's apples and oranges. Consumers and businesses. We buy cars as consumers rather than build them because we don't have the capability to build them (for the most part) at anywhere near the sophistication and cost. We build applications and systems as businesses to gain a competitive advantage. You're not flushing money down the toilet if your company can develop an application or build a system that truly separates your company in the marketplace. No, we don't want to build PCs and email systems ourselves. But not every IT asset is a commodity.  
 
petey
50%
50%
petey,
User Rank: Strategist
2/5/2014 | 10:45:02 PM
Go ahead, buy it
In today's world of what have you done for me lately mentality, you would be flushing money down the toilet to build. Assuming you built something twice as good at a fraction of the cost of anything you could buy today, you will have just painted yourself into the obsolete corner in 5 years with lost flexibility and aging rockstar developers. I don't see the need to build my own car when I have 60 new models to choose from each year built by professionals.
Coverlet
50%
50%
Coverlet,
User Rank: Strategist
2/5/2014 | 9:30:50 AM
Re: Buy v Build
@Vinnie  I read your post about this article.  Appreciate the thoughtfulness.
Coverlet
50%
50%
Coverlet,
User Rank: Strategist
2/5/2014 | 9:26:39 AM
Re: Mobile
@ChrisMurphy:  History repeats.  Remember how the enterprise first reacted to the web?  Companies came in and charged $120K for 4 html pages-- dropping the jaw of every inhouse tech.
Coverlet
50%
50%
Coverlet,
User Rank: Strategist
2/5/2014 | 9:22:13 AM
Re: Does everyone need to build?
@TerryB.  Spot on.  If I were a radical editor, I'd nix everything in the original piece but the last line.
TerryB
50%
50%
TerryB,
User Rank: Ninja
2/4/2014 | 1:22:40 PM
Re: Does everyone need to build?
@sacalpha1  We are not as far apart as I originally thought from your first post. My objection to your original post was that you can take a package and "configure" it to do whatever you want. Or buy 3 different packages and "configure" them to work together. You are obviously intelligent enough to know that is not the case, I'm sure that is not what you meant now.

Everyplace I've worked has always been a Buy AND Build scenario. Of course you do not need to write the backoffice functions, things like G/L are highly configurable without source modifications. But that is not the case for the front end of business, if your goal is one truly integrated system. And once you get out of the G/L post interface, the integration points get harder and harder. A/R? Brings the entire Sales Order and Invoicing process into the mix. A/P? The 3-way match brings Item Master and Inventory Control (receiving) into it. So if you run one package to handle those backoffice functions but need a different package for your MES, each has an Item Master. So how do you "configure" your way into that integration? Surely you are not counting those middleware data transform packages as "configuration"?

The reality is you are lucky if you can Buy a package that supports 60-80% of the business, then Build to close the gaps and have one integrated system. Maybe someday these packages will be so API rich you can interconnect them without modification but I'll be cold in the ground before we see that.

So truthfully, how many places have you been that bought a single vanilla package and got 100% of their business on it? From the shop floor to the lab to the back office? Even in a Buy situation, you have to judge the efficiency the organization to know if you are successful. I've seen so many ERP implementations that needed low level clerks to handle the transactions, the level of automation is just not there. You can Build on top of that and increase the efficiency where those people are not necessary. That pays for the IT person you need to do it.

Coding and systems analyst work are not mutually exclusive. I was trained for both in college, have always done both. It sure helps the Buy when you know what you can Build on top of it to make fit the business. I don't believe in settling or compromising on efficiency. I write code but communicate with everyone in the business, from the President to the A/P data entry clerk. It's my job to understand the business, being able to write code just makes things more efficient and gives my company more value for their money. I've been doing that since the 80's, all for $30-$100 million SMB manufacturers. It works.

You throw out SAP so casually, like anyone can buy that. Really? Is cost no object here? One of our sister units uses SAP, it cost them $20 million to get it working and it is not vanilla. They have support staff of 5-6 people who tailored it to fit their business, the vanilla implementation was absolutely unacceptable to mgmt there, it nearly destroyed them in the beginning.

Neither myself or Coverlet is saying you always Build, that was not point of his article. But if you have the talent to Build on top of whatever you Buy, you are in a much better position to succeed than organizations who can not. So many of them have no idea what they bought until it is too late, then they are stuck in mediocrity forever.

 
Sacalpha1
50%
50%
Sacalpha1,
User Rank: Strategist
2/4/2014 | 12:56:02 AM
Re: Does everyone need to build?
@ TerryB

I have worked in chemicals, forest products, metals and mining, consumer products, assembly manufacturing, configrue to order, engineer to order, and high tech manufacturing operations, so your assumption is incorrect about my background.  I know of companies who use package software quite extensively for rolled metal products like wire and for other wire products like fiber optics.  The configure to order and dimensional characteristic and compound characteristic driven manufacturing is somewhat unique and often requires some enhancement to the package product to fully meet requirements.  However, this is not unique to wire manufacturing.  This same issue exists in other metal based manufacturing operations (say rolled steel) as well as in forest products, some plastics based configure to order operations and to some extent in chemical company operations.  And by the way, SAP happens to be the defacto standard for core ERP/CRM processes for both forest products and chemicals.  Pull a list of companies if you don't believe me.

Part of my point was that operations are less unique than people often think as I have pointed out above.  And part of my point was that even when parts of the buisness may be somewhat unique, other parts are not.  Why custom build core financial, HR, procurement, inventory, etc. solutions when a package can work just fine and then you can enhance the product for the things that are truly unique and differentiating.

I freely admit that hedging is more of a unqie business function and it is not typically supported in most ERP/CRM package products.  Even though I am not an expert in hedging, enough companies do commodities hedging (again your company is not that unique as other metal companies, oil and gas, chemicals, and consumer products/food companies hedge commodities all the time) that I would bet there are some package products that would probably be worth invesitgating.


Comments and attitudes like "if you are just manipulating configurations, you aren't even real IT" are the things that get IT in trouble.  The purpose of the IT organization is to meet a business case in support of a particular business function or set of functions.  You should be looking for the best way, whether buy or build, to meet the business case - which approach best supports the business process(es) for the cheapest cost and highest benfit and least risk.  If after proper analysis that is "buy", then that's the right decision.  If after proper analysis that is "build", then that's the right decision.  In my experience buy has and is more often the right base answer, but that view point would not preclude me from properly examing the buy vs build question for a particular solution and chosing build if appropriate.  Opinions about "I'm not doing real IT work unless I am coding" are irrelevant and all they do is serve to reenforce the rest of the business' poor impression that IT is just a bunch of tech weenies that don't get it.

@Coverlet

If you had limited your article to banking/financial services or even some set of service industries, I would have reactly less strongly or might not have even responded at all.  You certainly have greater expertise in financial services than I do and maybe your article is spot on for that industry.  But the article you wrote is a broad statement without reference to industry so by default would aplly to all types of businesses.  I take exception because you are making a broad statement that you can not back up with relevant experience and because in my experience your premise is just wrong.  Since you have freely admitted that you have fairly narrow experience, I would suggest that you not generalize your experience and viewpoints to industries/businesses in which you have not worked.
Page 1 / 3   >   >>
The Business of Going Digital
The Business of Going Digital
Digital business isn't about changing code; it's about changing what legacy sales, distribution, customer service, and product groups do in the new digital age. It's about bringing big data analytics, mobile, social, marketing automation, cloud computing, and the app economy together to launch new products and services. We're seeing new titles in this digital revolution, new responsibilities, new business models, and major shifts in technology spending.
Register for InformationWeek Newsletters
White Papers
Current Issue
InformationWeek Tech Digest - June 10, 2014
When selecting servers to support analytics, consider data center capacity, storage, and computational intensity.
Flash Poll
Video
Slideshows
Twitter Feed
InformationWeek Radio
Archived InformationWeek Radio
Join InformationWeek’s Lorna Garey and Mike Healey, president of Yeoman Technology Group, an engineering and research firm focused on maximizing technology investments, to discuss the right way to go digital.
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.