Earlier this week I published a piece declaring that to realize meaningful ROI from agentic development, the tech industry needs to consider enterprise-wide use cases instead of focusing on the current vogue for personal productivity agents. This should not be too surprising, since the argument is that a bigger investment in enterprise-grade applications, if it’s done well, will lead to a bigger economic impact for the business.
This week at the Amazon Web Services re:Invent conference, customers have been sharing best practices from their move to agentic computing. However, these customers are usually market-segment leaders that are typically considered innovators. How about companies that are large but not necessarily innovative? Or what about companies that would like to innovate but are held back by mountains of legacy technology or technical debt?
It seems that AWS has been thinking about these types of companies quite a bit.
Legacy Apps Are A Meaningful Business Problem
First, it’s important to understand the reality that these companies are facing. Despite all of the growth in CSPs from the deployment of AI and machine learning solutions, the majority of IT spending is still on-premises. On-premises is pegged somewhere around 55% to 60% of total IT spending. Some analysts predict that AI growth will push CSPs above the 50% mark in this decade; whether it hits that number or not, there is clearly a lot of room for growth among the CSPs. But it also must be understood that the last 50% of opportunity will be a lot harder to achieve than the first 50%.
Some key industry statistics back this up. At the recent TBM 2024 conference, McKinsey said that 75% of all IT costs come from servicing legacy workloads. This amount is consistent with other estimates. For example, IBM Consulting recently stated that 70% of enterprise workloads needed modernization. Compounding this problem is that IT outsourcing and an evolving IT workforce are making it harder to maintain such a heavy base of legacy applications. All of this means that while AI and other technologies are being innovated rapidly, many enterprises do not have enough funding or skills to put them to good use. If these legacy apps are not addressed, the innovation opportunity will shrink even further in the future.
Based on many conversations and what I’ve seen at re:Invent this week, it’s apparent that AWS is keenly aware of this reality. Indeed, as the largest CSP in the world, AWS also understands that it competes not only with other CSPs but also with enterprises that choose to keep their workloads, especially legacy workloads, within the confines of their own datacenters.
AI Tools Must Go Beyond Code Translation And Embrace A Change Management Process
As generative AI developer assistants were getting a lot of coverage this past summer, there were a number of vendors talking about code transformation. The common example was either for an upgrade like Java XX to Java 17 or even something like .NET to Java. And again, while those capabilities do enhance the productivity of individual developers, what’s needed is something more in tune with a software development lifecycle approach.
That is why AWS recently announced a new set of agentic transformation capabilities in its Q Developer product intended to help drive impactful software transformation projects. Q Developer is now going beyond a typical integrated development environment and taking the entire lifecycle into consideration. For example, what if the application has terrible documentation and the developers initially involved in the project are no longer with the team? Before you start transitioning code, you may need to fully document the existing application. You might also need to incorporate code reviews or unit testing into the process, as opposed to just recompiling the code. This is the kind of challenge that the folks at AWS have clearly been thinking hard about.
The agentic development style goes beyond carrying out single tasks. Q Developer’s capabilities align well with how I defined agents in a piece I published in September. Instead of one agent asking a single LLM to perform a task, the small transformation agents in Q can collaborate or autonomously enlist other agents or LLMs as needed. This is possible thanks to Q Developer’s integration with Amazon Bedrock, and these key agentic capabilities enable the completion of far more complex tasks and processes.
The Cloud Is A Solid Infrastructure Foundation
The challenging element in this type of transformation is that once you go outside the scope of a version-to-version upgrade, the project gets much more complicated. Again, Q Developer is addressing this complexity with this new agentic approach. Let’s start with a challenge that is one order of magnitude more complex, such as a .NET to Java migration. A project like this can involve decisions that have a profound impact on costing in the long term. In this example, beyond converting the .NET code, Q Developer considers many other infrastructure improvements that could present themselves, depending on the application. For instance, could some components leverage serverless computing to help save on costs? How about transitioning not only the code but migrating the underlying data to a new database such as MongoDB or Postgres?
AWS has also announced that this approach will be utilized for even more complex infrastructure migrations. This includes moving from VMware to containers or from a monolithic COBOL-based mainframe to a distributed stateless architecture. These are all capabilities that Q Developer either has now or has on its roadmap. AWS is harnessing the agentic approach to take a more holistic and architecture-driven view of what are some of the most demanding migration efforts. This should not only reduce the time required for these efforts but also improve the operation of the migrated workloads long term.
While these new agentic capabilities may create exciting opportunities for transformation, all of them require a reliable, secure global infrastructure—which, fortunately, AWS knows something about.
Creating An Operational Process
One of the historic challenges of these types of lift-and-shift projects is that they are one-time, ad-hoc events. This creates a major issue for those who seek to justify the effort to the C-suite. For starters, the ROI case is typically built on future cost avoidance, which is often hard to measure across the years it can take to realize those savings. Secondarily, there is always a fear that once the project is completed the first time, the work will be considered “done” and won’t be taken up again until the next big upgrade event.
What’s nice about using generative AI is that once the project is automated and completed the first time, the agents can be invoked over and over to keep the applications up to date. There should also be an expectation that each update will be easier to execute as the time gap between future upgrades gets shorter.
But it could even go beyond just running the same process next time. Once there is a reliable path for keeping things current, a good deal of the work can be offloaded to non-development resources. A good example of this possibility is the web interface for Q Developer’s transformation capabilities, which is designed to be used by DevOps staff. For example, future lighter-weight scans may require only in-place upgrades and CVEs. In that case, the update can be scheduled and executed with minimal human touch versus the high-touch approach in the first migration effort.
AWS Is Introducing A Mature AI-Driven Mindset To A Classic Problem
This is the type of AI productivity that has a meaningful impact on IT budgets. My observation is that tech companies like AWS are starting to understand that generative AI will require a shift in mindset toward business impact when it comes to delivering demonstrable value.
The good news is that there are now opportunities and methods to do just that. Through Q Developer, AWS is ultimately attempting to create a company-specific “factory” to automate IT transformation. In many ways, this degree of modularity and automation is similar to how cloud service providers such as AWS were able to achieve high scale in their own cloud infrastructures. Now they are taking those ideas to their customers’ pre-cloud apps.
It’s Not IT Nirvana, But It’s A Big Step Forward
As great as this sounds, I’d suggest that you need to ground yourself in a few practical realities for taking this approach. These migration projects have historically been hard to execute, and AI does not magically make it “easy.” Keeping that in mind could ease some of the pain and the risks. Here are a few key considerations.
- Time and effort will not shrink to zero. So many demos position AI as a way to reduce hours of work to seconds and to possibly redefine or eliminate job roles. But a better way to think about this class of transformation is reducing years to months. There is a good chance you will still need to do a lot of heavy lifting to resolve issues and deploy new services, despite the potentially massive gains brought by AI.
- You will always have some legacy. I have been through my share of legacy software migrations, and sometimes you find that some portion of the code you still need simply works best on the old infrastructure. So when you’re re-architecting, total eradication of the legacy codebase may not be realistic. But you can still probably get pretty far.
- Consider the sources and motivations. As exciting as agentic applications are, and for all the potential they show, what we are seeing right now remains something of an install-base capture exercise. In the case of application platforms, the goal will be to either incrementally increase per-user revenue or simply to add more users. In the case of Q Developer, while there is a great opportunity to transform and optimize your enterprise applications—potentially saving significant money—the deployment target is still the AWS cloud. None of this is bad per se, it’s just a reminder that when selecting a solution, you should consider all of the long-term costs and tradeoffs.
If you are an enterprise suffering with a high technical debt or legacy overhead, agentic capabilities like those in Q Developer could be quite attractive. And the biggest advantage may come from adopting a mindset of continuous health versus a one-shot focus on getting healthy that fades over time.
