Wide Awake Developers

Why Do Enterprise Applications Suck?

February 20, 2009

What is it about enterprise applications that makes them suck?

I mean, have you ever seen someone write 1,500 words about how much they love their corporate expense reporting system? Or spend their free time mashing up the job posting system together with Google maps? Of course not. But why not?

There's a quality about some software that inspires love in their users, and it's totally devoid in enterprise software. The best you can ever say about enterprise software is when it doesn't get in the way of the business. At it's worst, enterprise software creates more work than it automates.

For example, in my company, we've got a personnel management tool that's so unpredictable that every admin in the company keeps his or her own spreadsheet of requests that have been entered. They have to do that because the system itself randomly eats input, drops requests, or silently trashes forms. It's not a training problem, it's just lousy software.

We've got a time-tracking system that has a feature where an employee can enter in a vacation request. There's a little workflow triggered to have the supervisor approve the vacation request. I've seen it used inside two groups. In both cases, the employee negotiates the leave request via email then enters it into the time tracking system. I know several people who use Travelocity to find their flights before they log in to our corporate travel system. And you wouldn't even believe how hard our sales force automation system it compared to Salesforce.com.

Way back in 1937, Ronald Coase elaborated his theory about why corporations exist. He said that a firm's boundaries should be drawn so as to minimize transaction costs... search and information costs, bargaining costs, and cost of policing behavior. By almost every measure, then, external systems offer lower transaction costs than internal ones. No wonder some people think IT doesn't matter.

If the best you can do is not mess up a nondifferentiating function like personnel management, it's tough to claim that IT can be a competitive advantage. So, again I'll ask, why?

I think there are exactly four reasons that internal corporate systems are so unloved and unlovable.

1. The serve their corporate overlords, not their users.

This is simple. Corporate systems are built according to what analysts believe will make the company more efficient. Unfortunately, this too often falls prey to penny-wise-pound-foolish decisions that micro-optimize costs while suboptimizing the overall value stream. Optimizing one person's job with a system that creates more work for a number of other people doesn't do any good for the company as a whole.

2. They only do gray-suited, stolidly conservative things.

Corporate IM now looks like an obvious idea, but messaging started frivolously. It was blocked, prohibited, and firewalled. In 1990, who would have spent precious capital on something to let cubicle-dwellers ask each other what they were doing for lunch? As it turns out, a few companies were on the leading edge of that wave, but their illicit communications were done in spite of IT. How many companies would build something to "Create Breakthrough Products Through Collaborative Play?"

3. They have captive audiences.

If your company has six purchasing systems, that's a problem. If you have a choice of six online stores, that's competition.

4. They lack "give-a-shitness".

I think this one matters most of all. Commerce sites, Web 2.0 startups, IM networks... the software that people love was created by people who love it, too. It's either their ticket to F-U money, it's their brainchild, or it's their livelihood. The people who build those systems live with them for a long time, often years. They have reason to care about the design and about keeping the thing alive.

This is also why, once acquired, startups often lose their luster. The founders get their big check and cash out. The barnstormers that poured their passion into it discover they don't like being assimilated and drift away.

Architects, designers, and developers of corporate systems usually have little or no voice in what gets built, or how, or why. (Imagine the average IT department meeting where one developer says this system really ought to be built using Scala and Lift.) The don't sign on, they get assigned. I know that individual developers do care passionately about their work, but usually have no way to really make a difference.

The net result is that corporate software is software that nobody gives a shit about: not it's creators, not it's investors, and not it's users.

Comments

I think I would put this a bit differently, but I'm in agreement with you. I think the core problem is that enterprise applications lack a meaningful feedback loop. The decisions about what gets implemented or fixed are made by people who don't use the system.

Certainly it matters if the people working on the system care about it, but I think we'd be remiss to overlook the value of user and customer feedback. And we do overlook that with frightening regularity in corporate settings - we spent years arguing for simple improvements to our custom internal tools for BestBuy.com, despite the fact that every person who actually used the tools on a daily basis knew they were desperately needed.

