Guest: Moti Rafalin (LinkedIn)
Company: vFunction (Twitter)
Show: Newsroom

“Technical debt is the biggest off-balance sheet liability that organizations have. With architectural observability, chief architects will be able to quantify, measure, and remediate that technical debt. That is really what we’re trying to do here.” – Rafalin

In this episode of TFiR: Newsroom, vFunction Co-Founder and CEO Moti Rafalin shares the latest iteration of vFunction with Architectural Observability and how it helps companies propel their journey to modernization.

On Architectural Technical Debt:

• Architecture is how the business logic of applications is structured.
• Architectural technical debt is the accumulation of architectural decisions and implementations that lead to complexity, which hampers the release pace, innovation, and scalability.
• According to Gartner, by 2026, 80% of all technical debt will be architectural technical debt.

Current Trends in the Market:

• There are many observability tools out there that help DevOps and developers identify performance issues, network observability tools for network managers, or anomaly detection tools for security. However, there is nothing out there for architectural observability.
• The architect’s role is being marginalized to a certain degree because it’s very hard to enforce architecture when you’re releasing once a day or once a week. The architect lacks tools to participate in the agile development world. They can do code reviews, they can impose coding standards, but they don’t really understand what’s happening out there in the field once the software is deployed in production.
• The market is still in the early stages of the modernization journey. Some organizations may have lifted and shifted their applications to the cloud, but they’re still not modern and they’re not cloud native. They’re not able to get the maximum value from the cloud and there are obviously still many workloads on prem.
• CIOs and heads of technology, specifically, are reluctant to allocate massive amounts of resources, be it capital and people, for modernization projects because many of these modernization projects fail.
• In terms of modernization initiatives, not everyone wants to immediately decompose the monolith into microservices.
• Some organizations just want to decompose to 1-4 services to get 80% of the value.
• Some just want to improve the architecture of their existing monolith, so that the modularity is better, there’s less cross-domain pollution, the dependencies on the database are reduced, and they can still release the software at a fast pace.
• Some already have modernized applications and they want to prevent the accumulation of technical debt on those microservices.

What’s New:

• vFunction started out by developing a modernization platform that helped companies understand monolithic applications and transform them into microservices.
• Today, it is an AI-driven architectural observability and automation platform that helps companies manage technical debt and enable continuous modernization.
• vFunction is rolling out the first and only observability for architects. It analyzes both pre-production and production to understand how the business logic is structured. It identifies the domains within the application, interdependencies, common libraries, and dead code.
• It allows companies to identify the drift that is happening between releases of specific applications.
• Initially, vFunction focused on full decomposition of monitoring microservices. Today, it is also able to address partial or ongoing modernization and identification of technical debt.
• This includes actual creation of to-dos on how to remediate that technical debt and integration with ChatGPT.
• It enables the architect to participate fully in this development process. It automatically generates a to-do list of things that need to be remediated. The architect can share that with the development team so they can be prioritized for upcoming sprints and releases.

How vFunction helps companies in their Modernization Journey:

• With vFunction, companies don’t necessarily have to stop everything and embark on a risky project. They can use the platform to identify the areas that they can start remediating, maybe extracting 1 service every 3 months.
• Using vFunction on an ongoing basis and addressing technical debt and improving the architecture on an ongoing basis can overcome some of the friction that exists in the market in terms of embarking on these very large modernization projects.
• The pricing is very much a software-as-a-service (SaaS) approach: relatively low price per class per month, and they can use it as much as you want.
• The applicability of vFunction is broad. It is for all types of applications. There are customers that went full cloud-native over 5 years ago and their microservices are now bloated and complex and the engineering velocity has slowed significantly.

This summary was written by Camille Gregory.