How many times are we yet to experience when a “big bang” style of software implementation hits the rocks of hard reality of complex computer systems putting deadlines and/or quality at substantial risk?
In current enterprise environments where vast amounts of data can coexist in thousands of possible combinations, the impact of inherent complexity and possible low quality of data stored in systems have a teremendous impact on feasability of simplest of projects. Imagine an upgrade of a contact management application. Sounds simple, doesn’t it? Now consider a contact management application which manages every citizen’s personal details and reconsider upgrading it.
Factor in complexity and quality of your data is the first point I always make before implementation of any project of any scale in such environment. Quality and amount of data is the important factor in estimating any software implementation and every software implementation in enterprise environments. Even best managed data warehouse has quality problems proportional to the management process and simply the amount of information. Considering that factor is the point which is still being missed too frequently.
Second point to be made is: in a complex environment, the risks of big, single point (“big bang”) implementation too often considered as viable despite the fact that it’s unnecessarily risky. Instead of replacing computer systems with another at single date and time, what needs to be considered is a scenario where systems are being implemented gradually and ran in a side by side setup where different versions of software and data can coexist and produce results for clients simultaneously.
Most of the database systems, carry “start date”, “end date” date range as well as “version” field for each piece of data, which can be used accordingly. Software needs to be designed in a such a way that each version can run in each own sandbox. The advantage of enterprise setup where software and data versions coexist side by side is that as you roll out new releases of software and migrate the data, you can still continue running or falling back onto the previous software with previous functionality, being driven by previous sets of data, where required.
As data and clients are being switched and served by new system, you can test the implementation gradually, narrow and focus your testing scope, start providing services of upgrades systems sooner and minimise the risk of overruning deadlines because of a small percentage of corrupted data or minor functionality being compromised. You can deliver the functionality to fewer customers, but you can do that with the release one, have the quality tested sooner and at much lower risk.