Enterprise Applications are built by committee. The committee's job is to put as many bullet points on paper as possible. The more bullet points they've put on paper, the more successful the committee was. The more complicated and long the documentation is, the more work the committee had to do and the more its people should be paid for being able to envision and document a system that is so complicated - without regard for whether that system had to be complicated or not.
Requirements get created for cases that no one knows exist or not. Partly this is because enterprise systems are sometimes thought to be write-once, run for a decade or so rather than systems that will see agile revisions. But partly it's also because, again, it's easier to talk about out of left field problems that will never occur than to actually tackle real problems.
Decisions are made random and arbitrary - but because those decisions are documented, they're fine. So, you want a way of storing that a bank account is closed? Well, we could just have a closed flag on the account when the customer closed it -OR- we could make the account no longer have a relationship to a person, have a zero balance in it and have it be more than 3 months since any activity happened in the account. Yep, that works. Then when a programmer says, but that's not a good way to do that, the question gets asked: why can't it be done that way?
That's the heart of the problem: why can't it be done that way? Of course it can be done that way. It just shouldn't. It's a terrible idea that only an idiotic committee would come up with because the more complicated the solution, clearly the harder the problem (and therefore the more money and adulation they should be paid). If it's simple, they're just doing their work, but if it's hard and requires an overly complicated solution, they deserve praise!
The worst part is that in all of those meetings, you constantly hear "we're building a 90% system" referring, of course, to not tackling outlying cases that may not come up. The problem is that, in the case of enterprise systems, it means tackling every outlying case imaginable while leaving the most common use cases with a terrible interface and sub-par reliability. And the worst part is that most of the outlying cases aren't imaginable so you haven't even solved that.
The problem is what gets rewarded in an enterprise environment and how non-techies see software. Something that is simple, reliable and gets the job done must be solving a really simple problem and took little work, right? In fact, I'm sure many of us have been approached and offered a few hundred dollars to create something just like (MySpace|eBay|Amazon|etc.) because they make the solution seem easy. So, the incentive is not to make something elegant, but to make something that shows exactly how difficult the problem really is - in fact, more difficult than the problem really is.
Likewise, the more features you can write down on a piece of paper, the more impressed your boss' boss will be with what you've been able to accomplish. "Elegant user-interface and code" doesn't take up enough space.
And we're left with crap.