Category: Uncategorized

Q&A Series: The 3 Layers of an Application: Which Layer Should I modernize first?

Posted on June 15, 2023 by - Uncategorized

How to avoid mistakes when modernizing applications

As Chief Ecosystem Officer at vFunction, Bob Quillin is considered an expert in the topic of application modernization, specifically, modernizing monolithic Java applications into microservices and building a business case to do so. In his role at vFunction, inevitably, he is asked the question, “Where do I start?”

Modernizing can be a massive undertaking that consumes resources and takes years, if it’s ever done at all. Unfortunately, because of its scale, many organizations postpone the effort, only deciding to tackle it when there is a catastrophic system failure. Those who do dive into the deep waters of modernization frequently approach it from the wrong perspective and without the proper tools.

Where to start with modernizing applications boils down to which part of the application needs attention first. There are three layers to an application: The base layer is the database layer, the middle layer is the business logic layer, and the top layer is the UI layer. 

In this interview with Bob, we discuss the challenges facing software architects and how approaching modernization by tackling the wrong layers first inevitably leads to failure, either in the short term or the long term.

Q: What do you see as the most common challenge enterprises face when deciding to modernize?

Bob: Most organizations recognize they have legacy monolithic applications that they need to modernize, but it’s not as easy as simply lifting the application and shifting it to the cloud. Applications are complicated, and their components are interconnected. Architects don’t know where to start. You have to be able to observe the application itself, how the monolithic application is constructed, and what is the best way to modernize it. Unfortunately, there isn’t a blueprint with clear steps, so the architect is going in blind. They’re looking for help in any form – clear best practices, tooling, and advice. 

Q: With a 3-tier application, you’d think there are 3 ways to approach modernization, but you say this is where application teams often go wrong.

Bob: Many technology leaders want to do the easiest thing first, which is to modernize the user interface because it has the most visual impact on their boss or customers. If not the UI, they frequently go for the database where they store the data perhaps to reduce licensing costs or storage requirements. But the business logic layer is where business services reside and where the most competitive advantage and intellectual property are embedded. It isn’t the easiest layer to begin with, but by doing so, you make the rest of your modernization efforts much easier and more lasting.

Q: What’s the problem starting with the UI layer?

Bob: When you start with the UI, you actually haven’t addressed modernization at all. Modernization is designed to help you increase your engineering velocity, reduce costs, and optimize the application for the cloud. A new UI can have short term, visual benefits but does little to target the underlying problem – and when you do refactor that application, you’ll likely have to rewrite the UI again! Our recommendation is to start with the business logic layer — this is where you’ll find the services that have specific business value to be extracted. This allows you to directly solve the issue of architectural technical debt that is dragging your business down. 

Q: What’s the value of extracting these services from the monolith?

Bob: In the past, everything was thrown together in one large monolithic “ball of mud.” The modernization goal is to break that ball of mud apart into smaller, more manageable microservices in the business logic layer so that you can achieve the benefits of the cloud and  then focus on micro front-ends and data stores associated with each service. By breaking down the monolith into microservices, you can modernize the pieces you need to, and at that point, upgrading the UI and database becomes much easier.

Q: Tell me more about the database layer and the pitfalls of starting there.

Bob: The database layer should only be decomposed once as it often stores the crown jewels of the organization and should be handled carefully. It also a very expensive part of the monolith, mostly because of the licensing, so it often seems like a good place to start to cut costs. But decomposing the database is virtually impossible to do without understanding how the business logic is using it. What are the business logic domains that use the database? Each microservice should have its own data store, so you need the microservice architecture designed first. You can’t put the cart before the horse. 

Data structures are sensitive. You’re storing a lot of business information in the database. It’s the lifeblood of the business. You only want to change that once, so change it after decomposing your business logic into services that access independent parts of the database. If you don’t do the business logic layer first, you’ll just have to decompose the database again later. 

Q: Explain how breaking down monoliths in the business logic layer into microservices works with the database layer.

Bob: Every microservice should have its own database and set of tables or data services, so if you change one microservice, you don’t have to test or impact another. If you decompose the business logic with the database in mind, you can create five different microservices that have five different data stores, for example. This sequencing makes more sense and prevents having to cycle on the database more than once. 

Also, clearly, you want to organize your access to the database according to the business logic needs versus the opposite. One thing we find when people lift and shift to the cloud, their data store is typically using the most expensive services that are available from cloud providers. The data layer is very expensive, especially if you don’t break down the business logic first. If you modernize first, you can have more economical data layer services from the get-go. If you start decomposing your business logic first, you have more efficient and optimized data services that save you money and are more cloud-native, fitting into a model going forward that gives you the cloud benefits you’re looking for. Go to business logic first, and it unlocks the opportunities. 

Q: What’s the problem with starting modernization with whatever layer feels the most logical?

Bob: Modernization is littered with shortcuts and ways to avoid dealing with the hardest part, which is refactoring, breaking up and decomposing business logic. UI projects put a shiny front on top of an older app. If that’s a need for the business, that’s fine, but in the end, you still have a monolith with the same issues. It just now looks a little better. 

A similar approach is taking the whole application and lifting and shifting it to the cloud. Sure, you’ve reduced data center costs by moving it to the cloud, but you’re delaying the inevitable. You just moved from one data center (your own) to a cloud data center (like AWS). It’s still a monolith with issues that only get bigger and cause more damage later. 

Q: How does vFunction help with this?

Bob: Until vFunction, architects didn’t have the right tools. They couldn’t see the problem so they couldn’t fix it. vFunction enables organizations to do the hard part first, starting with getting visibility and observability into the architecture to see how it’s operating and where the architectural technical debt is, then measuring it regularly. Software architects need that visibility. If we can make it easier, faster, and data-driven, it’s a much more efficient path so that you don’t have to do it again and again. 

Q: How do you focus on the business logic with vFunction? 

Bob: If you’re going to build microservices, you need to understand what key business services are inside a monolith; you need a way to begin to pull those out and clearly identify them, establish their boundaries, and set up coherent APIs. That’s really what vFunction does. It looks for clusters of activities that represent business domains and essential services. You can begin to detangle and unpack these services, seeing the services that are providing key value streams for the business that are worth modernizing. 

You can pull each out as a separate microservice to then run it more efficiently in the cloud, scale it, and pick the right cloud instances that conform to it. You can use all of the elasticity available in containers, Kubernetes, and serverless architectures through the cloud. You can then split up a database to represent just that part of the data domain the microservice needs, decomposing the database based on that microservice. 

Q: Visibility is key here, right?

Bob: Yes. The difficulty is having visibility inside the monolithic application, and since you can’t see inside it or track technical debt, you have no idea what’s going on or how much technical debt is in there. The first step is to have the tools to observe and measure that technical debt and understand the profile, baseline it, and track the architectural patterns and drift over time. 

Q: How does technical debt accumulate, and what can architects do about it?

Bob: You may see an application that was constructed in a way that maybe wasn’t perfect, but it was viable, and over time it erodes and gathers more and more architectural technical debt. There are now more business layers on top of it, more code that’s copied, and new architects come in. There are a lot of permutations that happen, and that monolith becomes untenable in its ability to fulfill changing requirements, updates, and maintenance. Monoliths are very brittle. Southwest Airlines and Twitter know this all too well.

But this is where vFunction comes in to help you understand where that architectual technical debt is. You can use our Continuous Modernization Manager and Assessment Hub to provide visibility and tracking, and then our Modernization Hub helps you pull apart and identify the business domains and services.

Q: What infrastructure and platforms support the business logic?

Bob: Application servers run the business logic. Typically, we find Oracle WebLogic, IBM WebSphere, Red Hat JBoss, and many others. Monoliths are thus dependent on these legacy technology platforms because the business logic is managed by these application server technologies. This means that both the app server and database are based on older and more expensive systems that have older licensed technology written for another architecture or domain 10-20 years ago. 

Q: What are the key benefits of looking at the business logic layer first?

Bob: By starting with the key factors that compose your architecture including the classes, resources, and dependencies, you start to deintirfy the key sources of architectural technical debt that need to be fixed. Within this new architecture, you want to create high levels of exclusivity, meaning that you want these components that contain and depend on the resource that are exclusive to each microservice. The primary goal is to architect highly independent of each other. 

Q: And what does that mean for the developer?

Bob: For the developer, it increases engineering velocity. 

In a monolith, if I want to change one thing, I have to test everything because I don’t know the dependencies. With independent microservices, I can make quick changes and turns, testing cycles go down, and I can make faster, more regular releases because my test coverage is much smaller and my cycles are much faster. 

Microservices are smaller and easier to deal with, requiring smaller teams and a smaller focus. You can respond faster to customer feature requests. As a developer, you have much more freedom to make changes and move to a more Agile development environment. You can start using more DevOps approaches, where you’re shifting left all of the testing, operational and security work into that service because everything is now much more contained and managed. 

Q: What does it mean from an operational perspective?

