As the cost of Software Maintenance for legacy systems increase, can you turn these applications into innovation drivers? Understanding what you have is the first step.
For many companies the IT cost of maintaining existing applications, whether called Keep the Lights On (KTLO), Business as Usual (BAU), Operations and Maintenance (O&M) or simply Software Maintenance, is a significant part of the overall budget. In many cases this cost increases year over year until there is a tipping point, usually highlighted by the CFO, that is stifling the ability to use available budget to increase market share, quickly attend to customer needs or invest in new ideas that may come to business fruition in the next 2-3 years.
It now becomes a game of reclassifying the definition of changes to the existing systems; from maintenance to small enhancements to customer significant enhancements, and so on, to be able to mask the costs of keeping the existing systems running. For the CFO it becomes difficult to classify these maintenance costs versus new business affecting costs, removing the CFO’s ability to curtail costs that are not moving the business needle forward. Therefore, we continue with business as usual and keep the systems running as is, or with small to moderate degrees of change, often compliance driven.
Regardless, the inability to understand the existing applications in place, the code, the data lineage and the impact and areas affected by a change increases the chances of introducing an unintended consequence. This could be in the form of an existing feature no longer working, system crashes or a security breach. Many of these applications were not developed with more modern development techniques, do not have extensive automated testing in place, do not utilize a mature development operation cycle and do not provide a full understanding of the code itself; no documentation exists. These applications could have been built years ago, hurriedly created and moved to production. The loss of knowledge from the original developers and numerous other factors contribute to having these applications being classified as Legacy.
With this state of affairs in mind, it is in the best interest of IT to perform periodic and careful incremental changes to the existing systems. This perpetuates the case of requesting the CFO to increase the maintenance budget, year-over-year, to ensure the business remains stable. One can employ agile methods to perform small changes more frequently and then call this a transformation project, simply not the case. The fact remains, it is irresistible to incorporate significant customer affecting features and call them maintenance upgrades or small enhancements, all bundled into an increasing maintenance budget.
Shifting the Cycle
The key to shifting this BAU maintenance approach and the organization’s view of legacy systems as necessary budget consumption items into an innovation driver or new business enablement, is understanding what the old systems do and how they do it. What are the business objects, data ingestion and outputs, code level business flows, business rules, and the customer facing interactions? Identifying the understanding of the old system and marrying that understanding to the goals of strategic advancement begins the shift; the ability to identify the pieces, and only those pieces that need to change, to be a business mover.
Decoding the entire application set, placing modern continuous development, continuous regression testing and continuous deployment can be a significant cost burden and difficult to fully justify as a business mover expense. Frankly, not practical. Doing targeted, incremental, upgrades or replacement has proven to be an effective method forward.
The solution is pick out areas that are significant business movers and then understand the underlying application structures that support that business direction. How does the legacy system power this direction? For example, what if we need to power data driven applications from our existing business applications? What if we want customers to use our data on a subscription basis? What if we want to expand our services, place them on the cloud but need the customer database, access and authentication services from our existing applications?
To solve for such examples requires an understanding of existing business objects, the data structures, taxonomy/ontology, data lineage through the application, the input and outputs of the application and the impact of a change. Ideally, understanding the entire application would be useful, but it is more practical to take an agile approach to focus on specific business impacting areas, then expand.
Concentrating on these areas moves the existing applications to power new innovations to the business by creating APIs, code decoupling and moving to a cloud enablement/migration strategy and shifts the budget discussions from a Maintenance conversation to a Business affecting budget conversation; reconciling existing budget dollars - doing more with the same budget and moving away from the BAU Maintenance trap.
Shifting to Innovation
Moving an application, or parts of an application away from a maintenance and small enhancement action to a powerhouse for innovation is not easy.
The transparent knowledge of the system enables controlling the scope, cost and risk so the focus stays on changing those pieces needed for business innovation and controlling changes, so they do not affect/interrupt the rest of the system. Putting in place APIs and tying existing legacy application objects to newer services is readily apparent with the transparency of the existing applications, one agile step at a time. Utilizing the ability to clearly understand the legacy application shifts this legacy system into a powerful asset that drives innovation and new business. Solutions and services exist today which can quickly and easily provide the needed level of understanding and transparency for these old systems
In summary, cutting in new capabilities, tied to the existing applications, releases some of the burden of continual maintenance, provides the opportunity to perform substantial customer affecting changes and upgrades the team’s ability to rapidly adjust to new innovations without incurring excessive business risk. The legacy application now turns from an incremental improvement service to the bottom line into the powerhouse for new business capture, increased margins and innovation enablement. The conversation transforms into how we can understand more about the existing systems to increase our market capabilities to expand our customer interactions and new customer acquisition. This makes the CFO happier, empowers the CTO with a path to move forward and empowers the teams to think bigger for the customer.
About the Author
Gregg Fenton is an Executive Director focused on solution capabilities across HP Marin’s Data, Digital Transformation and Legacy Solution domains. Gregg is a Technology and Digital Transformation Leader with over 35 years’ experience in leadership and executive positions across multiple industries at companies such as JP Morgan Chase, Honeywell, Bloomberg, the New York Times, Ericsson, Sperry/Loral, and a startup Whitewater Mobile. Gregg is a thought Leader in the areas of digital transformation, data, analytic solutions, and product development. Gregg holds seven patents across mobile and multimedia messaging and is a member if the IEEE.