Half the time I can't even figure out how to use the crap. Things like "features" need to step aside until I can figure out how to log on to SAP and approve a purchase order or god forbid... open a req!

I agree with you. I am a software developer also and my fiance is a social worker. Last year, the NGO she works for deployed a new "corporate" system in order to "control" what they were doing. Well, I've had a first hand experience on how frustrated she was with the software, its interface but most of all, its focus. It was not about making their work easier but for giving management enough numbers so they could be "sure" about the decisions they had to make.

This may sound "reasonable" from a management point of view, but when you are the one responsible for "feeding" that IT monster with the data, then you start wondering how difficult it would have been to begin its design thinking of its users and not the people who will just get numbers out of it.

Short story: everybody is now feeding it with the numbers the system lets them or the numbers that won't cause them troubles with their corporate overloards. And NOW, those over-illuminated management people swear they have everything under control.

So yes, we need to change this somehow. But I don't think it's just about a "feedback loop". That will help only if there's the willingness to hear user's opinions without sticking the "I-know-better-because-of-my-MBA" card in their faces.

This problem is actually what gives me a job. I work as a consultant for a software company, and my job is to create custom implementations of our software to help out users that are crushed under things such as six purchasing systems.

However, that being said, I really don't care about what I'm building. I pretty much never meet the people who end up using what I write, and I never get any true satisfaction from helping a call center agent wrap up a call in two minutes as opposed to five. While I'm not actively looking, I'm definitely on the market for a new job where I can develop software that I care about. My ideal would be video game development, but I've always seen that as the holy grail of development jobs.

Great list of comments/critiques on enterprise apps. I agree with the comment above especially from Kevin Matheny @ Best Buy as well. A few additional thoughts:

I work at a Fortune 500 corporation consisting of 15+ divisions with headquarters in various cities in the U.S. I work in IT at one of the company's divisions and much of what I deal with I inherited from people who inherited it from someone else. This is often accompanied by a lack of documentation of system processes and an abundance of tribal knowledge by the tenured employees.

The danger in this is that nobody really has visibility into the entire enterprise, its systems, or its data. At the end of the day, what I inherited is terrible by today's standards, but it works good enough to get the job done and I'm paid to focus on higher-priority initiatives.

Just 3 years ago when building a website, we still had to make a business case for why it could be developed in 1024x768 resolution and not 800x600 out of fear of alienating end-users who only had 800x600 monitors. The point here is that in just 3 years, things have changed exponentially and many enterprise systems that we all have the displeasure of using have been in place far longer than 3 years and were somebody else's idea.

It's kind of like driving the car that you bought in 1999. By today's standards, it's outdated, but hey, insurance is cheap, you don't have any payments on it, and it still runs despite the occasional service it requires. When you can get by with what you have, it's very hard to justify the costs of something new. In this economy, we'll only see more of this mentality.

Too true. Kevin M. has a great point. Part of the problem is that corp's and the webs are organized in diametric opposition to each other. One is top-down, the other bottom up (guess which). See Scott Burkun's survey on why designers fail: http://www.scottberkun.com/blog/2008/why-designers-fail-the-report/ The top reason given? "People in non-design roles making design decisions." We have to organize around knowledge, and actual results (evidence-based management), and leave the industrial age hierarchies designed to simply control (exploit) labor for manufacturing in the, well, industrial age. The web has always been subversive. If it were left to large corp's no web would even exist. No ajax. No "web 2-shmoe." Something to consider in "down times."

Also, software design and dev't, esp. web-based, requires closer collaboration than for other media. Communication is complicated by team size. A rare PM can counter it. Multiply by geographic/time zone separations, and cultural ones sometimes, too. I don't remember who said it but there's an old quote: "any company with more than 100 people creates so much work they no longer need to interact with the outside world." Paraphrasing, but rings true. I've been working via daily conference calls. The team met for two days and we got more done in them than the previous two months. Is agile scrum the solution? It can make a dent, at least. But it's core benefit is improved collaboration. Not in words only, but in deeds. We have to learn to communicate and collaborate more, and better, and well, and truly most of all.

