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

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.

Comment  | 
Print  | 
Comments
Newest First  |  Oldest First  |  Threaded View
<<   <   Page 2 / 3   >   >>
Somedude8
50%
50%
Somedude8,
User Rank: Ninja
2/3/2014 | 1:40:28 PM
Re: Scratching the surface
You hit several nails on their heads, especially your description of the user experience. That exactly describes it. One place I saw not too long ago, where all the office was doing their work through the online applications, if the website blew up (which it did a couple times a day), they would just wait 10 minutes, because they knew that servers were being rebooted etc.

I did work at a place for a few years that started out as a spaghetti mess, but I was given very wide lattitude and the time to refactor as we went. After about 2 years, things reached the break even point. About a year after that, we actually had time to innovate and try new things. Roughly half the new features that went in to production were not based on Business requests like "We need XYZ", but were based on programmers basically playing with new toys. That company quickly stood out from its competitors. It was a beautiful thing!
TerryB
50%
50%
TerryB,
User Rank: Ninja
2/3/2014 | 1:28:29 PM
Re: Scratching the surface
You make some great points. Especially how to tell the difference in good IT build skills and what is a future nightmare waiting to happen. Very few companies, especially in the SMB realm I work in, have the resources to manage such a thing. Coverlet mentioned that in his article.

The end user may see a working application but has no idea it is going to be a future maintenance nightmare, something only another coder would know. But it still shows up eventually to them, when they ask for that modification in the future that seems straightforward. But then everything like that becomes a matter of months to turn around. Then the backlog builds so months become never. Then users just quit asking for anything, they know it will never get done. I have seen that so many times in my travels.

But that is the measurement of a great Build environment. Can you create a situation where continuous improvement is constant? Where backlog is non existent? Where most requests are done in hours, not days? That is when you have something. I've always heard since I started in the 80's that a good developer is worth 10 average developers. As the complexity of this web application infrastructure has ramped up, that is more true than ever.

But that is tough to manage, in many ways. I remember when I was working for contracting company, my reviews were done by another contracter who had been there for quite awhile and had worked at a client at same time as me. She was introducing me to a new office manager who was taking over, telling him that I was so good that I made the other contracters look bad to the client. Her comment was "Terry will be done with his project while you are still deciding how you are going to do yours." In that contracting world, that wasn't necessarily a good thing to my employer living on billable hours. But as inhouse employee, you are like gold.

But if you were doing first interview with me, you would have no idea. What questions do you ask to separate the good from the average? The spaghetti coder from the top down structured coder who writes for the next time he has to work on that code? I'm sure the Google's and Microsoft's of the world have the resources to vet people. But a manufacturing SMB? What a crapshoot in that hiring process. No wonder so many choose not to do it all and turn it all over to a vendor.
TerryB
0%
100%
TerryB,
User Rank: Ninja
2/3/2014 | 10:35:24 AM
Re: Does everyone need to build?
Sacalpha, you are making some very big generalizations about what manufacturing companies are. It doesn't matter if you worked at 30 of them if they all did the same type of thing. Some Mfg companies fit very nicely in the vanilla ERP box, some don't fit at all. The current company I work for upcasts copper alloy wire (50+ different flavors) and then forms them to different sizes and specifications for other businesses to make the end products. Another sister unit in our global Corp makes superconducter wire for MRI machine manufacturers and things like the CERN supercollider project in Europe. There is no Buy software for stuff like that, there aren't enough companies in the world who do this to market a commercial product for our industry. Show me a software that manages hedging metals, if you even know what that entails.

I'm with Coverlet, if you are just manipulating configurations, you aren't even real IT. I call those people "superusers". You can not configure any ERP system to the extent of what you can do by writing code, it is impossible. And superusers cost just as much in salary as code writers. The difference is, I can manipulate configurations AND write code for the same money.

Faye, always enjoy your posts. I've spent my career working with small mfg companies just for reason you say, to be appreciated. And they do, they consider me one of most strategic assets they have, not a cost. One of my favorite stories here, I was listening to them discuss a Lean program sponsored by Corp to have weekly one on one reviews between employee and manager. I was kidding them they never review with me. The answer was "We see what you do, we use your work everyday to get our jobs done." I'll take that anyday to a job who's success depends on factors you can not control, the whims of consumer market or the politics of the office.
jerrylust1
100%
0%
jerrylust1,
User Rank: Apprentice
2/2/2014 | 4:46:50 AM
True in more ways than listed
I worked for 37 1/2 years at an IT company. I watched as the technical staff, hardware and software, were disposed of by HR. I ducked the bullet and went to education. Then they put education under HR. Why? HR had too many people so they would stick other groups under them, dump those people but keep the allotment. We eliminated over 65% of the educational staff with the simple statement that "We will outsource those needs". How do you outsource training on Proprietary software and equipment. Then take into account that you are presenting this to a group of instructors and they were amazed that there was no chearing from the folks facing layoff! All said and done nobody could train, there was no one to train either, but we had an abundance of HR! I, BTW, did not get knocked off until I had had enough but saw many good friends get the boot.

