SmoothSpan Blog

I recently responded to the free-for-all Robert Scoble started on unfriendly Enterprise Software.  Now George Ou writes about IT’s perspective, and had this to say:

• Enterprise software generally has lower usability and more bugs than commercial software.  That’s sort of counter intuitive to the word “enterprise” but the name is a joke in IT circles since enterprise software is typically painful.
• Enterprise software is designed for and sold to IT departments so the expectation is that you have trained people supporting the software whereas commercial off-the-shelf software has to more or less be self explanatory.  Enterprise isn’t sold to the end user and the end user doesn’t sign the check so their considerations are secondary to enterprise software makers.
• Enterprise software requires a lot more interaction between multiple systems which makes it fundamentally more complex to develop, deploy, and support.
• Enterprise software also typically addresses a much smaller user base than off-the-shelf software like Microsoft Office so the development budget to user ratio is smaller.  This means programming shortcuts like Java are often taken which makes the software horrendously bloated and inefficient.  You’re not going to see enterprise software developed in light-weight C++ like MS Office any time soon because that level of skill is too rare and difficult and expensive to acquire.

George sure sounds like an IT guy to me, and a card carrying member of the Old School.  That’s not necessarily a good thing, I’m afraid.  He’s written a doozy filled with misperceptions and I had to respond point by point to clear some of the fog away: 

• Enterprise software generally has lower usability and more bugs than commercial software.  That’s sort of counter intuitive to the word “enterprise” but the name is a joke in IT circles since enterprise software is typically painful.

I presume George is trying to compare Enteprise Software to packaged software like MS Office (which he refers to in another bullet), but he really doesn’t say.  Having been on both sides of the fence (I built Quattro Pro for Borland and have done several Enterprise gigs), I don’t see any reason to agree with George’s broad brush statement.  I found the recent release of MS Office 2007 to be surprisingly buggy, very unfriendly to someone that already new the prior version, and Vista is not exactly setting new standards for quality or end user satisfaction.  OTOH, Vista was designed primarily to appeal to what Old School IT cares about, so maybe that makes up for it with people like George.

• Enterprise software is designed for and sold to IT departments so the expectation is that you have trained people supporting the software whereas commercial off-the-shelf software has to more or less be self explanatory.  Enterprise isn’t sold to the end user and the end user doesn’t sign the check so their considerations are secondary to enterprise software makers.

George, you could not be more wrong in my experience.  I’ve sold multi-million dollar Enterprise Software to a variety of Global 2000 companies.  In the majority cases (nut not all), we found that the business users were completely driving the need to purchase, not IT.  In terms of training, yes there was some, but a part of every sales cycle was sitting the likely trainee down at the keyboard without said training and trying to see whether they could get comfortable enough to endorse purchasing the package.  This doesn’t even consider the raft of Enterprise Products that people use without training such as Expense Report software or HR Focal Review software.  Very few of our seats sold were occupied by trained users.   There were certainly a few guru admins that needed the training, but the majority had to be able to walk up and use the software unaided.  In the case of my last company, this included salespeople who wouldn’t sit still for a lot of training anyway.

There is no end of categories for Enterprise Software that require usage with minimal training.  I think the real problem is that IT is often very isolated from the user expderience.  Their focused on tasks like Database Administration of the newly installed Enterprise Software and often have little idea what their end users are going through except by anecdote.  This doesn’t have to be the case, and shouldn’t be the case if IT will be supporting the software, my only observation is that it often is the case in many real organizations I’ve dealt with.  Further, IT often doesn’t really understand the business needs or requirements.  I have frequently had business users come to me very concerned that IT is solely focused on their own needs (which have to do with minimizing the package’s impact on their IT organization) and wanting to make sure the Business side is heard.  When I hear IT folks like George say things like, “Enterprise isn’t sold to the end user and the end user doesn’t sign the check so their considerations are secondary to enterprise software makers,”  I really begin to feel these user’s pain.

• Enterprise software requires a lot more interaction between multiple systems which makes it fundamentally more complex to develop, deploy, and support.

This is true, but it’s an IT consideration that has little to do with end user friendliness or with whether the code is “bloatware”.  If the latter is a problem, it’s usually because IT has a bunch of poorly maintained Legacy systems that are hard to integrate with.  Whatever the case, this is very much secondary to the discussion.

• Enterprise software also typically addresses a much smaller user base than off-the-shelf software like Microsoft Office so the development budget to user ratio is smaller.  This means programming shortcuts like Java are often taken which makes the software horrendously bloated and inefficient.  You’re not going to see enterprise software developed in light-weight C++ like MS Office any time soon because that level of skill is too rare and difficult and expensive to acquire.

This is some very bad Old School thinking, and many comments on George’s column call him to task over it.  I’ve got several reactions.  First the obvious one for anyone who actually develops software:  the myth that C++ is lightweight and fast compared to Java was laid to rest a LONG time ago.  George may be technical, but this reflects a profound lack of understanding of the tools involved.  Moreover, it makes no sense to think that “programming shortcuts” lead to bloat.  If we’re building software with less budget (this is another myth I’ll get to), less people, and less time, who had the time to write the bloat? 

These interpreted languages lead to less code, not more.  In fact, it’s tempting to advocate ditching Java for many projects and moving even further towards the scripting language world.  George’s views on this raise one important commercial issue in doing so:  IT won’t necessarily understand what it means and may think less of the software if it is written in PHP or Ruby On Rails.  They’d be wrong for the most part, but it could factor into sales. 

As regards smaller development budgets, I have two reactions.  First, SAP and similar companies spend as much developing their modules as Microsoft does building MS Office.  Second, having these huge teams and spending so much is the wrong way to build great software no matter what area you’re focused on.  I’ve talked before about the virtues of small teams.  They can make a huge difference in the final software and in the overall productivity of the team.

It’s been fun to get all this off my chest.  There are some classic old chestnuts of IT thinking here, evidently still doing harm in various ways.  What this really brings home to me is that the SaaS model is fundamentally better in the face of these kinds of attitudes.  Rather than try to fight through these entrenched viewpoints, SaaS sidesteps most of it entirely.  The Business does make the decision on SaaS software in most of the cases.  They do so with minimal IT intervention.  Evaluation cycles are shorter as a result, and a lot of practical IT interests just don’t matter.  The details of the care and feeding of the software, for example, go away.  IT is often very concerned about platforms because they have to live with the care and feeding issues and their people are trained on particular platforms.  With SaaS, IT is not responsible for care and feeding, so it need not concern itself. 

Lastly, the SaaS vendor is on the hook month-by-month for keeping the customer happy.  This is probably the most important part of the whole equation.  SaaS is just a better way to do business with you software vendor.