×

Welcome to the Slashdot Beta site -- learn more here. Use the link in the footer or click here to return to the Classic version of Slashdot.

Thank you!

Before you choose to head back to the Classic look of the site, we'd appreciate it if you share your thoughts on the Beta; your feedback is what drives our ongoing development.

Beta is different and we value you taking the time to try it out. Please take a look at the changes we've made in Beta and  learn more about it. Thanks for reading, and for making the site better!

In Favor of Homegrown IT Solutions

Unknown Lamer posted more than 2 years ago | from the insufficient-buzzword-compliance dept.

IT 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.'"

cancel ×
This is a preview of your comment

No Comment Title Entered

Anonymous Coward 1 minute ago

No Comment Entered

265 comments

Now if only ... (0)

fsckmnky (2505008) | more than 2 years ago | (#38350746)

We can fly to that planet that clones stormtroopers and contract them to grow some IT gurus.

Re:Now if only ... (5, Insightful)

roc97007 (608802) | more than 2 years ago | (#38351044)

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.

...and the biggest things we've lost are agility, performance and stability. It takes easily an order of magnitude longer to get anything done, and downtime numbers ratchet upwards. But the company is grimly determined to stick it out, because the vendor has "mature processes" which we supposedly didn't have before.

Re:Now if only ... (3, Insightful)

Herkum01 (592704) | more than 2 years ago | (#38351162)

Hell sometimes you have to educate the vendor's minion's on what their product is supposed to do!

Re:Now if only ... (3, Insightful)

skids (119237) | more than 2 years ago | (#38351454)

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.

Re:Now if only ... (4, Interesting)

fsckmnky (2505008) | more than 2 years ago | (#38351170)

I didn't intend it as anything more than a maybe funny, snide remark. 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. The "we contract everything at our detriment" crowd, who complains about the lack of gurus, would contract to get an in-house guru, get it ?

Of course, I'm a guru, but I don't want to work for the "we contract everything" crowd, so maybe thats the problem. ;)

Re:Now if only ... (5, Insightful)

Anthony Mouse (1927662) | more than 2 years ago | (#38351970)

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.

Re:Now if only ... (2)

hazem (472289) | more than 2 years ago | (#38351212)

> and the biggest things we've lost are agility, performance and stability.

What's left that's of any value? Are they saving lots of money?

Re:Now if only ... (-1)

Anonymous Coward | more than 2 years ago | (#38351370)

What's left that's of any value?

Nigger jokes. And the way white people get more pissy about them than black people ever did. That part's valuable.

Re:Now if only ... (-1)

Anonymous Coward | more than 2 years ago | (#38351544)

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

Just highlight and chord-click...OOOohhhh, you're THAT kind of "guru"...

So contracted labor isn't all it's cracked up to b (4, Insightful)

sethstorm (512897) | more than 2 years ago | (#38350750)

When you treat people like second-class citizens by making them contracted labor, especially in IT, this shouldn't be a surprise.

Re:So contracted labor isn't all it's cracked up t (2)

stephanruby (542433) | more than 2 years ago | (#38350840)

Yes, it's better to make them full time exempt employees, this way you can make them work sixty hours a week without over-time.

Re:So contracted labor isn't all it's cracked up t (1)

Anonymous Coward | more than 2 years ago | (#38351066)

You first need to recruit them and that is where the at-least-15-years-experience-with-windows7 headhunters try to score their introduction bonus, providing you with the wrong people loaded with certificates which only prove that they are very good in following the Cisco/Microsoft/Orcale guidelines.

All-round programmers with a solid experience that run entire enterprises with just a small group are a endangered species.
Take good care of them.

Find a decent employer, for what rarity they are. (3, Interesting)

sethstorm (512897) | more than 2 years ago | (#38351240)

Some of us have worked for employers that made the extra hours worth it; that doesn't mean you'll have to exclude large businesses either as well.

How about fixing the overtime law to remove the IT exemption, along with something that makes requirements more reasonable(e.g. if you can't find someone, you're going to be on the hook for directly hiring someone - not as any form of a contractor - and training them as an FTE at full wage)?

Loaded cost of a software developer (0)

Anonymous Coward | more than 2 years ago | (#38350772)

The loaded cost of a developer (including benefits and the like) is in excess of $200,000. Per year. For just one guy. How is this cheaper than most support contracts?

Re:Loaded cost of a software developer (2)

MrEricSir (398214) | more than 2 years ago | (#38350850)

First of all, if your software engineers are getting paid $200,000, could I forward you my resume?

Second, support contracts can easily cost far more than that.

Re:Loaded cost of a software developer (2, Informative)

Anonymous Coward | more than 2 years ago | (#38350868)

Salary is probably in the neighborhood of 80-90k. There are a *LOT* of other costs. For example the computer, the desk, the chair, the lighting, AC/Heat, internet, 401k, SS, health insurance, etc...

Re:Loaded cost of a software developer (1)

shaitand (626655) | more than 2 years ago | (#38350888)

Most of those "costs" are general overhead that you'd have to pay with or without the developer.

Re:Loaded cost of a software developer (4, Insightful)

Grishnakh (216268) | more than 2 years ago | (#38351104)

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:Loaded cost of a software developer (4, Informative)

garyebickford (222422) | more than 2 years ago | (#38351402)

When I worked at an F500 high-tech company, they accounted the total cost of each software and hardware engineer as 2.5 times salary. This included the buildings, computers, training, and all the other stuff necessary to keep the engineer productive. For big companies that's probably still pretty reasonable.

Re:Loaded cost of a software developer (1)

Grishnakh (216268) | more than 2 years ago | (#38351432)

Wow, that's more than I would have thought; I would have guessed 2x at the max.

Re:Loaded cost of a software developer (4, Insightful)

hawguy (1600213) | more than 2 years ago | (#38351848)

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:Loaded cost of a software developer (5, Informative)

salesgeek (263995) | more than 2 years ago | (#38350948)

Loaded cost for an employee is typically 18% of salary + $320/month for real estate overhead. So a $90 K employee ends up costing about $120,000 with benefits.

No (0)

Anonymous Coward | more than 2 years ago | (#38351008)

For most large organization, overhead is assumed to be 50% of an employee salary.

Of course, we have retirement plans, funded 401K's, excellent medical care, and a great downtown location (to name but a few).

So the original poster had it right.

Re:No (2)

alexander_686 (957440) | more than 2 years ago | (#38351070)

And
      Company paid training
      Pay Roll Tax
      Vacation leave with pay
      Family leave without pay (Why do you say that's a cost? With a group of about 20 you can expect 1 or more to be off missing for a extended period of time - need to build in some type of cushion.)

A lot of time we go with outside vendors just because it's easier. We will get random regulatory requirements (in 2 years everything must be published in BRML). Do we want to retro fit our current process to that standard (and hire new staff to handle this new technology) or just go with a 3rd party vendor? In this case we went with a 3rd party vendor - because we know next year another huge, random, request will come down the pike.

Re:No (0)

Anonymous Coward | more than 2 years ago | (#38351096)

He had it right for your company, but maybe not for your competitor...

Think about that. Maybe your company has too many managers^H^H^H^H^H^H^H^Hoverhead.

Re:Loaded cost of a software developer (0)

Anonymous Coward | more than 2 years ago | (#38350890)

Can support contracts that cost more than $200k/year be replaced with a single employee?

Re:Loaded cost of a software developer (2)

Rob Riggs (6418) | more than 2 years ago | (#38350886)

The loaded cost of a software developer depends a lot on location and industry.

Re:Loaded cost of a software developer (2)

gutnor (872759) | more than 2 years ago | (#38351166)

My company charges 2000$ per developer per day for enhancements, analysis, ... (bug fixes are free though, some client pay more, some *much* less). So you can pay up to 500.000$ per year per dev.

Our client have so little staff that they hire us (at that rate) to analyse their requirements on their systems. Recently they hired 5 people for half a day for basic data entry (skill level = updating status in facebook) They are literally bleeding money anytime their business is not working entirely automatically. Some client have literally outsourced their whole business knowledge to us - they don't have a single person anymore that has experience with what the system is supposed to do and how it interacts with other system in their organisation. The best/worst part ? They pay that rate even if the developer actually doing the work is a cheapo one from our indian office.

But ... we sell that rate because we do our job and that means that generally after a while the system settles. Some of our client have basically no interaction with us for years. So the problem is not as easy as it seems: sure they overpay massively for a short period of time (a few years), but hiring would commit them with long term employees.

Management (-1)

Anonymous Coward | more than 2 years ago | (#38350790)

Yes, but to be able to do this would require management to be able to actually make a sensible decision that could be justified (and they don't seem to be able to do that)

IT shops are run by MBAs those days (2, Informative)

Anonymous Coward | more than 2 years ago | (#38350826)

I was trained to be an IT manager, where most people move on to an MBA. All the classes taught were BS outsource this, best of breed that, vendor support another. The technical skills were deemphasized to the point that they are "complementary skills" rather than primary ones. You don't need to know how to manage a server, or configure Active Directory, or run an Exchange mail server. All that you know is to write business requirements for vendors to come in and set everything up.

My company decided to go with a vendor for their accounting platform, Great Plains. And now whenever we want to do any shit in that application, the vendor would take eons to come back with a workable solution and bill a fortune -- a great pain! Fortunately, the IT director, who is a highly technical guy, saw the problem and sent a few folks for Great Plains training.

Re:IT shops are run by MBAs those days (4, Insightful)

jellomizer (103300) | more than 2 years ago | (#38351090)

Those must be some bad MBA schools in your area. I got an MBA and I was never taught we should outsource everything.
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:IT shops are run by MBAs those days (0, Insightful)

Anonymous Coward | more than 2 years ago | (#38351448)

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:IT shops are run by MBAs those days (0)

Anonymous Coward | more than 2 years ago | (#38351598)

really there is no excuse.

not giving a fuck is one

Re:IT shops are run by MBAs those days (0)

Anonymous Coward | more than 2 years ago | (#38351634)

What is "venders", Mr MBA?

Re:IT shops are run by MBAs those days (3, Insightful)

AK Marc (707885) | more than 2 years ago | (#38351662)

In my MBA program, we discussed that outsourcing almost always costs more than insourcing for the simple matter that if it costs them $10 to do it, or costs you $$10 to do it, they'll mark it up 50% and sell you the service for $15, but if you'd had the capability to do it at cost, you'd be out $10. Oh, and that the single greatest "cost" of outsourcing is almost never counted. Risk. What's the risk the outsourcing company will close down? don't know? Then you shouldn't be relying on them for a business critical function. What's the risk that your competitor could pay off your outsource company to get access to your systems? Don't know? Then why are you outsourcing?

yes and no (4, Insightful)

Trepidity (597) | more than 2 years ago | (#38350834)

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 (-1)

Anonymous Coward | more than 2 years ago | (#38350848)

Maybe you just don't know what the fuck you're doing? That's my guess, fucktard.

Re:yes and no (5, Insightful)

Mad Merlin (837387) | more than 2 years ago | (#38350962)

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!

locks you into microsoft? (0)

Anonymous Coward | more than 2 years ago | (#38351000)

that's my guess.

Re:yes and no (2, Informative)

BitZtream (692029) | more than 2 years ago | (#38351226)

Because there isn't any alternative that integrates with as many other products and provides as many features in as easy to use package as Sharepoint + Office?

If you don't understand why people use sharepoint you don't need to be discussing IT related topics as you're clueless.

Sharepoint, much like Outlook is a steaming pile of shit, but its still better than the alternatives ... which there aren't any.

Re:yes and no (5, Insightful)

Tablizer (95088) | more than 2 years ago | (#38351668)

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".

Re:yes and no (2)

jonwil (467024) | more than 2 years ago | (#38351252)

The problem is not SharePoint, its people who use SharePoint for things it is not designed for.

Re:yes and no (1)

sleigher (961421) | more than 2 years ago | (#38351352)

You mean like when the director says get rid of all file servers and put everything in sharepoint? hmmmm...

Re:yes and no (0)

Anonymous Coward | more than 2 years ago | (#38351422)

The problem is not SharePoint, its people who use SharePoint for things it is not designed for.

Oh yeah , its a piece of shit whatever way you look at it . Sharepoint design should be included in classrooms for teaching what not to be .

Re:yes and no (1)

hjf (703092) | more than 2 years ago | (#38351806)

Yeah, everyone knows Excel spreadsheets are the answer. I mean you can do anything with them. Price lists, contact databases, everything. It's just great.

Re:yes and no (1)

Lehk228 (705449) | more than 2 years ago | (#38351854)

we got set up with a sharepoint server quite a few months ago, as far as i know nothing has happened with it since then.

it effectively allows semi-technical people to clumsilly administer their own versioned file repository and self contained WYSIWIG web site maker for internal sites with semi-database features.

in short, it is a case of rope you can give to management types that is just long enough for them to hang themselves with.

Re:yes and no (3, Insightful)

jd2112 (1535857) | more than 2 years ago | (#38351886)

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:yes and no (0)

Anonymous Coward | more than 2 years ago | (#38352022)

For a group that doesn't use any Dynamics products, there's plenty of OSS ways to do some of the basics of Sharepoint, arguably better than Sharepoint does them. But when you're running a line of business application like DynamicsNAV, DynamicsAX, or even Great Plains, Sharepoint becomes a web front end for some really valuable information locked up in the aforementioned products. Your paystub, inventory, deliverables, receivables, you know the things that pay the bills.

Re:yes and no (2)

roc97007 (608802) | more than 2 years ago | (#38351142)

It's not necessarily the application, it's the system management. The vendor in our case manages the exact same applications that we used to manage in-house, only a *lot* slower and with hilarious communication issues.

I'm pretty sure the article is talking about infrastructure (partly because the summary *says* "shift the burden of maintaining and troubleshooting large parts of their IT infrastructure on to the vendors") which doesn't at all mean, to me, that the IT admins were writing their own database and the IT manager wanted to use Oracle instead.

Some things *are* generic, like most email requirements, and can be managed in a generic way. But even then, you have to be careful of bait-and-switch, where the vendor parades first class IT engineers in the discovery phase and then what you actually get are former Hyundai assemblers in Sriperumbudur.

Re:yes and no (1)

Tablizer (95088) | more than 2 years ago | (#38351726)

In my observation, well-run in-house software is better than crappy off-the-shelf software and vice verse. It's a matter of managing, configuring, and selecting tool choices and staff smartly. I know this is probably obvious, but there are some who insist one is almost always better than the other based on a few bad experiences.

Exactly... (3, Interesting)

gadzook33 (740455) | more than 2 years ago | (#38350940)

I couldn't agree more with this. We run an in-house development shop that continually out-performs areas of the organization that purchase COTS stuff (and then spend millions trying to customize it). In the beginning we got a lot of crap for having a "not-invented-here" approach and coming up with custom solutions. The first time we replaced one of these multi-million dollar solutions with something much cheaper (and easier to maintain) the comments stopped. This isn't to say we don't use commercial frameworks, appliances, etc. But these are tools (sometimes power tools), not pre-fab homes.

Opportunity cost (0)

Anonymous Coward | more than 2 years ago | (#38350958)

Keep in mind that if you are asking someone to do IT, and they paid to be a software engineer, you are paying double for that person. once for IT work and once for lost software productivity. Not an absolute truth, but something that too many nerds overlook.

Integrating Diverse Software (4, Interesting)

DERoss (1919496) | more than 2 years ago | (#38350982)

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.

For 24 years, I worked for the System Development Corporation (SDC), which eventually became part of Burroughs which then merged with Sperry Univac to form Unisys. We worked with the Aerospace Corporation and with Lockheed. Together, these three companies held the organizational memory needed to maintain computer systems for operating an ever-changing array of earth-orbiting space satellites. Our role at SDC-Burroughs-Unisys was to receive software packages from 10 or more independent software development companies (sometimes the same companies that built the satellites) and integrate them into a single system. We audited the developers' specifications and tests, tested the merged packages, performed configuration management, prepared user documents, conducted training for the end-users, and diagnosed suspected errors. On occasion, we even rejected software and sent it back to the developer company to rework. Contrary to current practices, the most senior professionals also provided "help desk" support. In all the time I worked on this project, not one space satellite was lost due to a software error. Considering the cost of a space satellite, the fact that our task doubled the overall cost of software development was money wisely spent.

While the project on which I worked was technically out-sourced from the U.S. Air Force, the repeated renewal of our contract and the contracts of Aerospace and Lockheed created an in-house professionally-skilled environment for acquiring and evaluating software. As a result, a very large software system with an expected life-span of 15 years evolved and was used for over 20 years.

Re:Integrating Diverse Software (4, Insightful)

BitZtream (692029) | more than 2 years ago | (#38351242)

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:Integrating Diverse Software (3, Interesting)

Alan Shutko (5101) | more than 2 years ago | (#38351386)

If the project has been around long enough, you end up with a bunch of people who only have a max of three years of experience with it, and any knowledge of the full history is second, third or fourth hand. The risk is that as you keep cycling people out, you develop an angry monkey situation [blogspot.com].

Re:Integrating Diverse Software (0)

Anonymous Coward | more than 2 years ago | (#38351694)

And the danger if you depend on "greybeards" for everything is what to do when they leave/get run over/etc. All of a sudden that expertise that keeps things running is GONE. One thing the military is good about is documenting - because you know someone WILL be taking your place, and you will be moving on. In my experience organizations that depend on greybeards don't have the same mindset - partly because that undocumented knowledge is what makes the greybeards so valuable.

Both have a place.

Re:Integrating Diverse Software (2)

AK Marc (707885) | more than 2 years ago | (#38351732)

When you institutionalize the transfer of knowledge, it doesn't matter that any particular person isn't there. The others are aware of the task, and the "why" is less important.

Source Code License (3, Interesting)

dg41 (743918) | more than 2 years ago | (#38350990)

This brings up a question. My organization replaced our old ERP and CRM-like system which was bought 20 years ago with the source code and heavily customized. The administration (through thir consultants-ugh) declined to buy the source code licenses for the new applications because "modern organizations don't buy source code licenses anymore." Now, predictably, people are upset because we cannot tailor the apps to our business rules. My question is whether the statement of the consultant is crap or not: do companies nor buy the source code license and solely rely on vendors to make changes via upgrades or custom programming?

Re:Source Code License (0)

Anonymous Coward | more than 2 years ago | (#38351122)

Always ask yourself where the loyalty of your consultants is.
Are they declining something to be able to shake more money out of your company.
Putting 4~5 consultants on upgrading your systems is probably much more profitable for them than buying a ready made software solution and hooking it up to your system.
The companies I worked for bought some source code in case it would save them some time developing.
Especially software for calculation certain statistic were just bought because it would take up too much time to build it our selves.
And you'll have support on them so if something doesn't work, the vendor can always help you out.

Re:Source Code License (2)

BitZtream (692029) | more than 2 years ago | (#38351244)

Well, considering the number of companies that still sell source code ... I'd say you should be able to draw your own conclusions.

You can, for instance, get the source to most of Windows, for the right price.

Re:Source Code License (5, Insightful)

AaronLS (1804210) | more than 2 years ago | (#38351262)

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.

Re:Source Code License (1)

tqk (413719) | more than 2 years ago | (#38351922)

This contractor/consultant negotiates a contract with clients. Clients can specify whatever they damned well please to be in the contract. Speaking only for myself, pretty much anything I do while contracted to a client is owned by the client, and I'm happy to sign NDAs as well. You pay my hourly rate, and I'm yours for the duration of the contract.

Often, going into an assignment, details are murky and I may end up working on anything; fine by me. Anything the client wants done after the contract ends is covered by a new contract.

I don't get benefits, vacations are taken on my own time (unpaid), and I can work remotely using my own hardware/software, cellphone, ... Clients only pay my hourly rate + sales tax.

I'm not a business consultant; I only work with tech. If I'm not getting the work done, clients can terminate the contract on no notice. I'm expected to give them two weeks to thirty days notice to terminate from my side. Neither's ever happened in my experience (early termination).

I often wonder why employers suffer employees at all. I often wonder why employees can suffer being employees.

Shortsighted (3, Informative)

wiedzmin (1269816) | more than 2 years ago | (#38351014)

While I would love to wave this article at my management and say "hire more gurus", I find it somewhat disconnected from reality. This concept would only work if you had a department dedicated to in-house development, with unlimited permanent headcounts all of whom would be flawless in developing, documenting and supporting their respective applications in a uniform, regulatory-compliance friendly manner and who would never, ever move on to the greener pastures. In reality, you have self-proclaimed "developers" from various departments, writing spaghetti code designed to address their specific problems, then eventually quitting and leaving IT to struggle with supporting the uncommented, undocumented application that now cannot be replaced because it contains "all customer data". And when your friendly neighborhood ISO 27001 auditor comes along, you end up hiring 3 more people to fix every missing data validation, credential management and change control problem in this irreplaceable creation, and then, maybe, it becomes that wonderful application the author is hoping to push for.

On the other hand, if you get a third party vendor to provide you with a solution - your upfront costs will seem higher, but chances are - unlike your departed headcount, that vendor exists for the sole purpose of supporting their solution. Their features, functionality, security and regulatory requirements have either already been hashed out by other customers, or will be hashed out for your if you ask for them. And unless they're a small enough vendor to go out of business without selling their assets to someone else who will take over, they will be there to support that application and provide feature updates while your in-house developers come and go...

Re:Shortsighted (1)

Anonymous Coward | more than 2 years ago | (#38351116)

In reality, you have self-proclaimed "developers" from various departments, writing spaghetti code designed to address their specific problems, then eventually quitting and leaving IT to struggle with supporting the uncommented, undocumented application that now cannot be replaced because it contains "all customer data".

As opposed to cutting a cheque to a third-party vendor so that you have the privilege of running their spaghetti code, then having the vendor go out of business or be gobbled up, with that particular product being discontinued, so that it now cannot be replaced because it contains "all customer data".

I've seen both scenarios happen. Pain occurs either way; pick your poison.

American Businesses hurt themselves here (0)

Anonymous Coward | more than 2 years ago | (#38351158)

IF you have a full-time support staff onboard, who "grew from within the ranks" of said organization, you have people who not only know the general tech details of OS, serverware, & programming + network support, but?

Addtionally - You have kept valuable people there at work who KNOW THE BUSINESS TOO, & where the data is, + what it is for and what it does... I.E.=> They "know the lay of the land" & how/why it's the way it is there...

This latter portion? That's what's missing a LOT nowadays in companies...

(And, it's what you miss out on when you decide to "outsource" or "offshore"!_

With "offshoring/outsourcing"? Heh - you get a "support staff" that may (or may not be) knowledgeable with the OS, serverwares, middlewares, & programming languages/toolsets, but also DO NOT KNOW the business flow of information particular to said company & data is a lifeblood source for many companies!

(IS systems wise, & mainly DB device locations + purposes of data they store, reports run over them, languages used to create said reports, etc./et al).

APK

P.S.=> It's a "double-edged sword" when you don't keep a long-term dedicated IS/MIS/IT team in place in a company - you LOSE what I noted above (big thing to lose)...

Why do companies do outsourcing/offshoring then?

Imo, Greed: Why keep on dedicated staff (& the costs like insurances, pensions, etc. as well), when we can "OUTSOURCE/OFFSHORE" & save on those costs in the "long term"?

This only weakens an "economy" when you take better than "hand-to-mouth" minimum wage jobs away from people, especially those in tech trades (as has been done since mid last decade the most imo), & this hurts an economy since less "disposable income" for "fun" above food, rent/mortgage for shelter, utilities, etc is not present in the hands of spenders...apkb

Re:American Businesses hurt themselves here (0)

Anonymous Coward | more than 2 years ago | (#38351948)

Shut the fuck up you stupid Hairyfeet fucktarded motherfucker. Back up your fucking host file and you dns servers, fuckstick.

Re:American Businesses hurt themselves here (0)

Anonymous Coward | more than 2 years ago | (#38352008)

Have u considered decaf?

Not So Fast... (3, Insightful)

Harshmage (1925730) | more than 2 years ago | (#38351050)

While having in-house solutions is great, but what happens when people move on? I work in the EDU part of the IT industry, and we have a particular system that was designed by a former employee, picked up by a second, redesigned by the same person, who denies that anything could be wrong with it. Support calls to them go unanswered, and they're rarely in the office. And they are one of the three Directors in IT. Personally, I work on our Windows 7 deployment, and all the underlying AutoIt scripts, plus the virtualization of our applications. I have trained all of my colleagues in what they may need in the event of my demise (or less worrisome event). And I get paid about $34k a year.

Re:Not So Fast... (4, Insightful)

AdrianKemp (1988748) | more than 2 years ago | (#38351222)

The job length of a well paid and respected employee is far longer than your typical product life cycle.

Re:Not So Fast... (2)

DarthBart (640519) | more than 2 years ago | (#38351380)

Yeah, but what happens when you need support from Whizbang Application Widgets, Inc and you discover that they've closed up shop and gone under?

At least with an inhouse application, you've got the code and can see what needs to be done/fixed.

Re:Not So Fast... (4, Insightful)

Belial6 (794905) | more than 2 years ago | (#38351526)

The same thing that happens when the employees move on from the company you contracted with. You just have a better chance of seeing it coming.

It goes both ways... (1)

caladine (1290184) | more than 2 years ago | (#38351130)

Like most things, there needs to be some balance between those things that you get from a vendor, and those things you do in house. Too much of either end of the spectrum is generally a problem. Too much from the vendors and you end up with the scenarios that the author describes. Too much of the in-house work, and you end up with a NMH (not made here) mentality which is ultimately destructive to the company. You end up wasting too much time re-inventing the wheel when an off-the-shelf solution would be adequate for your needs.

In the end, weigh the factors involved (timeframe, cost, how close existing solutions are to what you need ) and just make sure you pick the right tool for the job. Too much time with the hammer, and everything starts looking like a nail.

Re:It goes both ways... (1)

theunixbomber (2023818) | more than 2 years ago | (#38351468)

I would very much agree with this. A balanced approach is needed.

The company I work for is always looking for that magic bullet. Some 3rd party software that will solve all of our problems. I keep trying to explain that what we need is good flexible software that will solve some/most of our problems. If we choose the right software, we can then write our own code to pick up the slack of the 3rd party software. Hopefully we can also write some code to integrate software A with software B.

But no matter how hard we search, no company has written software that will solve all of our problems.

On the fence (1)

um... Lucas (13147) | more than 2 years ago | (#38351174)

I work at a small law firm, and all of our infrastructure is in house. Since I wear a few hats, and with the IT part of my job now the least demanding part, I've been contemplating moving some of our services out. It does get disruptive when there are fires to be out out right when there are deadlines due.

One thing I've been investigating is abandoning exchange for google apps. It would defiantly help up the security, as we'd only need a single open rdp port. And maintenance, service packs, anti-spam subscriptions would mostly become a thing of the past. Uncomfortable with google though, as we do have a lot of confidential information in our mail flow, and their propensity for analyzing very it of data they an get their hands on seems counter to the need for privacyin our communications.

Or course I haven't read their usage agreement so maybe by virtue of paying them for services, they might eschew the need to learn everything they can about us and our clients.

Point being, there seems to be a trade off that makes outsourcing the deal worth looking into, especially for small firms where budgets and manpower face more constraints than with fortune500 companies.

Any thoughts for or against?

Re:On the fence (1)

kiwimate (458274) | more than 2 years ago | (#38351274)

Any thoughts for or against?

Yes.

1. I have a lot of experience with law firms, and before you pitch going with Google (and turning over all your confidential data) you'd better have your ducks in a row.

I haven't read their usage agreement

2. This isn't having your ducks in a row.

Point being, there seems to be a trade off that makes outsourcing the deal worth looking into, especially for small firms where budgets and manpower face more constraints than with fortune500 companies.

3. Yep.

4. If you're going to make a significant pitch, get someone else to check the grammar before sending it off to lawyers. (Hint - much as I dislike Google, going to Google apps still can't really be said to help increase security in a defiant manner.)

Re:On the fence (1)

enjar (249223) | more than 2 years ago | (#38351430)

1. Ask your user base what they want (they pay your salary :) )
2. Look for Exchange hosting companies if you want to move it out. I would not be surprised to know there is some hosting company somewhere who specializes in dealing with law firms.
3. Make sure to have a lawyer review it :)

Real I.T. professionals don't agree with InfoWorld (1)

tfiedler (732589) | more than 2 years ago | (#38351220)

I have 20 people who support 7,500 endpoints, nearly 1,500 printers, 450 servers, and over 500 switches across a multi-site facility. Consider also ensuring that data is backed up, secured, and that disaster recover works they way you planned, or the difficulty in finding people who can solve problems, which is what being a good I.T. professional is actually all about.

I outsource to vendors because I simply haven't got a chance in hell to support it any other way.

For a talking head, such as Paul Venezia to have the audacity to think he knows jack about the enterprise is an insult to those of us who do, and indicative of what is really wrong in I.T.; people who have neither the intellect nor aptitude for information technology being in positions to influence the industry, like the editors for rags like InfoWorld.

Re:Real I.T. professionals don't agree with InfoWo (1)

AdrianKemp (1988748) | more than 2 years ago | (#38351312)

When people reference nothing but hardware you know they have no fucking clue about enterprise or the industry in general.

I can count on one hand the number of man-hours spent on switches in a year. There are days when I can't count on both hands and feet the number of man-hours wasted on a buggy vendor-provided API.

Vendors know their products? (1)

modmans2ndcoming (929661) | more than 2 years ago | (#38351304)

My experience has been the vendor theoretically knows their product, in that they know where to configure something.... but they know shit about how their product operates in the IT infrastructure of your company. most of the vendor products I have installed needed quite a bit of extra code to be written just to fit into the environment and be able to be properly monitored so the support staff on our end could go home for a weekend and not have to worry about files that did not process for 4 days with the first alert being the people we send these processed files to bitching.

Another product (an e-forms product) was so difficult to publish new forms in, that when I handed it off I wrote a utility that allowed the new support staff to publish, move, rename, and remove forms from any location in the forms tree.

Vendors pretend that their products are the only ones in your IT department. you still need good staff to integrate them.

Best of Both (5, Insightful)

maeglin (23145) | more than 2 years ago | (#38351310)

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 (2, Insightful)

Anonymous Coward | more than 2 years ago | (#38351314)

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.

Generic Solutions and Support (1)

David_Hart (1184661) | more than 2 years ago | (#38351340)

Most mature organizations have reached the point of understanding that custom solutions cost too much to maintain and support unless they are core to the business. Organizations make do to with off-shelf-solutions and support. As for integration, more and more organizations are also buying software suites instead of standalone products or relying on contractors for integration.

In fact, custom solutions actually makes organizations less nimble by tying them to their customized in-house infrastructure. By buying off-the-shelf solutions, it is easy to change products and migrate data, as competitors provide tools to make transition from competitor products easy. Migrating data from a customized solution, especially a large one, takes takes at least twice as much time and resources. In addition, if the homegrown solution relies on a few gurus to support it, what happens when they leave? At least off-the-shelf solutions have a support organization that understands the product throughout it's lifecycle.

I do agree with Paul Venezia that it is difficult to measure the trade-offs. But most organizations that have lived through the customization era of the 80's and 90's went to off-the-shelf solutions during the Year 2000 upgrade cycle and haven't looked back since. It was during Y2K that they realized just how much all of that customization was going to cost them. The trade-offs, at least at that point, favored off-the-shelf solutions. My thought is that they still do.....

Yeah totally stupid. (4, Interesting)

unity100 (970058) | more than 2 years ago | (#38351378)

Imagine - you are trusting a PRIVATE party with your sensitive stuff. they can do something stupid and go bankrupt, get sold, this that. you have no power over hirings there, so you wont know whether they are hiring reliable individuals or people who could leak your stuff at any given point. what are their goals their policy changes this that.

basically you are giving your balls to them. and they grip tightly.

i.t. became too complicated now indeed. but, is that much complication really necessary ? KISS rule (keep it simple, stupid) is applied in software development, but, ironically it is not applied in setting up i.t. infrastructure of an organization - nowadays people try to incorporate every 'next big thing' into the setup. and you get a mess.

KISS outside, KISS inside the infrastructure. And then keep your own infrastructure. That's the key.

Re:Yeah totally stupid. (1)

HockeyPuck (141947) | more than 2 years ago | (#38351844)

You forgot the fact that when you work with a PRIVATE party, you have to agree to a legal document up front. Want to approve of every single employee that works on your system? Get it in the contract (aka "Statement of Work"). Want to make sure nobody works on it that is not a US citizen? Get it in the contract. Uptime? Unscheduled outages? Scheduled Outages? How long it takes for a part to get on side?

Get it in the contract. And if they're in breach, set the lawyers on them and get your money back.

Good luck doing that with Dept 8675309 and the long bearded fellow, who's thinking about retiring or the young kid who dreams of quitting and going to Facebook.

Oh Dear God No (well, maybe Yes, sometimes) (2, Interesting)

enjar (249223) | more than 2 years ago | (#38351404)

I work at a company that has a very high "we build it ourselves" ethic. This can be a great thing if you are actually spending time and energy on building the product you are shipping, as that does crazy things like create value for the company and generate revenues because you deliver the features people actually want. Revenues end up making profits. This pays my salary and ends up putting food on the table, paying the mortgage and keeps the house warm. YAY.

What doesn't do a darn thing for productivity and the generation of those features are competing version control systems, programming environments, poorly written/maintained tools, web pages that are barely comprehensible and business processes that make you want to jump out of the nearest window. For every new technology we have adopted over time, in many cases there was some piece of junk that someone had developed in a blitz over a weekend as a "temporary thing". They moved on to some thing else, and the temporary became five years when much better stuff came and went -- and we still did it The Way We Know.

I'm not saying that any internal wizardry should be avoided -- but really when you develop internal solutions you should know what you are getting into, and know how long you are going to put up with it, especially when the remainder of the world moves on -- and leaves you behind the times. Also be VERY wary of what's termed "the lottery problem" or the "hit by a bus" problem -- as in, when the guru who put together your super awesome sales lead processing database / application stack that's central to your company making money doesn't show up at work anymore, what are you going to do? When the desktop machine that's responsible for keeping track of your development metrics is re-imaged by mistake, what do you do then? When the world's best custom-designed project tracker heads for the bit bucket with all the plans in it, what next? Hopefully these kinds of things can be identified and the little projects that grow into business critical services will be properly supported, but I've seen it go the wrong way quite a few times.

Re:Oh Dear God No (well, maybe Yes, sometimes) (2)

Rumtis (887583) | more than 2 years ago | (#38351718)

A good (maybe not great, though) analogy I heard of in regards to in house IT: Designer clothing

An internal team will cost extra, but can create a solution that fits the company perfectly and it looks/works *really* good. The thing is (a) they are the only ones who can build it just to the company's needs and (b) hopefully the size of the company doesn't change dramatically. Otherwise it won't fit right.

On the other hand, a one size fits all may work for the company, but nobody looks good in a muumuu.

There seem to be economies of scale here (2)

fiordhraoi (1097731) | more than 2 years ago | (#38351418)

While I can see a larger business being able to support the personnel to have such an experienced/skilled in-house development team, the fact is that for most small and mid sized businesses such a setup just isn't worthwhile.

One of my previous jobs was the systems/network administrator for a 65 person company. The yearly IT budget for software licensing, hardware, etc was about $150k. The software we bought met the needs of the company admirably, with only a little bit of customization required. Myself and one of the other IT staff were reasonably skilled as DBAs and could customize reports from our databases (a mix of Oracle, MSSQL, and MySQL), and the other guy was decent at wrapping the GUI around those queries. There's just no way that the $150,000 of our yearly budget could be stretched into hiring programmers to make custom software for us. Nor was there a need to do so - our needs were small enough - and to be frank, generic enough - that existing enterprise software just plain did what we needed with a minimum of hassle. The benefit as compared to the cost of creating a development team just didn't make sense looking at the ROI. In fact, there was no ROI at all.

That said, I can see companies with unique needs and larger companies with more complex business processes needing a better solution. For them, it may well become worthwhile to consider custom solutions for more of their tricky items.

Someone Else's Problem (0)

Anonymous Coward | more than 2 years ago | (#38351470)

While there are some advantages to outsourcing (to a vendor) you tend to lose Professional Stewardship and Institutional Knowledge.
Something that isn't considered when calculating the savings of outsourcing to a vendor.

That server in the next rack making weird noises is somebody else's problem.

"This is because it relies on people's natural predisposition not to see anything they don't want to, weren't expecting, or can't explain." - Douglas Adams

 

Yes, but be selective. (3, Insightful)

C_Kode (102755) | more than 2 years ago | (#38351472)

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.

Undisciplined nerds and ivory towers... (1)

Anonymous Coward | more than 2 years ago | (#38351510)

Several decades of bleeding projects, IP locked in the brains of self professed 'gurus' is what brought this about.

How many large projects have you been involved with that a) developed reasonable quality support documentation b) didn't vest all of the knowledge in the project team and c) Had a thorough handing over to a BAU team, with adequate funding and resources to run it.

Crickets?

Yeah, thats why you outsource. All you need to worry about is the bill, and you've got a handy outside organisation to scapegoat when things go wrong. Substantially lower career risk.

IT nerds with poor project discipline brought this change about.

Re:Undisciplined nerds and ivory towers... (3, Informative)

Todd Knarr (15451) | more than 2 years ago | (#38351742)

My response is:

  • A: How many projects actually budget time and resources to developing documentation? Most of the time management insists on trimming that time off the project because it doesn't deliver any business features and will take longer than the actual development will (documentation is a time-consuming project in itself).
  • B: How often does management not want to allocate additional staff to essentially do nothing but learn someone else's job? The usual line I hear from management is that there's no return there, the additional person won't be doing anything that isn't already being done and they could be more useful doing something that isn't already being handled. And see A about documentation.
  • C: A good point, developers often aren't good at hand-off. But they aren't entirely to blame, see B and A for management's unwillingness to invest time and resources in the things you need to do a successful handoff. I also see a certain unwillingness to hold a BAU team responsible when the developers are right there and can just help with any problems that come up.

As with many things in IT, it comes down to the fact that the developers are not the ones with the authority to do these things. The authority and the responsibility rests with the managers and executives who make the decisions and set policy. As an "IT nerd" (read "techie, guy who's paid to make the little boxes with the blinkenlights do their thing") I'm often caught between the desire for good project discipline and the reality that management doesn't want good project discipline because it interferes with delivering the most features in the least amount of time (notice that I said "features", not "bug-free working software"). And I can't tell the CIO "No, you're not shaving 4 weeks off the project schedule. No, you're not assigning Joe to another project. No, you're not adding those 5 new requirements to the list without adding additional time to the schedule.". I'd love to, but I'm not his boss so I'm not the one giving him orders. And if he ignores what all the people under him are telling him, there's only one person responsible for the resulting trains-wreck. But his bosses won't hold him accountable for it, so it's no skin off his nose.

The blame game (3, Insightful)

Glendale2x (210533) | more than 2 years ago | (#38351520)

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:The blame game (1)

Tablizer (95088) | more than 2 years ago | (#38351750)

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.

Which they probably wrote or approved.
   

Compromise - A Kit (3, Insightful)

Tablizer (95088) | more than 2 years ago | (#38351628)

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.

Enterprise Software (2)

PPH (736903) | more than 2 years ago | (#38351650)

Its where your business processes are implemented these days. If your company has no competitive advantage over others based upon these processes, then by all means, buy the same s/w package that the guy down the street uses. Or hire the same consultants. More often than not, rather than customizing an application to suit your business, they whip out some boilerplate procedures manuals and get some of their inside people to slip them into your business plans. It makes their subsequent sales job much easier.

There are legitimate issues of core competence vs activities outside your companies value chain. Once you can identify what it is you do that gains you an advantage in your market and apply your IT (and other) resources to that, the rest can be bought off the shelf.

Okay, I call bullshit. (3, Insightful)

Chas (5144) | more than 2 years ago | (#38351754)

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.

driving while blind... (1)

Anonymous Coward | more than 2 years ago | (#38351868)

as long as in-house IT staff are considered mere overhead and not an area of strategic advantage, business will continue to outsource critical functions to the lowest bidder and wonder why they have to keep hiring expensive consultants every time a new project or requirement rears it's head. Then, as soon as the project is complete, they let go of all the expensive consultants only to hire a new batch (who of course need a project plan, specs, integration studies with the existing solutions etc) when the next wave of upgrades or projects starts. Tide come in, tide go out lol...

Load More Comments
Slashdot Account

Need an Account?

Forgot your password?

Don't worry, we never post anything without your permission.

Submission Text Formatting Tips

We support a small subset of HTML, namely these tags:

  • b
  • i
  • p
  • br
  • a
  • ol
  • ul
  • li
  • dl
  • dt
  • dd
  • em
  • strong
  • tt
  • blockquote
  • div
  • quote
  • ecode

"ecode" can be used for code snippets, for example:

<ecode>    while(1) { do_something(); } </ecode>
Sign up for Slashdot Newsletters
Create a Slashdot Account

Loading...