Bob: From an operational perspective, if the application is architected with microservices, you have more scalability in case there’s a spike in demand. With microservices and container technology, you can scale horizontally and add more capacity. With a monolith, if I do that, I might only have a certain amount of headroom, and I can’t buy a bigger machine. With memory and CPU limits, I can’t scale any further. I may have to start replicating that machine somewhere else. By moving to microservices, I have more headroom to operate and meet customer demand. 

So, developers get higher velocity, it’s easier to test features, there’s more independence, and operationally, they get more scalability and resilience in the business. These benefits aren’t available with a monolith. 

Q: This sounds like it requires a cultural shift to get organizations thinking differently about modernization.

Bob: Definitely. From a cultural perspective, you can start to adopt more modern practices and more DevOps technologies like CI/CD for continuous integration and continuous delivery. You’re then working in a modern world versus a world that was 20-30 years ago. 

As you start moving monoliths to microservices, we hear all the time that engineering morale goes up, and retention and recruiting are easier. It’s frustrating for engineers to have a backlog of feature requests you can’t respond to because you have a long test cycle. The business gets frustrated, and engineers get frustrated, which leads to burnout. Modernizing puts you in a better position to meet business demands and, honestly, have more fun. 

Q: Are all monoliths bad?

Bob: No, not all monoliths are bad. When you start decomposing a monolith that results in many microservices and teams, you should have a more efficient, scalable, higher-velocity organization, but you also have more complexity. While you’ve traded one set of complexities for another you are getting extensive benefits from the cloud. With the monolith, you couldn’t make changes easily, but now, with microservices, it’s much easier to make changes since you are dealing with fewer interdependencies  While the application may be more efficient it may not be as predictable as it was before given its new native elasticity. 

As with any new technology, this evolution requires new skillsets, training, and making sure your organization is prepared with the relevant cloud experience with container technologies and DevOps methodologies, for instance. Most of our customers already have applications on the cloud already and have developed a modern skillset to support that. But, with every new architecture comes a new set of challenges. 

Modernization needs to be done for the right reasons and requires a technical and cultural commitment as a company to be ready for that. If you haven’t made those changes or aren’t ready to make those changes, then it’s probably too soon to go through a modernization exercise. 

Q: What is the difference between an architect trying to modernize on their own versus using a toolset like vFunction offers? 

Bob: Right now, architects are running blind when it comes to understanding the current state of their monolithic architectures. There are deep levels of dependencies with long dependency chains, making it challenging to understand how one change affects another and thus how to untangle these issues. 

Most tools today look at code quality through static analysis, not architectural technical debt. This is why we say vFunction can help architects shift left back into the software development lifecycle. We provide observability into their architecture which is critical because architectural complexity is the biggest predictor of how difficult it will be to modernize your application and how long it will take. If you can’t understand and measure the architectural complexity of an application, you won’t be able to modernize it. 

Q: Is vFunction the first of its kind in terms of the toolset it provides architects?

Bob: Yes. We have built a set of visibility, observability, and modernization tools based on science, data, and measurement to give architects an understanding of what’s truly happening inside their applications. 

We also provide guidance and automation to identify where the opportunities are to decompose the monolith into microservices, with clear boundaries between those microservices. We offer consistent API calls and a “what if” mode — an interactive, safe sandbox environment where architects can make changes, rollback those changes, and share with other architects for greater collaboration, even with globally dispersed teams. 

vFunction provides the tooling, measurement, and environment so architect and developers have a proactive model that prevents future monoliths from forming. We create an iterative best practice and organizational strategy so you can detect, fix, and prevent technical debt from happening in the future. Architects can finally understand architectural technical debt, prevent architectural drift, and efficiently move their monoliths into microservices. 

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:

Technical Debt Risk: Review SWA, the FAA and Twitter Outages

Posted on June 15, 2023 by - Uncategorized

How all organizations can learn to spot the warning signs

Until recently, “technical debt” was a term reserved mostly for those in IT, specifically, architects, developers, app owners and IT leaders. Thanks to a few high-profile outages at Southwest Airlines, the FAA, and Twitter, technical debt has made it to mainstream media outlets which are reporting on how unchecked technical debt contributed to failures that impacted millions of people and to some, cost billions and immeasurable damage to their brand reputation. 

While these organizations likely wish their hardships weren’t blasted to the public, perhaps the spotlight will serve as a warning to the thousands of other organizations that could share similar fates if they don’t act soon to address their technical debt. As more organizations shift applications to the cloud to enhance their capabilities, the problem will only increase. 

In this Q&A with Bob Quillin, the chief ecosystem officer at vFunction, we take a deep dive into how technical debt happens, the risks of ignoring it, and how it can be efficiently managed before it leads to major issues.

Q: Can you give me a little background on each of these system failures? Let’s start with Southwest Airlines.

Bob: Southwest Airlines has actually had two failures recently. The most recent issue was a firewall failure. Even the vice president said they never know when a failure is going to happen, and fixes have been slow. This is the definition of technical debt risk.

The first outage impacted tens of thousands of travelers during the peak holiday season. At first glance, you might think it was just an unfortunate coincidence, but technical debt typically is most dangerous when there is stress on the infrastructure, so the timing of this crash wasn’t random.

Over the last few years, Southwest has been called out for its outdated systems that need upgrading. How they interact with crew members and guests is very manual and phone-based. Even the pilots and crew have been saying the systems are antiquated. Most major airlines have fully modernized their business processes, whereas Southwest has not. They knew they had technical debt, but they weren’t addressing it. This scenario is typical of most technical debt issues we see in the marketplace. You keep kicking the can down the road and crossing your fingers. 

When you start seeing technical debt being used in both financial and mainstream press as reasons for high-profile business outages, it raises the visibility of the business impact, where the IT and engineering teams aren’t the only ones talking about it. When it causes a billion-dollar outage that impacts millions of people, it’s more obvious even to business people outside of IT. It can affect application availability, firewalls, data security, and more. When one card falls, others fall too, and you never know when it’s going to happen or how many systems it will impact.

Q: What about the FAA?

Bob: The FAA failure was an issue around a damaged database file and is a good example of an aging app infrastructure. With an older monolithic architecture like the FAA has, a single issue in one location has a ripple effect all the way down, cascading to a greater issue. Had they broken down their monoliths into microservices, they would have had a more distributed architecture with greater survivability, so one outage wouldn’t cause others to shut down the system. 

The FAA knew they had an outdated application that needed to be modernized, but it was risky to change. Everyone is adding more features and trying to patch it here and there, so one problem causes so many others. 

Q: Is there a way to reduce that risk?

Bob: You have to directly measure and manage technical debt to try to understand the risk — what are the dependency chains, the downstream effects? To stay in front of that you need a technical debt analysis strategy to track architectural drift and monitor how components are dependent and interrelated. Then you can begin isolating where problems occur, and the blast area is smaller. A best practice is if there is a problem, you are able to isolate it to minimize the cascading effect. Southwest Airlines couldn’t handle the scale, but the FAA had one small problem that cascaded into a bigger issue. It’s why so many organizations are moving to a cloud-native architecture.

Q: Let’s talk about Twitter. It had less of a catastrophic impact, but it was at a minimum, an inconvenience for users.

Bob: The Twitter outage was attributed to a coding mistake. There was a lot of public discussion within the engineering teams sharing that the application has grown dramatically over the years, and it’s slow and hard to change. They traded velocity over performance, spending a lot of time trying to add more capabilities without fixing the technical debt. We see this mistake across many companies.

Twitter is now trying to make more structural changes, replacing old features with new ones, and realizing the code can’t change as quickly as the new management wants. They are trying to ramp up engineering velocity, but the applications weren’t built for that. 

With a cloud-native architecture, they could add those features more quickly with more agility, but the technical debt they’ve accumulated over the years makes it harder to make changes. They’ve taken on too much technical debt to adopt new features quickly, and the application has just become too brittle. Unfortunately, you can’t take a monolith and turn it into a cloud app magically.

Q: These are examples of technical debt risk at large organizations. Does technical debt apply to smaller companies as well?

Bob: Most definitely. If you take a look at the types of organizations we’ve just discussed, we have a 40-year-old major airline, a government entity that’s slower to modernize but has mission-critical applications, then a newer cloud-unicorn company that you’d think is technically advanced. All three share issues around technical debt that are formed for different reasons that caused high-profile issues that transcend from a technical problem to a business problem. 

What typically happens is that technical debt is only discussed inside of engineering and only surfaces when something catastrophic happens. But, all three examples are very visible, and they occur on a smaller scale at probably every company. 

Q: How can a company know they have a technical debt problem?

Bob: Technical debt issues cause many familiar symptoms, like a feature that didn’t come out on time, or you lost a key customer or lost out to a competitor, all of which are often related to your inability to respond quickly due to slow engineering velocity that’s dragged down by technical debt. You can see it occurring at a micro level that’s less visible than a total system crash. You lose a deal, a customer, or market share one drip at a time. All of those things can be because technical debt slows your ability to innovate and keep up with opportunities.

