Part 4 in the Uncovering Technical Debt Series from Intellyx, for vFunction. [Check out part 1 | 2 | 3 here.]
We’ve dug deep into our technology stacks, uncovering all of the legacy artifacts and monoliths that we could find from past incarnations of our organization.
We’ve cataloged them, rebuilt them to modern coding standards, and decoupled their functionality into object-oriented, service-enabled, API-addressable microservices.
Now what? Are we modernized yet?
Well, mostly. There are always some systems that just aren’t worth the time and attention to replace right now, even with intelligent automation and refactoring solutions.
Plus, we acquired one of our partner companies last year, and we haven’t had a chance to merge their catalog with our ordering system yet, so they are still sending us EDI dumps and faxes for urgent customer requests…
We’re never really done with continuous modernization
We’ve compared legacy modernization to the discipline of archaeology. But what happens once archaeologists finish their excavation and classification expeditions? Anthropologists can take over the work from here, interpreting societal trends and impacts even as the current culture continues to evolve and generate new artifacts.
Similarly, discovering and eliminating uncovered technical debt isn’t a one-time modernization project, it’s a continuous expedition of reevaluation. Once an application is refactored, replatformed or rearchitected, it creates concentric ripples, exposing more dependencies and instances of technical debt across the extended ecosystem, including adjacent applications within the organization, third-party services and partner systems.
Mapping the as-is and to-be state of the codebase with discovery and assessment tools is useful for prioritizing the development teams’ targets for each project phase around business value, but business priorities will change along with the application suite.
Development teams also get great utility from conducting modernization projects with the help of AI-driven code assessment and refactoring solutions like vFunction Code Copy, but they can realize even greater benefits by retaining the history of what worked (and didn’t work) to inform future transformations.
Not every modernization project works out equally well, but when the hard lessons of modernization feed back into the next assessment phase, this virtuous cycle can become part of the muscle memory of the organization, allowing mental energy to be spent on the most important choices that affect the long-term goals of the business.
Putting technical debt to rest: what to expect
No computer science college student or self-taught coder sets out to spend a career finding and fixing bugs in their code, much less someone else’s – but on average, developers spend at least 30 to 50 percent of their time on rework, rather than innovation and enablement of new features that are perceived to add business value.
Besides the perceived thanklessness of the effort, developers encounter morale-destroying toil when sifting through legacy code, which usually contains lots of class redundancies, recursive methods, poor documentation and a general lack of traceability, resulting in slow progress.
Continuous modernization offers a way out of this thankless job, by preventing technical debt from collecting during each assessment and refactoring phase.
Here’s some levers teams are pulling for successful long-term improvements:
- Continuous assessment. The best performing initiatives are not just conducting initial assessments, they are continuously mapping, measuring and observing modernization efforts before, during, and after each refactoring run.
- FinOps practices basically bring financial concerns and tradeoffs to each modernization selection process or option. IT buying executives have been doing ROI analyses for vendor selection and capex computing investments for years. Now, savvy buyers are getting better cost justification for money spent on modernization, with real financial metrics for resources, employee and customer retention, and delivered customer value.
- SLO objectives offer positive motivation for time-and-labor savings and incremental delivery of new services, in comparison to the negative contractual penalties enforced through SLA failures. Developers are incentivized to meet goals such as faster refactoring projects, faster automated deployments, and higher value updates – with fewer hitches and developer rework required.
- Qualitative business goals are equally as important to success. Better team morale improves productivity and employee retention rates, versus trying to replace high-quality people with new ones that could take months to get up to speed. Developers love working for agile enterprises, where they can test theories and ultimately help the application suite evolve faster in the future to meet changing customer needs.
Trending toward velocity and morale at Trend Micro
Trend Micro is considered a global leader in cloud workload security, with several successful products underneath the banner of its platform – but that didn’t mean their modernization journey started without major headaches.
Much of their existing product suite, with more than 2 million lines of code and 10,000 independent Java classes, was built before secure API connections between cloud infrastructure and microservices were fully sussed out by the development market. Therefore, earlier customers were more inclined to trust on-premises installations and updates of vital virus, spam and spyware prevention software.
As the modern trends of SaaS-based vendors and cloud-based enterprise applications really hit stride over the last decade, Trend Micro started offering a re-hosted version of its suite under their CloudOne™ Platform banner.
Their initial lift-and-shift of one module’s code and data store to AWS offered some scalability and cost benefits due to elastic compute resources, but as the user base grew, it was becoming harder and harder for product dev teams to get a handle on inter-product dependencies that hindered future releases and updates to meet customer needs. Morale suffered as the replatforming took about a year.
Trend Micro turned to vFunction to identify and prioritize modernization of their most critical “Heartbeat” integration service – with more than 4000 Java classes that take in data from sensors, event feeds and data services across the product suite.
Then using vFunction for modernization, the team was able to visually understand code complexity, with an applied AI for identifying essential, interconnected and circular dependencies, deprecating dead code that would no longer add any actual value for customers going forward.
Through refactoring, they were able to decide which classes should be included as part of the new Heartbeat service, and which should be kept in a common library for shared use across other product modules in the future.
This modernization project took less than 3 months – a 4X speed improvement over the previous project, with successive update deployment times decreased by 90%. Best of all, morale on the team has improved by leaps and bounds.
The Intellyx Take
Continuous modernization offers enterprises a lasting bridge from the monolithic past to a microservices future, but with constant change at enterprise scale, the journeys across this bridge will never really end.
To get to the bottom of the biggest obstacles of modernizing our digital estates, we must first assess and prioritize code refactoring and application architecture efforts around resolving technical debt.
Then, our intrepid teams can venture forth, digging to unearth the artifacts and digital foundations of our organizations, transforming our applications into modular cloud native services, resetting the values of our shared culture, and adapting our architectures to meet the challenges of a global, distributed, hybrid IT future.
Can you dig?
©2022 Intellyx LLC. Intellyx retains editorial control of this document. At the time of writing, vFunction is an Intellyx customer. Image credit: Licensed from Alamy “2001: A Space Odyssey” movie still.
