Is Enterprise Software an excuse for sloppy code?

By Greg Myers

If you follow the chatter on Twitter these days, there’s a newer hashtag flying around that is gaining in popularity, #EnSW, short for Enterprise Software. It helps people find other people discussing enterprise software and hopefully bringing like-minds together.

I’ve been thinking about enterprise software a lot these days. Mainly because its my job to help customers make sure they get everything they paid for with an investment in an enterprise software suite like SAP BusinessObjects Business Intelligence 4.0. I recommend how big the systems should be, help them build it, migrate their old content into it, and ultimately support and maintain it once that system becomes productive. BOBJ isn’t the only enterprise software I’ve maintained over the years. I’ve also worked with Microsoft SQL Sever, Hyperion Essbase (back when Hyperion still owned it), Oracle databases to some extent, and SAS, and various smaller non-SAP HRIS systems to name a few. And while most of these tools all have something to do with data and business analytics, they have something else in common, too. They’re all a bugger to work with from the implementation and administration side. So as this current conversation on Twitter continues to evolve and unfold, I started to wonder what enterprise software means to me.

I’ve been told several times over the years, when talking with various peers or even vendor support staff, that enterprise software is meant to be hard. That somehow, a massive implementation and support effort are etched into the phrase “Enterprise Software” somehow. I had a manager many years ago tell me jokingly “If this stuff was easy, we wouldn’t need you, Greg.”

But does Enterprise Software really need to be so complicated? Sure it needs to be complex in how it operates and robust in the features it provides. That’s really why we buy it, right? We need these large suites to run our companies. But does the fact that the feature set is large, internal operations are complex, make a valid excuse for sloppy integration, buggy code, and frustrating documentation? I know a lot of people think it does.

But I disagree.

If I had a dollar for every time I was told that a less-than-intuitive feature or workflow inside of an enterprise software application was okay, because it was documented that way, I’d be retired by now. Does documenting a kluge justify its existence in the first place?

Think for a moment, if we applied Steve Jobs’ design principles to enterprise software. Imagine if the code, and the integration of all of the various components that make up an enterprise software suite was sleek and clean in the user interface, but was equally as beautiful in how it worked under the hood. Imagine a suite where everything had a unified theme, that a feature or component was consistently named throughout the system. A place where error messages, if they ever did happen, made sense in plain language. Imagine a fast, clean installation process.

Part of the reason we have Enterprise Software the way it is is political. And I’d even go so far as to say the political factors are really two distinct problems.

First, companies that produce Enterprise Software tend to be large, and by the nature of being large, there exist ‘silos of power’. The software suite is too large to be developed by any one team, and the different teams tend to report to different managers, and even be in different geographic locations. Therefore, software is developed in independent silos with little or no communication between the silos until it is time for integration. By the time a project reaches integration, it is too late for major changes or even code reviews. It’s time to jam it together and make it work no matter how bad it looks. Put some lipstick on it and shove it out the door.

Second, companies that produce Enterprise Software are extremely reluctant to innovate on any type of grand scale. While they may put out something totally new, they continue to have to support years (sometimes decades) of legacy code to continue to pull along. There is often a huge reluctance to throw the old into the recycle bin and start over from scratch using newer, more viable technologies. Think about how bloated Microsoft Windows was over the years, until they finally seemed to ‘get it’ with Windows 7.

Another part of the reason we have Enterprise Software the way it is is our own fault. We buy it. Making a purchase of such code, in essence, condones it in the state it is in, which often is less than perfect. Tough stance, I understand. We often very much need the software we buy to run our business, and the choices aren’t always there to take a stand like this. But the fact remains. We buy it, so they keep making it.

I certainly realize that an enterprise software suite is not an iPad application. But what if it followed the same principles as one?

* Easy to download and install
* Simple, clean, beautiful user experience
* Consistent
* Easy to maintain
Doesn’t that sound like an enterprise software suite you’d like to use? It sure does to me.

The enterprise software market is in for some changes in the years ahead. As people who grew up using computers, and even now grew up using smart phones and tablets enter the workforce, and begin to take positions where they have purchase authority, the ‘rules’ about what is acceptable software are going to change. Just think about how we work has changed in the last 30 years. 30 years ago, in a typical corporate office setting, there were almost no computers at all. Maybe a few very large ones in a “Computer Room”. 30 years ago people laughed at Bill Gates when he said he thought there would be a computer in every home in America.

In order to compete, or even survive in the future, enterprise software vendors are going to have to be mindful of the changing quality and experience requirements of the upcoming consumer generation. (Some of us have these expectations already). Status Quo isn’t going to cut it.


Ref: http://evtechnologies.com/is-enterprise-software-an-excuse-for-sloppy-code/