Subscribe to our mailing list

* indicates required

Friday, February 27, 2009

Why is enterprise software so bad?

Matt Asay blogged the other day (as did Michael Nygard) on why enterprise software is so shockingly bad. I couldn't help but smile sadly, nod my head, and wipe a virtual tear from my cheek.

Obviously not everything in the world of enterprise software is poorly done (there are some exciting things going on out there, after all), but the fact is, you and I know exactly what people mean when they say that enterprise software sucks.

Enterprise software is typically big, slow, and fugly, for starters. The GUI (if there is one) is often a usability disaster. Sometimes there are strange functionality holes, or things don't work the way you'd expect. And of course, a lot of the time the software is just plain unstable and ends up detonating.

I've worked in R&D for two software companies, one large and one small. Both companies made Java enterprise software, and rest assured, we shipped our share of chunkblowers.

In one case, we had created a sizable collection of connectors (priced around $15K each) designed to let our customers integrate with popular products from SAP, JD Edwards, Lawson, PeopleSoft, Siebel, IBM, and others. I took classroom training on some of the "remote systems." And I was mortified by how inferior the user-facing pieces of some very expensive middleware products are, compared to the desktop software I use every day.

When I first arrived in the enterprise software world (a wide-eyed noob), it was a shock to the senses. I noticed a number of things right off the bat:

1. Data (and in particular, data integrity) matters more than anything else. You can throw exceptions all day long. Just don't lose any data.

2. Getting the job done is top priority. How you get it done doesn't matter as much as getting it done. If mission-critical software somehow manages to "do the job" (no matter how poorly), life goes on. If not, the world comes to an end.

3. Most user interfaces are designed by developers. (Which is kind of like letting welders do plastic surgery.)

4. Usability testing (if it happens at all) happens near the end of the development cycle, after it's too late.

5. Customers, alas, don't know any more about good UI design than you do. They can only tell you what doesn't work.

