3 ms·
He's right that the buyers not being the users is an issue, but there's far more too it than that. There are a lot of good answers already here, but to add a f
by akeefer 16y ago
He's right that the buyers not being the users is an issue, but there's far more too it than that. There are a lot of good answers already here, but to add a few more (and consolidate some others):
1) The developers often aren't the users either, which instantly makes things far more difficult. My company builds insurance applications; it would be 10x easier (if not more) for me to write an e-mail application with a good user experience than for me to write a policy administration system with a good user experience because I'm not an agent or underwriter. With consumer software, development or collaboration tools, and a lot of small business software, the developer might actually have to/want to use their own stuff. For most enterprise software, that's rarely the case.
2) As has been pointed out already, a lot of enterprise software is complex. It's hard enough to get everything to work, let alone to have a really nice, slick UI. There are often endless numbers of non-optional corner cases to handle. If you're really unlucky, the process in question will be subject to lots of government regulations you have to abide by; if you're even unluckier, those regulations will vary by state (not to mention by country). It's hard to make something that complex user-friendly.
3) In addition to complication, there's the issue of surface area, which is somewhat orthogonal. It's much easier to polish a web application with 20 different screens that to polish one with 2000, no matter how simple those 2000 are; you often don't have the resources to devote huge amounts of attention to detail on an application with that kind of surface area.
4) Enterprises themselves are difficult to sell to. Extremely difficult. It's largely a self-inflicted wound, but it results in an increased barrier to entry in that market, which increases the cost of actually selling into that market, which leaves fewer resources for development (relatively speaking).
5) Enterprise systems often need to integrate to a bunch of other enterprise systems. Any way you spin that, it's difficult and time consuming to do that, which sucks up more resources.
6) Most enterprise solutions involve a lot of vendor lock-in. That's partially due to the storage of large amounts of highly critical data, partially due to general risk-aversion at most companies (since such changes, if they're botched, can be disastrous), and partially due to the integration work mentioned above. The cost of switching tends to be very, very high.
7) Everyone wants to be a unique snowflake. For core business processes many companies consider their process to be a competitive advantage; at the very least, it's a core part of their business. As a result, enterprise software often has to be customizable so it fits with what data the customer captures and how they do business. That dramatically ups the complexity factor and makes polishing things much harder.
8) Because of all those factors, enterprise markets have a high barrier to entry. The complexity of the products means that you need a decent amount of funding to even begin to enter the market, and the sales difficulties suck up more money and make it difficult to establish a consistent revenue stream. The relatively small market sizes combine with that to turn many of the markets into winner-takes-all sorts of games. As a result, you end up with two classes of companies: new entrants and incumbents. The new entrants don't have the resources to really polish their stuff; they're struggling to build stuff that's functionally complete, actually works, and to sell it without running out of money. They can't afford to chop their footprint in half in order to make sure it's really slick, or to spend twice as much on development. The incumbents, on the other hand, often have no incentive to not suck. They tend to have high levels of lock-in and they know their competitors have huge barriers to entry, so the competitive pressure to be good isn't there.
9) The most talented developers and designers often simply won't work on enterprise software. You're working on something you wouldn't use and have no personal connection to, and no one you know can use or see your work. At least in the valley, if you tell people you build enterprise software, people often react like they feel sorry for you, or like you're some sort of idiot-leper who simply isn't good enough to get a job building cool consumer stuff. Ask awesome developers if they want to work on a database, a social networking site, or a claims processing system, and I think we all know which option will come in third place.
10) Those are all reasons why commercial enterprise software written by software companies sucks. A lot of enterprise software, however, is written in-house. If a company that can amortize their costs across dozens or hundreds of customers has a hard time doing it, you can imagine what happens when one company attempts to build things themselves. They really don't have the resources or expertise to product anything thoroughly polished most of the time. And the hiring problem there is even worse: most good developers would rather work at a software shop than in the IT department of some massive company.
- humblepatience 16y agoread my mind, awesome list.
- bpyne 16y agoFantastic list but just to add a few items from my experience. 11) COTS enterprise software, as often as not, is a Frankenstein mismatch of packages purchased by the vendor and stitched together. Our major software system is on its third owner. We have access to the source code. It dates back 20 years to mainframe software that has been ported. It's written in a combination of COBOL, C, PL/SQL, Java, Oracle Forms, and a smattering of browser scripting languages. The vendor's software suite is completely purchased and thrown together (a.k.a integrated) in the cheapest way possible. 12) Developers of enterprise software often get requirements from a dedicated analyst. Perhaps it was me but when I tried working from another person's analysis, I found it hard producing software the users actually wanted. 13) Software developers are not interface/user experience designers. Enterprise software vendors hire many more of the former than the latter. I'm not a fan of having the analyst role split out from the development role. Coming to understand the user requirements is a major part of development. Requirements are not facts to be memorized and worked through like a check list. They have to be internalized to the point that you understand why something is a requirement. Much the same argument as with the analyst role. I would rather have a developer with a passion for UI design get the proper education in design instead of having a developer and a designer as separate people. My experience is that some developers naturally gravitate towards the visuals, so harness it. EDIT: Removed footnote marks because they looked confusing.
- bmm6o 16y ago#7: Exactly. There is no 80-20 rule for enterprise software. If you don't meet 100% of the requirements, it isn't a replacement for their current system. You can't compromise on functionality for the sake of usability or elegance; every item on the spec sheet has to be included.
- saikat 16y agoOn your point #2 - it is true that enterprise software tends to be complex, but this problem is compounded by the fact that enterprises are unwilling to approach building/buying solutions to complex problems with a conquer and divide approach. In the consumer/small business world, small, lightweight tools that solve one problem well(think Redis for databases, Etherpad for collaborative editing, etc.) are easier to make good interfaces for. When it comes to buying software, big companies don't like choosing small, well-designed tools that they can put together to solve a problem because the decision-making process of choosing technology is expensive and time consuming when you are risk averse. At a large financial institution that I used to work at, we spent months going through different third-party offerings of a new data platform. Everyone hates doing it, and it cost a ton of money in developer time (plus some companies actually charge you to do a lengthy demo). So people just tend to gravitate towards the products that are bloated with features and will solve all our problems at once, and we all know what kind of UX these kinds of products will offer.