The Simple Enterprise

The most memorable is a project I was on a few years back for a large, multinational corporation. There was one specific requested feature that the European business representatives demanded be included that I just did not see any value in including. I wasn’t alone as most of the representatives from the rest of the world thought the idea simply crazy. Since the first rollout was to be in Europe, the functionality was put into the initial release. When I left the company 18 months later, this vital, critical, utterly important feature, which took several months of developer time and several more months of analyst time, had not been used once since go-live. Given the schedule delays and cost overruns that plagued that project, I continually point to it as a project that could have done with a great deal less complexity.

Experiences like that project have taught me to value simplicity, even if it is difficult to achieve. That is why I have come to value articles like this one in TechCrunch from Box.net founder Aaron Levie. There are many great quotes in this article, so go read it all, but there are a couple which really struck home with me:

Isn’t that the truth? How many times have you heard someone quote, “You never get fired for buying IBM.” I’m not poking fun at big blue, but the sentiment is that the more complex an option you purchase, even if it is complete overkill for what you’re doing now, you give yourselves options for the future. While that might be true, what you’re really doing is saddling yourself now with a high cost structure that must be maintained for the life of the application.

The analysts Aaron was speaking of here were industry analysts, not business analysts, but sadly I’ve seen the same behavior out of both groups. We get this idea stuck in our heads that what our users really need is this one cool new feature we read about somewhere on the Internet that some startup is trying and we then shove that into our enterprise application where it is nothing more than an ugly wart on the side.

So true. Its easier in the short term just to capitulate to the solution someone brings you than to really sit back and dig through the problem to find a simpler solution to the problem. This may not be a bad thing, if the solution they bring is already simple and fits well into your application, but that’s not a common occurrence, in my experience.

There are a couple guidelines I like to use in my goal of building more simple enterprise applications:

First, think. No, I mean it, really think. Stop to do it even. Its a really easy trap to get caught up wanting to do everything for our stakeholders. My stakeholders generally love me because I bend over backwards to try and make them happy. However, new requests to add complexity or deal with rare edge conditions add a lot of complexity. There may be easier methods using existing functionality that, while they may take a few additional steps than what is ‘optimal’, may work just as well as they can be done now and not after the next release.

Second, aggregate. I don’t know about you, but it is a very rare day for me when I don’t get at least one new request for functionality from some part of the business. Most often the requests are nothing more than variations on a theme of something that already exists or something that has already been requested in a slightly different form. Don’t create a new request for whatever comes in, but add it to the existing requests that are similar. When it comes time to implement that set of requests, look at how you can accommodate as many of those as possible, but in such a way that keeps the user from needing to making ridiculous decisions.

Let me give you an example of this one… a particular application I once worked on had a few hundred different ways, when all the configuration options were used in combination, to simply find a price for an item. This was a nightmare for testing and making development changes, something that had plagued the development team for years. When we were tasked with finding a new solution to replace the existing enterprise application, I was determined to find a solution to this problem. I studied the existing user base and found there were really only 3 primary configurations used. It made sense to then focus our efforts on these 3 commonly used configurations, not the hundreds of potential combinations.

Third, return the investment. I’ve almost always had fantastic users and sponsors. They care about their business areas and want to see them succeed beyond anyone’s wildest expectations. Often times they are so caught up in their vision of what might be that they fail to see the price it would take to make their dreams come true. Anything, given enough time and money, can be automated, but not everything should be automated. If a user has a great idea for something that currently has an acceptable manual process because it only occurs once every few months, this probably isn’t a good candidate for automation, unless the downside of failing to do it correctly the first time is so large that your business would crumble. Always ask how much money and time does it take to do this now, how much of both would it take to do it in an automated fashion and what is the risk difference between the two alternatives.

Lastly, select or build an application which allows for changes to be made administratively. This does not mean toss in a bunch of parameters and allow users to set up whatever they want. It does mean build a logical method for allowing rapid change to occur within the business without the need for the IT group to pull all-night coding sessions. There are a few tools which will allow you to do this: workflow engines, business rule expression evaluation engines and addition/modification of user interface fields and layouts. None of these three items are trivial to build, but they provide a wealth of payback. Instead of spending time with each release tweaking report and screen layouts, along with their underlying database and coded logic constraints, you provide a framework for users to build their own logic and then support only the implementation of the framework.

So those are my ideas on how to make your applications simple. What other ideas do you guys have?