On the flip side, look at what happened to Zoom. Zoom took the pandemic as an opportunity and was able to race ahead of competitors. No one anticipated everyone going virtual. They had the agility to make those changes quickly because they were cloud-native. Other businesses were slower to respond.

What happens when pandemic-effect is over? Can you respond to the next opportunity? All those windows are built upon engineering velocity driving business agility. There is nothing worse for a CTO, senior engineer, or app owner than to have to explain to their CEO or CFO that the company can’t innovate and win because it doesn’t have engineering agility.

Q: So how do organizations typically approach the lack of engineering velocity or business agility?

Bob: Usually, they debate whether they should hire more people or less expensive resources or outsource it. They ignore technical debt and bolt on more and more features to keep trying to move faster. The problem with monoliths is there’s only so fast you can move. Having more people doesn’t always mean you can move faster. You can’t hire enough people or buy big enough machines to keep up. 

The only way to increase velocity to innovate faster is to rearchitect the product. With a monolithic architecture, you have fixed costs in terms of hardware and software infrastructure that are cost-prohibitive. We have one customer that couldn’t buy a bigger machine because it didn’t exist. Their only option was to break up the monolith into microservices to scale up. They could then afford to add resources where it helped the business, but they had more efficiency and applied the dollars they had to infrastructure licensing needs.

Q: Are budgets a significant component here?

Bob: The problem is that companies aren’t addressing technical debt because they don’t want to dedicate the resources for it – time, people, and money. They either need to add more resources or dedicate the time to fix it. Unfortunately, your resource budget isn’t likely to go up and will probably be reduced. So what do you do? 

You can just let things go and keep adding more stuff to it to make it work at the expense of fixing the debt. That works out fine until the rules change. For example, Elon comes in and says we’re going to get rid of this and add this, and then engineers say they can’t make those changes that are required to change the business model that way.

Q: So, there is a cost to carrying technical debt?

Bob: Absolutely. That’s where business planning comes in. You have to look at what technical debt is costing and build a business case to show there is ROI to modernize. How do you break out of this deadly cycle, where technical debt is going up, and innovation is going down? It requires a frank conversation. Before vFunction, there was nothing to build that business case so you could have the conversation.

Q: How does vFunction help build that business case for reducing technical debt risk?

Bob: Our goal is focused on using science and data to analyze your app, determine the most effective way to modernize it, and help you put together a business case. We tell you where to modernize, the reasons and risks, and the upside — you’re spending this percentage of your IT budget on technical debt and on innovation. We can provide those insights in just six months. 

Businesses of all sizes have to have the data, analysis and ability to understand what architectural changes they need to make to get that velocity and avoid outages that others are seeing. More importantly, you get the business velocity you need to get into a win-win situation — minimizing catastrophic events and creating a greater velocity.

Q: In the past, it was hard to quantify innovation, but vFunction can do that?

Bob: Yes. Our software puts numbers on what innovation means. Innovation is a goal, but what does your feature backlog look like in terms of features and new capabilities you want to add to your application? How much is that growing over time, and are those features working? 

If you can increase your feature velocity, that will give you a dollar amount on the other side. Will it add $1M to your bottom line? You can build a business case on feature velocity. You can also understand how much an outage would cost, or if you already have one, how fast you can make bug fixes. There is a cost to that. 

There is also a cost to run an app — high-cost hardware, software licensing, and database licensing. All have a compelling, hard dollar cost. You need a business case with a clear view of what you want to do, where you want to do it, and how long it will take, and make sure you can have a clear discussion about business value. 

Most modernization projects that have been successful have this full visibility into the advantages. That said, you have business-critical apps that need to keep running, and you can’t just flip the switch. There are a variety of best practices, like the Strangler Fig Pattern, to keep monolith alive while you modernize. It’s a risk-averse, programmatic, sequential way to move from an old pattern to a new one without having a drop in services. 

Q: How long does assessing technical debt risk take?

Bob: vFunction Assessment Hub is relatively quick, typically focusing on a core set of apps you determine are worth modernizing, that can be a handful or it could be hundreds that have a business value. Our Assessment Hub is an affordable, efficient and automated way to build the business case, taking less than an hour for one app or a few weeks for a larger application estate. 

Q: Once you understand the extent of your technical debt, then what?

Bob: vFunction Modernization Hub analysis is automated, but it involves active interaction with an architect through our Studio UI to refine and refactor the architecture. But a process that might take years to complete without vFunction takes only weeks or months with it and with higher-quality results. With Modernization Hub, you have the data and the understanding of how the architecture and dependencies improve or not with each change. 

Q: What are the costs and time associated with modernizing with Modernization Hub?

Bob: The cost and time are based on the scale of the app, so the Assessment Hub will tell you how long it will take. Some apps have millions of lines of code and tens of thousands of classes, so it takes more time. Our pricing and estimations are based on complexity and the number of classes within the app. With our service extraction capability, it’s a full, end-to-end cycle. We find a major value in visualizing the recommended service topology and refining the architecture from there. 

Q: What is the role of the architect here?

Bob: The architect stays in control, but we guide them. They can decide if they want to split out the services or combine them. We facilitate those decisions and provide guidelines and recommendations, but it’s important to use vFunction as the expert tool that helps them do their job more efficiently and clearly with observability and control on their end.

Q: Is modernization a one-and-done sort of thing?

Bob: It’s not. It’s continuous because there are always changes to the architecture and apps. But vFunction Continuous Modernization helps you baseline your architecture, monitors the metrics you need to track, and detects critical architectural drift. We alert you when something exceeds an expected baseline or threshold — anything that causes a spike in technical debt that needs to be controlled. Then, the architect can go back into the Modernization Hub to fix it. 

Q: Finally, what’s the ultimate lesson we can learn from the Southwest Airlines, FAA, and Twitter failures?

Bob: The fact that technical debt has worked its way into the business press and everyday conversation is not a good thing. It’s a warning to every business, and now that it’s so public, your business leaders will likely start asking how technical debt is being addressed. 

If you’re not tracking your technical debt, you will miss the warning signs. You’ll start to see slowdowns and glitches, business failures, and failure to meet business expectations. Every application owner is assuming and hoping these issues won’t snowball into a catastrophic failure down the line, but we are seeing more of these happening. 

It’s easy to understand it if you think of it in health terms — like an early sign of a heart attack is a stroke. If technical debt is truly something that can have a critical effect on your business, and you see warning signs, at least measure, monitor and prepare. You need a physical for your application estate. We are like an EKG, identifying where the problems are and their extent. You don’t want to wait until fixable issues grow into a catastrophe like they did with Southwest Airlines. Be proactive now, and you can proactively manage technical debt and control the risk so that it won’t stop the heart of your operations. 

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:

Red Hat and vFunction Present at Red Hat Summit 2023

Posted on June 1, 2023 by - Uncategorized

Why do application modernizations fail 79% of the time? Red Hat and vFunction answered that question at Red Hat Summit 2023 and provided three recipes for success. Co-presented by Markus Nagel, Principal Technical Marketing Manager at Red Hat and Bob Quillin, Chief Ecosystem Officer at vFunction, the session is now available on-demand on the Red Hat Summit 2023 Content Hub (registration required).

Check out the full video to see how-to details behind these recipes including:

  • Recipe #1: Shift left and use observability, visibility, tooling to understand, track, and manage architectural technical debt
  • Recipe #2: Use AI-based modernization & decomposition to assess complexity, identify domains & service boundaries, eliminate dead code, build common libraries
  • Recipe #3: Leverage the strangler fig pattern to shift traffic and workload from monolith to new microservices

Specific integration patterns detailed in the session described how to use vFunction Modernization Hub to decompose and extract one or more microservices from a monolith. This involved leveraging the vFunction Red Hat Certified OpenShift Operator and using the OpenAPI definitions generated by vFunction Modernization Hub to expose the new microservices via Red Hat 3scale API Management on OpenShift.

As a foundation, these new services would also benefit from cloud-native runtimes such as Quarkus. Alternatively, Red Hat also supports Spring Boot on OpenShift, among other available options.

To execute the Strangler Fig Pattern, the session described how to use the new Red Hat Service Interconnect (based on the open source Skupper project) to connect the remaining monolith (and possibly other legacy components) with the new microservices on OpenShift.

Details of the session include:

Session Link: https://events.experiences.redhat.com/…

Session Title: Why Application Modernizations Fail (and 3 Proven Recipes for Success)

Abstract:

Why do application modernizations fail? Attempts to modernize monolithic applications into microservices —specifically business-critical Java and .NET apps we depend on every day—can be frustrating and fraught with failure.

In this virtual session, we will:

  • Identify key reasons for failures from independent industry-based surveys.
  • Explore 3 proven recipes for successful modernization with case study examples, demonstrations. and deployments to Red Hat OpenShift.
  • Explore the role of artificial intelligence (AI)-augmented architectural (technical) debt assessment, observability-driven decomposition analysis, and strangler fig pattern rollouts.
  • Architects and product owners will learn how to use the automated analytics of vFunction AI-driven assessment and analysis of monolithic applications to deploy on Red Hat OpenShift, while significantly reducing the effort and risk of the process.

