on Jan 25th, 2007Enterprise Software Maintainence - steps to reduce maintanence costs
Interesting article I came across in Sadagopans blog, about software expenditure. Google’s GM for enterprise applications says that almost 75 to 80% of software expenditure by CIO’s are used up in maintaining the systems that they have. Enterprise products sell at high costs, the money usually is for customising existing SOA’s to fit business models, probably migration from other mainstream products and last but not the least maintainence and service.
Products cannot be foolproof but users can, that is the motto that maintainence projects live by. There is no doubt that products are sturdy and well tested, but the lack of technical know how amongst the people who use these products or technologies always leads so called assumptions. Take for example searching for and inventory, an employee figures out if he can do a search on one of the screens then he sees information, the same is passed as knowledge to the other people in the team. Problem, the screen was never meant for that, no this creates new holes and inadequacies in the product. The result, incosistent data , unstable system state and yes since these from base systems for MI applications, all reports will have perculated wrong values. In an enterprise software chain, where one product feeds of another and so on, the affected modules could be plenty, and lot of rework would be required to get the system back to its inital state. This where the maintainence team cashes in, coming in as disaster recovery experts , they set right almost every issue raised by the enterprise. This ofcourse, comes at a really big price.
So how do we control such expenses and leaks? Well one solution would definitely be to train employees and possible people who affect the system is susceptible to such errors. But it doesn’t end there. Products themselves should build auto correction mechanisms and sense incosistencies based on data patterns, for example you cannot sell 5 inventory when you have 2 left, if so, then something is wrong and you invalidate the transaction or correct the mistake automatically.
One of the most important factors is the failure to communicate the vision or future plans. Typically software is developed or customised based on Business needs, the products should be designed with change as an essential component and the most important point is to communicate to them the proposed visons, by doing so you give the software vendoer food for thought and they will try and make the system easy to accept the predicted change.
Hope all this didn’t fly over people heads…….