Re: in-house development versus packaged solutions

In article <4817d577@xxxxxxxxxxxxxxxxxxxxxx>, ray_porter@xxxxxxx says...
I know we can develop the system in-house and do a darned good job and for
far less than any of the major packaged solutions. We can also tune it to
the internal business practices in use at this university while also
improving the system. Just 18 months ago a campus-wide taskforce agreed
with that judgment. Now we've got to justify our decision and plan all over
again with all the resulting delays. A non-technical colleague in the
alumni association has asked me to come up with something discussing the
pros and cons of in-house vs. packaged solutions he can present to the
president of the association (who was one of our strongest supporters
originally). I think that office mostly supports doing it in-house but
would like some outside thoughts on the advantages and disadvantages each
way.


Ray,
I've been there and worked in situations where in-house development
has been considered next to packaged solutions.

But in each case, the bespoke development has come from third parties
rather than truly having been in house.

And my company has been one of those third parties.

Every time a new contract has been offerred to the marketplace, the
Delphi solution has won the job.

We've teamed with other solution providers where there is some heavy
lifting needed that our small team could not provide, and I believe the
team approach is what won us the contract.

The other providers (in the cases where I have worked they were IBM,
HP and Unisys) could provide the iron, but not the apps nor the app
development skills.

Our little Delphi team had intimate knowledge of the way the business
worked, so could provide apps with a UI tailored to the real-life
processes.

We left it up to the heavy lifters to do stuff that you really don't
want to do on a PC.

Break your requirement down a bit and pros and cons might start to
show themselves.

A decent Delphi app can interface to any accounting package, but you
don't need to have the accounting package be part of a Delphi solution.
Just leverage what can be supplied.

Identify the generic parts of the system, then find the parts that
need to be customized. I think you might find that a Delphi system can
do those custom bits, and can also wrap generic services provided by
another party in such a way that the end user would never know that they
were using more than one system.

If you can do this, and draw a diagram showing how you can distribute
the code, you can probably get anyone to buy into your idea if that is
what you want to do.

Just an opinion.

Scout
.