How to get buy-in and budget for successful application modernization
Bob Quillin, chief ecosystem officer at vFunction, is an industry expert when it comes to application modernization. He often finds that the biggest hurdle to application modernization is developing a compelling business case to take on such a complicated task that can be costly and frequently fraught with risk. Business leaders need justification for budget allocation, yet most architects lack data to prove it’s essential or determine the resources needed to pull it off successfully.
A business case must be backed with data — data that is easy to understand and see the bigger picture. Business leaders don’t often want to be told something has to be done, preferring to be shown why it needs to be done and what is likely to happen if it isn’t. This is precisely what Bob and his team at vFunction do with their Assessment Hub and Assessment Hub Express tools. These solutions were built specifically for architects who want a simplified way to build a data-driven application modernization plan and need to create a strong business case to do so.
In this interview with Bob, we discuss the key inhibitors to successful modernization projects and how to develop a rock-solid business case for application modernization. He will also discuss how the vFunction Assessment Hub works and the benefits it brings for gaining rapid visibility into the health of the entire application estate.
Q: Tell me why building a business case for application modernization is so difficult.
Bob: One of the key inhibitors to modernization projects being successful is that it’s hard to build a business case to get them approved and off the ground. Traditionally, architects haven’t had a clear understanding of what exactly needs to be done, how long it will take, or how complex it will be, all critical components of a business case. But now, we can provide the science and data to build the case.
Q: What happens without a business case?
Bob: Oftentimes, nothing. Modernization projects are either delayed, never start, or end in failure. If you aren’t looking inside and analyzing the application architecture, you can’t accurately predict the value of modernization. Without the business case, you can’t have a successful modernization project and vice versa.
In our 2022 study with Wakefield Research of 250 technology professionals, we found, “Failure to Accurately Set Expectations” was the number one reason given by respondents who started modernization projects they didn’t complete. Areas of particular concern include unrealistic expectations relating to budget and schedule requirements and anticipated project results such as improvements in engineering velocity and application innovation.”
With vFunction’s suite of application modernization solutions, architects and senior engineers can understand the technical debt in each app, pull that out and fix the prob, modernize it, and continually monitor and fix new issues to prevent technical debt from accumulating again.
Q: How do architects know they have a technical debt problem?
Bob: From a qualitative level, application leaders have a strong sense that they are carrying a heavy load of technical debt by the symptoms they go through every time they add a new feature. How long does it take? If it’s taking your team more and more time each sprint, you know you have an issue. It can also become harder to add new features because it’s more difficult to figure out where to add the new feature and integrate it. It will also become much more difficult and time-consuming to test. One small change in a monolith requires you to test the entire application because you don’t know the downstream implications.
With monoliths, there is a high degree of dependencies, so release cycles expand, engineering velocity decreases, and eventually, your ability to compete and add new features slows. You’ll often see a backlog of feature requests you have in your project management and tracking systems that you can’t keep up with. It significantly hampers the Dev team’s capacity and production.
Q: How can all of this lead to increased costs?
Bob: If you have a spike in demand (requiring more CPU and memory resources) or it’s an important application, it becomes difficult to scale a monolithic application without buying bigger machines or cloud instances types or shapes. On the flip side, cloud-native architectures are more horizontally scalable with greater elasticity. The two factors I hear architects complain about are that they can’t scale and costs go up.
There are costs to run the app, even after a lift and shift. If you break down that monolithic application into microservices, you can be more efficient in how you apply the wider variety of cloud instances to that particular need. Release velocity increases, testing speed cycles increase, and there is elasticity and scalability, all at a lower cost. These are all reasons to break down monolithic apps into microservices.
Q: If there is such a need and so much to gain, why is it so hard to get an application modernization project off the ground?
Bob: We surveyed 250 application teams and looked at the top reasons for failure. The number one reason was a failure to set expectations for leaders and architects accurately. At a minimum, they need to understand what application modernization will solve in terms of technical debt, how long it will take, and what it will cost. They need an ROI — what they will get in terms of reducing technical debt and increasing innovation.
Q: Why is this information so elusive?
Bob: Currently, the only information available is mostly qualitative. In other words, they just use their experience and best guesses, bring in consultants or a system integrator, or outsource the whole thing. It isn’t based on any science, automation, or best practices. When they don’t have data to measure architectural technical debt, they can’t assess the complexity of the app or the risks of changing it. They need observability to understand dependencies, dead code, and what’s common and not common code — all the things that make up the architecture. Without it, it’s nearly impossible to make a plan on how to rearchitect an architecture you don’t understand. A classic business mantra is if you can’t measure, you can’t improve it. When you can measure it, you can decide how to improve it, what to fix, how long it will take, how complex it will be, and what the cost will be.
Q: vFunction directly addresses these challenges with the vFunction Assessment Hub. Is there anything else out there like it?
Bob: There are other tools that analyze source code to report back how it is written, any number of code “smells” or poor software engineering practices, and cyclomatic complexity that tracks the number of linearly-independent paths through the application. Source code analysis is different from architectural analysis, which looks at how an app is built and constructed versus how it is written. It’s easier to track little source code errors along the way versus fixing the architecture itself, but you never truly modernize the application if you don’t address the underlying root cause of technical debt.
I like to think of it like a house. When you’re updating a kitchen or adding a bathroom to a massive house, you have to figure out the architectural components before you can tie new plumbing into the old. All of the plumbing is interdependent, so if you make a mistake with one piece of plumbing, it can impact the entire plumbing system. The monolithic application is the house. Think how much easier it is if you had the opportunity to break up a mansion into individual casitas, or microservices in this analogy. Adding on or fixing plumbing issues is now much more manageable, with fewer dependencies to worry about.
Security is another issue. If you add a piece of open-source code that has a known vulnerability, you can scan that library or code prior to adopting that component. People call source code tracking “checking for code smells,” which means looking for different errors or anti-patterns that developers have added along the way that can be detected and fixed. Security analysis tools will pick up security issues. Static analysis tools pick up code smells. At vFunction, we actually use these in our own software development process, but what’s missing typically for development teams are measurement and tracking tools for architectural technical debt
Q: What is an example of an architectural issue?
Bob: Dead code is a good example of an architectural issue. You can’t analyze it just by looking at the source code. We define dead as code that is reachable but no longer used. We have found over the years that there are large swaths of obsolete or “zombie” code hidden in most monoliths. Something could call it, but nothing does. Maybe the service is now obsolete. It’s just sitting out there and not being used.
Architectures drift over time, new features get added or maybe replaced, and older features are no longer used by customers and have been replaced. You’re carrying that technical debt forward. No one wants to touch it because maybe they weren’t there when it was written and don’t know what to do with it, or they fear if they touch it, there will be negative downstream effects.
Q: How is innovation impacted by technical debt?
Bob: Modernization requires funding, people resources, and time, diverting resources from other priorities, so you will have to build a business case and get approval. The question is, do you want to keep doing what you’re doing and add more and more features and ignore technical debt, or finally reduce that debt and start investing the savings in innovating for the future?
Over time, there is a tipping point where all that technical debt weighs down the application and the organization to the point of breaking. The calculus here is that every dollar spent on technical debt is a dollar you aren’t spending on innovation. If you want to innovate more, you have to reduce your technical debt to get the ROI from modernization.
Q: How does vFunction help increase innovation?
Bob: vFunction will measure and help you manage architectural technical debt and, then highlight the upside if you reduce it — how much ROI you’ll have in terms of innovation. This translates directly to dollars. In fact, this is one of the first factors we look at: how much architectural debt are you carrying, and how is it impacting your ability to innovate? Instead of theories and “gut feels,” we can give you numbers — here’s your ROI and TCO. Now, you have a business case that clearly illustrates to decision-makers that “if we want to increase business velocity, customer satisfaction, and innovation, this is how we have to apply our resources to bring down technical debt.”
Q: Tell me more about vFunction Assessment Hub and how it gathers and presents the data.
Bob: Our Assessment Hub analyzes technical debt based on two factors: complexity and risk. Then, those are synthesized into a technical debt score.
Complexity is based on the degree of class entanglements within your application. It measures the density of the dependencies and how complex the application will be to modernize.
Risk is based on the length of the dependency chains in the application. We measure the dependency chains, and how those interrelate downstream so you know that if you make one change here, what are the consequences down the line? This is the bane of the monolith — if you make one change, you have to test the whole thing. With microservices, you have a high degree of exclusivity of the resources you use, and they are constrained within the boundaries of the microservice. The risk of making a change is much lower.
Q: How does that technical debt score inform decisions?
Bob: We set the technical debt score per application, and you can compare it with other applications. We also show how much effort it will take to fix it in terms of time and people. Architects can use that as a way to say, “Here is our technical debt and what it’s costing us. If we reduce the tech debt, here’s the innovation that occurs.”
The Assessment Hub scores the top 10 technical debt classes and presents a prioritized list of where to start. For example, if you fix only these 10 things, we can say what effect that will have — the ROI. This kind of insight helps people understand not only a top-level debt score, but the components of complexity and risk, and then where to start. We also analyze the architecture to identify aging platforms and frameworks you will want to update.
Q: What comes next once you understand the scope and magnitude of the modernization project?
Bob: Ideally, you would then jump into the vFunction Modernization Hub to do it. We’ve given you the path, now go at it with an AI-enabled approach.
The vFunction Assessment Hub Express is designed to be fast. You download and run it yourself from our website. We use this as part of our own analysis to help customers get started on modernization. It gives them a snapshot of what it will take. They can then say, “This will be a complex project or wow, this isn’t that hard, and we can do 100-200 classes ourselves.” Sometimes they don’t need full-blown modernization, or they can just lift and shift because they aren’t carrying much debt anyway. You have to make sure there are clear business reasons to modernize.
Q: So, modernization isn’t always necessary? How do you know?
Bob: For an application to warrant modernizing, it needs to be an application that is actively used and critical to the business. If there’s a large backlog of features to add or requests to fix it, you know there’s a strong demand to extend or improve the application that isn’t being met. But if there’s no business reason to extend, there’s no business IP or competitive value, or if it can be easily replaced by a modern SaaS alternative, refactoring or rearchitecting may not be the best path.
Modernization is complicated, so you have to make sure there is a viable business reason to modernize. Only the business can understand and prioritize if it’s something they want and need to do.
Q: We assume modernization is to cloud-enable a legacy application. Is this true?
Bob: Partly. We are looking at more besides improving the architecture. One of the greatest motivators besides velocity, scalability and elasticity is reducing costs and increasing efficiency. When people move to the cloud, they’re also looking to lower infrastructure spend. Cloud services can be less expensive if you architect your application to use them more efficiently.
But it’s also about reducing licensing costs. Legacy licensing for databases and Java itself is expensive. If you move an application to the cloud, like an enterprise monolithic application you’re still carrying significant licensing costs. Most customers want to reduce licensing costs across the board. So, the cost of running an expensive monolithic application and the related licensing costs are also common motivators to modernize.
Q: Have vFunction users reduced costs this way?
Bob: Yes. If you look at our Trend Micro study, they took a monolith they lifted and shifted, modernized to microservices, and reduced their cloud instance spend by 50%.
Legacy applications that are lifted and shifted to the cloud require some of the most expensive services in the cloud. If you’ve just taken an older app to the cloud, it’s running with high CPU and memory requirements, plus the most expensive data layer services as well. A lift and shift application has not been optimized for the cloud. In addition, a lift and shift doesn’t reduce licensing costs, combined with high infrastructure costs. Unless it’s cloud-native, you can’t take advantage of the efficiency of the cloud. Vertical scaling is very expensive. You will get more horizontal scalability and elasticity with microservices, and it is much more cost-effective.
Q: Last question. You mentioned the importance of presenting the data the Assessment Hub gives in a way that’s easy to understand. Can you explain how the Hub does that?
Bob: The Assessment Hub is graphical. You see a visualization of complexity, risk, debt (with a score), components of tech debt, and the number of aging frameworks. Then, you can analyze TCO, the benefits of fixing the identified debt, and the resulting increase in innovation.
We present this in different ways on a dashboard. For example, there is a pie chart view of innovation versus technical debt. It graphically represents how much you’re spending on innovation versus technical debt, with percentages for added detail. You can ask, “What are the benefits if I fix this technical debt, and how much will my TCO improve?” You can also download this information as a shareable pdf.
If you’re not ready to modernize, you can let Assessment Hub run over time to monitor trends. Our latest feature is a multiple-application dashboard. It provides compelling observability across multiple apps at the same time to visualize technical debt for a large application estate so you can compare and prioritize.
You can scope the project to know what you’re getting into and if it’s worth it. If an architect doesn’t have the data, they can’t have a viable, believable business plan. The goal is to get people thinking about this as early as possible.
Bob Quillin not only serves as Chief Ecosystem Officer at vFunction but works closely with customers helping enterprises accelerate their journey to the cloud faster, smarter, and at scale. His insights have helped dozens of companies successfully modernize their application architecture with a proven strategy and best practices. Learn more at vFunction.com.
Related Posts:
