Misunderstanding enterprise software
December 09, 2007
In a post titled "Robert Scoble doesn't understand enterprise software," ZDNet blogger Michael Krigsman lays in to Scoble for having the temerity to ask why business applications can't be redesigned to be more like consumer applications - fun, friendly, even "sexy." Sniffs Krigsman:
As an enterprise software blogger ... I feel qualified to comment on the issue: Scoble’s question is irrelevant and meaningless. Robert Scoble misses this point: unlike consumer software, where sex appeal is critical to attracting a commercially-viable audience, enterprise software has a different set of goals. Enterprise software is all about helping organizations conduct their basic business in a better, more cost-effective manner. In software jargon, it’s intended to “enable core business processes” with a high degree of reliability, security, scalability, and so on ...
When I’m at home using Twitter, a great example of cool consumer software, I want to be delighted, thrilled, entertained, and engaged. When I transfer money through my bank, which is certainly a non-sexy enterprise system, I demand the system work every time without fail. There’s a big difference between enterprise and consumer systems, a lesson I suspect Robert Scoble is about to learn.
I'm sorry, but I think Krigsman is the one who doesn't understand enterprise software - or at least doesn't understand what it could become. The distinction he draws between business and consumer applications is specious. Are we really to believe that making software engaging is somehow incompatible with making it reliable and secure? That's just baloney.
Look, for instance, at a consumer-directed application like Amazon.com's store. You might quibble with some of Amazon's design decisions, but it's a friendly, easy-to-use application that gives each customer a huge amount of power to tailor its workings to his or her particular preferences and needs. And yet the Amazon store processes a vast amount of sensitive data, keeps it secure, is extraordinarily reliable, and is scalable as all get-out. There's no reason that corporate systems can't emulate this model. Indeed, many new web-based business applications reflect the simplicity and ease of customization that we've come to take for granted in many consumer applications. Hell, even some online banking applications are starting to get much simpler to use and customize.
By perpetuating a false dichotomy between the friendliness of consumer apps and the seriousness of business apps, all that Krigsman is doing is giving enterprise vendors cover for continuing to produce software that's difficult and unpleasant to use. Give Scoble credit. He's asking the right question, in his own strange way.
UPDATE: In a follow up, Krigsman says I'm living in a fantasy land. At the same time, though, he admits, "Ultimately, the problem can be solved by software technology that completely isolates the user interface from all other elements of the application, including data, backend services, and so on." Welcome, Mike, to my fantasy land, which is also sometimes referred to as the 21st century.
No doubt user friendliness is something that enteprise software players need to learn from the consumer world players - startups and bigger players included. Todays’ leading consumer sector players all have aspirations to move into the enterprise space faster. I see huge opportunities in the fusion - the consumerization of enterprise technology has the potential to open up new powerful combinations. The possibilities of such fusion of different worlds may open up good chances for disruptive innovation - this provides a platform for such an ideal fertile ground that can lead up to a potential business model innovation – so enterprises need to be well prepared to capitalize on such possibilities. see my note
Nick - what part about UI and the use of social computing metaphors in Mike's post did you miss? As regards Scoble - he's not asking the right question at all. He talks about blogs and CPM, making the fundamentally flawed assumption you can equate consumer to business. You can't. You're only talking about a tiny slice of the consumer facing action as you should well know. Pillorying Mike K in this way is specious.
Posted by: Dennis Howlett at December 9, 2007 03:16 PM
I think you are seriously mistaken about this and several other important, global issues. See my blog post for a full, in-depth discussion. ;)
Posted by: Anshu Sharma at December 9, 2007 03:28 PM
Nick, I agree with you. There is a lot to be learned in the Enterprise Software space from the consumer world. There are also a lot of benefits to be had by making enterprise software "Sexy."
It depends on how you define "Enterprise Software". I'm a SAS developer and quite a few of my programs run in the "Enterprise" space. As an example, churn analysis, loyalty management, etc... I write this code on the desktop and port to the mainframe. If you do a little research, you will see a lot of complaints about the SAS UI and how it hasn't changed much over time. Sexy UI's make development easier, faster and more efficient. So I think Scoble & Carr both have a point. Btw, is MS Office "Enterprise Software"?
Posted by: PhilRack at December 9, 2007 04:03 PM
I like your title, though I have to say I saw it coming.
So, Dennis, you agree that drawing a distinction between engaging software and reliable software is justified and useful?
By the way, I changed the title of this post. The original title was meant as a cheeky play on Krigsman's title, but I realized that it could take on a life of its own in search results, which would have been unfortunate.
I commented on Michael Krigsman's blog post that I was recently witness to a SAP meltdown at 150 employee company. I won't quote verbatim here, but the gist is that the promises never match the burden for small companies when training and usability are factored. Most egregious were the SAP consultants; criminals more like it with a license to steal from the unsuspecting. Ultimately, the client lucked out and found a bright your fellow to weave together some simple Web based apps that give them 90& of what SAP promised them
IS it as integrated as the SAP install could have been? No. Is it in daily use at a fraction of the cost? Yes. Are the people who have to deal with the system on a daily basis happy with it, oh yes.
Posted by: abm at December 9, 2007 04:27 PM
I am glad you like the title. And yes, you had it coming. ;)
Posted by: Anshu Sharma at December 9, 2007 05:22 PM
Nick, give me a break. Your comments ignore a whole lot of realities. My response over at ZDNet:
Posted by: mkrigsman at December 9, 2007 05:23 PM
As a daily user of enterprise software, I can attest that it is unbelievably unfriendly. Nick and Scoble are right on the money; hiding behind transactions, and other technical metrics may make you sound like serious commentator, but that’s it. This is SOA vs. REST from a user interface perspective.
Nick, sorry, you sound like a con-ned-sumer of technology...
Posted by: vinnie mirchandani at December 9, 2007 07:14 PM
Enterprise software is about one thing only, that's delivering business value, most often through a productivity boost.
Ultimately I assert, User Experience has as much (and occasionally more) to do with productivity as functionality.
Jeez, Vinnie, you Enterprise Irregulars are starting to sound like Enterprise Regulars.
I think Krigsman doesn't like the term "sexy". "Sexy" doesn't describe reliability, quality or even value of a piece of software, but describes the degree of hype and public noise. The public perception and talk about a software is all about sales - but at the end of the day it's the quality of a software moving firms to buy and use it or not.
On the other side, people making decisions on acquisition of an enterprise software are definitely receptive to noise concerning software (mass) markets. So I think this tenor can influence significantly their decision.
Posted by: Alex at December 9, 2007 10:31 PM
It's all really about engineering methodology:
Enterprise software has a reputation for being lousy to users for the simple reason that so much of it designed by a waterfall method. Somebody writes down a specification of a UI and N months and $K million later there it is, expensively fixed in stone. As Krigsman hints, the motivation for this practice is its reputation as a reliable methodology: the interface to the banking system may be awkward or even painful but events where a software glitch screws up transactions are rare.
Is that reputation deserved or not, in comparison to other ways of building software? That's kind of an open, academic question. Software engineers in the audience might understand the question as, for example, will modern type-check systems help more agile development styles to produce really trustworthy code? (In some ways, the answer to that was is in and is "yes" but, anyway, that's the general direction where the future of enterprise software is being decided.)
What seems to be confusing the capitalists, from my perspective, are competing claims that various pieces of new technology are somewhat "silver bullets" that enable a more improvisational, agile development of software that is, nevertheless, of enterprise quality. In other words, the technology is foggy and its hard to assess risk, though everyone strongly suspects things are changing.
Place your bets.
I'd be reluctant to look too casually at something like Amazon and assume that much of what works there is easily transferred to other projects. The reproducibility of the methodologies supposedly responsible for those successes is an open, empirical question. (With all kinds of interesting, complicated, circumstantial evidence on both sides.)
Posted by: Tom Lord at December 9, 2007 10:41 PM
It wouldn't make sense for enterprise apps to share the same attributes as consumer software: enterprise apps see less competition and the purchase decision makers have different criteria from the users (as 37signals pointed out recently).
There's some hope: 1) buyers will increase their desire for usable solutions and 2) solutions birthed out of the SMB marketplace, where buyers are users, will appeal gradually more to the enterprise space.
In SK his own words asks:
>> Why is enterprise software often hard to use?
>> Several reasons:
He gave several answers but here’s one he left out: Cost of Maintenance (COM)?
I've heard figures in the area of +67% of expenditures for enterprise software are in the maintenance and upgrade phase. Easy to use software that reflects transparent business logic is just not profitable; its revenue that the major vendors bank on. Businesses seem to be able absorb the cost; however, consumers just get infuriated by having to upgrade constantly.
Posted by: Linuxguru1968 at December 9, 2007 11:52 PM
I explored the notion of why people who are exposed daily to high interface and interaction values inherent in TV, movies, advertising, magazines and gadgets in the consumer sphere are somehow supposed to be rendered incapable of expecting and appreciating the same within the walls of the enterprise from 9 to 5, with a dozen enterprise examples that aren't sexy:
Posted by: Kontra at December 10, 2007 03:36 AM
I'm with Nick 100% on this one. I have been involved in many large scale enterprise software projects over the last 10 or so years. One could argue that the majority of the folks who use enterprise applications are probably not the same folks (in general) who use todays web20 consumer web based applications. However what we have learnt from todays' AJAX based consumer services is that given a good UI, easy navigation and a little sex appeal then the user take up for such services can be significant. Now consider one of the key problems with enterprise software (and CRM software in particular) .. functionally the majority of the enterprise applications work well however the user take up is so often a problem. An organization could spend $millions implementing Siebel and end up with limited user adoption, reduced ROI and overall lack of customer satisfaction.
If we applied todays so called web20 technologies to enterprise application I think we will see increased usability, improved user adoption and in general higher customer satisfaction from both the users and the organization itself.
Many of you may know that SAP has announced a redesign of their CRM solutions to be web20 friendly:
And for the rest of the organizations that do not use SAP my startup may offer some web20 relief. I am working on a solution which provides the ability for any organization to participate in the web20 world without having to make any changes to their underlying operational systems, at very low cost and (hopefully) significant value to the organization and efficiency increases in employees. If any of you are interested to learn more please contact me directly at : jason at mee-mah dot com.
We are in stealth mode right now but I am interested in talking to anyone who has an interest in what we are doing.
I disagree with Nick on the usability factor. There is a difference in Fancy system and easy to use system. Enterprise systems need not to be a fancy colorful screen, but it must be easy to use for the user. I do come across some functionally good systems but complex user interface to use and unfriendly 25 steps to complete an entry. It is achievable for any enterprise system to improve the usability without compromise on their functional features.
I absolutely believe that enterprise software should be sexy! I am saying this with the understanding that when we say 'sexy' we really mean 'intuitive'. No one cares how 'cool' a piece of software looks if it's unusable and takes drilling down into multiple stacks of menus to accomplish what you want to. We think software is 'cool' and/or 'sexy' when it's easy to use. Everyone wants to spend less of their time learning the ins and outs of [non-intuitive] software and more of their time doing value-add work. We should be able to figure out what we need to do with a combination of a few clicks of the mouse and reading the help. I have just recently been part of a successful SAP implementation and can tell you that it works beautifully. But guess who uses SAP most? The really bright people. The ones who compensate with the difficulty of learning SAP with brute-force intelligence. Not everyone who's using it is highly educated - that's not a slam or insult it's an admission of fact. These are the users that concern me. They are the ones that use the system by wrote, removing any chance that they will use it creatively or spontaneously to solve the real-world problems they face daily. As soon as its use falls outside of their procedural training they will fail. Mistakes will be made. They will not be able to apply common sense or more accurately, their basic problem-solving skills to using it to getting their jobs done.
In my mind, enterprise software has failed completely in this respect. It continues to treat its users, especially those on the plant floor, as industrial-age 'hands' - without valuable insight into the business processes of which they are the true masters. We, and they, are knowledge-workers. I predict that within the decade enterprise software as we know it will be fast on its way out. Within 25 years it will be relegated to the world today's mainframes live in. As the shift from the industrial age to the knowledge age intensifies, so will enterprise software's market share continue to shrink.
Posted by: Asad Quraishi at December 10, 2007 09:17 AM
Not to make a mountain out of a mole hill, or more of a mountain, and I know there are as many definitions of 'sexy' as there are people, but enterprise apps do need sex appeal. There is no way around it. The first iteration of a full client was pretty rough, but over time the user interface must become easier, more configurable/customizable and more pleasant to look at and work with. When talking to the average user in the sales cycle these values are paramount. People want to enjoy software, not tolerate it or fight with it.
Posted by: Thomas Foydel at December 10, 2007 10:45 AM
Nick, we are not regulars at all. We are constantly pushing the enterprise and enterprise vendors to improve...but there is this naive view out there than a better/more social UI will "fix the enterprise"
if we are going to re-do UI, let's also be prepared to destroy it for many non value added intermediaries in various processes...blindly Ajazing a web 1.0 or green screen or SaaSing a process is no way to "fix the enterprise" ...it is paving the old UI and business process cow path...
see my post this morning
Posted by: vinnie mirchandani at December 10, 2007 11:18 AM
"Welcome to my fantasy land, which is also sometimes referred to as the 21st century." We completely subscribe to your point of view!
If you want to do something about this status quo you will have to focus on the "market" dynamics that is causing it. Because 1) consumers can switch easily and 2) consumer web sites (like Amazon) can much more easily measure the impact of improved usability on their bottom line, the consumer software/service providers are more likely to invest in usability until the point of no additional benefit.
I believe the most effective way to remove this "usability gap" is to try to make the enterprise software market structure more dynamic. This would involve something like
- Coming up with ways to measure the impact of usability on corporate profits (or against any other metric valued by management and shareholders)
- Improving the ability to switch or even better give employees a choice between multiple competing solutions for carrying out the same function.
Full blog: http://dev2dev.bea.com/blog/jesperfj/archive/2007/12/consumer_class.html
Posted by: Jesper at December 11, 2007 12:55 PM
BTW, your commenting log in process would make the most enterprisey "lets make it megacomplex for the sake of complexity" UI designer chant "we are not worthy."
My take here. http://theotherthomasotter.wordpress.com/2007/12/11/complexity-syndrome-and-rumplestilskin-20/
Posted by: Thomas Otter at December 11, 2007 02:34 PM
I think you've answered the "SHOULD", and "POSSIBLE" parts of the problem, but I don't see that anyone has answered the ECONOMIC (not financial, but economic) incentives, or the COMPLEXITY of enterprise applications that drives their usability compared to that of consumer applications.
I agree that the difference between enterprise software and consumer software is specious, as you said, as a design problem -- it's all just software. However, that being said, I think that as a practical reality, Enterprise software is hard to use for a number of reasons:
1) COMPLEXITY. Software in the enterprise is, almost without exception, solves far more complex problems than does consumer software. If you rattle off any consumer level product where the user interface is easy to use, the task at hand is far more simple by comparison. That's because the problem is more than one of choosing a simple interface that would suit consumers. Most complex transactions have been simplified in a way that would be untenable in the enterprise equivalent. (You might argue that that less complex parts of software might be easier to use, and I would agree, but then for the advanced user, that usability would be a detriment because he or she is interested in efficiency if the task is done frequently, and not, if infrequently. So the user interface design would depend on frequency of use. which in turn, is a property of people's memory. Which is the problem most developers face, is that they over value the budget of short term memory that people can devote to any given task. Although, if they don't remember it because it's too easy that might not always be good as well.) Simplicity means "More general" and that means it OBSCURES INFORMATION, or that it eliminates or reduces information. Whereas a consumer has little incentive to add vast detail to any task, many businesses require that they add such detail to any task. There are also complexity problems for which we do not have a user interface solution yet, because people's short term memory cannot be assisted in the two dimensional space in a way that facilitates the task. These are rare, but if solved, (DNS Management for example) in a way that makes it easy to use, the solutions we have actually make the interface problem worse by introducing too many steps or too many layers of abstraction.
There is, (I haven't seen a study on this but I'm both sure they're out there and I've sketched some rough ideas out on it myself) a maximum amount of complexity that can be conveyed by a two dimensional interface given the short term memory of the average person who is a candidate for operating the software. That boundary is actually fairly low. In order to get past that boundary, a software company must:
a) find a way of solving the problem for the user (wizards for example)
b) Simplify the actual feature (by picking a general case rather than providing coverage for all possible cases)
c) Hide functionality so that it can be found by advanced users (and provide configuration to expose it permanently for those to whom it is standard functionality.)
In other words, there are inelegant solutions to problems, because there are relationships that cannot easily be expressed in a two dimensional interface, unless the interface design is so complex that it obscures the task (visual programming for example, workflow management software, interfaces for products like Biztalk and similar process oriented software.)
This is not to say that people don't develop poor user interfaces, it is to explain, for reasons other than incompetence, why it is difficult to produce good user interfaces for complex applications. *because it's simply very hard* is one of the explanations.
DIGRESSION: I have seen at least four generations of user interface evolution now, and it is getting better, but all interface development is some form of abstraction and with increased complexity we increase abstraction, which the user must learn like a new language. We tend to be unaware that we're doing so because it's an evolutionary process, but if we try to predict user interface development, we're actually not predicting it, we're inventing it. (Predicting anything other than dinner is a very improbable proposition.) You invent the technical future, you do not predict it. (MS's awesome Surface Computing and 90's UI's. Or Gibson/Stephenson virtual worlds versus today's 3d MMORG's, virtual worlds, or Online Shooters.) You do not invent the behavioral future, you observe it, which is what Nick did with "Does IT Matter?" and it's far easier with degenerative processes than innovative processes.
2) TRANSACTION COSTS: The transaction cost for individuals to learn the software is higher than consumer entertainment software, but the value proposition is higher as well. ( Entertainment which is a low value versus keeping your job which is a high value, for example.) So there is less incentive for the product developer to focus on usability since it is LESS of a function of determining a sale and subsequent product adoption. Compare this with any consumer software that is entertaining, and the transaction cost of adoption must be very low because the consumer cost of adoption must be very low. Hence Boomers have a different engineering philosophy from GenY'ers. (Another interesting problem facing society.)
And that is not to say that consumer products have good interfaces. Most games for example, outside of the game space, have terrible user interfaces. (The difference between the sales of counter-strike and Tom Clancy's games is partly complexity, partly failing to understand user experiences, and as such, understand game play, which is, in itself, a user interface.) Even the most hit games (Today's Call Of Duty 4 for example, has terrible user interface problems and it's their fourth attempt at the same product.) There are a few examples, say Quicken, or the tax programs, but they are easily criticizable for the reasons I've listed here, as having a valuable learning curve that is worth the customer investment. The Microsoft Money team for example, spent ridiculous amounts of time and money trying to improve on the Quicken interface and in some ways they did, but it was not sufficient to alter the market place. One fairly interesting area of interface development today is that of converting different audio and video formats. You can, for free, download a product that will do by far a better job than a shelf product. The initial interface is very difficult to understand, but by trying to make the tasks easier for consumers, competing products actually have made the product incomprehensible by making it unpredictable.
The pricing of products in different markets reflects this difference in transaction costs. Consumer applications must be easy to learn and adopt because the company can only charge a little money for them, and the cost of sale and support must be very low. Compare this with enterprise software where, given the greater scarcity of customers, and the greater capital behind each sale, the cost of sale can be high, the cost of the product can be high, the cost of customization can be high and the cost of learning can be high. The difference between enterprise applications is that that there are fewer product choices and these choices are made by feature set that affects the business, not usability, which is simply another cost of the product.
Lastly, one little flake of conspiracy for the theorists who think that it is actually possible to solve all of these problems rationally: increasing the learning curve increases customer retention, because they are less willing to move from one product it took two years to master - especially if the mastery produces more detailed information and they have built business processes around it - so the real cost is changing the business process. This benefits the selling company. (Seems Nihilistic I know, but it is reality.) The more repetitive and administrative the work (accounting functions) the more important this is. However, this cost is visible even in products like 3d rendering (Maya, Lightwave, 3dMax etc) or 2d rendering (Photoshop) where the cost of adoption is so high (the cost of developing habits executed as muscle memory so that scarce time for thinking can be devoted to the work not the interface). For example, for geometry, which includes most man made objects, a body of very inexpensive products exist for easily developing three dimensional objects. But because these products cannot as easily do organic character animation, developers make simple objects using complex software that is far harder to use.
The traditional example of a bad user interface that has high value, is an insurance company's information must be very dense - so dense that it would frighten a consumer - but there is a value in that information density to the skilled user. Because he uses the software all day long.
So the issue is developing the interface for the target the usage, rather than seeking to find an ultimate expression of the human interface independent of usage. And again, an enterprise software must tailor itself to many companies, rather than ask consumers to forgo detail, or flexibility in exchange for ease of use. This is the COVERAGE problem software companies face. That consumer applications when they are simple must cover the middle of the bell curve to be successful in the market place. Enterprise applications must cover most of the middle, but they are DESELECTED in the purchasing process for features at the right hand side of the curve: at the extremes. This coverage problem creates an investment (cost) problem for the people funding the development of the product, since the farther you move up that curve, the more complex the interface becomes, the more expensive it becomes to develop and maintain, and you don't know in advance whether there are enough customers to warrant the expense. If you combine this problem with that of how engineers approach problems, which is, that they say "I can't know that answer, so I will make it solve all possible answers" which they view as flexibility, the usability actually will go down for many people. if on top of that you normalize the data store to reflect that complexity, you make it even worse.
3) OPPORTUNITY COSTS: Because there is always a very high risk of failure with product development, because companies and investors want to minimize the risk of capital, and once a product is released, a vast number of feature requests come from customers, marketers and sales people, there is a competition for development time that could be spent on making the user interface easier.
This does pay off in certain circumstances: MSCRM is having a harder time against it's consumer oriented competitor salesforce.com because salesforce is an easier product to use given that you have a more simple business problem. Or, perhaps, one that is more visible on the web is Omniture versus Webtrends, where, the executive team lost their jobs because they failed to understand (as many engineering companies do) that the market for dense information is filled, and now the more user friendly market (at lower cost) is the only one available.
For this reason, most enterprise software companies fall into innovator's dilemma traps because they fail to calculate the opportunity cost between gaining market share down with consumers who invest less in software, and professionals in the enterprise who invest more. In fact, if someone hasn't coined this as a "law" yet, then they should, and add it to Wikipedia: "The conflict in any business decisions is correctly judging intertemporal opportunity costs in relation to the complexity of the software." Perhaps stating it more simply. (I am an economic philosopher, making simple, well, that's not my job - a parallel of interesting concepts.)
But over time that is the real issue driving the usability of business applications. It is not one of POSSIBILITY or of SHOULD'S, it is a problem of business' judgment of it's opportunity cost given the amount of time it takes to develop a feature (a long time) and the corresponding movement of the opportunity in the marketplace. This is true for any product that takes time to produce, and the core of the entrepreneurial decision making process: the ability to forecast different opportunities in time, when, an error is disastrous, and a correct guess means you stay in business.
CARRYING THE PROBLEM OUT TO THE DEMOGRAPHIC
(Or, social factors that come in to play - just for fun.)
Well, that's more than I wanted to write on the for a blog posting, but user interface design for enterprise software is a non-trivial problem, not because it cannot be made like consumer software, but because it may be economically disadvantageous to do so for the reasons above. Not because they don't care, but because it is actually far harder to develop a solution for all cases, rather than for the median case. Not because ideas cannot be made more simple, but because some ideas, when made simple, lose their contextual utility. Not because they arent' smart, but because the future and consumer demand is very difficult to predict, and most importantly, because the network of opportunities one must choose from given finite financial resources and finite time, are very difficult choices to make. Even if, at times, some very large companies exacerbate the problem by creating bureaucracies that effectively eliminate the ability to make choices. I would argue that any piece of software that is beyond the ability of one architect to envision cannot be made usable. And conversely, that the theory holds true: that any sufficiently advanced piece of software evolves to become email, with the human being as the only determinant function remaining.
Another axiom that is driven by Nick's set of ideas: that software is not a competitive advantage to companies, except as a very short intertemporal equilibrium. (You can't hold a technology advantage for long because of the low cost of your competition's obtaining it.) As such, we are in a box where software must be increasingly easy to use because people see less and less value in it, while the complexity of the software to accomodate it's decreasing value must reach an equilibrium where further investmetn in the technology is no longer sensible.
This might mean that people will get "dumber and dumber" so to speak by being less and less challenged by technology to increase their learning of abstractions, and that computers have already conveyed their behavioral gift to us by modifying our own processing power to it's limits, (sort of like how people who live in cities discount information because there is too much to process and tehy ignore it, and how agrarian people are overly concerned about information because of it's lesser density and greater potential for behavioral impact, and how this difference seems to produce differences in political preferences in most civlizations in history) or it might mean that there is a correlation between the competitive value of any technology given that adults can only learn about 3% per year (which is the natural rate of inflation for that reason by the way.). And people can only seeem to increase their core IQ by .3 per year as an adult, up to some maximum, which means their ability to adapt to abstractions has a somewhat fixed maximum rate. As such, the rate of technological growth without some way of pre-digesting the abstractions for people, reaches a limit that cannot be surpassed.
That bit was just for fun to see if anyone actually read through it, but the ideas come across. It is not a trivial problem and it's not because people are foolish. (though plenty of them are, that's a correlation, not a causation.)
BTW, your commenting log in process would make the most enterprisey "lets make it megacomplex for the sake of complexity" UI designer chant "we are not worthy."
Sadly true, and due entirely to the laziness of the site owner.
Posted by: Nick Carr at December 11, 2007 03:31 PM
Holy shit, linkbaiting has become extreme here. Anyway, I'm with Nick and I think I also have not one, but two answers to Scoble's question.
Q.: Why doesn't enterprise software become sexier?
A1: Because they don't have to. If Amazon becomes less-user friendly, people will click away from it. I may hate my SAP UI, I still have to enter those invoices.
A2: Because then SAP and their lackeys would not be able to sell me overpriced training to fix their programming ineptitude.
@CurtD: do you REALLY expect anybody to read through three screens worth of your rants ?
>>....expect anybody to read through three screens...
I am always surprised at the number of people who do. Never ceases to amaze me.
But more importantly, do you think your little posting actually conveyed anything valuable? Did it add any insight? Any content? Other than an emotional expression? Perhaps there is a middle ground for content depth and length but it's just hard for people to find it...including me.
I was in the enterprise software space for a long time and I'm with you, Nick. Rather than taking up space here, I've detailed my thoughts on my blog at:
Posted by: pmizota at December 12, 2007 02:16 AM
This has a lot to do with who's buying the software: the end-user or the IT manager. When management is choosing an application, sexiness can count against it. Do you want to be the IT guy who picks something with lots of eye candy that the CEO thinks is a toy? This is a business, not an arcade.
I've worked on a few business apps that had very dull UIs that I was eager to improve, at least aesthetically, but the philistine developers wanted to keep them "business-like," partly so they'd be taken seriously, and partly because, like most nerds, they had no taste.
And isn't it a little ironic to have this discussion now, when Windows Vista and MacOS Leopard have placed too much emphasis on "pretty" over "compatible," costing us a lot in lost productivity?
I'm a fan of using the discussion areas of blogs for discussion so I don't blame you for posting something long. You lost this reader early on, though, with the claim that enterprise software tends to be more complex. I think that's the opposite of the actual case.
For example, by most interesting metrics, a transaction processing system for, say, book orders is vastly simpler than, say, a modern desktop office suite. You can learn most everything you need to know to write the transaction processing system during a good undergraduate course of study -- the office suite, on the other hand, will take you a good decade to wrap your head around.
Enterprise software is generally the least complex and also the most tested. It is exactly because so much rides on the correct operation of these programs that they tend towards the simple-mined (including clunky UIs).
Software, pretty much, has negative value in the enterprise. New products find markets by force: if one firm buys a copy, its competitors have to do the same just so that everybody breaks even. It's all pure cost. (In theory, the customers of the firms win from the newly gained efficiencies. I guess, for example, modern supply chain management and Walmart would be poster child for that.)
Consequently, one of the bigger concerns for enterprises is to try to rely only on things that certainly work: hence the whole market lags a long time behind the bleeding edge of what software engineering can, in principle, do.
Posted by: Tom Lord at December 12, 2007 11:05 AM
Thank you for understanding use of blogs for debate. But if you disagree I am not sure what we're talking about when we say Enterprise Software. Pick a few products (the microsoft, peoplesoft, oracle, sap product stacks for example or counter with some others) and help me understand why they are not complex compared to consumer applications? I mean, if you mean, office for example, do you consider it a consumer applicaton or an enterprise application? I am fairly sure the in terms of revenue. I think that around 70% of the user base is in the enterprise space covered by Enterprise Agreements, and is used by business people for business applications. THey do not however, contain business process logic, as do the other enterprise products that I listed.
So, can you help me understand your position?
Sure, the terminology is a little fuzzy in the literature. So, here is how I think of it. Actually, let me experimentally "make up" a definition and see if it sticks:
"Enterprise software" is essential to the firm, has large sunk costs, has huge switching costs, and typically has 0, 1, or 2 substitutes available on the market.
"Professional quality software" is all software which at least some large firms would be willing to buy. That includes but is not limited to enterprise software.
"Consumer software" is professional quality software that can be sold in units of 1 (e.g., for the benefit of very small numbers of users).
"Commodity software" is software for which there are many substitutes and competition, beyond some basic tiers of quality and services, is mainly about price.
MS Office and Open Office are, arguably, commodity software programs and are also consumer software. From a vendors perspective, the bulk of an Office program's sales might count as "Enterprise revenue" because large firms buy so many seats but, from the perspective of those firms themselves, Office programs aren't Enterprise Software: sunk costs are modest, switching costs non-trivial but not overwhelming, substitutes exist, etc.
Big-user CRM apps, OLTP systems (e.g., credit card processing, supply chain mgt.), billing systems, accounting systems, etc.: These are enterprise software. These are expensive IT systems without which the firm can't operate, which (dues mostly to scale and criticality) have all the maneuverability of an aircraft carrier, and for which switching is a highly risky 5-10 year project requiring buy-in and coordination at all levels and entirely across the firm.
Lines get blurred. Is "Linux" and the LAMP stack and similar a commodity consumer product? or Enterprise? Depends on who's using it, how, for what. But, let's skip over these grey cases so I can make my point about complexity:
Take an RDBMS stack (please :-). Say, DB2 used for OLTP for credit cards (do people use it for such? I'll guess). There are centuries of person-years (at least) of labor there and nobody, anytime soon is going to whip off a duplicate of the sprawling code base. It's quite "complex" in that sense. But, take a good B.S. or Masters graduate from a good school, plunk him down just about anywhere in that project, and he can figure out and begin improving the code very quickly, with a deep understanding of how it relates to the larger project. (Understanding the business around it is probably harder.) The recent grad got a good 80% of everything they need to know to get started in a few intensive classes. The most common reaction of surprise I've heard from graduates who go this route is they're initial amazement of how many hoops they have to jump and how long it takes to move even small changes to the code into the production code base. It's that very deliberate process engineering that soaks up the development dollars of enterprise software.
In contrast, take an Office suite. (Please! :-)
Our recent graduate can, if he picked the right studies, know all about MVC toolkits, event loops, string algorithms, how spreadsheet engines work, etc. In that sense, he's fully qualified to sit down and write a new dialog box, etc. But, that's about all he's good for or will be for a long time. For example, ask him to design the API for a new method in some core class (let's say, some new functionality in a multi-media text object), based only on his learning, and then collect back the responses from everyone else about what's wrong with it. He'll make false assumptions about typography, UI edge cases, accessability, flow of control edge cases, abstraction barriers, natural language semantics, user interface guidelines, project-specific design pattern conventions, and on and on. After an additional few years our recent grad will have learned enough new stuff not to make such mistakes but, the point is: it's more complicated than most enterprise software.
It should make sense: enterprise software is harder to write, harder to test, etc. To make progress on an Office program you need nothing more than a single user workstation and a few hours. So, all of the additional liberty to make the code more baroque gets taken up... all software, enterprise and consumer, tends to become as complex as the circumstances of its creation permit.
Posted by: Tom Lord at December 13, 2007 01:27 PM
Post a comment
Thanks for signing in, . Now you can comment. (sign out)(If you haven't left a comment here before, you may need to be approved by the site owner before your comment will appear. Until then, it won't appear on the entry. Thanks for waiting.)
"Riveting" -San Francisco Chronicle
"Rewarding" -Financial Times
"Ominously prescient" -Kirkus Reviews
"Riveting stuff" -New York Post