29 November 2010

The Simple Enterprise

I'll admit, in my 9 years as a project team member, I've been guilty of this sin many times... I've added complexity needlessly to applications when it would have been much better if I had given my customers a simple, flexible process. Now, there have been many instances of this happening where I wasn't given much choice in the matter as my users and their management demanded it, but I wonder if I could have found a better solution that did not require a flotilla of developers to create and maintain.


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:
And while no one explicitly desires cumbersome technology, we keep buying it because we’ve built a strong correlation between the number of features a solution has and the likelihood it will solve our problem. That, and you won’t get fired. 
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.
This bias isn’t limited to technology buyers or builders – the analysts I speak with often focus more on feature comparisons and product matrices than end-user experience and customer success
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.
Building simple technology is not easy; it inherently takes much more work to reduce complex problems into simple solutions for people. Building products that suck is far easier
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.

My Solution

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?

4 comments:

  1. Sound principles. It's like the technical debt metaphor for analysis work. If you just keep investing in new features you build up a debt of system and business complexity that has to be unraveled in "transformation" program."

    A difficult challenge is for analysts and IT managers to take ownership of the problems. How many times is a perfectly obvious improvement not implemented because it has to wait for a 'business' sponsor?

    It may be someone else, but in most cases it has to be IT because they are the ones who manage the systems.

    ReplyDelete
  2. Ryan C10:18 pm

    Great read. Have just found this blog and I find it very thorough and thought provoking.

    Simplicity though I think is perhaps not the right word for what we want to strive for when developing. You want to make your applications "elegant."

    An elegant solution has beauty, sits well with its surrounding components and gives off only the impression of being simple. Elegance makes a complicated solution easy and appealing.

    ReplyDelete
  3. Thanks Ryan for joining us. Don't forget to share it around.

    I'm with you on elegance. There is something they teach in architecture school about the beauty and form of a building relying on it's context. That
    's a great concept to bring into the projects discussion.

    ReplyDelete
  4. Always nice to find people and ideas I agree with! I too have just found this blog, and glad I did...great post and comments.

    I once "skirted" an application/development group in the dept that had found itself supporting something like 71 separate instances of their app because they had gone the customize rather than configure route...what a little simplicity and elegance would have done for them! It even spawned a dept-wide "Configuration over customization" campaign! I was fortunate enough to be working with a sage-old developer who always provided administrative functionality in our applications; he was also called upon during the campaign to rescue a number of projects by implementing administrative modules in other apps. While "wearing the BA hat", my job was to keep the discussions focussed on analyzing the actual problems, to allow for the development of elegant solutions.

    Thanks for starting the conversation.

    ReplyDelete

Search This Blog