On 1/21/07, Brian Keefer <[EMAIL PROTECTED]> wrote:
> Little off topic, but I need some help. For a week I'm working in a > small company. (~250 workstations). Till 2008 there will be 400-600 > workstations. So, they are planning to buy something for spam/mail > filtering (http://www.barracudanetworks.com/ns/products/ > spam_overview.php). > I think the best would be to use openbsd+pf+spamd (with carp if > necessary). But - I have quite stupid CEO and I need many arguments, > why blackbox for many $$$ is bad (from corporate view). > Please, help me with these arguments.
If someone very clever builds something from scratch, but then leaves, who is going to keep it running? How much do they need to pay to retain someone who understands the home-grown solution, vs. how much would they need to pay someone to just click buttons? How many hours will it take to maintain a home-grown solution vs. just clicking buttons? When there's a problem, how long will it take the staff to fix it vs. just calling tech support for the company you bought software from off-the-shelf? There's a lot more to cost than just the initial price tag, and the value in terms of cost-savings in other areas is something else to consider--would a commercial product block more malware, have less false-positives, be able to comply with government regulations, etc?
Note that you can do some things to mitigate the risk of some of these cost areas up front, if you just devote the time to it initially. If that clever someone that crafted your solution can follow it up with thorough documentation about the solution, its components, application care and feeding, update procedures and so on, you may find it easier to justify the in-house developed solution. In my experience these kinds of things make it easier for future (and sometimes less knowledgeable) personnel to own and maintain the solution in the future. My experience doesn't justify putting too much stock in vendor technical support; I'm let down more often by the low level of knowledge most first (sometimes second) level technicians have about their own products. For some reason most organizations don't follow these kinds of things through this far though; they stop right after implementation and trudge along on it until it breaks and then they lament the situation they're put in. Don't underestimate the value a little supporting documentation can provide (and contrary to popular belief, it's not costly or time consuming to do it, especially once you complete a couple.) DS