Shift Left to Avoid Technical Debt Disasters

Posted on May 24, 2023 by - Uncategorized

Can technical debt cause business disasters? Just ask Southwest Airlines: their technical debt caused a shutdown during the 2022 Christmas season that cost the company more than $1 billion, not to mention the goodwill of irate customers who were stranded by the collapse of the carrier’s flight and crew scheduling system.

Or you could ask Elon Musk, whose new Twitter acquisition suffered its own chaos-inducing disruption in March of 2023 due to what one employee described as “so much tech debt from Twitter 1.0 that if you make a change right now, everything breaks.”

As these examples indicate, unaddressed technical debt can indeed pitchfork a company into a sudden and disastrous disruption of its entire operation. That’s why for many companies, addressing the technical debt carried by the mission-critical software applications they depend on is at the top of their IT priorities list.

But identifying and reducing technical debt can be difficult. And that’s especially true of architectural technical debt, which is often even harder to isolate and fix.

In this article, we’ll examine the challenges of architectural technical debt, and see how continuous modernization, along with the “shift left” approach to quality assurance (which helps minimize that debt by beginning QA evaluations early in the development process) can substantially reduce a company’s vulnerability to technical debt disasters.

What is Architectural Technical Debt?

The Journal of Systems and Software describes technical debt as “sub-optimal design or implementation solutions that yield a benefit in the short term but make changes more costly or even impossible in the medium to long term.” Although the term has generally been applied to code, it also applies to architectural issues. The Carnegie Mellon Software Engineering Institute defines architectural technical debt similarly, in this way:

“Architectural technical debt is a design or construction approach that’s expedient in the short term, but that creates a technical context in which the same work requires architectural rework and costs more to do later than it would cost to do now.”

Architectural technical debt may be baked into an application’s design before coding even starts. A good example is the fact that most legacy Java apps are structured as monoliths, meaning that the codebase is organized as a single, non-modularized unit that has functional implementations and dependencies interwoven throughout.

Because the app’s components are all together in one place and communicate directly through function calls, this architecture may at first appear less complex than, for example, an architecture built around independent microservices that communicate more indirectly through APIs or protocols such as HTTPS.

Related: The Cost of Technical Debt and What It Can Mean for Your Business

But the tight coupling between functions in monolithic code imposes severe limitations on the flexibility, adaptability, and scalability of the app. Because functions are so interconnected, even a small change to a single function could have unintended consequences elsewhere in the code. That makes updating monolithic apps difficult, time-consuming, and risky since any change has the potential to cause the entire app to fail in unanticipated ways.

Challenges of Managing Architectural Technical Debt

Not only may initial design decisions insert architectural technical debt into apps up front, but changes that occur over time, through a process known as architectural technical drift, can be an even more insidious driver of technical debt.

Architectural technical drift occurs when, to meet immediate needs or perhaps because requirements have changed, developers modify the code in ways that deviate from the planned architecture. The result is that over time the codebase diverges more and more from the architectural design specification.

What makes such drift so dangerous is that while designed-in architectural debt can be identified by comparing the design specification against modern best practices, the ad hoc changes inserted along the way by developers are typically documented poorly—if at all. 

The result is that architects often have little visibility into the actual state of a legacy codebase since it no longer matches the architecture design specification. And that makes architectural technical debt very hard to identify and even harder to fix.

The problem is that while architects have a variety of tools for assessing code quality through, for example, static and dynamic analysis or measuring cyclomatic complexity (a metric that reveals how likely the code is to contain errors, and how hard it will be to test, troubleshoot, and maintain), they haven’t had comparable tools for assessing how an app’s architecture is evolving or drifting over time.

Why Measuring and Addressing Architectural Technical Debt is Critical

While code quality and complexity are key application health issues, architectural technical debt is an even higher level concern because unaddressed architectural deficiencies can make it very difficult, or even impossible, to upgrade apps to keep pace with the rapidly evolving requirements that define today’s cloud-centric technological environment.

For example, the monolithic architecture that characterizes most legacy Java codebases is notorious for having ingrained and intractable technical debt that imposes severe limitations on the maintainability, adaptability, and scalability of such apps.

But given the difficulty of detecting and measuring architectural technical debt, how can architects effectively address it to prevent it from eventually causing serious issues? As management guru Peter Drucker famously said, “You can’t improve what you don’t measure.”

The answer is by following a “shift left” QA strategy based on use of the advanced AI-based tools now available for detecting, measuring, monitoring, and remediating architectural debt and drift issues before they cause technical debt meltdowns.

Shifting Left to Address Architectural Technical Debt

In the traditional waterfall approach to software development, operational testing of apps comes near the end of the development cycle, usually as the last step before deployment. But architectural issues that come to light at that late stage are extremely difficult and costly to fix, and may significantly delay deployment of the app. The shift left approach originally aimed to alleviate that problem.

In essence, shift left moved QA toward the start of the development cycle—the technique gets its name from the fact that diagrams of the software development sequence typically place the initial phase on the left with succeeding phases added on the right. Ideally, the process begins, before any code is written, by assessing the architectural design to ensure it aligns with functional specifications and customer requirements.

Shift left is a fundamental element of Agile methodology, which emphasizes developing, testing, and delivering working software in small increments. Because the code delivered with each Agile iteration must function correctly, shift left testing allows verification of the design and performance of components such as APIs, containers, and microservices under realistic runtime conditions at each step of the development process.

In this context, shifting left for architecture gives senior engineers and architects visibility into architectural drift throughout the application lifecycle. It makes modernization a closed-loop process where architecture debt is always being proactively observed, tracked, baselined, and where anomalies are detected early enough to avoid disasters.

That’s especially beneficial for modernization efforts in which legacy apps are refactored from monoliths to a cloud-native microservices architecture. Since microservices are designed to function independently of one another, the shift left approach helps to ensure that all services integrate smoothly into the overall architecture and that any functional incompatibilities or communications issues are identified and addressed as soon as they appear.

The Importance of Continuous Modernization

One of the greatest benefits of legacy app modernization is that it substantially reduces technical debt. This is especially the case with monolithic apps—the process of refactoring them to a microservices architecture automatically eliminates most (though not necessarily all) of their technical debt.

But modernization isn’t a one-time process. Because of the rapid advances in technology and the quickly evolving competitive demands that characterize today’s business environment, from the moment an app is deployed it begins to fall behind the requirements curve and become out of date.

Plus, the urgency of those new requirements can put immense pressure on development and maintenance teams to get their products deployed as quickly as possible. That, in turn, often leads them to make “sub-optimal design or implementation solutions that yield a benefit in the short term.” And that, by definition, adds technical debt to even newly designed or modernized apps.

As a result, the technical debt of any app will inevitably increase over time. That’s not necessarily bad; it’s what you do about that accumulating debt that counts. Ward Cunningham, who coined the term “technical debt” in 1992, puts it this way:

“A little debt speeds development so long as it is paid back promptly with refactoring. The danger occurs when the debt is not repaid.”

That’s why continuous modernization is so critical. Without it, the technical debt carried by your company’s application portfolio is never repaid and will continue to increase until a business disaster of some kind becomes inevitable. As a recent Gartner report declares:

“Applications and software engineering leaders must create a continuous modernization culture. Every product or platform team must manage their technical debt, develop a modernization strategy and continuously modernize their products and platforms… Teams must ensure that they don’t fall victim to “drift” over time.”

Related: The Top 5 Reasons Technical Debt Accumulates in Your Business Applications

The Key to Continuous Modernization

Until recently, it’s been difficult for software development and engineering leaders to establish a culture of continuous modernization because they lacked the specialized tools needed for observing, tracking, and managing technical debt in general—and architectural technical debt in particular. But the recent advent of AI-based tools specially designed for that process has been a game changer. They enable software teams to identify architectural issues, understand their complexity, predict how much time and engineering effort will be required to fix them, and actually lead the team through the refactoring process.

The vFunction Continuous Modernization Manager enables architects to apply the shift left principle throughout the software development lifecycle to continuously identify, monitor, manage, and fix architectural technical debt problems. In particular, it enables users to pinpoint architectural technical drift issues and remediate them before they contribute to some future technical debt catastrophe.

If you’d like to know more about how an advanced continuous modernization tool can help your company avoid technical debt disasters, contact us today.

Getting a Handle on Architectural Debt

Posted on May 23, 2023 by - Uncategorized

In March 2023, Amazon.com published an article on how it rearchitected its Prime Video offering from a distributed microservices architecture to a ‘monolithic’ architecture running within a single Amazon Elastic Container Service (ECS) stack.

Despite a reduction in infrastructure cost of over 90%, the seemingly counterintuitive move generated consternation across the cloud architecture community. Monoliths are ‘bad,’ laden with technical debt, while microservices are ‘good,’ free from such debt, they trumpeted. How could Amazon make such a contrarian move?

