I tend to think that splitting development into API and front end solves some of this.
The main problem with "enterprise" software is that it's done cheaply, and violates levels of abstraction. Thus why it frequently requires specific versions of antiquated technology ("Our CRM requires IE6", "We can't upgrade past Windows 2000").
If it was designed properly, you could easily rip out both parts and iteratively redesign them to meet business and technical goals.
Seconded. The university I'm attending uses PeopleSoft (acquired by Oracle) as their ERP system, and it's horrendous. Not a week goes by where I don't hear students and faculty members openly complain about it.
I've got a live PeopleSoft installation running on a server in my apartment that I'm outfitting with code to do exactly what you mentioned - split out the back-end from the front-end. So far it's going brilliantly - for some sadistic reason, I enjoy trying to reduce the complexities of these applications.
You know, I wanted to do something very similar with my university's installation of PeopleSoft - but my intent was more focus on improving the UI and frontend than backend. But I have to ask: how did you get a copy of PeopleSoft?
Actually, what I'm working on involves both front-end and back-end. I've got a UI that trades data back and forth with a web service endpoint called Integration Broker within PeopleSoft. I'm focused on enrollment right now, and currently I've got a system that allows me to enroll in classes using the new UI on a live PeopleSoft install - all without touching/modifying the business logic in the delivered vanilla PeopleSoft implementation.
Re. the PeopleSoft copy - Oracle provides all of their software (and master license codes) for download for evaluation purposes through a portal called eDelivery. I had to read a few hundred pages of documentation, but after a month I was able to get all the components to talk together. I'm trying to convince Oracle to give me a non-support license so I can cover myself legally, but I'm getting the silent treatment since it's just me and I don't have the budget of a CTO lol.
The main problem with "enterprise" software is that it's done cheaply, and violates levels of abstraction. Thus why it frequently requires specific versions of antiquated technology ("Our CRM requires IE6", "We can't upgrade past Windows 2000").
If it was designed properly, you could easily rip out both parts and iteratively redesign them to meet business and technical goals.