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.
Another thing you see with software developed by large teams: No one takes ownership. Think about it-- How many people who worked on Vista say, "Wow-- Vista SUCKS. And I feel responsible." My guess is NONE. Instead, they all say, "Vista sucks. I did the best I could to make it NOT suck, but I just couldn't make a big enough difference."
The rare examples of big-team success that you say invariably have a big ego (benevolent or not) at the top who has a sense of ownership (Steve Jobs? Linus?).
If everyone on the project has the attitude of "This is MY baby and you will NOT fuck it up," you can build great things. If no one does (the most common state on software teams), you almost certainly cannot.
Enterprise applications are a cost to the company, whereas commercial software applications are the product. All enterprise app development must be a give and take between functionality and cost. Businesses will differ in where they fall in that balance, but ultimately companies must reduce the cost as much as possible while maintaining required functionality.
Perfect enterprise applications are therefore by definition the fastest, cheapest software to get the job done. Anything else and the company is wasting money.
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.
Because vendor-made enterprise software is a culmination of that vendor trying to say "yes" to the questions of almost every company who expressed interest in their software.
Could a portion of this issue stem from "the market" being left out of the equation? I guess this would only apply to in-house apps.
That said, EA companies seem to do quite well in the market. I guess any committee can pat themselves on the back for finding an "already built" solution that meets (or can be customized to meet) all of their needs. Of course, internal talent must then configure this software monster and build all of those pesky integration pieces to make all of it work.
Well after the purchase, you might hear something along these lines: "Why does it take so long to simply configure something that should work 'out of the box'?"
This is where marketing meets truth (and runs screaming) and bubbles get busted. :)
EA companies do well in the market, but markets are far from efficient. Some points:
* No one likes responsibility. When an EA company says, "don't worry, we'll take responsibility," managers like that. For some reason, there is no blame assigned to people who choose bad vendors as long as the vendor made good promises. This is one reason I think open-source adoption is slow. Open-source doesn't promise to work. If an open-source solution fails, it's your fault. If a vendor lied to you, the solution seems to be throwing more money at the vendor. But no matter what, you aren't to blame: the vendor is.
* Most EA software can't be tested nicely before purchase. You get beautiful controlled demos with sales people who can mold the situation. Excuses for why something can't be done in the demo, but work perfectly in real-life or will be coming in a month are common and accepted. Again, they're promising that you don't have to deal with it.
* EA software is expensive. Ridiculously so. Most EA software that we use has annual maintenance fees that rival a salary and still require someone in-house to configure and deal with it. Once you've spent that much money, there is a real drive to build things into it that lock you into it - you want to get your money's worth, don't you? More, there's a huge social-psychological barrier to someone saying, "I'm an idiot that wasted 50 grand and we should really dump what I was paid to choose for something else." Even beyond not wanting to admit you're dumb, you don't want others to know that because if you're not good at choosing platforms, what on earth are you getting paid for? So, the only way to actually switch away from it is to find some excuse about how times have changed and it was good at the time, but not now. Even then, why couldn't you have foreseen that this company wouldn't suffice long-term?
* And finally, by the time enough time has passed to make one of those excuses, you have too much investment in the old system - whether that be training, data, lock-in, etc.
Think of it this way, you shell out $100,000 for a system with $75,000 in annual maintenance/support and sign a two-year contract. You get the system and it's quirky, but you've paid so much for it and are determined to use it. You find out over the next 3-4 months that it's just terrible: the sales people outright lied, you didn't investigate what really needed to be looked at, and it's just terrible for what you need. But you need something now so you pay the company $20,000 (in addition) to build a bit of custom thing. At this point, you definitely can't switch before the 2 years are up (or you've just wasted $270,000 which you will have to explain). Plus, by the 6 month period someone in your company will have found one random thing that they will never let you hear the end of if it ever works slightly differently. It's a terrible "feature" that no logical person would want and would be incredibly difficult to duplicate and so you now have even more resistance from outside IT.
And you can always defend the system as "the cost of doing business" and any shortcomings are the vendor's fault, not your shortcomings (whether or not you should have been better at choosing a system). Markets are powerful, psychology and ego can be more powerful ;-).
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.