This controversy centers on what people mean by ‘monolith,’ and why its connotation is so negative. In general parlance, a monolith is a pattern saddled with architectural debt – debt that the organization must pay back sooner or later. Based on this definition, an organization would be crazy to move from an architecture with less debt to one with more.

But as the Amazon story shows, there is more to this story – not only a clearer idea of the true nature of architectural monoliths, but also the fundamental concept of architectural debt.

Architectural Debt: A Particular Kind of Technical Debt

As I explained in an earlier article, technical debt represents some kind of technology mess that someone has to clean up. In many cases, technical debt results from poorly written code, but more often than not, is more a result of evolving requirements that existing technology simply cannot keep up with.

Architectural debt is a special kind of technical debt that indicates expedient, poorly constructed, or obsolete architecture.

Even more so than the more familiar source code-related technical debt, architectural debt is often a necessary and desirable characteristic of the software architecture. The reason: too much software architecture in the early phases of a software project can cause systemic problems for the initiative that lead to increased costs and a greater chance of project failure.

In fact, the problem of architecture that is too much and too early, aka ‘overdesign,’ is one of the primary weaknesses of the waterfall methodology.

Instead, modern software principles call for ‘just enough’ or ‘just in time’ architecture, expecting architects to spend the minimum time on the task necessary to guide the software effort. If a future iteration calls for more or different architecture, then the architect should perform the additional work at that time.

Good vs. Bad Architectural Debt

Given such principles, you’d think that Amazon’s move to a monolith would be better received.

After all, the reason Amazon’s architects chose microservices in the first place was because such a decision was expedient and didn’t require excessive architectural work. The move to a monolith was simply a necessary rearchitecture step in a subsequent iteration.

Where the confusion arose was over the difference between this ‘good’ type of architectural debt – intentional ‘just enough, just in time’ architecture as part of an iterative design – and the ‘bad’ type: older, legacy architectures that may have served their purpose at the time, but are now obsolete, leading to increased costs and limited flexibility.

Examples of Good vs. Bad Architectural Debt

It may be difficult to distinguish between the two types of architectural debt. To help clarify the differences, here are two examples.

Example #1: Addressing good architectural debt.

An organization is implementing an application which will eventually have a global user base. The architects consider whether to architect it to support internationalization but decide to put this task off in the interests of expediency.

Eventually the development team must rework the app to support internationalization – a task that takes longer than it would have had they architected the app to support it initially.

Nevertheless, the organization was able to put the application into production more quickly than if they had taken the time to internationalize it, thus bringing in revenue sooner and giving themselves more opportunity to figure out how they should improve the application.

Example #2: Addressing bad architectural debt.

An organization struggles with the limitations of its fifteen-year-old Java EE application, running on premises on, say, Oracle WebLogic. The app is now too inflexible to meet current business needs, and the organization would like to move the functionality to the cloud – a migration that WebLogic is poorly suited for.

The organization must first take inventory of their existing architecture, requiring architectural observability that can delineate the as-is architecture of the application, how it’s behaving in production, and what its most urgent problems are. The architecture team must also establish an architectural baseline and then determine how much the as-is architecture has drifted from it.

At that point, the organization must implement a modernization strategy that considers the technical debt inherent in the internal interdependencies among architectural elements (Java classes, objects, and methods in this case). Only then can it make informed modernization decisions for the overall architecture as well as the software components that make up the application.

Architectural observability from tools like the vFunction Architectural Observability Platform is essential for understanding and thus dealing with bad architectural debt. Such debt is difficult to identify and even more difficult to fix. In some cases, fixing architectural debt isn’t worth the trouble – but without architectural observability, you’ll never know which architectural debt you should address.

The Intellyx Take

The term ‘monolith’ is saddled with all the negative connotations of bad architectural debt, but as the Amazon example illustrates, such connotation paints the term with too wide a brush.

In reality, what constitutes a monolith has changed over time. Object-oriented techniques relegated procedural programs to the status of monolith. Today, cloud native architectures apply the label to the object-oriented applications of the Java EE days.

Understanding architectural debt, therefore, goes well beyond the labels people put on their architectures. With the proper visibility, architects can differentiate between good and bad architectural debt and thus begin the difficult but often necessary process of modernization in order to get a handle on their organization’s architectural debt.

Copyright © Intellyx LLC. vFunction is an Intellyx customer. None of the other organizations mentioned in this article is an Intellyx customer. Intellyx retains final editorial control of this article. No AI was used in the production of this article.

Image credit: Atom.D.

Benefits of Adopting a Continuous Modernization Approach

Posted on May 16, 2023 by - Uncategorized

In 2021, the Standish Group published a report on the effectiveness of different approaches to software modernization. The report looked at the efficacy of replacing legacy solutions with entirely new code or using existing components as a basis for modernization. The authors also identified an approach they called “Infinite Flow,” where modernization was a continuous process and not a project with a start and end date.

The Standish Group’s definition of infinite flow mimics that of continuous modernization (CM). CM is a continuous process of delivering software updates incrementally. It allows developers to replace legacy software iteratively with less user disruption. Both definitions focus on the ongoing nature of software delivery and its organizational impact.

According to their analysis, the report authors determined that continuous flow processes deliver more value than other methodologies, such as agile or waterfall. They calculated that waterfall projects are 80% overhead and only return a net value of 20%. In contrast, continuous modernization operates with 20% overhead and delivers an 80% net value. They also calculated that 60% of customers were disappointed in the software delivered at the end of a large development effort. In comparison, only 8% of customers felt the same with continuous development processes.

If continuous modernization delivers a more significant net value and increases customer satisfaction, why aren’t more organizations using the methodology as they replace legacy systems? Let’s take a closer look at this strategy to determine why more companies don’t realize the benefits of CM.

What is Continuous Modernization?

The Information Systems Audit and Control Association (ISACA) defines continuous modernization as a strategy to evolve an existing architecture continuously and incorporate emerging technologies in the core business operating model. With CM, organizations develop solutions in increments that encourage frequent releases where the software is monitored and refined, feeding back into the development cycle. 

The approach allows companies to gradually replace aging technologies that pose business risks. It enables businesses to add features and functionality to existing systems without disrupting operations. However, CM is more than a development strategy. It is a mindset.

Traditional software development is project-based. A scope of work is defined with a start and end date. It doesn’t matter if the development method is waterfall or agile. Cumulative software updates are released on a pre-defined date. After installation, bugs may be identified and fixed. Some flaws are added to the scope of work for the next release.

With CM, on the other hand, software development becomes part of a continuous improvement mindset where each iteration enhances the existing software. New software is deployed monthly, weekly, or daily. Unlike project-based development, changes are not withheld until a project scope has been completed. The steady stream of updates requires a cultural shift.

Related: Navigating the Cultural Change of Modernization

Key performance indicators (KPIs) for software development and measurement methods no longer apply. Testing procedures are automated to keep pace with incremental software releases. End users see small changes in the user interface or functionality instead of massive changes delivered simultaneously. If organizations are to realize the following benefits of CM, they need to address the cultural changes necessary to support a continuous improvement model.

What Are the Benefits of CM?

The 2021 Standish authors indicated that the flow-like modernization methodology had the following benefits:

  • Modernization using a series of microprojects had better outcomes than a single large project.
  • Microprojects achieved greater customer satisfaction because of built-in feedback loops.
  • Microprojects delivered a higher return of value.
  • Modernization using continuous improvement reduced risk and monetary loss.
  • Continuous modernization has a higher degree of sustainable innovation.
  • Continuous modernization increases application life.

Outcomes were evaluated in terms of time, budget, and customer satisfaction. In general, smaller projects in a continuous improvement model delivered better outcomes than more traditional large projects, especially in the areas of customer satisfaction, net value, and financial loss.

Increased Customer Satisfaction

Continuous modernization is less disruptive to operations. When large projects are delivered, it often results in downtime. Even if the software is installed after hours, the massive changes usually require user training. Struggling to learn the software while performing their job frustrates employees. 

Since most large projects do not solicit extensive user input during development, the updated features may not operate as users expected. Customers become disgruntled when they are told the feature operates as designed, so it isn’t a bug and won’t be addressed until the next release.

With microprojects, small changes are made incrementally with minimal impact on user operations. Employees aren’t trying to learn new functionalities while performing their job. Soliciting feedback from users as changes are deployed means modifications can be incorporated into the iterative process.

Reduced Risk

Old code is risky code. Who knows what is lurking in those undocumented modules? Depending on the age of the software, everyone associated with the original project may have left the company. Suddenly organizations are faced with a knowledge deficit. How can they support the software if no one understands the code?

Twitter is an excellent example of the impact technical debt and knowledge deficit can have on a company. Long before Elon Musk took over Twitter, employees complained that parts of the application were too brittle. Some even suggested that the technical debt was too extensive, requiring a complete rewrite. Then, Musk began his widespread staff reduction. As a result, fewer employees were available to keep brittle code functional.

In March 2023, Twitter had an operational failure. Users were unable to open links. The API that allowed the data interchange was not working. After service was restored, the source of the failure was found to be an employee error. The one engineer assigned to the API made an incorrect configuration change. Removing old code reduces the risk of a disastrous outcome from a simple configuration change. 