This is another example of build (In house staffe developing products, hardware/software, and the courses necessary to train the field support) or Buy (Get someone to train that is not really current or tied in to the product developers). Very short sighted!

Two worst letters in the alphabet when combined. Great article!
Somedude8
50%
50%
Somedude8,
User Rank: Ninja
2/1/2014 | 8:19:03 PM
Scratching the surface
Love these articles. Wish I could go back in time and make most of the folks I have worked for over the years read and understand this stuff.

I see this as only scratching the surface, and in many cases being a symptom. I can't really quantify what 'it' is, but I know what it smells like a hundred miles away.

Its the C-level guy in charge of IT that sees IT as nothing more than red ink.

Its the project manager who is so focused on the process and the dates in his MS Project docs that he has no perspective of the objective of the projects he is 'managing'.

Its the team leader who has doesn't have the techincal chops to know good from bad, be it architecture, design, what have you.

Perhaps most costly of all, its the programmer who writes horrific spaghetti code, all day every day, but manages to meet his deadlines for the most part, and his stuff works, for the most part. His boss probably thinks he is a stellar programmer.

Its the website/application/whatever that is nearly impossible to work on. A friend at a major IT/Goods place that may or may not rhyme with hell had to scope out a project: Add a shirt size to the website. Time to complete: 2 man weeks. To add 2 sizes? Estimated 12 man weeks.

In the face of these things, its no wonder that in so many shops, buying looks so much more attractive than it really is. And in so many of those same shops, you will find code that should have never made it to production, but belongs on the TheDailyWTF.com. And nobody notices!

I see the build/buy quandry as one where so often an organization just doesn't have the chops to even properly frame the question, let alone come up with a reasonable answer. Its not wonder they end up dry on real talent. 'It' is self perpetuating too; its like The Dark Side or something.
Mark Montgomery
50%
50%
Mark Montgomery,
User Rank: Strategist
2/1/2014 | 2:02:33 PM
Hybrid approach makes sense for some
I've tested this issue over the past couple of years. Since my company ( http://www.kyield.com ) has strong next gen technology, but is small without legacy models to protect, we do have some freedom others lack. Considering all things, it makes sense for some co's to adopt a hybrid of build and buy. Liability is becoming a big problem for internal IT shops -- esp for their boards who don't jump ship every 2 years like so many in IT. Bottom line- no org has all of the internal IP and IC they need to remain competitive for long--external R&D is too critical, but some do have internal talent that are as strong as any leading vendor. So we provide a hybrid option tailored to mutual need.
Coverlet
50%
50%
Coverlet,
User Rank: Strategist
2/1/2014 | 8:04:02 AM
Re: Does everyone need to build?
Appreciate the counterpoint. This is the second piece of mine to which you've had an allergic reaction.  Amused that you keep seeing the byline, forcing yourself to endure it, and spending significant time on the response. Fine line between love and hate.

That said, I've been in investment banking technology for a while.  Unlike other verticals-- i.e., product/manufactoring-- we think of both engineering talent and technology as a differentiator.  To your point, there is an ecosystem of tech consultants that flourishes around the implementation of packaged software.  And there are masses of folks who choose to "learn marketable skills" -- the remoras to SAP's shark.  But in my experience, they aren't hardcore engineers.  Or if they once were, they traded it in for their own reasons.  

Building with Legos is different than building Legos.  The "with" makes a difference.  And that's at the heart of the piece.  There is a substantive engineering skills chasm between the top builders in IT and what you call configuration resources.  And in large IT shops, you need the hardcore engineers on the buy projects.

As for me, I wouldn't jump to a vertical that doesn't differentiate thru technology.  So my experience will remain narrow.  By choice.

And I would trade a dozen config folks for a hardcore hacker any day.
Faye Kane, homeless brain
50%
50%
Faye Kane, homeless brain,
User Rank: Strategist
2/1/2014 | 3:47:24 AM
Re: Does everyone need to build?
 

> If IT makes it possible to hire fewer people, produce better products, and make it easier for the  customers; how is that non income producing?

