Comments
Build Vs. Buy: A Dangerous Lie
Threaded  |  Newest First  |  Oldest First
RobPreston
50%
50%
RobPreston,
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. 
Coverlet
50%
50%
Coverlet,
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.
keitha0000
IW Pick
100%
0%
keitha0000,
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.
TerryB
100%
0%
TerryB,
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.
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. 
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

mbstemps
50%
50%
mbstemps,
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.

John.
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).
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.
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.
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.
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.

 
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.
Lorna Garey
50%
50%
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.
bob.leek@multco.us
50%
50%
bob.leek@multco.us,
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.
gev
50%
50%
gev,
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.
ANON1242037829718
IW Pick
100%
0%
ANON1242037829718,
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

 
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.
ChrisMurphy
50%
50%
ChrisMurphy,
User Rank: Author
1/31/2014 | 3:22:18 PM
Mobile
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.
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.
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.
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.
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.
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!
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!
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.
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/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: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 | 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.


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 - August 27, 2014
Who wins in cloud price wars? Short answer: not IT. Enterprises don't want bare-bones IaaS. Providers must focus on support, not undercutting rivals.
Flash Poll
Video
Slideshows
Twitter Feed
InformationWeek Radio
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.