Then again, even the best scrum can't overcome inexperience or lack or vision or other ills in authority.

"Architects, designers, and developers of corporate systems usually have little or no voice in what gets built, or how, or why." After having built several of these so called enterprise systems, I think this is the bottom line. The successful implementation has passionate architects and designers and the busienss does not micromanage them or tell them HOW to do it. Unfortunately that happens so rarely, that few systems are truly successful. Business, however, will still find a way to declare success by redefining the measurement... meanwhile their good/valuable architects and personnel are tunning out...

Hi Mike - long time. I've been following the blog and have enjoyed it. I loved this post. I would add one thing to the list though. Not sure the best way to phrase it, but it is a lack of measurement and accountability: Is the purpose of the system defined and measurable for a business perspective and, if so, does it meet this objectives? If not, who gets the axe?

Perhaps this is just a symptom of all 4 above. Consider this example:

We built an IVR years ago that promised a decrease in phone lines and headcount in a call center by automating some simple calls and streamlining others. Those savings were used to justify a huge development cost.

The application's interface was so poor (#1) that it took longer to go through the IVR than talk to a person. A high percentage of people had to dump out to an operator anyway.

The result? Call times increased, phone lines increased, customer satisfaction decreased, and the number of agents had to stay the same.

What happened? The project sponsor was lauded for being able to deliver the project on time and on budget. I remember thinking - am I missing something?

This is a well written post, and I don't disagree with what you're saying.

But we know this, don't we? It's been said before, many times, over the last 10 years (and probably even longer than that).

Isn't it time we move past the obvious deficiencies of internal enterprise apps (and the way they're built) and started talking about how to make things better? I don't have any answers, but I think it's a more interesting (and hopefully more productive) debate, IMO.

("I mean, have you ever seen someone write 1,500 words about how much they love their corporate expense reporting system? Or spend their free time mashing up the job posting system together with Google maps? Of course not. But why not?

There's a quality about some software that inspires love in their users, and it's totally devoid in enterprise software. The best you can ever say about enterprise software is when it doesn't get in the way of the business. At it's worst, enterprise software creates more work than it automates.
")

applies just as much to *commercial* enterprise software as it does to internal, departmental applications. How many people just ADORE their mail server app?

Your reasoning about only doing "gray-suited, stolidly conservative things" certainly applies. To a lesser degree, so do your comments about serving the overlords (IT products are purchased by the CIO, not the users) and having captive audiences (IT products are pretty much an oligopoly).

But when it comes to commercial IT products, your reasoning about “give-a-shit-ness” is WAY off-base. For the people who produce these products, it IS our brainchild, our livelihood, our passion. And yet, for the most part, we produce products that (as you say) at best help things along without getting in the way too much.

Since commercial IT products suffer from the same Blah experiences as internal ones, I’m left to believe that your first 3 reasons are on-the-money, but that there may be something else that’s overlooked. And “Give-a-shit-ness” is actually not a core cause of the problem.

There is nothing worse that working in an enterprise where the people who do not use the software are the ones making the decisions that directly affect the software. I used to work in the web development department of a major corporation and we would A/B split test or multi-variate test everything to find which variations help us achieve our online goals. Then the head of our department would meet with Senior Management to share our findings and make recommendations for the direction of the website's design. Some of the VPs understood the value of the data that was being presented, but most of them didn't. They would say things like, "Oh, well, I don't like the color scheme in that banner ad even though it increases conversions by 5% over all of the other variations. If you fix the colors I could approve of it." Well, if you 'fix' the colors you will lower conversions. Sometimes I don't understand what the SVPs are thinking.