A Forensic Approach to Information Systems Development: Part II - Ways to Fix the Problem

In the first of this two-part Executive Update series,1 I took a swipe at the currently accepted approach to systems development. My argument was that if a system is to adequately support a business, the information it handles must be rigorously derived from the business itself. By producing a process model, then an information model, then a data model, and then handing it all over to an implementation team, we can end up somewhat removed from the reality of the business. The people responsible for each of these steps in the chain usually don’t have a good understanding of each other’s specialities, and the result can be “Chinese whispers.” I also noted there are a number of legacy systems out there that are decades old and attempts to replace them with modern technology have failed. The fact that the old systems are so useful is perhaps more of a mystery than the fact that today’s technology seems to offer nothing to beat them. Another trait of the these old systems that have stood the test of time is that they (mostly) seem to have been developed inhouse, in the days before there was a specialist IT function in the business. This is even stranger. How can a system that’s 20 to 30 years old and developed by a bunch of enthusiastic amateurs outperform the latest technology, designed and developed by highly specialized information technologists and business analysts?