Nicholas Carr writes,"When it comes to developing software today, innovation should be a last resort, not a first instinct." Excerpts with edits and my comments added:
Research by the Standish Group, a software research and consulting firm, illustrates the troubled fates of most big software initiatives. In 1994, researchers found, only 16 percent were completed on time, on budget and fulfilling the original specifications. Nearly a third were canceled outright, and the remainder fell short of their objectives. More than half of the cost overruns amounted to at least 50 percent of the original budget. Of the projects that went off schedule, almost half took more than twice as long as originally planned. A follow-up survey in 2003, however, showed that corporate software projects were doing better; researchers found that the percentage of successful projects had risen to 34 percent. Between 1994 and 2003 - The Internet boom went bust. Stung by wasted investments in complicated software systems, business executives began taking a more skeptical view of such projects. They scaled back their expectations, pursuing more modest software enhancements with narrower goals - and far higher chances of success.
Equally important, they stopped trying to be creative. Rather than try to customize their software, they began looking for cheaper, off-the-shelf programs that would get the job done with a minimum of fuss. When necessary, they changed their own procedures to fit the available software. Old, generic technology may not be glamorous, but it has an important advantage: it works.Mr. Carr also pints out to scrapped custom built initiatives in support of this viewpoint.
My Take:The key question that enterprises should think about before deciding to develop software rather than purchase it,is: Is our organization a software company? If you aren't a software company, think twice before assuming the ability to successfully develop and deploy a software project? ( Some exceptions could be like scale of operations, security concerns or an history like that of Walmart where there is a full fledged inhouse team)I feel that unless there is a overriding compulsive value, an enterprise should not work on developing custom applications in-house. The options for them are:
A.outsourcing from well established softwared development houses
B. Buy COTS application and adapt your processes to be aligned with the application. Focussing on core business would help enterprises to be better off. Enteprises need to be convinced, if software development is not core to them, it is highly unlikey that they can develop, deliver, deploy software on their own within reasonable measures on time, quality and cost. Most of the times,bean counters come in the way saying light custom apps serving needs of the dya would suit the enterprise rather than buying an extensible software pacakages. There is an issue here however - even so called fully evolved pacakge applications need armies of programmers to extend, configure, integrate their solutions - the COTS industry has to critically focus on simplifying this aspect of customisation and deployment and increasingly make this look non-technical.Typically a COTS package deployment should be like manning a cockpit in an aircraft where through parameter controls, one should be able to guide the direction, distance and speed factoring in all relevant issues - though this example may look a little far fetched - I firmly believe that this is what is needed to expedite the inevitable - embracing the COTS world in droves and significantly enhancing the returns on IT investments..
|
