“Buy, don’t build” generally makes good sense. The software company that sells the “canned” solution can spread the development cost between all its customers, whereas the costs of an application built in-house will be borne by one company.
I worked IT for an open source software company for a while. Many of the programmers were pretty upset when we’d choose a closed-source software package to do the things we needed done. They argued that they could write it themselves. But that completely ignored the fact that they already had things they were supposed to be working on. The dev group managers (who were also incensed about the closed-source solutions) stopped griping pretty damn fast once they were asked flat out: Which of your engineers will you be devoting, full time, to developing and supporting this app?
Aside from manpower issues, time is a factor. Purchased solutions work now (or at least, soonish) as opposed to having to go through a whole development cycle, testing, etc. Even if buying it is more expensive, getting things done faster is often more cost effective in the long run.
Purchased products also tend to have employable experts floating around in the work force that you can hire. Need someone versed in Oracle or Remedy? The headhunter can find someone. Need someone who knows your homegrown app after your current employee walks off the job? You’re hosed.
Also, if ready-made solutions reduce the IT force to glorified Radio Shack clerks (they don’t, of course; Oracle guru’s hourly rates reflect this fact) that’s good for the business. Any time you can get by with less skilled and, more importantly, lower paid employees, you have the opportunity to cut costs. Since I’m an IT guy, I can’t say I like that a lot, but it makes good sense from a business standpoint.
There’s also the issue of capital assets vs. ongoing salaries. Having your regular IT guy (who’s going to be a fairly well paid guy if he’s also qualified to develop apps) building something shows up on the books as a recurring salary. Buying some expensive software (and even hiring contractors to make it run properly) can be jotted down as a one-time expense, which generally looks better on the annual budget report. (I can’t say I fully understand this, but that’s what the bean counters have told me)
So, yeah, I’d say “buy, don’t build” is the standard in IT shops.