3 ms·
This reminds me of situations where people “buy then customize”. Such as buying a payments gateway, then using its internal RDBMS tables directly for reports a
by Scubabear68 4y ago
This reminds me of situations where people “buy then customize”. Such as buying a payments gateway, then using its internal RDBMS tables directly for reports and integrations. Or buying Great Plains and then massively building on it.
Then one day these products eventually go EOL and the company is often stuck maintaining a zombie product. Or the products undergo a major refactor that breaks their customizations and integrations, and they end up stranded forever on version X.
I hear ERP systems often go like this too.
The only thing worse to me is entire huge products built in stored procedures. I know one product that was written in about 2 million lines of PL/SQL. It did some amazing things, but we were locked into PL/SQL for all time, and the Oracle scaling bills and HW were astronomical…
- SoftTalker 4y ago> Then one day these products eventually go EOL This happens with any product you buy. Dealing with it has to be included in the value proposition. > we were locked into PL/SQL for all time, and the Oracle scaling bills and HW were astronomical Yeah Oracle is expensive. Scaling costs should have been part of the calculation to commit to it. For most orgs that use Oracle, the cost is not really an issue in the grand scheme of what they spend on IT and servivces.
- Scubabear68 4y agoI agree, all products die, but how you integrate is all the difference. When you start reaching into the private guts of the system (in this case, the database), you are hopelessly intertwined with them. There are much cleaner ways to do this that makes a migration to something new a lot less painful.
- bluedino 4y agoYup, they are better off making small changes to their processes to fit the ERP system, instead of the other way around.