6. An easy installation experience is not perceived as having anything to do with solving business problems (it's orthogonal), hence it's not a priority, hence software installation and setup tends to be a brutally punishing experience.

7. "Interoperability" and "standards friendly" means putting everything in XML (using your own inscrutable custom schema that no one else uses), then describing all of your one-off proprietary interfaces in WSDL so you can tell your customers you have a Web Services API.

8. If your customers aren't finding the software easy to use, it's because they didn't get enough training.

9. If the software is too slow, it's because you need a bigger machine.

10. Frequently heard phrases: "There's a fixpack coming." "Did you look in the logs?" "You're the first person to report this."

In a macro sense, enterprise software ends up being disappointing for two main reasons, I think. First, the process surrounding enterprise-software procurement and deployment is typically somewhat thick, involving large numbers of stakeholders and a fair amount of bureaucracy. The more bureacracy there is, and the more people that get involved, the greater the likelihood of a failed exercise in groupthink. A lot of really poor decisions get made by well-meaning people working together in large committees. Bottom line: a flawed procurement process leads to situations where "all the checkboxes are checked" yet no one is happy.

The second thing is, making a good software product is hard. It requires extra effort. And that means extra cost. Manufacturers don't like extra costs. So there's a substantial built-in incentive to turn out software that's "good enough" (and no better).

McDonalds didn't get to be the most successful company in the fast-food business (the IBM of food, if you will) by producing great food. It's important to be clear on that. They produce food that's good enough, and they do it at a price point that hits a sweet spot. (And they have a delivery mechanism that allows customers to consume the product the way they want to, such as in the car on the way to someplace else.) Secret sauce has little to do with any of it.

I do think things are getting better. Enterprise software doesn't suck as much as it did ten years ago (or heaven forbid, twenty years ago). The pace of change has certainly quickened. Iterations are faster. Competitive pressures are higher. And customer expectations are rising.

It's still pretty bad out there, though. Which is either a curse or an opportunity, depending on where you sit and how you want to look at it.


  1. Totally, totally agree :)

    3. Most user interfaces are designed by developers. (Which is kind of like letting welders do plastic surgery.)

  2. I agree. I think another factor is that they test to see if something works. They don't do all the strange things that users do to the system. If it works as intended when used as intended, it ships. Then it dies in the wild.


  3. #2 is probably they key part in this. No one really wants to take pride in doing a good job. It's all about moving responsibility off their plate ASAP, regardless of how it is done.

    Number 11 should be: Documentation is only done if there is "spare time" to do it before delivery. This generally applies to documenting requirements and design as well as end-user documentation.

  4. As a VP of Product Management for an Enterprise Software company, I have to say that I totally agree with this post. Great job boiling down the issues in getting a decent enterprise software package to market. The other issue that I face a lot is that there is a constant race to get features and functionality out the door and the UI becomes a secondary consideration. It is almost that the UI design is a bit of a luxury item when compared to getting the new feature to market.
    Although, I'm only making excuses now and not really solving the problem. You raise great points that will cause me to review my development process from here on out.
    thank you.

  5. Why do 3. automatically mean bad UI design? I don't think that it does. Think about this for a minute, how does the code that these developers wrote for the enterprise project? See the correlation? It's not about "developer UIs" vs "usability ''experts''". I have experienced disasters coming from these "experts" and seen great UIs from developers (in fact, great developers).

    The reason enterprise UIs fail are the same reason why everything else fails, so stop this stupidity about "developer UIs". There are only good and bad UIs, made be _someone_.

    But apart from that, pretty spot on. Enterprise software is horrible and the typical enterprise programming languages makes me cringe.

  6. I don't think anyone would dispute that Enterprise software can be hard to use - but it is actually trying to solve very difficult problems, or at least trying to minimize the impact of the complexity to the customer, and to only require business focused development. The interface between the customer side of the solution and the 'complex' side can be an issue, but longer term relationships between customers and vendors certainly can help, and especially with new agile development approaches.
    I think it is also important for both vendors and customers to move towards standardization at least for parts of the solutions. With some aspects of a solution being standard, then not only are skills less of a problem for customers but also vendors can be keener to advance their solutions to avoid customers moving to other vendor solutions.
    While as an IBMer I am not sure I completely enjoy the comparison to McDonalds, I guess being globally ubiquitous and delivering a familiar product can achieve a lot, as long as you have different offerings for different consumers. This is a challenge for most vendors, who try to meet the needs of their most advanced customers, as well as customers just starting with approaches such as SOA. IBM may at times seem to have a huge array of products, but it does help meet the needs of different customers. Imagine sitting in a restaurant and being able to have a delicate risotto, a beef stew, and a quick and simple burger, all from the same menu, meeting all customer needs. It might mean chaos in the kitchen but the goal should be delight at the table.

  7. I don't understand why Point No. 1 was shocking, or even why it is considered a negative point. Any enterprise software should be designed to protect every byte of a user's data given to it, even at the cost of the umpteen exceptions. I don't see how any other aspect of the software could be more important. Would it be better for the software to throw less exceptions (and risk not being able to identify a problem), or simply "lose" a message or file here and there?

    Also, I agree that points 8 and 9 are an issue, but only because of their frequency. In moderation, they sound like valid concerns.

    Thirdly, from my personal experience, point three makes sense in more ways than one. If I may expand your analogy, welder-made plastic surgery may not look pretty, but it tends to be more resistant to attack (stress testing, or user mis-use). This can look like a hostile work environment to a user unfamiliar with the program's inner workings, in which case a little more of point 8 might be in order.

  8. Anonymous3:49 PM

    I have used it for a year JD Edwards, in the Medical Industry. One of the main problems is :
    data has to be manually entered in too many places slowing things down. It is cumbersome and
    slow. I used AS400 at another job and although
    ancient, it rolled much faster ironically thru
    screens and in a fast paced accounting
    need speed, being bogged down with JD Edwards is
    a morale killer the way..



Add a comment. Registration required because trolls.