In Favor of Homegrown IT Solutions 265
snydeq writes "Today's IT organizations turn too readily to vendors, eschewing homegrown solutions to their detriment, writes Deep End's Paul Venezia. 'Back when IT was "simple," several good programmers and support staff could run the whole show. Nowadays, [companies] buy hefty support contracts and shift the burden of maintaining and troubleshooting large parts of their IT infrastructure on to the vendors who may know their own product well, but have a hard time dealing with issues that may crop up during integration with other vendors' gear. ... Relying solely on support contracts and generic solutions is a good way to self-limit the agility and performance of any business. In short, more gurus equals less hand-wringing and stress all around.'"
So contracted labor isn't all it's cracked up to b (Score:5, Insightful)
When you treat people like second-class citizens by making them contracted labor, especially in IT, this shouldn't be a surprise.
yes and no (Score:5, Insightful)
The general in-house versus outsource vs commodity question here is a bit inextricably tied up in the more specific "enterprise software sucks" problem. I've seen moving from in-house solutions to third-party stuff work well, when it's good third-party stuff. For example, near the end of my time there, my university switched from an aging home-rolled email setup to a Zimbra [wikipedia.org] installation, which, while not perfect, was generally better and more reliable. On the other hand, there is certainly plenty of crap that they pay Oracle and Microsoft $$$ to run that doesn't serve anyone's needs very well, or integrate with anything else.
Re:yes and no (Score:5, Insightful)
On the other hand, there is certainly plenty of crap that they pay Oracle and Microsoft $$$ to run that doesn't serve anyone's needs very well, or integrate with anything else.
Like Sharepoint? It baffles me as to why anybody would buy that monstrosity... it doesn't do anything!
Re:Now if only ... (Score:5, Insightful)
There are IT gurus out there with free time. Some of them are working in environments that have completely outsourced to vendors, and the gurus end up educating the vendor's minions, sometimes on the most basic operations. Personally I find it easier when I open a ticket with the vendor to copy/paste the exact commands for them to run on servers on which I no longer have root. It saves time.
Not So Fast... (Score:3, Insightful)
Re:IT shops are run by MBAs those days (Score:5, Insightful)
We were taught to get venders when the requirements word distract the existing staff from their mission focus. I had to read case studies where outsourcing worked well and when it failed miserable and should have kept the inside staff. We were taught the complexities of global business and that American staff tend to be more productive and creative even though they cost more. How bean counting causes you to miss the good envestments. And a good HR policy means treating your workers right and at a good pay.
I am willing to bet there are less MBA but BBA who are out of a 4 year business with no experience, trying to save money by stepping on the backs of anyone who gets in their way. The MBA program is far more responsible.
Re:Loaded cost of a software developer (Score:5, Insightful)
Wrong. If you don't have the developer, then you don't need as much floor space for your office, you don't have to buy cubicle furniture, you don't need as large an IT staff, etc. Obviously if you get rid of one developer, you're not going to immediately save this money, but when you're looking at hiring a whole team of people versus contracting something out, you probably will (as for a whole team, you'll need to rent more floor space somewhere, unless your company happens to have a bunch of unused floor space, but most don't as that's wasteful).
Also, 401k, SS, and health insurance absolutely do immediately increase each employee's cost.
Re:Now if only ... (Score:4, Insightful)
Hell sometimes you have to educate the vendor's minion's on what their product is supposed to do!
Re:Not So Fast... (Score:5, Insightful)
The job length of a well paid and respected employee is far longer than your typical product life cycle.
Re:Integrating Diverse Software (Score:4, Insightful)
A high turnover of employees creates problems with in-house development and maintenance of software. The "organizational memory" -- how did we get here, what were the problems, how were they solved -- is lost.
In the U.S. military, cognizant personnel are often rotated to new assignments every 2-3 years. This has the same negative effect on long-term maintenance and evolution of software for military uses. For this reason, military software projects are (or at least were) out-sourced.
You do realize the one of REASONS the military rotates personal every few years is to avoid EXACTLY what you're referring to, right?
Losing any one person doesn't kill a project because there are multiple others with experience on it and no one person 'owns' the project.
Re:Source Code License (Score:5, Insightful)
It depends on if you mean a vendor's 3rd party product versus outsourced programming.
If you hired an outside consultant and paid them by the hour to produce a custom piece of software, then I'd default to having the contract written up to include the source code as a deliverable. You might encounter resistance if its a big firm and they have reusable libraries they've created and don't want to share them. In this case the compromise might be to provide the compiled DLL's for these, but you are back at square one where you depend upon them to fix issues in those DLLs, but at least this way it reduces the dependencies.
When I think "Vendor" I think of someone who has some premade product, which seems to be what the article is refering to. I.e. its like going to a vending machine and saying I want the "Blah Blah Account Management Software". These products are usually sold to many different customers and thus have had a stream of revenue over a long period of time or for a large team to enhance the software over time. Thus they are somewhat large and even if there was a source code license option available from the vendor(although there usually isn't), the code base would probably be large and probably somewhat difficult to customize by internal staff.
Also, the cost to develop these vendor products is spread across many customers, but as the article author points out, you can pay dearly in the areas of integration and customization. You may find corner cases or new requirements down the line that the software simply cannot handle, and in my experience(having continuously been in one scenario or another dealing with a vendor for the last 5+ years) there are a lot of barriers to cross in getting the customization or fixes done.
If people are upset about the inability to customize the vendor product, then you need to go back to the stakeholders and say hey, "In light of new requirements, we clearly need a solution that 1) has some features that support these customization scenarios, OR 2) has a source code license and developers who have the skills and time to deal with implementing those customization(it's hard to know what you are getting yourself into until you actually see the source code), OR 3) roll our own solution." #3 can be a good option if you are only using a small subset of the vendor's product's features, which I've found to often be the case(since usually over time it has been enhanced to meet many customer's needs, but any single customer will only need a subset of these). Thus to roll your own solution isn't going to be nearly as complex, and may be a breath of fresh air for your users who can be overwhelmed by extra unneeded features/complexities.
I've also found that vendors put a premium on integration features. The more features they provide for integration, the more their fear that you or another vendor's product will stand in place of one of their extra "modules" that they wanted you to buy from them.
Best of Both (Score:5, Insightful)
The company I work for has the best of both worlds. They go out and buy a $500,000 piece of Enterprise Software*, forgo the expensive contractors and dump the setup and configuration on 2 or 3 in-house developers, a project manager (who is usually an outside contractor who happens to be friends with an executive -- a budget locust, if you will) and an IT manager. After about a year the esteemed project manager moves on to the next project, the manager in charge gets promoted, the software is blamed for the lack of results and a new $500,000 purchase is made.
*For those that haven't used the stuff, Enterprise Software doesn't actually work out of the box. It's much like a do-it-yourself plane kit with lots of manuals on FAA regulations, a glossy guide full of pictures of planes "other customers" have built and a box full of parts (with a few random parts missing) but no actual assembly instructions.
It depends who is more competant (Score:2, Insightful)
It is better to outsource if you are outsourcing to people who are more competent than your in house staff. Unfortunately the people who make these decisions often are not sufficiently competent in IT to make an informed decision. My boss certainly never believes me when I tell him I'm more competent than those bozos.
Re:IT shops are run by MBAs those days (Score:0, Insightful)
From your post I take it that basic English skills are not required for your qualifications or job.
All of the major browsers should have spell-checked your post so really there is no excuse.
Re:Now if only ... (Score:4, Insightful)
Doing that now with a product being developed by a major company which shall remain nameless. I'm having doubts the corporate culture is actually capable of engineering such a complex product. We'll see.
The biggest drag about contracted services is that, even if you are lucky and they actually save time rather than waste it, they have external costs in that some of your projects get hamstrung waiting for vendor fixes. The flip side of that is at least you don't ever drown in a sea of options.
Yes, but be selective. (Score:4, Insightful)
This is true, but you have to be selective. Sometimes pre-built solutions makes since.
I've seem way to many people try to build solutions when an off the shelf solution would have been easier and cheaper in the long run. (say after a failure, and sometimes before!)
If you need a mail server with lots of accounts, but no bells and whistles. Build it yourself. You need an mail server with all the bells and whistles. (calendaring, etc) Buy one off the shelf. You will save yourself a lot of head aches. (providing you're not stupid in implementing your off the shelf product)
I have a couple of name brand HA NAS devices. I also have a couple of Linux NFS servers running DRBD and heartbeat. I knew where to buy off the shelf and where I could do it myself.
The blame game (Score:4, Insightful)
A lot of the time it's because when shit hits the fan then management can shift blame to the vendor and/or support contract.
Re:Not So Fast... (Score:5, Insightful)
Compromise - A Kit (Score:4, Insightful)
I'd like to see software "kits" for families of application domains. One purchases the software kit's source code and then customizes it, perhaps with an optional subscription to get future doo-dads.
Doing everything from scratch takes too long and buying pre-built solutions shoehorn you into something both missing features you need and that carries the baggage of features you don't.
Write them in common languages such as Dot.Net, Php, Java, etc.
However, enforcing licenses may be tricky.
Re:IT shops are run by MBAs those days (Score:4, Insightful)
Re:yes and no (Score:5, Insightful)
I'm not sure what Sharepoint's forte is. It's a file server with a web interface more or less with some MS-Office integration features. Some try to use it as a intranet WCM system, which it does poorly and requires lots of tweaking to work right. I don't get "it".
Okay, I call bullshit. (Score:4, Insightful)
I understand that some environments can be more flexible or more dialed-in to company/user needs with a full time, active development staff doing everything homegrown.
But the talent pool for this sort of thing is woefully limited. I've seen "in-house" development groups come up with some of the nastiest, most byzantine pieces of crap-hackery you could possibly imagine. And there's ZERO planning for what to do when the system reaches obsolescence. And don't give me any crap about how it won't ever happen. It WILL. Then, what's the upgrade path? How do you get the data out? And a million other niggling little things.
There's also the problem of relying on a group of individuals like this. It's essentially a thinly disguised form of vendor lock-in. Save the vendor is a group of your own employees. And what happens if they all up and move on to greener pastures? How do you maintain the system? CAN it be maintained? Can it be extended? Can ANYTHING be done with the system without bringing it crashing down?
How do you know Joe WannaSecureMyJob didn't back-door the system?
Yes, a lot of these are concerns you face with vendors too. But with vendor approaches, if you dislike the direction the project is heading, you can kill it, cut out the vendor, and move on to something you find more acceptable.
Not saying it CAN'T work. Just that the level of care you have to take when risk managing is different from what you need with outside vendors.
Re:Loaded cost of a software developer (Score:5, Insightful)
In my experience, the biggest difference in outsourcing operation of key software is that it forces internal customers to rethink their expectations. If software is maintained in-house, they expect it to fulfill their every whim. When the IT dept says "It will take 3 of our developers 6 months to do what you want", then say "Ok, we need it! Do it now!". But when they are dealing with a software vendor, and they say "It will cost you $175K to do what you want", they say "Hmm...well, that's kind of expensive, I'm not sure we need it".
When you have your own developers, they can tailor the technology to meet the needs of your business. When you purchase pre-packaged software, the business tailors its needs around the software.
Re:yes and no (Score:4, Insightful)
Like Sharepoint? It baffles me as to why anybody would buy that monstrosity... it doesn't do anything!
Sharepoint does do something, It firmly locks you in to the entire suite of Microsoft products (Windows, SQL Server, Exchange, Office) while at the same time irrecoverably looses your documents.
Actually almost all 'Enterprise' software is like this. No matter how much it costs it doesn't do a damn thing out of the box. To get it to do anything you have to hire an army of programmers and consultants to customize and configure it. The real money isn't in the product itself but in professional services to make it work.
Re:Now if only ... (Score:5, Insightful)
The article was about contracting versus in house gurus, and every month it seems there is always an article about the lack of gurus, hence the comment.
I suspect the problem is corporate executives who know the cost of everything and the value of nothing. There is a simple way to increase the supply of something: Pay more. If companies would pay competent IT people more money, then more people who would otherwise go on to be tax lawyers or securities traders will go into IT instead.
By contrast, what you hear in the media is the executives thinking with their MBA brains: If you want to increase supply, you can pay more... or you can go to the government and create artificial incentives to increase supply. More H1B visas. Government education subsidies for tech majors, to divert labor supply from occupations that pay the same or less than IT into IT. More supply at the same price.
The problem is that the latter doesn't create "gurus" -- it creates paper MCSEs. It makes the problem companies have in hiring competent staff that much harder, because you create a population of applicants who have degrees and certifications and even experience, yet have no earthly idea what they're doing. It attracts exactly those people who are too stupid to understand that a $1000 scholarship is a completely asinine way to make a career choice, instead of those who are smart enough to do just about anything and who make decisions based on forward thinking criteria like which career will allow them to afford a house in a neighborhood with better schools and a comfortable retirement.
It's the same disease that allows them to make the IT department a cost center: They count all of the salaries and equipment and ignore the productivity improvements that accrue to other departments as a result of their existence. Which makes it look like cutting staff or replacing them with less qualified but lower paid employees will save them money: The cost savings goes straight onto the spreadsheet, without accounting for the lost profits that will occur when a major system falls over and there is no longer anyone competent working there who can get it running before you lose a big client.
Comment removed (Score:4, Insightful)
Re:yes and no (Score:2, Insightful)
Well the fileserver portion is actually pretty slick. It's a rudimentary revision control system for said files, with a proper audit trail, unlike using a volume shadow copy, and just reverting by date. Additionally with a groove workspace you can trade files, IM files, or even created workgroup shares harnessed through sharepoint to trade files to Joe in Aruba, and Frank in Seoul. All without using anything more than an https connection. The files themselves do not need to be loaded into sharepoint directly even. They can be sitting on random puters, laptops, and worktstations in or outside of the LAN.
For the early adopters outside of IT, it's turned into a quick way that the marketing geeks trade mp3s without having them on an "official" fileserver as that's verboten. As one of the resident IT geeks and ostensibly the network paratrooper, I know they do it, but I'm turning a bit of a blind eye on it. They don't ask me no questions and I definitely move that traffic into the "less than best effort" diffserv queue in all the switches and routers :D
Your right, it tends to get used for an intranet portal pretty regularly.... and mostly poorly. The forums are grotesquely slow, the group workspaces through the web based part are tedious to use (really ditch it for a Sharepoint/Groove workspace). When you use Sharepoint as a relay between your intranet and the internet to facilitate teamwork it's actually pretty cool.
Could most of the collaborative bits be done in Exchange/Outlook, sure. But you might have to get the exchange team to build you a mailbox or a public folder or a shared workspace. With sharepoint, the users can just spool up their own workspace as needed. They can control the groups and then as rapidly they created the working group, they can also dissolve the groups when the project is done. No IT overhead for operational procedural changes.
It's really about the flexibility you give the users to police themselves.
Now is the cure more complicated than the poison? Good question, hard telling yet.
Re:IT needs apprenticeship not degrees. Tech schoo (Score:4, Insightful)
And what does CS have to do with IT?
Re:Okay, I call bullshit. (Score:4, Insightful)
I'm a contractor that has spent most of my career 'on site' at various large institutions. Never less than 2 years at any one spot - the contract has always been extended even after the original work has been done.
I've seen "in-house" development groups come up with some of the nastiest, most byzantine pieces of crap-hackery you could possibly imagine
Very true, It you hire crap staff you will get crap results. Most of the places Ive worked had environments like this. In fact, its usually why I get called in ("ARGHH!! ITS ALL SHIIIIIIT FIX IT!!!!!!!")
But with vendor approaches, if you dislike the direction the project is heading, you can kill it, cut out the vendor, and move on to something you find more acceptable.
Hang on. Your saying that an IT department that is not capable of hiring even basically competent staff is some how magically able to contract and evaluate a 3rd party to meet their businesses needs?
That's rubbish.
The same lack of management competency that led to hiring crap staff will result in a crap outsourcing project.
If you have a good management layer, you will succeed regardless of outsourcing or in sourcing. If you have a continual need for X number of developers, why pay the over head of a contracting firm? Sure bring in people when you need to, but they should support your in house team not replace them.
I say if your big enough for an IT Department, your big enough for at least one full time developer. If you want to outsource, then walk the walk and outsource THE LOT (Includes all CIO and IT related management positions)
Re:IT shops are run by MBAs those days (Score:4, Insightful)
I have seen this in many areas, not just IT. The idea that management does not have to have any of the skills needed to do the jobs subordinate to them is very prevalent. While a manager does not need the skills to sub in for all of their subordinates (although it does help), they should be able to do the job of a significant number of their subordinates. Otherwise, they will have trouble recognizing the relative value of different staff members contributions.
Re:yes and no (Score:5, Insightful)
I think I figured it out myself, but a certain amount of this is guesswork based on observation. Take it with as much salt as you think it needs - if anyone can add to this, please do so.
Sharepoint doesn't give you a lot out of the box, as you've mentioned. What it does give you is a very capable framework with which to put together your own solution.
What I think happens is this:
Person A (who is not in IT - perhaps he's a salesman) works for company B that implements a Sharepoint-based system. Company B is quite joined up - they'll get all the major stakeholders on board when there's a big project. IT will advise on sorting out the underlying infrastructure and making sure it all works; other business units will get involved to make sure the project achieves what it's supposed to. They take their Sharepoint project seriously - they allocate a budget to it, they put together a clear set of requirements based around their business processes (which were already pretty clear) and they hire in or contract out development work. Ultimately they wind up with an extremely competent system that does all they could ever want with pretty good efficiency - and the project is delivered in record time. Yes it's based on Sharepoint but they've really harnessed it to make it work for them.
Person A doesn't know anything about how the project was implemented, however. All he knows is that his employer brought in Sharepoint and it's fantastic.
Anyhow, time marches on and Person A gets offered a new job as a sales director at company C. It's a nice little promotion, so he takes it. What's the first thing he sees? Company C doesn't have anything like the sophisticated computer system he used at company B. So he demands Sharepoint.
Note that person A has a lot of influence in his new job. He's a sales director in charge of a small team who essentially provide the money the company needs to survive. He demands Sharepoint, he gets it. The problem is, nobody at company C - not even person A - actually knows what Sharepoint is. Oh, they know it's some sort of computer-type-system-thingy, but that's as far as they go. Expecting it to be a big project, someone is tasked to look into it and figure out how much it's going to cost..... oh. That's interesting. Apparently, Sharepoint is free. And not free as in "free from some dodgy website", it's a free download from Microsoft themselves.
So instead of putting a formal project together, the IT department simply downloads Sharepoint Foundation, installs it, sends everyone a URL and thinks to themselves "That was easy".
It soon becomes apparent that Sharepoint isn't the all-singing, all-dancing system our blue-eyed boy proclaimed it to be. Sure, it's a competent enough little Intranet and it's a lot less hassle than a traditional fileserver to store your documents on, but the way it was being discussed initially, anyone would think the second coming of the Messiah was in the form of a computer program. It sure isn't that. But nobody quite knows why.