Navigating the Complexities of Software Modernisation: Insights from Leading CTOs

Prefer listening over reading? Press play and enjoy

Navigating the Complexities of Software Modernisation: Insights from Leading CTOs

According to a report by Deloitte, the cost of technical debt in the United States alone was estimated at $1.5 trillion in 2022. Despite this staggering figure, many companies struggle to allocate sufficient budgets to effectively address these issues.

Last week, the London CTO's roundtable, titled "Software Modernisation and Digital Transformation: Tales from the CTO Trenches," provided a timely examination of these critical topics. Steve Lydford from Codurance presided over a panel of experienced CTOs, including Codurance's Co-founder Mash Badar. The event offered valuable insights, lessons learned, frank conversations, and numerous tips on modernising software estates.

The discussion points from the roundtable, while perhaps only skimming the surface, are nonetheless worth sharing:

Key Takeaways from the CTO Roundtable

  1. Career Pathways of CTOs: CTOs typically start their careers as engineers and are often engaged in software modernisation exercises. They are keen to share their experiences to support colleagues across various companies and sectors.

  2. Triggers for Modernisation: Several triggers can prompt a modernisation exercise, some more clear-cut than others. Examples include:
    • Outdated Tech Stack: Time to market slows due to an outdated tech stack, unsupported tooling, difficult production issues, or dissatisfied engineers.
    • Leadership Changes: New leadership or the necessity to prove value, which may or may not align with business drivers.
    • Familiarity with Technology: Moving to a technology that decision-makers are familiar with.

  3. CI/CD Considerations: Not all services need to be Continuous Integration/Continuous Deployment (CI/CD). The applicability of CI/CD can vary depending on the specific application, which was a topic of debate during the roundtable.

  4. Risks of Complete Rebuilds: Undertaking a complete rebuild, as opposed to modernisation, can risk a company’s market position if it means customers will not receive new features for an extended period.

  5. Product Roadmaps: A well-defined product roadmap can be a significant driver for modernisation initiatives.

  6. Modernisation vs. Rebuilds: Unlike modernisation, which delivers value at every stage, a rebuild cannot be paused easily and may tie up resources and management for a considerable length of time.

  7. Monoliths: Monolithic systems do not always require modernisation. Often, 80% of the functionality in existing systems works well. A complete rewrite, unless significant changes are planned, may result in a lot of effort spent re-implementing the same functionality in a new language.

  8. Strangler Fig Approach: A practical application of the ‘strangler fig’ approach is to allow the team to "do whatever you like as long as you can go to production each month."

  9. Value-Driven Modernisation: When modernising, it is crucial to reach value early and pause the project whenever necessary to reassess and ensure continued alignment with business goals.

  10. Leadership Buy-in: Leadership buy-in for modernisation can fall into two categories:
    • Inside-out: Leaders with the technical capacity and business context to understand the value immediately.
    • Outside-in: CTOs must justify the value of modernisation to other leadership members because the existing solution is generating revenue. This highlights the importance of the CTO aligning closely with the CFO and CEO.

  11. Cost Reduction vs. Value Creation: The cost reduction impact of a modernisation project can be easier for a CTO to communicate to the board than the creation of new value.

  12. Re-writes as Failures: A complete rewrite is often seen as a failure, emphasising the importance of incremental modernisation.

  13. Developer Satisfaction and Business Alignment: Aligning developers' sources of satisfaction with what truly matters to the business is crucial for successful modernisation.

  14. Tech Debt as a Feature: Encouraging product teams to treat technical debt as a feature can help integrate modernisation into regular development workflows.

  15. Continuous Modernisation: A continuous process of modernisation helps avoid stressing the ‘design stamina’ of the solution, ensuring long-term sustainability and adaptability.

These points reflect a comprehensive approach to software modernisation, emphasising the importance of incremental improvements, leadership alignment, and the practicalities of managing technical debt and legacy systems.