Why Do Enterprise Applications Suck?

From my personal experience:<p>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.<p>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.<p>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: <i>why can't it be done that way?</i><p>That's the heart of the problem: <i>why can't it be done that way?</i> Of course it <i>can</i> 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!<p>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.<p>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.<p>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.<p>And we're left with crap.

They suck because:<p>1. The people who build them are told it's fine that they suck. People who "own the process" (or whatever) don't know anything about software and discount programmer warnings -- "Don't worry, that's not a concern, we aren't here to worry about that." "It doesn't matter if the interface is confusing, because the users will be trained." "As long as there's a workaround, it doesn't matter." "If that button crashes the client, the users will figure out not to click that button."<p>Sometimes it's just basic stupidity. I know of one case where programmers on a data entry system accidentally implemented a use case that took ten minutes instead of twenty seconds. No problem; the fix was simple. However, they weren't allowed to fix it, because it wasn't "a primary use case." And it wasn't: the users were executing hundreds of use cases per day, and only about five would take ten minutes. So they deployed the software to dozens of hourly workers, who of course ended up spending almost an hour a day, on average, staring at their screen waiting for that use case to complete.<p>2. Regardless of policy, requirements are almost always gathered from users' managers instead of from the users themselves. Many managers of hourly workers think they know every detail of the jobs under them, but they often don't know the latest details and policy changes. And that's the best-case scenario. A more typical scenario is that a manager comes in with a vague "management overview" idea of what her workers do and a condescending attitude that anything more specific is inessential.<p>Couple this with the tendency to keep enterprise programmers on a short leash, implementing only the features that were specified in the design process, and you get a result so incomplete that sometimes the only way to avoid rolling back a software release is to remake business processes and policies to fit the software. On the bright side, this can result in simplification and streamlining. On the not-so-bright side, you alienate customers because you suddenly can't serve them the way they've come to expect.<p>3. The process is single-shot instead of iterative. There's no user testing, and not even any before-the-fact observation of users. Managers don't make any attempt to distinguish between legitimate user complaints and the normal, perennial "OMG something changed" office worker whining. This is especially true when the users are low-paid and not highly educated, which is a shame, because those are the ones who do simple mechanical jobs where their interaction with a software system can materially affect their productivity.<p>I know of one case where there was a "testing link" from one screen to another that had been accidentally left in the software by a programmer. It turned out to be crucial for workflow, and when it was removed in the second release of the software, productivity plummeted. The workers immediately alerted their manager, but they were ignored. Instead of asking for an immediate bugfix release, the manager waited until several months of metrics piled up demonstrating a massive uniform 20% productivity loss among her workers.<p>All these point to three problems:<p>1. The software development process is controlled by people who don't understand software or don't take it seriously.<p>2. Software developers have no credibility inside the corporation.<p>3. The corporation always respects the pretense that managers know more (and better) than workers, especially low-paid, uneducated workers, even when this pretense is obviously false.

Having spent the last 7 years working on enterprise systems for insurance companies (at a vendor, not internal IT), I can point out a few less sinister reasons. Sure, design by committee never helps anything, but there are just some fundamental difficulties around enterprise software.<p>* The developers don't understand the software they're using. Everyone uses e-mail, so it's pretty easy to know if you're making a crappy e-mail client. I'm not a claims adjuster, so it's much harder for me to understand if I'm building a claims system that makes the most common operations too difficult, or presents the data in a way that doesn't put the most useful information together. Sure, we've got product managers whose job is to figure that out, but they're not really users either, so there's always something lost in translation. Building software that performs a function you yourself perform is just way, way easier to "get right" than building software for a function you yourself don't understand.<p>* As is pointed out elsewhere, for internal development projects (which a lot of enterprise software is), the economies of scale work against you. It's difficult to build anything robust and functional for under a few million dollars, so most likely you'll end up with something not-so-robust and not-so-functional instead.<p>* On the flip side, companies make themselves very, very difficult to sell to, which provides a very high barrier to entry for vendors. Part of that is historical: they've been lied to so many times over the years that I can't really blame them. Most of them have a long history of failed implementations and IT projects, and they're naturally risk averse. On top of that, they have all the usual corporate red tape that commons with massive purchases, and since the market for most of that sort of software is often relatively small (compared to consumer markets, at least, or to more general-purpose tools), vendors have to charge a lot for their software if they want to stay in business. Unfortunately for their customers, that means that it's difficult to sell to them, which lowers the number of entrants in the market, which reduces competition on the vendor side, which leads to poorer quality software.<p>* Enterprise software is often boring to develop, you don't understand the use case, you can't show it to your friends or family or anyone else that will care, the deployment model often sucks, if you're a vendor you have to make things configurable (which makes it 10x as hard to develop, reason about test, etc.), and the companies you're selling to make the sales process incredibly difficult. And that's just working at a software company; obviously corporate IT in-house work is even less appealing. Understandably, the most talented developers often choose to work elsewhere. My impression these days is that the "you can't show it to anyone" bit is the most important for people; if you work for a company people have heard of or on a product people have heard of, you can take pride in showing that off, and not having that ability to show someone the cool stuff you're doing takes away a lot of the fun of software development.<p>* The small market and difficulty of deployment generally means that real user testing is difficult and costly, so people just don't do it. As a vendor, there's not much we can do (we can and do go watch people using the software, but there's not much we can do before we ship a version), and that's not a core area of expertise for the IT departments that are installing the system (or building one themselves). We can't just throw something out over the web and do A/B testing, or push a new version and roll it back if people report too many bugs.<p>* The market isn't yet there for hosted enterprise apps, so you're stuck with in-house deployments for now. I've commented on why that is earlier, but it comes down to both pricing, customization requirements on the customer side, integration requirements, and market valuations. It might work for certain types of enterprise applications that have large enough markets to make it scale, but for industry-specific systems where the target market is in the 1000's of companies, the math doesn't really add up.<p>There's definitely an opportunity there for a company of talented engineers to disrupt some portion of that market (which is what I like to think Guidewire, my employer, has done). But it's not as easy as just building a web app, attracting users, and slowly growing it: the domain-specific knowledge required is off the charts, and the barriers to entry are incredibly high.

