|
|
CTO ArticlesIT World The application configuration conundrumBy Sean Mc Grath Where does all the money go when you install a line-of-business software application? Obviously there is the cost of the software product and perhaps the other software and hardware pieces required to make it function. There is the ongoing cost of system management and perhaps there are training costs for staff. What else is there? In an ideal world, that should be just about it. However, as we all know, unless the product is very simple or very commoditized, or both, there is one big outstanding cost. I speak of the potentially long and potentially costly exercise known as "configuration". Application configuration cost is something an Einstein-like thinker should take a close look at. Just as the speed of light is constant no matter what, it appears that application configuration costs (at least in terms of elapsed time) are constant no matter what. In particular, the time taken to configure an application appears to be independent of how much money you spent on it. Let me try and express that in more concrete terms. Imagine that two identical twins set off in opposite directions to run identical business ventures. The first twin installs a set of open source components to make up the required software application. The software cost is zero or so close to zero that it is zero for all practical purposes. It then takes two months (at X dollars a day) to configure the software to the needs of the business. The second twin installs a group of best of breed, commercial applications. The capital cost is significant. It then takes two months (at Y dollars a day) to configure the software to the needs of the business. Odd, don't you think? Then there is the nature of application configuration itself. An endlessly fascinating and eclectic activity! At one end of the spectrum we have configuration by modifying a few parameter files. At the other end of the spectrum we have fully blown custom programming to effect the required configuration. When does configuration stop and custom application development start? Perhaps it is my imagination but I get the impression that as applications get more and more flexible and complex and abstract, the need for configuration is growing apace. So much so, that I have seen examples where the distinction between "product" and "collection of more or less re-usable bits and bobs plus a Java/c# compiler" blurs significantly. Furthermore, the growing use of powerful scripting technologies like Javascript, Python, Tcl and so on make it possible to do at configuration time, effectively anything you could do back in the development shop. You can change the behavior of the very guts of the application, on site in an, um, 'configuration file'. Actually, I'm all in favor of this latter form of configuration - as long as the configuration consists of manipulating well defined core components in the application. Unfortunately, as I have written before in this column, we as an industry suffer greatly from the lack of a workable concept of a 'component'. Some day, we will get there. For now, let's just be charitable and say that application configuration is necessarily a mixed bag of techniques. The not-insignificant cost of tailoring a set of applications to a business has resulted in an interesting phenomenon in recent times. Namely, some entrepreneurs have found it easier to build their business models around the default capabilities of a line-of-business application rather than go through the time and cost of tailoring the application to their business model. I came across two examples recently. One was a five person company of road-warriors selling office equipment who set themselves up to directly reflect the model built into their off-the-shelf contact management system. The second was a much larger enterprise that found it easier to change their model to suit the needs of an ERP system rather than have the ERP system configured. Configure your business to the needs of the software. Now there's an idea! |