Well ... that I think depends on the task to be accomplished. But in
general, if at all possible you should buy (or acquire open source)
infrastructure rather than build it. Here's what I recommend:
I tend to agree that it's better to reuse than to recreate. Beyond that,
however, I start running into some disagreements with you.
1. Collect your requirements.
2. See what you can buy (or acquire) that best meets them.
3. If there are fewer than three viable sources, go back to your
stakeholders and start axing requirements. Remember, you're trying to
minimize costs and free up programmers to produce software you can sell.
Axing requirements should happen earlier than that -- not because you
should be trying to maximize the field of existing software that fills
your needs, but because too many requirements are a sign of poor focus.
Whether or not you can find more than three off-the-shelf software
packages that suit your requirements list has basically nothing to do
with that. You can have very specific, well-defined requirements and not
find a single off-the-shelf solution that'll work, and you can similarly
have scattered, unfocused, poorly considered requirements for which there
are thousands of options. Most often, however, what you end up with in
cases of scattered, unfocused, poorly considered requirements is a VP who
insists that something like MS Exchange is the *only* solution that can
possibly work for your "needs".
OK ... now assume you've got the requirements negotiated down to the
point where there are three or more viable sources. If there are more
than three, throw out all but the three most expensive. Why? Because
they are either incompetent or competent and attempting to buy the
business. In either case, you don't want to deal with them.
You've just thrown out open source software again -- and you've limited
the choices to the industry dominating options, which may or may not be
worth a damn. This sounds surprisingly like an "enterprise resource
management software acquisition" process, which tends to end up with a
company investing $120,000 in a piece of software that's going to cost
another $40,000 to get installed and configured, and still may not work
properly. Maybe I'm exaggerating a little, for the average case, but I
think that's only because the average case gets a little more lucky than
that.
. . and that's the problem: the success of this scheme seems to be
significantly predicated upon an assumption of luck.
Now you're ready to go out for bids. Make *damn* sure all three can meet
your requirements, and that they aren't written to favor one of the
sources. If your requirements don't pass this test, again, go back to
your stakeholders and negotiate until you get what you need -- a set of
requirements that three competent sources can meet.
At this point, it's starting to sound more like "Plan your acquisition
based on what looks good to middle-management, then play damage control
to try to limit the amount of obscene costs such a middle-management
conceived plan of acquisition tends to engender." I think there are
better ways -- and they start with bringing more focus to your
requirements in the first place, nailing it down to what you absolutely
cannot give up with a short list of wanna-haves, then just checking to
see what fits that (regardless of how many of them there are in the
market or how much they cost).
All I'm saying, when you really think about it, is that you need to
apply the YAGNI principle to infrastructure ruthlessly. You Ain't Gonna
Need It, and putting a real price tag on it by forcing yourself to buy
it and justify buying it forces you to think about it, rather than just
saying, "hey, for only ten lines of Ruby code I can ..."
I agree somewhat, in that you should write the software yourself only if
something premade either:
1. doesn't exist to suit your needs, or
2. costs far, far more than the resources involved in writing it
yourself.
Of course, that also assumes you have the discipline in your organization
to avoid going nuts on feature-adding while writing it yourself. Then
again, we're assuming your organization has the discipline to cut down
requirements rather than going with the mediocre "feature rich" "industry
standard solution" just because it "does everything" -- failing to think
about whether or not it'll do it well or consistently (or for a
reasonable price).
If you did your procurement right, *you* shouldn't have to do a lot of
configuration or customization or any other kind of programming
disguised as system administration. You bought infrastructure -- the
vendor should teach you how to use it and fix it when it's broken. You
shouldn't have to do things with it that it wasn't meant to do, write
scripts or edit XML files to work around defects, interface it to
someone else's pet database, etc.
You've pretty much limited your field of vendors to IBM, at this point.
Hopefully they have something that suits your needs.
Yes, I'm overstating the case a bit -- but it's to make a point.
Editing XML files in ERP and similar software markets isn't about working
around defects, unless you consider that entire software market to be
defective (which is certainly a valid viewpoint in many cases); it's just
how the software is configured for your needs. If you consider the
entire market to be defective, however, you've just come back to the
"roll your own solution" answer to the problem.
It's probably worth keeping in mind that in certain niches of
off-the-shelf software markets, *nothing* that you can find to buy is
likely to be worth the time spent evaluating it, let alone the incredible
price tag it carries.
If you *have* to build infrastructure, by all means, do it in a
pragmatic, agile manner with Ruby or similar tools. But don't do it just
because it's *fun* or because you think you're saving money, because you
aren't saving money -- you're spending it.
With that statement, it seems like we're in agreement again. Funny how
that happens.
I think a big part of the problem in our points of disagreement here is
that you seem to view software as a product, and I see it as process.
Software is basically just a process specification, and the computer is
the part of the organization that executes that process. The point is to
streamline operations and make certain tasks more efficient so that they
consume fewer resources -- perhaps making completion of those tasks
affordable at all, thus providing your organization with the ability to
accomplish more. That's what all process is: a means of making
operations "better".
A product is something you slot into process because your process demands
it, like providing chairs for your employees to use when they're working
in their cubicles.
Confusing products with process is, I think, one of the biggest problems
the software industry has right now.
