In the last week or so, a ton of industry commentators have been yammering about enterprise software's sexiness, cool factor, and so on. George Ou's post about enterprise software is pretty insightful (which doesn't surprise me because we've talked about this topic a zillion times). One area that I don't think he spends enough time discussing is that enterprise software and desktop/consumer/Web software tend to address wholly different needs.
A hallmark of enterprise software is integration and interfaces with other systems. In fact, I would say that enterprise software is simply a system that consumes and/or exposes integration hooks and programmatic interfaces, while adding some custom workflow and business logic of its own along the way. I can interpret many systems through this lens, from SAP to Exchange. Traditional desktop/productivity applications and consumer applications just do not fit this description; they are about communication, content creation, and content consumption. Web applications and dynamic Web sites are overwhelmingly about content consumption and are increasingly becoming "enterprise-y" on the backend.
This is why enterprise software costs so much and takes so long to install and configure. Popping the CD in and hitting "Next" is the least of the concerns. The headache begins when you need to get the system "talking" to everything else. To make matters worse, no vendor can predict or test every possible combination of OSs, other systems, hardware, and so on. The interface between Widget 5.0 on Solaris and Foobar 8.2 on Windows may work great, but who knows what will happen when Widget 5.0 gets updated to 5.1, and a dinky field in the XML schemas suddenly disallows the NULL characters that Foobar 8.2 used to send? Or what if Foobar 8.2 on Windows insists that the data that it receives from Widget 5.0 use the Windows newline character combination, and Widget 5.0 on Solaris won't send it?
In enterprise software, what the user touches is a very small fraction of the data, workflow, or decision-making process. In comparison to other applications, the user has little insight into what is happening "under the hood" when they use an enterprise application. The transparency that desktop application users value ("that happened because I clicked the button") is flipped around ("I clicked the button and magic happened").
This is why enterprise applications tend to have such miserable interfaces that look like a dinky Access form with a toolbar slapped full of buttons that make little sense. It is grocery store functionality — everything you can possibility imagine under one roof, mostly grouped in some fashion but without much logic in the group. In a way, it makes sense. If the usage of the software could be more linear, chances are, the system would not need the user in the first place. The user interface handles the relatively rare (measured by number of bytes handled) instances where human intervention is needed. The rest of the data manipulation happens automatically.
Another hallmark of enterprise software is that it is always on. Even when you are not working, it is working. In the "Mad Max" future, SAP, PeopleSoft, and Exchange systems will still be swapping packets, while the rest of our civilization is a smoking crater. These systems are the cockroaches of code. Look at those old COBOL mainframe applications; they are the template from which all enterprise systems are designed after. They will not (and probably cannot) ever die. They keep mutating in the environment, but the internals will remain mostly unchanged for decades.
These systems provide great opportunity for employment and profits for programmers — someone needs to keep them running and make changes. Moreover, hooking them up is big business. It is a poorly hidden fact that integration costs often far outstrip the original price of the software. Imagine paying someone $1,000 to spend three weeks hooking up an inkjet printer, and you get an idea of the situation as it stands. I would never recommend extorting a customer to keep an aging system running or deliberately designing a system to sell cheap and integrate pricey. Nevertheless, this is a fact of our business: If you are interested in $150/hour to $300/hour consulting fees, learn to integrate one of these contraptions because these systems are only good for integrating to other systems. What the user touches is ignored, and the developers working on these applications would prefer that users never touch them.
I think it is a shame that the users are the ones who suffer for this, and it is business owners and stockowners who foot the bill. Until businesses end their reliance on the data processing mindset (fat chance), the world of enterprise computing will remain the same in spirit. The platform might shift a bit — for instance, maybe Web 2.0 will get some mindshare, and mainframes like AS/400s will lose a bit of market share — but "it is what it is."
Justin James is the Lead Architect for Conigent.