Reduced Technical Debt

Technical debt is no different than financial debt. At some point, it must be repaid. If it goes untouched, it only accumulates until an organization is no longer viable. A recent survey found that technical debt inhibits 70% of a company’s ability to innovate. 

CM allows developers to gradually replace legacy code that contributes to technical debt. It also keeps the debt from growing. For example, companies that release software updates once a year accumulate debt while they are writing new code. Given the exponential rate of digital adoption, the technical deficit can easily double in a year.

Following a continuous modernization approach, developers are consistently replacing older code. Because the incremental updates require less test time, new code can be delivered faster. Changes in methodology or coding standards can be incorporated into the cycling development list to minimize the amount of added technical debt.

Limited Monetary Loss

Continuous modernization incorporates user feedback into the development process. With feedback, developers can adjust the software to better reflect user needs. This process minimizes monetary loss that can result from a comprehensive software update.

Large development projects that follow the traditional management path consume significant resources before the end user sees the software. If the final product does not meet expectations, companies run the risk of bringing a product to market that lacks key features. Costs for reworking the software are added to the original expenditures. Businesses can find themselves selling solutions at a loss if the market will not support a price increase.

Related: How Opportunity Costs Can Reshape Measuring Technical Debt

With large projects, the opportunity costs can be significant if resources are tied up reworking software after delivery. Instead of pursuing an innovative solution, developers are occupied with existing development. Iterative development allows for immediate feedback so course corrections can occur early in the development process. If the product fails to meet market expectations, organizations can terminate the effort before incurring significant losses.

Sustained Innovation

Adopting a continuous improvement mindset allows developers and architects to implement a continuous modernization methodology for software development. The process enables programmers, DevOps, and engineers to deliver innovative solutions as part of their workday.

The iterative approach lets developers test innovative solutions as early in the process as possible and receive user feedback to ensure acceptance. Freed from reworking existing code and compensating for technical debt, development staff can spend more time exploring opportunities.

Limiting financial loss and reducing risk from outdated code provide businesses with added resources to investigate new markets. With a cost-effective methodology for modernization, organizations can deliver innovative solutions that consistently meet customer expectations.

Realize the Benefits of Continuous Modernization

To realize the benefits of continuous modernization, businesses must establish and measure KPIs. They must look for tools that can refactor applications and assess technical debt. 

vFunction’s Assessment Hub analyzes applications, identifies technical debt, and calculates its impact. The Modernization Hub helps architects transform monoliths into microservices. The newly released Continuous Modernization Manager lets architects shift left and address issues that could impede ongoing modernization. To see how we can help with your modernization project, request a demo today.

vFunction Recognized in the Gartner® 2023 Report: Measure and Monitor Technical Debt With 5 Types of Tools

Posted on May 15, 2023 by - Uncategorized

We’re excited to share that vFunction has been named in the Gartner 2023 Measure and Monitor Technical Debt With 5 Types of Tools. According to Gartner, “Growing technical debt negatively impacts feature delivery, quality, and predictability of software applications. Software engineering leaders should introduce tools to proactively measure and monitor technical debt at both the code level and the architectural level.”

As stated by Gartner in their introduction:

“Technical debt often goes undetected early in product development, and software engineering teams often deprioritize technical-debt remediation to instead focus on quickly delivering new features.

Eventually, technical debt accumulates to a critical mass. At this point, the software becomes unstable, customers become dissatisfied and the product fails. This leads to large cost overruns and potentially fatal consequences for organizations.

Software engineering leaders want to mitigate these risks. They want to understand how to measure and monitor technical debt, and which types of tools their teams can use. Use this research to guide your choice of tools for measuring and monitoring your technical debt at both the component or code level, and the software architecture level.”

Gartner further describes:

“Static code analysis tools cannot provide high-abstraction-level visibility to identify technical debt in the architecture. The code-and-component-level technical debt is usually the easiest type of debt to measure and pay down. At the same time, the architectural-level debt has a much higher impact on overall product quality, feature delivery lead time and other metrics. Unfortunately, it also takes the most effort to fix.”

Recognized as an Architecture Technical Debt Analysis Tool, vFunction analyzes, baselines, continuously observes, and helps fix architectural technical debt and drift problems before they can result in high profile business outages or shutdowns.

Newly launched, vFunction Architectural Observability Platform is designed to give application architects the observability, visibility, and tooling they need to understand, track, and manage architectural technical debt as it develops and grows over time. This shifts architectural observability left into the ongoing software development lifecycle from an architectural perspective to manage, monitor, and fix application architecture anomalies on an iterative, continuous basis.

In the report, Gartner’s recommends:

“To help their organizations to successfully measure and monitor technical debt, software engineering leaders should:

  • Avoid compromising code quality and application delivery by proactively measuring and monitoring technical debt at the code level.
  • Prevent time-consuming architectural rework by introducing tools to analyze architectural technical debt and monitor the amount of debt in their software architecture.

View the full Feb 2023 report Measure and Monitor Technical Debt With 5 Types of Tools (for Gartner subscribers).

GARTNER is a registered trademark and service mark of Gartner, Inc. and/or its affiliates in the U.S. and internationally and is used herein with permission. All rights reserved.

Note: Gartner does not endorse any vendor, product or service depicted in its research publications, and does not advise technology users to select only those vendors with the highest ratings or other designation. Gartner research publications consist of the opinions of Gartner’s research organization and should not be construed as statements of fact. Gartner disclaims all warranties, expressed or implied, with respect to this research, including any warranties of merchantability or fitness for a particular purpose.

7 Pitfalls to Avoid in Application Refactoring Projects

Posted on May 12, 2023 by - Uncategorized

Every software development project has three constraints—time, resources, and quality. Knowing how to balance them is at the core of delivering consistent success. A well-balanced project resembles an equilateral triangle where the same stability is available no matter which side forms the base. 

Over time, even the most balanced software loses stability. New features are added, and old functionality is disabled. Developers come and go, reducing team continuity. Eventually, the equilateral triangle looks more like an isosceles with a significant amount of technical debt to manage. That’s when refactoring projects often enter the development process.

What is a Refactoring Project?

Refactoring enables software teams to re-architect applications and restructure code without altering its external behavior. It may involve replacing old components with newer solutions or using new tools or languages that improve performance. These projects make code easier to maintain by eliminating dead or duplicate code and complex dependencies.

Incorporating refactoring into the development process can also extend the life of an application, allowing it to live in different environments, such as the cloud. However, refactoring doesn’t always reshape code to a well-balanced equilateral triangle. Plenty of pitfalls exist that can derail a project, despite refactoring best practices. Let’s look at seven mistakes that can impact the outcome of an application refactoring project.

Mistake #1: Starting with the Database or User Interface

When modernizing a monolith, there are three tiers you can focus on: the user interface, the business logic, or the data layer. There’s a temptation to go for the easy wins and start with the user interface, but in the end, you may have a shinier user interface, but you are facing the same issues that triggered the modernization initiative in the first place: exploding technical debt, decreasing engineering velocity, rising infrastructure and licensing costs, and unmet business expectations.

On the other hand, the database layer is also a first target to modernize or replace due to escalating licensing and maintenance costs. It would feel great to decompose a monolithic database into smaller, cloud-native data stores using faster, cheaper open source-based alternatives or cloud-based data layer services. But unfortunately, that’s putting the cart before the horse. In order to break down a database effectively, you need to first decompose the business logic that uses the data services.

By decomposing and refactoring the business logic you can create microservices that eliminate cross-table database dependencies and pair new independent data stores with their relevant microservices. Likewise, it’s easier to build new micro-frontends for these independent microservices once they have been decomposed with crisp boundaries that minimize or eliminate interdependencies.

The final consideration is managing risk. Your data is gold and any changes to the data layer are super high risk. You should only change the database once, and only after you have decomposed the monolithic business logic into microservices with one data store per microservice.

Focusing on the business logic first optimizes microservice deployment to reduce dependencies and duplication. It ensures that the data layer is divided to deliver a reliable, flexible, and scalable design.

Mistake #2: Boiling the Ocean

Boiling the ocean means complicating a task to the point that it is impossible to achieve. Whether focusing on minutiae or allowing project creep, refactoring projects can quickly evolve into a mission impossible. Simplifying the steps makes it easier to control.

One common mistake in refactoring is trying to re-architect an entire application all at once. While a perfect, fully cloud-native architecture could be the long-term goal, a modernization best practice should be to select one or a small number of domains or functional areas in the monolith to refactor and move into microservices. These new services might be prioritized by their high business value, high costs, or shared platform value. Many very successful modernization projects only extract a key handful of services and leave the remaining monolith as is to

For example, instead of jumping into a more complex service-mesh topology first, take a more practical,  interim step with a hub and spoke topology that centralizes traffic control, so messages coming to and from spokes go through the hub. The topology reduces misconfiguration errors and simplifies the deployment of security policies. It enables faster identification and correction of errors because of its consolidated control.

