No Budget Left for CHANGE as RUN Costs are Too High?

This article focuses on the dilemma arising when the high costs involved in running legacy systems and applications eat up the bulk of IT budgets, leaving (too) little room for CHANGE projects. The article ends with our experience in this matter.

Leading IT analysts such as Gartner have indicated in many studies that RUN costs can represent as much as 60% to 70% of a CIO’s budget. While it appears that 30% to 40% of the CIO’s budget remains for CHANGE projects, this is not always available for business transformation projects as mandatory, regulatory-driven projects have priority. At the same time, the CIO is confronted more and more with the business requiring rapid “sprints” to support client-, value-driven changes while legacy IT applications – which lack agility – prefer to support a “marathon run” (cf. Gartner’s Bimodal IT).

So what can a CIO do when facing such budgetary dilemma? Options are:

1. Maintain status quo
2. Spread CHANGE projects over a multi-year budget
3. Convince the Executive Board that CHANGE leads to lower RUN costs and improve business agility
4. Take a policy decision to lower risk

Before zooming in on our experience in this matter, let’s briefly look into each of those 4 options:

1. Maintain the Status Quo

“Whatever you do, don’t call the fire brigade” can be a silent motto if and when:

• Legacy systems and applications keep on running smoothly and
• Skills to maintain these are abundantly available and
• The CIO prefers a short term horizon for whatever reason (merger, acquisition, job rotation, or end of career)

While RUN costs may increase, as well as the difficulty to manage hundreds of change requests related to back-end applications running on legacy systems, a lack of sense of urgency may lead to the CIO’s preference not to embark on a transformation project at this point in time.

This option will however be difficult to sustain as soon as:

• Problems – such as system outages – start to arise;
• Skills to maintain legacy systems start to evaporate;
• The vendor (re)increases license fees or support costs related to legacy systems;
• Or it becomes hard to recruit new software developers and provide in-house training

2. Spread CHANGE Projects Over a Multi-Year Budget

As a CHANGE project – such as an automated legacy migration project – can take 1 to 2 years to complete before RUN costs can be (drastically) lowered, the pay-back point may be reached in year 3 or 4.

As a result, such project generally requires multi-year budgeting and a value analysis/business case. While a time horizon beyond 3 years is not always obvious in publicly traded companies, it is more common in privately held businesses.

3. Convince the Executive Board that CHANGE Leads to Lower RUN Costs and Improve Business Agility

While option 2. is feasible from a financial perspective, there may be other reasons to convince the Executive Board that such multi-year budget is required, such as:

• The business is not agile anymore. The business environment is fast moving / disruptive but IT requires a lot of time to adapt legacy systems and applications;
• Certain business applications should be run in the Cloud;
• The know-how on how to quickly adapt legacy applications remains in the head of a few people who are over-worked;
• Junior staff may be less motivated to work with legacy technologies , requiring “employer branding” to overcome;

4. Take a Policy Decision to Lower Risk

When the “house is on fire”, it is necessary to call the fire brigade meaning that pure financial and human resource motives are insufficient. This is the case when:

• Vendor support is discontinued and internal policies forbid the use of unsupported technology;
• Legacy systems and/or applications are becoming hard to maintain and test so changes become a burden;
• Skills did evaporate while outsourcing legacy system operations is no longer a good option;
• Regulators (e.g. for retail banks) have warned that system outage triggers hefty fines;
• (last but not least) the company’s and CIO’s reputation is at stake;

In such case, a policy decision to lower risk on the so-called “IT debt” is (over)due.

In many cases, it is wise for the CIO to involve the Executive Board with respect to the planning and value analysis of a (large) transformation project – such as a mainframe re-hosting project – as such project does require the top leadership to stick out their neck as a team and support the CIO with multi-year budgeting, a policy decision, and/or change management.

While short term financial gains may not always be feasible for the business, the decision to embark on such a transformation project – if well-implemented – will benefit the business both financially (through lower costs) and commercially (through more agility) while lowering IT-related risks going forward.

If the company is willing to share relevant costing data with us, Anubex can help to run such value analysis with a goal to underpin decision-making.

So looking at the above options, what is our experience in this matter?

1. Unsupported technologies: In regulated industries such as banking, a policy decision is generally taken not to run applications which embed unsupported technologies. For example, when Microsoft halted maintenance on its VB6 line of development tools, many of our customers did take a policy decision to convert applications to VB.NET;
   
2. Lack of knowledge: The same is true for large organizations where the knowledge of legacy technologies remains in the heads of a few “baby boomers” nearing retirement. One of our customers, for example, took a decision to eliminate IDMS within their organization as only one of their staff, aged 65, had expert knowledge on this pre-relational database technology;
   
3. Need to recruit junior developers: As certain procedural programming languages – such as COBOL – are no longer taught in higher education programs, many of our customers did take a policy decision to program in object-oriented languages – such as Java or C#.NET - with an eye to attract more entry-level recruits;
   
4. License fee increases: When an organization faces sudden or hefty license fee increases on legacy technologies, our experience shows management typically will take action to limit or reduce the internal use of this technology. As the business may see no short term benefit from eliminating legacy technology, the decision to embark on such transformation project requires a multi-year budget and – in most cases – a human resources plan to re-train software developers. For example, a number of our customers made the decision to phase out Adabas - Natural over a multi-year period after the vendor increased license fees. During this period the company invested in the retraining of these developers;
   
5. Run costs to be lowered: When the CIO realizes that – for instance - a mainframe and related legacy software technologies absorb a high chunk of the RUN costs while certain applications can be hosted on lower cost platforms (such as Linux or Windows), the CIO may discuss with the Executive Board about a transformation and/or re-hosting project. As such a project does not only require a business case but also a vision on how business applications can evolve faster and cheaper on modern technologies, both financial and strategic aspects will be involved in the decision to embark on such transformation;
   
6. Business functionality to evolve faster: While small business applications can be re-written or replaced by an off-the-shelf package, this is not always feasible for large, critical applications. In case the presence of legacy technologies hinders rapid functional changes by a limited number of software developers, the CIO will again trigger a debate with the Executive Board about when to embark on such transformation project. Our experience shows that such project does requires a business and technology vision – next to a business case and change management - before the Board will support the transformation decision and allocate the multi-year budget.
   

Luckily, in more than 30 years of experience in legacy migration projects, Astadia did come across many CIO’s who had the vision and guts to put such transformation project on the leadership table. As we understand that this can be the start of a “pilgrimage”, we always stand ready to support the CIO and his/her team with respect to technology choices, value analysis and change management. Our experience also shows that CIOs appreciate that we are able to:

• Provide a fixed price turn-key proposal for the core migration project (after a pre-study), and

• Provide the option to involve a local or global partner. Astadia partners with all of the leading cloud providers and system integrators to help assist clients migrating legacy applications & data to the cloud.

‍