Tell me if you’ve heard this one before: “This is the year of legacy system replacement in the industry.” Ok, old news. But we are finally getting realistic appraisals of why some legacy technologies persist, and the reasons may be more analog and carbon-based than digital and silicon-based.
Since the 1990s, pundits have been predicting the imminent demise of legacy technology. Some even wrote eulogies. Consider this explanation (written by the History of Computing Foundation in 2002) for why the Y2K bug was such a non-event: “most legacy systems were replaced due to the normal update cycle before the year 2000, were (sic) the millennium bug was treated as a routine check in the new systems.”
The reality is that within most organizations with any history, there are technologies that qualify as ‘legacies’ of a previous era. The problem with legacy systems in insurance is that they are like that TV bunny … They keep going and going and going with little effort (which is not to say grumbling) on the part of the users or, more importantly, the users’ managers.
Robert Regis Hyle postulates in a recent article in PropertyCasualty360 that “Making changes in your core systems is often the defining moment in the career of a CIO. As much as they hate the legacy systems they inherited from their predecessors, IT leaders have to feel a grudging admiration for the dependability of those old systems.”
In other words, the CIO is facing a possibly that her/his legacy in the organization will be that of replacing a system that works with one that does not. So is it fear and insecurity that prevents change? Probably so, but it might also be the lack of support for risk taking that comes into play.
Karen Furtado, of SMA, Strategy Meets Action, wrote recently “SMA observes that frequently companies approach technology updates with their eye focused more on the limitations they want to free themselves from, rather than the possibilities that could transform their businesses.” That’s fine if the business only needs incremental change. However, if a fundamental change is required, the incremental approach might only mask, and possibly even compound the problems.
We believe Furtado’s recommendation is correct here: “The critical link between the strategy and the technology, the definition of functional business capabilities, needs to be shaped and guided by the business strategy.” If the strategy is to build incrementally, perhaps incremental change is sufficient. But if an organization is looking at transformational change, then the risk/reward calculus needs to be calibrated to adequately support the decisions on the legacies; those of the organization’s systems and those of the people making the decisions.