Trying to implement a full-mesh topology increases connections, complicating monitoring and troubleshooting efforts. Once comfortable with a simpler topology,  then look at a service mesh. Taking a step-by-step approach prevents a mission-impossible scenario. 

Mistake #3: Ignoring Common Code 

Although refactoring for microservices encourages exclusive class creation, it also discourages re-inventing the wheel. If developers approach a refactoring project assuming that every class must be exclusive to a single service, they may end with an application full of duplicate code.

Related: What Are the Benefits of Microservices Architecture?

Instead, programmers should evaluate classes to determine which ones are used frequently. Putting frequently used code into shared or common libraries makes it easier to update and reduces the chances that different implementations may appear across the application.

However, common libraries can grow uncontrolled if there are no guidelines in place as to when and when not to turn a class into a shared library. Modernization platforms can detect common classes and help build rational and consistent common libraries. Intelligent modernization tooling can ensure common code is not ignored while minimizing the risk of a library monolith.

Mistake #4: Keeping Dead Code Alive

Unreachable dead code can be commonly detected by a variety of source code analysis techniques. The more dangerous form of dead code is code that is still reachable but is no longer used in production. This can be caused by functions that become obsolete, get replaced, or merely forgotten as new services are added. Using static and dynamic analysis, developers can identify reachable dead code or “zombie code” based on observability tooling that compares actual production and user access to static application structure.

This type of dead code exists because many coders are afraid to touch old code as they are unsure of what it does or what it was intended to do. Rather than risk disrupting the unknown, they let it continue. This is just another example of technical debt that piles up over time. 

Mistake #5: Guessing on Exclusivity

Moving toward a microservice architecture means ensuring that application entities such as classes, beans, sockets, or transactions appear in only one microservice. In other words, every microservice performs a single function with clearly defined boundaries.

The decoupling of functionality allows developers to build, deploy, and scale applications independently. The concept enables faster deployments with lower risk than older monolithic applications. However, determining the level of exclusivity can be challenging.

Intelligent modernization tooling can analyze complex interdependencies and help design microservices that maximize exclusivity. Without automated tools, this is a long, manual, painstaking process that is not based on measurements and analytics but most often relies on trial and error.

Mistake #6. Forgetting the Architecture

Refactoring focuses on applications. How efficiently does the code accomplish its tasks? Is it meeting business requirements for agility, reliability, and resiliency? Without looking at the architecture, improvements may be limited. Static code analysis tools will help identify common code “smells,” but they ignore the architecture. And architectural technical debt is the biggest contributor to cost, slow engineering velocity, sluggish performance, and eventual application failures.

Related: What Architects Should Know About Zombie Code

System architects lack the tools needed to answer questions regarding performance and drift. Until architectural constructs can be observed, tracked, and managed, no one can assess the impact it has on refactoring. Just like applications, architecture can accumulate technical debt.

Architectural components can grow into a web of class entanglements and long dependency chains. It can exhibit unexpected behavior as it drifts away from its original design. Unfortunately, without the right tools, technical debt can be hard to identify, let alone quantify. 

Mistake #7. Modernizing the Wrong Application

Assessing whether you should modernize and refactor an application in the first place is the critical first step. Is the application still important to the business? Can it be more easily replaced by a SaaS or COTS alternative? Has the business changed so dramatically that I should just rewrite it? How much technical debt is the app carrying and how hard will it be to refactor?  

Assessment tools that focus on architectural technical debt can help quantify project scope in terms of time, money, and resources. When deployed appropriately, refactoring can help project managers break down an overwhelming task into smaller efforts that can be delivered quickly. 

Building an Equilateral Triangle

When software development teams successfully manage the three constraints of time, quality, and resources, they create a well-balanced solution that is delivered on time and within budget, containing the requested features and functionality. They have momentarily built an equilateral triangle.

Creating an Equilateral Triangle with Automation

With AI-powered tools, refactoring projects will accelerate. Java or .NET developers can refactor their monoliths, reduce technical debt, and create a continuous modernization culture. If you’re interested in avoiding refactoring pitfalls, schedule a vFunction demo to see how we can help.

Why Organizations Add App Modernization to their CCOE

Posted on April 18, 2023 by - Uncategorized

To keep pace in their marketplace, many businesses today are attempting to modernize their business and the legacy apps they depend on by moving them to the cloud. But experience has shown that migrating workloads requires a structured framework to guide developers and IT staffers in this new environment. That’s what the cloud center of excellence (CCOE) is all about. According to Gartner, a CCOE is the optimal way to ensure cloud success.

Simply lifting and shifting legacy software as-is to the cloud still leaves you with a monolith and merely changes the location of your problem. Most legacy apps can run fine in the cloud but can’t take advantage of  today’s cloud native ecosystem and managed services, and moving them unchanged to the cloud does little to fix their issues. That’s why application modernization, which restructures apps to give them cloud-native capabilities, must be an essential component of any sound cloud strategy.

Application modernization can itself be a complex and difficult process: the historical failure rate for such projects is 74%. But by incorporating a specific application modernization focus into your CCOE, you can avoid common pitfalls, enforce best practices, and lay a firm foundation for success.

What Is a Cloud Center of Excellence?

Amazon Web Services (AWS) offers a good definition of a CCOE:

“A Cloud Center of Excellence (CCoE) is a cross-functional team of people responsible for developing and managing the cloud strategy, governance, and best practices that the rest of the organization can leverage to transform the business using the cloud.”

The cloud center of excellence guides the entire organization in developing and executing its approach to the cloud. According to the AWS definition, the CCOE has three main responsibilities:

1. Cloud strategy

Your cloud strategy outlines the general approach, ground rules, and tools your organization will use in moving software and workflows to the cloud. It defines the business outcomes you want to achieve and establishes the technical standards and guidelines you’ll follow, taking into account issues such as costs vs benefits, risks, organizational capabilities, and legal or compliance requirements.

2. Governance

Red Hat defines cloud governance as “the process of defining, implementing, and monitoring a framework of policies that guides an organization’s cloud operations.” A governance regime will include specific rules and guidelines that aim at minimizing complexity and risk by defining how individuals and teams in your organization use cloud resources.

3. Best practices

Cloud best practices often differ substantially from those developed in on-site data centers. So, a fundamental part of a CCOE’s responsibility is to introduce developers and IT staffers to practices that are optimized for the cloud environment.

The Importance of Application Modernization

Because today’s market environment is highly dynamic, companies must be able to quickly respond to changes in customer requirements or other aspects of the competitive landscape. But legacy software, by its very nature, is difficult to adapt to meet new requirements.

Legacy apps are typically monolithic in structure (the codebase is organized as a single unit of perhaps millions of lines of code with complex dependencies interwoven throughout). As a result, such apps are usually hard for modern developers to understand and can be so brittle that even small changes might introduce downstream issues that bring the entire system to a screeching halt.

Plus, because these older apps were normally designed to operate as a closed system, integrating them into modern interdependent cloud managed services can be difficult and complex.

But many organizations still depend on these technologically ancient apps for some of their most business-critical processing, so they can’t simply be retired. The alternative is to modernize them by refactoring the monolithic code into a cloud-native, microservices architecture.

The effect of that kind of modernization (as contrasted with simply moving apps to the cloud with little change) is to give you a suite of re-architected applications that, while maintaining continuity for users, have the flexibility to be easily updated to meet new business requirements.

Why App Modernization Should Be a Core Competency of Your CCOE

Your cloud center of excellence should be your organization’s acknowledged authority on all things cloud. And application modernization is all about restructuring your legacy apps so that they can integrate smoothly into the cloud ecosystem.

Related: Why Modernize Legacy Applications?

Refactoring legacy apps to a cloud-native architecture is an inherently complex process that demands a high degree of expertise in architecture, design, cloud technology and operations. That’s why it’s critical that your CCOE also function as an MCOE (modernization center of excellence). Otherwise, your modernization efforts are very likely to struggle, and you stand a good chance of adding a percentage point or two to that 74% of app modernization projects that fail to meet their goals.

Not only will your CCOE/MCOE provide the fundamental cloud-related technical expertise and guidelines that underpin any successful effort to translate workflows to the cloud, but it must also help reshape your entire IT organization to fit the technological and operational requirements of the cloud environment.

For example, when a company’s modernization efforts lack the guidance and governance that an MCOE should provide, the organization is very likely to run afoul of Conway’s Law. This maxim, formulated in 1967 by software expert Melvin Conway, declares that:

Any organization that designs a system (defined broadly) will produce a design whose structure is a copy of the organization’s communication structure.

The practical effect of Conway’s Law is that to be effective, your modernization teams must be restructured to reflect a whole new set of technological and organizational imperatives imposed by the cloud environment. In other words, to successfully refactor legacy apps to a microservices architecture you should reorganize your development teams based on the way cloud-based microservices work. Neglecting to restructure your development organization based on specific cloud-native technological patterns is an almost sure recipe for failure. As software engineer Alex Kondov so graphically puts it:

