My (admittedly anecdotal) evidence is to the contrary. Enterprise applications are neither the fastest nor the cheapest solution (at least not as implemented in any of the "Enterprise" places I have worked).
I think generally the problem is twofold. First, as the GP pointed out, design decisions (both technical and aesthetic) are made by people who aren't programmers or end users. These people care more about documentation and 'The Plan' than solving the problem elegantly.
The second problem is that most 'technical' people doing in-house enterprise apps aren't that great. I know this sounds callous of me, and there are definitely still great people here and there, but the average ability level is pretty low. My 'enterprise architect' has never even used Java 5 (her excuse: she hasn't had any training for it yet). People like this aren't going to be confident enough to suggest (or even aware of) alternative implementations to those given them by the 'design committee'.
I just started a job doing 'Enterprise Java' (gotta pay the bills until grad school this fall) and they have me working on this project for the next 6-7 months. Once I finally parsed all the buzzword bingo documentation, I realized that what I'm implementing is basically a read-only ORM.
The design as I'm given requires 15+ lines of Java to get a single object back (you know, Post.find(:title => 'foo')) and requires the end user to know which table goes with which DAO goes with which business object, among other things. I'm slowly but surely getting changes approved by my 'architect', and hopefully will, in the end, have something a little more sane.
The fact that they are paying both me and her for six months worth of work to do something that really could be handled by an existing ORM definitely doesn't point to in-house 'Enterprise software' being the cheapest solution. Throw in some of the ridiculous design decisions and 'requirements of our company's standard architecture', and it's not really the fastest either.
As for the Enterprise software from vendors, I'd argue that the problem is that it's solving the problems of these in-house developers and managers, who only have the problems due to over-complexifying (not a word I know) what they do.
> My 'enterprise architect' has never even used Java 5 (her excuse: she hasn't had any training for it yet).
Training! Twenty-five years ago, the vice president of the engineering consulting firm where I worked got some bee in her bonnet and announced that the "staff" needed some sort of "training." Being young and politically foolish, I glared at her and said, "Training is for chimps. And don't call a room full of people with engineering degrees staff."
I have no idea what your 'enterprise architect's actual abilities are, but the poor gal talks like a chimp.
You're absolutely right about the quality of internal development. Corporations should take advantage of hard economic times like these to recruit good developers (for more than corporations are accustomed to paying, but less than good developers are accustomed to making) and assimilate them into the corporate culture. After a few years, many of those developers will be comfortable and will be more interested in their wives and children than in their careers. It's natural that some of the talent that goes to startups in boom times should shift to corporations in bad times.
Won't work. Companies like that don't tolerate competence and creativity. Good developers will be beaten down by insecure and technically incompetent managers, even worse when you involve same from other departments. Requirements documents, high level design, low level design, review by the barely computer literate, turf wars, budgets that dont include your tools, internal standards, methodologies, and consultants. Sometimes even food on the table isnt worth it. Moreover the recruiters will recognize that the good programmer will be gone in 6 months and that will be another recruiting fee down the toilet.
I think generally the problem is twofold. First, as the GP pointed out, design decisions (both technical and aesthetic) are made by people who aren't programmers or end users. These people care more about documentation and 'The Plan' than solving the problem elegantly.
The second problem is that most 'technical' people doing in-house enterprise apps aren't that great. I know this sounds callous of me, and there are definitely still great people here and there, but the average ability level is pretty low. My 'enterprise architect' has never even used Java 5 (her excuse: she hasn't had any training for it yet). People like this aren't going to be confident enough to suggest (or even aware of) alternative implementations to those given them by the 'design committee'.
I just started a job doing 'Enterprise Java' (gotta pay the bills until grad school this fall) and they have me working on this project for the next 6-7 months. Once I finally parsed all the buzzword bingo documentation, I realized that what I'm implementing is basically a read-only ORM.
The design as I'm given requires 15+ lines of Java to get a single object back (you know, Post.find(:title => 'foo')) and requires the end user to know which table goes with which DAO goes with which business object, among other things. I'm slowly but surely getting changes approved by my 'architect', and hopefully will, in the end, have something a little more sane.
The fact that they are paying both me and her for six months worth of work to do something that really could be handled by an existing ORM definitely doesn't point to in-house 'Enterprise software' being the cheapest solution. Throw in some of the ridiculous design decisions and 'requirements of our company's standard architecture', and it's not really the fastest either.
As for the Enterprise software from vendors, I'd argue that the problem is that it's solving the problems of these in-house developers and managers, who only have the problems due to over-complexifying (not a word I know) what they do.