Two radically different approaches to enterprise application software

Nothing stays still for long in this business. Every day (or so it seems) there is some new technological innovation that changes the business environment. Competitive forces move and shape-shift all the time. To keep up, you develop/deploy your own technologies that in turn may change the business environment in which you operate. Around and around the cycles of change we go...

The obvious way to handle such a changing business environment is to treat it like driving a car in traffic. The only viable model is to keep up with the flow, run with it, get into lock-step with the hoard that are all traveling as fast as you are ... The alternative is to get run over. This has a pleasing finality to it, and goodness knows there will be times when you wish you could just engage the handbrake but...

The software world feels like driving in traffic most of the time. Application environments change so rapidly, it is very difficult to keep up. If only it were viable to engage the handbrake...

Recently, two radically alternative approaches to dealing with the volatility of enterprise application environments have passed through my head. One is only slightly radical and the other is, well, very radical. I will ease you into this alternative world by talking about the only slightly radical solution first.

Consider the business of selling some sort of office equipment. The details do not matter much for my purposes here. What is your business model? Well, it is quite likely that it is one of the standard ones for selling office equipment. Consider now what happens when you look for business software - CRM for example - to support your business. Darn it! You find that some off-the-shelf solution is nearly-but-not-quite exactly what you want. What to do? Well, generally speaking, in these situations folks employ folks to customize the off-the-shelf application to suit the business needs. A time honored and very honorable tradition.

Here is the radical alternative: you could consider changing your business to fit the application rather than changing the application to fit your business. Crazy? Not necessarily. I know of a number of companies who have tailored their business specifically to meet the capabilities of two well-known CRM systems for example. Both companies have chosen to differentiate themselves in areas that do not involve technology. They both have rules of thumb which state that they only ever use hardware or software gadgetry in off-the-shelf configurations. If some square peg needs to fit a round hole they look to change the business before they look at changing the applications/gadgets. It is not as crazy as it sounds at first.

Now that was just the warm up. I want to turn to the really radical alternative approach. Consider again, the business of selling some sort of office equipment. You decide you need an application specifically developed that supports your business. Your applications people outline a development plan. Flexibility is crucial. After all, who knows what the business is going to look like in 18 months time? You need to ensure that you can alter data entry screens, create new queries, modify workflows, generate new reports and so on. All that flexibility dramatically increases the engineering effort involved in building the application. Flexibility in the face of change comes at a high cost. Take bridge building as an analogy. It is as if instead of building a bridge you now need to build a toolkit for building unknown and unknowable bridges in the future. A big task at an engineering level.

And the radical alternative is? So your business will be radically different in 18 months time? Fine. Just build your application as quickly as you can to meet the needs of your business today and today only. Throw the application away in 18 months time if necessary and just build a new one. Maybe it will be cheaper to re-write the application every 18 months than try to develop a single application that can cope with all conceivable changes in the future.

Is this crazy? I don't think so. At least not always. In fact, it has helped me to understand something that has always puzzled me. Namely, the unreasonable effectiveness of extremely shoddy engineering practices in the modern software business. If what is being developed will be thrown away in 18 months time; if you never need to worry about supporting version 2.0 because version 2.0 will be a completely new application; a whole new engineering dynamic applies.

Suddenly, a lot of things I see happening out there in the industry make sense to me.

I find myself relieved and horrified in equal measure.