Develop in house or configure off the shelf?

[Pondlife]

I don't know why I'm posting this in the bearpit but here we go...

A (purely hypothetical) client has a locally developed app that sits between its ERP system and its process control systems. It's a manufacturing site that produces different varieties of similar products, although the manufacturing process can be quite complex.

The application was developed approx 20 years ago and was at the time ideal for their requirements but as the business has developed over the last two decades and the systems the app interfaces to have changed, it's now no longer as flexible as it once was.

So today's discussion is - What are the pros and cons of developing a replacement in house vs buying an off the shelf vendor solution and configuring to meet requirements.

[cojak]

What are your business requirements?

You'll need to review the software specs with your requirements.

[Scoobos]

It depends on -

1. If you are just talking about modernising the existing code to say .NET, with access to the source code. This will usually expose it to new APIs / connectivity methods, that should be the only parts requiring a brand new write.

2. If you want a whole we-write with no access to source code

3. How close the off the shelf is to the required solution, and if they have any existing customers who you can contact; who use the features you want. (If the vendor promises but no-ones done it, you will eat time ).

My 2 cents, from a little experience, is that you're always better off picking 1 , then 3, then 2 in that order.

[original PM]

A good question.

the full answer would depend on your exact situation but my experience is that

1) develop in house can give better results however it will always be developed to do what the last system did also you can normally get a really good UI which pleases the users

2) Off the shelf often means you have to review all processes and potentially change them which can be a good thing but you are stuck with that packages UI which can cause problems for the users...

[cojak]

Cost/speed/quality/ the usual pros and cons.

Bespoke may get you (almost) exactly what you want but can be very expensive and will take more time.

COTs may give 80% percent of what you want (but probably >80% of what you need) at less cost for less time.

[oracleslave]

Should have gone wall to wall oracle instead of that poorly architected cobbled together .net solution eh? Will you and Milan ever see the light?

[cojak]

Cost/speed/quality/ the usual pros and cons.

Bespoke may get you (almost) exactly what you want but can be very expensive and will take more time.

COTs may give 80% percent of what you want (but probably >80% of what you need) at less cost for less time.

Oh and in my experience Bespoke often gets canned for being hugely expensive, way over-time and giving almost nothing to the users that they wanted in the 1st place.

[original PM]

Should have gone wall to wall oracle instead of that poorly architected cobbled together .net solution eh? Will you and Milan ever see the light?

[Pondlife]

Apologies for being so generic but it's more of a things to consider type question. Assume that the existing source code has been modified so many times that it is of little value and it would be a start from scratch, define new requirements type project. Assume the vendor based solution will give +90% as vanilla but would need to be enhanced for the additional 10%. Hardware reqmt's would be equivalents.

I'm interested in peoples experiences of support costs of in house vs store bought, flexibility to business change. etc.

[cojak]

Oh and in my experience Bespoke often gets canned for being hugely expensive, way over-time and giving almost nothing to the users that they wanted in the 1st place.

And the problems start right at the beginning with no (or very poor) Benefits Management.