“You can’t fight Conway’s Law… Time and time again, when a company decides that it doesn’t apply to them they learn a hard lesson… If the company’s structure doesn’t change, the software will slowly evolve into something that mirrors it.”

Reshaping your entire IT operation (and by extension your organization as a whole) should not be undertaken lightly. It should only be done based upon authoritative guidance provided by a team that has an acknowledged depth of experience and expertise; in other words, a well-established and respected CCOE/MCOE.

Implementing a CCOE/MCOE is an Emerging Best Practice for Successful Companies

Today more and more companies are recognizing the critical necessity of having an effective CCOE/MCOE organization to guide their modernization efforts.

For example, an IDC report relates the experience of a large logistics company that failed three times in its efforts to move applications and workflows to the cloud. But it succeeded on its fourth attempt “when it created a multi-persona cloud center of excellence team responsible for architecture, automation, governance, operations, and unified delivery model.”

This experience is far from unique—other well-known companies, such as Dow Jones, have reported similar success stories. So, it’s not surprising that in a 2022 survey of corporate cloud infrastructure stakeholders an impressive 90% of respondents said they either have or plan to institute a cloud center of excellence. According to Computerworld, 64% of SMBs (small and medium-sized businesses) have already implemented CCOE-like teams.

Next Steps: Create or Upgrade Your MCOE

Ideally, you should have a CCOE/MCOE organization in place from the very beginning of your company’s modernization journey. But even if you’ve already started without an MCOE, it’s critical  for long-term success that you initiate one as soon as possible.

If you already have an established CCOE/MCOE, you’ll want to focus on ensuring that it has the requisite skills, expertise, experience, mandate, and perhaps most important, management backing to provide authoritative leadership for your organization.

Related: Common Pitfalls of App Modernization Projects

If, on the other hand, you have not yet instituted an MCOE (or an MCOE focus within your CCOE), now’s the time to put one in place. But how do you get started?

Getting Started

Whether you’re starting or upgrading your CCOE/MCOE, there are a couple of essential steps you should take.

The first and most important step is to ensure that your company’s executive management is visibly committed to the program. The CCOE/MCOE team will not only require budget and staffing resources, but must also have clear authority to set and enforce uniform technical and operational guidelines that apply to all cloud and modernization initiatives across the organization.

Then you must assemble and train your team, ensuring that it either has or can tap into the highest levels of cloud-related technical skills. Remember that your CCOE/MCOE team must not only be able to provide authoritative guidance concerning industry-wide technical best practices, but must do so within the context of your organization’s unique culture, goals, and cloud strategy.

But if your company is like most, you’re likely to discover that your in-house staff simply doesn’t possess all the experience and skills required to build a CCOE/MCOE that can be effective at providing expert cloud guidance and governance companywide. The best way to ensure that your team can tap into all the technical skills and tools it needs is to partner with another company that specializes in cloud and modernization technologies.

vFunction not only offers industry-leading experience and expertise in cloud-based application modernization, but also provides an advanced, automated modernization platform that can deliver data-based assessments of the modernization requirements of your legacy apps, and then substantially automate the process of refactoring those apps into microservices.

If you’re ready to take the next step in creating or upgrading your CCOE/MCOE team, vFunction can help. Please contact us today.

Shift Left for Architects with Continuous Modernization

Posted on April 4, 2023 by - Uncategorized

vFunction today launched the Continuous Modernization Manager (CMM), a new product for architects and developers to continuously monitor, detect, and pinpoint application architecture drift issues before they cause technical debt meltdowns. vFunction CMM enables software architects to shift left and prevent technical debt disasters by baselining, observing, pinpointing, and alerting on application architecture drift issues before they result in business catastrophes like we’ve seen with Southwest Airlines, Twitter, FAA, and countless, unnamed others. Read the full press release.

Architectural Technical Debt

Architectural technical debt accumulates unobserved in the shadows until disaster strikes – literally a silent killer for business. Application architects, up to this point, have lacked the architectural observability, visibility, tooling to understand, track, and manage architectural technical debt. This has resulted in not only technical problems such as architectural drift and erosion but numerous large and small disasters.

So what is architectural technical debt? It’s the accumulation of architectural components, decisions, and drift that results in “a big ball of mud” that architects are unable to see or track – making it essentially an opaque “black box.” Architectural technical debt consists of class entanglements, deep dependencies, dead-code, long dependency chains, dense topologies, and lack of common code libraries. Architectural debt is NOT source code quality or cyclomatic complexity, although these are critical technical debt elements to track and manage.

Architectural technical debt is hard to find and harder to fix. It affects product quality, feature delivery lead time, testing times, and very importantly it is the primary predictor of modernization complexity – how hard will it be to modernize (refactor or re-architect) this application. Peter Drucker established one of the most basic business principles when he stated, “You can’t improve what you can’t measure.” He also emphasized that you can’t stop at measurement, you need to also manage it. Architectural debt has been hard to measure thus hard to find and fix. Your need to observe the architecture, baseline, and detect architectural drift and then apply intelligent modernization tooling & techniques to manage the architectural anomalies.

“One of the most critical risks facing organizations today is architectural technical debt,” said Jason Bloomberg, Managing Partner of analyst firm Intellyx. “The best way to keep such debt from building up over time is to adopt Continuous Modernization as an essential best practice. By measuring and managing architectural technical debt, software engineering teams can catch architectural drift early and target modernization efforts more precisely and efficiently.”

Architectural Observability

Observable architecture is the goal. Today, architects lack the observability, visibility, tooling to understand, track, and manage architectural technical debt. They are looking to answer questions like:

  • What is the actual architecture of my monolith?
  • How is it behaving in production?
  • What’s my architectural baseline?
  • Has the app architecture drifted from the norm?
  • Do I have a major architecture issue I need to fix now?
  • Where is it and how do I fix it?

If I can’t identify my core services, their key dependencies, my common classes, or my highest debt classes, and the relevant service exclusivity, I’m running blind to the software development lifecycle from an architectural perspective.

Shift Left for Architects

vFunction Continuous Modernization Manager lights up the application black boxes and ball of mud apps – making the opaque transparent – so architects can shift left into the ongoing software development lifecycle from an architectural perspective.  This allows them to manage, monitor, and fix application architecture anomalies on an iterative, continuous basis before they blow up into bigger issues. CMM observes Java and .NET applications and services to first baseline the architecture, set baselines, and monitor for architectural drift and erosion to detect critical architectural anomalies including:

  • New Dead Code Found: detect emerging dead code in applications indicating that unnecessary code has surfaced in the application or the baseline architecture drifted and existing class or resource dependencies were changed.  
  • New Service Introduced: Based on the observed baseline service topology, when a new service has been detected vFunction will identify and alert that a new domain or major architectural event has occurred.
  • New Common Classes Found: Building a stable, shared common library is a critical modernization best practice to reduce duplicate code and dependencies. Newly identified common classes can be added to a common library to prevent further technical debt from building up.
  • Service Exclusivity Dropped: vFunction measures and baselines service exclusivity to determine the the percentage of independent classes and resources of a service, alerting when new dependencies are introduced that expand architectural technical debt.
  • New High-Debt Classes Identified: vFunction identifies the highest technical debt classes that are the highest contributors to application complexity. A “high-debt” class score is determined by its dependents, dependencies, and size and pinpoints a critical software component that should be refactored or re-architected.

Users will be notified of changes in the architecture through Slack, email, and vFunction Notifications Center. Through vFunction Continuous Modernization Manager, architects will be able to configure schedules for learning, analysis and the option to configure baseline measurements.

New in Modernization Hub and Assessment Hub

In addition, the newest release of vFunction Modernization Hub has added advanced collaboration capabilities to enable modernization architects and teams to more easily work together. New analytics also pinpoint the highest technical debt classes to focus the refactoring priorities. vFunction Assessment Hub has added a new Multi-Application Assessment Dashboard to analyze technical debt across a broad application portfolio.

Newly announced, vFunction Assessment Hub now includes a Multi-Application Assessment Dashboard that tracks and compares different parameters for 100’s of applications. Multiple applications can be analyzed at a glance for technical debt, aging frameworks, complexity, state, and additional architectural factors.

Also new in vFunction Modernization Hub 3.0 are a set of collaboration features for modernization teams to more effectively collaborate to avoid conflicts and improve clarity, working in parallel on different measurements, and then later merging them into one measurement. A user can protect services they wish to keep unmodified, preventing conflicts when multiple teams are working on the same measurement, especially when adding or removing classes to common areas.

Modernization is Not Linear: It’s a Continuous Best Practice

The most important takeaway from this announcement is that modernization is not a one-and-done project. It needs to be an iterative, cyclical best practice process that requires teams to adopt and commit to a culture of continuous measurement and improvement – led by architects shifting-left into their development processes and taking firm ownership of their actual architectures. Create observable architecture through architectural observability and tooling that catches architectural drift before it leads to greater issues. We’ve all seen what can happen if you let the silent killer of architectural technical debt continue to lurk in the shadows. Shine a light on it, find it, fix it, and prevent future monoliths from ever forming again.