Most of the last and current generation of tech university leavers appear to be trying to be the next Facebook - instead of trying to disrupt the enterprise software market.<p>It really bothers me that all these talented kids are outside of the companies that produce most of our economic activity - so big corps are still using the same crappy unproductive software they were a decade ago.<p>Not only is nobody inside these companies causing disruption - but I see few startups targetting core business functions like purchasing or logistics.<p>VCs could be driving this. Instead, like a herd, they are all trying to back the next greentech, cloudtech, socialtech etc.<p>The biggest opportunity to create cost savings for new businesses is in reinventing the way the enterprise apps work and communicate with other enterprises - for instance creating auction and bidding systems to improve procurement.<p>A startup has more chance of saving 1% of costs for a Top 500 company - than it has of being the next Facebook.

I'll add a couple more points:<p>- They lack the best people. People at the bleeding edge of software development and interface design tend to work for companies like Apple or Google, or to start their own thing, not go build a risk-reporting system for a bank.<p>- They go about development the wrong way round. They start with a huge list of features and then try to make it usable. Most start-ups do the reverse - they start with something usable and only then think about adding features. I'll be writing a blog post about that on <a href="http://www.woobius.com/scribbles" rel="nofollow">http://www.woobius.com/scribbles</a> sometime soon...

I'm surprised nobody has mentioned economies of scale so far.<p>Enterprise applications are highly customized systems with deployments of 1 in many cases. We talk about the outrageous cost, but consider an 500,000 dollar application. That's a lot for a company, but that's not a lot for an application budget.<p>With a 1.6 multiplier for expenses, that's enough for 2 fte senior engineers @ 90k or 3 young ones at 60k, .5 QA @ 70k, 1 manager @ 120k for 20%, a half a technical writer and a half a business analyst - let's call it one person @ 45k. That's 454,400 there. You haven't even accounted for travel yet, or a part time contractor for domain expertise or a graphical designer or someone to design an aesthetically competent interface.<p>Now, the cost of programmers might be high for senior outside major metros, but the numbers aren't far out of line for a project in less expensive markets.<p>How much are you going to expect two (or three) programmers to do for a full fledged product? Add to this the shifting requirements, client corporate bureaucracy, and associated complications that have been listed below, it's really no surprise that enterprise products have difficulty with quality.<p>I've given it a bit of thought on how to deliver better products in the sphere, but I start designing and realize that we've quickly found our way into architecture astronomy quickly. I'm starting to think the best route is actually something akin to <a href="http://baseportal.com/" rel="nofollow">http://baseportal.com/</a> with a rules workflow system and a little more front end polish.<p>The problem, again, runs into the customization problems. The more customization that is allowed (and that is a requirement in enterprise), the more complex the system becomes and the advantages of quicker development dissolve.

