Solution Partner Views
Insurance IT Transformations: Paying the Technical Debt Piper
Let`s start with one of the key business questions in this new millennium: How do companies maintain their competitive edge in an era of technology hyper drive? That`s a difficult question to answer, but the key lies in this notion of “technical debt,” That debt can be thought of as the amount of accumulated software assets that have gone without re-factoring for many years or even decades.
A major consequence of this is the cost in time, effort, resources, and expenses required in maintaining it all. The more “technical debt” a company has accumulated, the more difficult it can be for that company to regain its competitive footing. A large amount of technical debt also increases the business risk for a company, by increasing the complexity of their technology layers, and therefore their ability to maintain and keep it all in good working order.
The analogy here is organizations make poor short-term tradeoffs without considering the long-term consequences, they keep accumulating technical debt. If this “debt” is not paid off periodically by way of meaningful re-factoring to address the shortcuts, the accumulated “debt” jeopardizes the competitive edge of the organization.
The standard response of most companies when they realize they have accumulated a lot of technical debt is to embark on large scale transformation or replacement initiatives. These efforts are usually fraught with big challenges like complex coordination, mobilizing skilled teams, and proper change management, to name but a few.
And amplifying all of this is that any business technology transformation has to be done while the outside world—customers, agents, other stakeholders—continue to progress in expectations and capabilities. It is now practically impossible to be immune to technology and process obsolescence due to the ever shorter cycles of technology turnovers. Moore`s law on steroids, if you will.
To illustrate this, the cycle of simple batch-oriented systems lasted decades, and that was followed by more decades of monolithic mainframe-based platforms. These are being replaced by the rapid spread of networks and personal computing, which are being followed by public networks and smart devices.
The desire for instantaneous responses by customers/consumers has resulted in transactional systems that morphed into self-service systems delivered through the Internet. The expectation of systems nowadays is anywhere/anytime. In turn, these systems have become highly connected and interdependent to satisfy these complex transactions. This trend doesn't seem to be slowing but accelerating.
What can companies do in this type of technology hyper drive? Do they simply ignore these trends at their own peril? What do the experiences of Kodak, Blockbuster, Borders, Blackberry and countless others teach us? One of the clear lessons is that it doesn't take a long time for entire industries to be disrupted. Nobody can claim to have a crystal ball to predict the next disruption heading their way.
Given all of this, is there a way for companies to reduce the risk with this cycle of "debt accumulation" and “risky transformations"? Companies, especially those whose core business is not technology, can start by rethinking how their knowledge workers are utilized. A greater emphasis on providing freedom and empowerment for innovation comes to mind, and is often a good place to start. What does this mean exactly? It means that companies have to create the kinds of environments—culturally and physically—that allow for freedom of experimentation and encourage innovation and continuous improvements.
A company well known for creating this culture, after several missteps, is Amazon. It went from selling books, to selling all sorts of goods, to the biggest cloud infrastructure company in the world. The genesis for their cloud services is rooted in offering programmatic access to their product catalog to the developer community.
According to Amazon CTO Werner Vogels, this success led them to consider offering system software building blocks as a service. The rest is history, and it`s a history the insurance industry could learn something from.
Amazon`s approach was based upon incremental but continuous improvement of their core software systems. Most insurers use the opposite model, installing and utilizing software for years without ever making more than maintenance-type improvements to it. That leads to the big bang transformation conundrum the industry finds itself in.
Another good example of this is how Canon entered the low-end photo copier market in the 1970s to eventually displace Xerox through continuous mini-transformations and innovation. This concept is not just limited to the technology field. A recent Harvard Business Review article discusses the disaster at JC Penny when its new CEO tried a big bang overhaul of the business model in its retail stores. The result is a steep decline in sales.
Would it have made sense to experiment the concept at select stores before companywide implementation? This mistake cost the CEO his job; a true “you-bet-your-career” decision. A strong and sustained commitment is required by companies to make this an integral part of their technology portfolio.
That commitment has not been present in the insurance industry to date, but there are some signs that the new sophistication in core systems, combined with the resource investments required to implement them, is starting to turn some heads toward avoiding big transformations altogether in the future.
For the insurance industry, along with many other non-technology companies, rethinking the way their technology departments operate to drive continuous mini-transformations with creative and innovative improvements is long overdue.
While big IT systems rewrite or replacement may be unavoidable when it comes to systems that haven`t been re-factored for decades, it is prudent for companies to take measures to avoid this situation in the first place, and the implementation of new core system is a good place to start. Going forward, this can be achieved by instituting a culture of periodic mini-transformations of systems to pay down “accumulated debt.”
If the systems are too big and monolithic, they can be targeted by partitioning the systems into manageable chunks. Whatever the approach, insurers need to seriously and thoughtfully consider this question as they work their way through core systems transformation projects.
Will my technology future be burdened with accumulated technical debt, or will it be debt free? The answer to that question will have implications for the future profitability of any insurance company.
Sreedhar Alavalapati is a consultant at X by 2, an enterprise architecture and transformational initiatives consultancy. He has over 30 years of extensive experience managing software development projects.