It IS income-producing, just like everything else IT does to support the business, including user support and PC repair. The problem is that only IT managers see the company as a functioning collection of integrated subsystems.  Other employees see only their own function, and the bigwigs see a black-box machine which money flows in and out of.

They view internal expenses as waste heat generated by their money-making machine.  Since they don't see the big picture, are incapable of understanding the technical issues, and are often remarkably stupid; management says:

"IT burns our money to keep warm and comfortable while they play with the toys we generously bought them. It's obvious that this waste should be minimized, so we ignore those chattering, bespectacled geeks who want to throw away more of our wealth instead of bringing in any for us."

When their mismanagement harvests the crop failure it has sown, they don't just use "IT screwed up again" as an employment-preserving excuse, they sincerely believe that they are excellent managers who were given uncooperative, unproductive, incompetent, jargon-speaking weirdos to manage.

It happened to me so much that I not only got out of IT management, I got out of the business world completely and live naked in a cave

And I'm not coming out until someone herds all the stupid people into boxcars and hauls them away.

--faye kane ♀ girl brain

Sacalpha1
50%
50%
Sacalpha1,
User Rank: Strategist
2/1/2014 | 2:30:23 AM
Re: Does everyone need to build?
I completely disagree with this article and take exception to almost every premise in the article.  In my experience, the opinions of this author come from someone who has very narrow experience, has worked at only a few companies, and comes from a service industry.  Companies buy because it's ultimately the right business case -  cheaper, less risky, and has a higher probably of actually getting something live.  I also believe there are business cases for build when the need is very unique, the scope is reasonably small (so the developers can really get their arms around the problem), the pre-built compents are not readily available, and/or there is an opportunity for innovative, disruptive technology to drive sales, brand awareness, or customer loyalty.

The primary argument about losing talented engineers when following a more buy centric path is just plain out wrong.  Following a buy centric path, you need technical resources to configure the product, adminster the system, complete enhancements using the vendor provided tools, etc.  The ability to learn marketable skills with SAP, or Oracle, or Salesforce.com or underlying platforms like Netweaver, Fusion, and Force.com are great attractors of talent.


Also, commenting on the notion of companies having to reengineer their processes to meet the software.  This simplistic view comes from those who have little to no experience implementing package products.  With the maturity of tier 1 (and even to a large extent tier 2 and 3 products), many variations in the execution of a particular process can be supported in the software without changing code.  That's why you need configuration resources.  So, many existing business processes can be supported within the package software.  It is also a good thing for a company to periodically evaluate their processes and simplify them and/or adopt best practices or standard practices.  Where there is a true need for retaining a unique process that is unsupported by the software, you have the option to build using the vendor's platform(s) or their APIs and a much broader assortment of development tools.  I have worked with about 30 companies over my career (and seen benchmark data and project profiles on coutless others) and companies are not nearly as unique as they think they are.  If you pick the right product, there should generally be less than 20 or 30 business scenarios that can't be changed because they truly provide some type of competitive advantage and are not supported by the package software.  The other 100 to 300 scenarios (of an implementation) can be supported either thru configuration or some reasonable adjustments to the processes.  And that's the whole value proposition of packaged software.....why should I pay substantially more to custom engineer and build something that's readily available and workable.

Products/manufacturing industries has been using package software with great success for over 30 years now and the trend in the last 10 to 15 years is for these technologies to cross over into service industries.  The trend is continuing both with on premise and cloud solutions and the companies who have historically been users are not retreating from these products.  With so many companies using the products, and more companies adopting them, that would tend to prove there is a reasonable business rationale for buy (including talent retention).
Brian.Dean
50%
50%
Brian.Dean,
User Rank: Ninja
1/31/2014 | 9:29:56 PM
Re: Does everyone need to build?
I am also thinking that this discussion is mostly for large enterprise, where the business's core activity and scale would determine the end decision. In an effort to cut costs and time the decision between build vs. buy would start from hardware itself: would x86 architecture or the Power architecture provided for the optimum level of saving. Once hardware has been decided then it is time for software, in-house, outsourced and different opinions. Since technology is in a state of flux, and markets take time to fill demand, yesterday's opinions could be viewed as today's lies. 
<<   <   Page 2 / 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 - September 10, 2014
A high-scale relational database? NoSQL database? Hadoop? Event-processing technology? When it comes to big data, one size doesn't fit all. Here's how to decide.
Flash Poll
Video
Slideshows
Twitter Feed
InformationWeek Radio
Archived InformationWeek Radio
A look at the top stories from InformationWeek.com for the week of September 7, 2014.
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.