Enterprise apps suck for a number of reasons. And yes, of course you can build a better UI for most of them, but that isn't really the problem in this space.<p>As a startup you face several problems if you want to get in on the enterprise market space. First of all, you're a start-up. You might go bankrupt tomorrow. Secondly, no-one else in the sector you're targeting is using you. Well, that's a no-go right there. This is a chicken-and-egg problem. Thirdly, you probably lack vendor support or recognition from analysts. Oops, you just failed the skimming test (as in 'skimming over basic requirements'). Can your product even execute in the major J2EE stacks? (Probably not).<p>If you're not 'proven' technology, then you have a hard time moving into this space.<p>And this space is not driven by user satisfaction or programmer happiness.<p>Look at how far Google has managed to move into the 'enterprise space'. Not very far.<p>In the Enterprise, the UI is usually just thrown on as an after-thought. Of course it's going to suck.

While I breathe, I cherish the hope that enterprise development will eventually be forced to change.<p><a href="http://weblog.raganwald.com/2007/09/we-have-lost-control-of-apparatus.html" rel="nofollow">http://weblog.raganwald.com/2007/09/we-have-lost-control-of-...</a>

I have some experience building enterprise software and I'd have to say the problem was that it is mind numbingly boring to do. A lot of it sucks, so to speak, because people can't stay motivated to give a damn.<p>It's pretty soul crushing to spend all of your working time building systems for inventory management, or AP/AR, or whatever mundane (but incredibly important) business function you're working on. This is why people make startups I suppose.<p>I agree that, if you have the mental toughness for it, enterprise software is a GREAT way to make money. During my days of having a real job, we were selling our software for $250,000 an install.

It's the difference between top-down and bottom up. Entreprise software is designed at the top, and we all know it half of it won't be used, and the half that will won't solve the biggest problems.<p>The way I write (very small) biz software is get a contract from the top, along with the specs for the first version, and over the next years (pretty much forever) get specific requests almost exclusively from middle management.<p>It's hard to scale though. I do what they ask because I care about my work, but on a strictly contractual basis I could reject or indefinitely postpone 90% of it.

Another reason they suck, is that many corporate CTOs fear open source. I contracted for an enterprise software dev company, conceptualizing product and producing prototypes.<p>Our protos were quick and simple affairs using jquery. The CTO refused to integrate jquery into the application itself, and rewrote everything custom, which worked half as well as our simple protos and took months longer to develop, had they built the front end with jquery.<p>The CTO lost his job recently due to cost overruns.

For the most part enterprise apps do suck. But I imagine there are enterprise apps that are just amazing. The software that allows UPS/Fedex to deliver packages so efficiently must be fantastic. Or the stuff that powers the supply chain of Walmart, or the stuff that powers Amazon.com's ecommerce. It'd be great if someone could share insights from real world examples of enterprise software that works amazingly well.

Some posters touched on this but I don't think anybody made a strong enough point.<p>Size. Too damn many people involved. Startups and small companies innovate/code circles around Enterprises cause they are small 2-5 maybe 10 people per project. They all know each other, they're all responsible, they're all committed to success and there's no one in their way.<p>The more people involved the closer to (their)average you get. It's possible to have small number of awesome, above avg people, but not the 50-100+ involved in enterprise app, not consistently.<p>If enterprise's gave cross-functional teams of 5-10, 20 people autonomy and a general goal they would rock out.

The people who buy it don't have to use it; that has got to be a factor.<p>I remember one company, the CEO was trying to prepare it to be bought by a large company - one bullet item - "enterprise contact management and sales tracking software needs to be in place" . So SalesLogix was bought, 15 people were trained on it - one week later no one was using it.<p>The top salesman was using his (original version, this was late 90s) PalmPilot and his Windows laptop instead.<p>The sales engineer that had been with the company the longest and was employee #5, had 3 big accounts to keep happy and maybe 2 people to talk to at each account, for a total of 6.

A (possibly) related blog post "Enterprise Software is boring" (<a href="http://ravimohan.blogspot.com/2006/07/but-martin-enterprise-software-is.html" rel="nofollow">http://ravimohan.blogspot.com/2006/07/but-martin-enterprise-...</a>)

I convinced the company I work for to switch their applicant-tracking system from CBIZ to CATS (catsone.com). Using something that was built by people who care has made a huge difference -- now it's a tool instead of a chore.

For some reason this site is very slow to render and a horizontal scroller pops up intermittently here on Opera 9.60 (it's maddening!). I think one of the ads is the problem, I see a never-ending 'loading' spinner floating above the Amazon ad.

High switching cost / no competition. Yup, classic.

Anything built by externally-motivated people will suck exactly as much as it is permitted to.

too many cooks spoil the dish.

A lot of EA apps suck, and a lot of them don't.<p>Conversely, a lot of open source apps suck too. A lot of them also don't.<p>Why are we stereotyping again?