 Technical debt is the biggest, and I repeat this, the biggest off-balance sheet liability that organizations have. With architecture observability, chief architects will be able to quantify, measure, and remediate that technical debt. This is your host, Saptan Bhaktia, and welcome to TFR Newsroom. And today we have with us once again, Moti Rufflin, CEO and co-founder of V-Function. Moti, it's great to have you back on the show. Thank you for having me, Saptan. I'm very excited to talk to you and your audience. And it's always a pleasure to talk to you. And today we are going to talk about a kind of new addition that you folks are making to your platform, which is V-Function Architectural Observability. Before we talk about this specific announcement, let's just remind our viewers also, it has been a kind of gap since we talked last time and things do change over time. So just quickly remind our viewers, what is V-Function all about? I'll give you a quick where we were and kind of tie it to the announcement of today. So V-Function, where we started was, we developed a modernization platform that helps you understand monolithic application and helps you transform them into microservices. And where we are today is that we're taking this platform to the next level and we're announcing architectural observability because in essence, what V-Function is, it's an AI-driven architectural observability and automation platform that helps you manage technical debt and enable you continuous modernization. So hopefully as we go along, I'll explain more kind of this announcement and how we're actually able to address a much bigger market with this new addition. And you use the term technical debt. If you look at just because most of our workloads today run on cloud, of course, data centers are there, they will be there for a long time, main frame will be there. We are also looking at edge. If you look at this whole sprawl of, of course, architecture's platform, what do you mean by technical debt? Technical debt is almost like a catch-all phrase. And what we're focusing on is architectural technical debt. And if you see what our friends at Garter defined that as, they say that by 2026, 80% of technical debt will be architectural technical debt. And what we mean by architectural technical debt is really how the business logic of applications is structured, right? So the way that it manifests itself is that over time, sort of the accumulation of architectural decisions and implementations that lead to complexity that prevents you from releasing features quickly, prevents you from innovating at the pace that you're looking for and prevents you from scaling the way that you would like to scale your application. So all of that is architectural technical debt. And of course it is also tied to the cloud because once an organization is looking to migrate to the cloud, they want to get more out of the cloud. They want to get more agility, more innovation, more scalability. And the architecture is what's preventing them from doing so, right? So that's kind of also how architectural technical debt is also tied to how it can get more out of the cloud, right? It all has to do with the architecture of your applications. Now, since we are talking about looking at things from architectural perspective, let's also talk about is there only difference between when we talk about journal observability versus architectural observability? There are many observability tools out in the market, right? APM tools that help DevOps and developers identify performance issues or network observability tools for network managers or even for security you've got anomaly detection, which is sort of an observability. What we're announcing here is the first and only as far as I know, observability for architects. And what we mean by that is that we're able to understand the architecture based on what we see in production and in pre-production. So we analyze both and we try to understand how the business logic is structured, what are the domains within the application, what are the interdependencies, how common libraries are structured, identifying that code, all these types of things that are relevant for architects. If you think about it until today, architects have no observability tool available to them. So we're focusing on the architecture, not on the performance, not necessarily obviously on security or network or bottlenecks or performance. We're solely focused on the architecture. And of course it's observability because you do it on all your applications on an ongoing basis in production. So that's kind of where we're sort of boring the term observability, but we're marrying it with architectural observability. So that is where it's kind of a unique type of observability tool. Now we understand architectural observability, we understand architectural technical debt. Now let's talk about V function architectural observability, what it is and how is it timed to release it now because you folks, a lot of things that you folks do is also based on what is happening in the industry. Customer feedback also plays a big role and responding to the needs or pain points. So talk about it. And once again, what niche it's fulfilling. Absolutely. So as I mentioned before, our focus until recently has been on this one very clear use case where we take more ethical applications, we understand them, we analyze them, we combine static and dynamic analysis and our artificial intelligence, we're able to identify and understand the different domains within the application and then have our automation part that helps you decompose that into services. What we've learned over the past couple of years is that if you think about what we're actually doing, it's architectural observability, understanding the architecture and then having some automation to take action on top of that understanding of the architecture. Now, from a market perspective, what we've learned is that not everyone wants to immediately decompose a monolith into microservices. There's a kind of a wide spectrum of modernization initiatives and processes out there. Some organizations just want to decompose to one, two or four services and they get 80% of the value. Some want just to improve the architecture of their existing monolith, so that the modularity is better, there's less cross-domain pollution, that the dependencies on the database are kind of reduced, so again, they can still release the software at a high pace and there are some that actually already modernized applications, let's say microservices and they want to prevent the accumulation of technical debt on those microservices. So again, our observability allows them to identify that drift that is happening between releases on those specific applications. So if they sort of try to recap, initially we focused on full decomposition of monoliths to microservices and today we're able to address full decomposition but also partial or ongoing kind of modernization, identification of technical debt and remediation within these monoliths and by the way, some of the functionality that we're releasing has to do with actual creation of to-dos to how to remediate that technical debt including integration with chat GPT which is pretty exciting and the last use case is for born in the cloud microservices you still want to prevent them from accumulating technical debt so architectural observability allows you to alert when there is architectural drift on those. So we're basically able to address a full spectrum of modernization projects, initiatives, we see that many times modernization is not necessarily a project but it's an ongoing process and by using the platform to identify those applications that it makes the most sense to modernize or areas of the application that it makes sense to modernize, we're enabling to do that. When we look at modernizing some of the traditional legacy which your term, we want to use it, how much far are we in this journey where you see there are a lot of organizations which are still in a very early stage of their modernization journey or cloud migration or cloud adoption journey. The reason I'm asking is also as more and more organizations like are becoming like depending on what a stage they are, cloud itself is evolving, whole Kubernetes let escape is also, so they will have to do more catch up versus what they were doing like two years ago. So can you talk about how much progress we have made and what are some of the major challenges that they face that of course you fork held up with? Yeah, so I would say that we're very much in the early stages of the modernization journey. So you have organizations that may be lifted and shifted their applications to the cloud but they're still not modern, they're not cloud native so they're not able to get the maximum value from the cloud that they were seeking and there are obviously still many workloads on prep. So this is a massive problem and the challenge with this modernization and especially in this macroeconomic environment is that organizations, CIOs specifically, heads of technology are reluctant to allocate massive amount of resources be it capital and people and dedicate them only for these modernization projects because many of these modernization projects fail, they're very risky, they take a lot of time and they're very expensive and that is exactly what we're able to address with our new platform because now we're saying, okay, Mr. CIO, you don't necessarily have to stop everything and embark on this risky project but rather use our platform, it will tell you, it will identify the areas that you can start remediating maybe extracting one service every three months so incorporate that as part of your ongoing sprints, 10, 15, 20% of the sprints without embarking on a very large risky project. So using our technology on an ongoing basis and addressing technical debt and improving the architecture on an ongoing basis is actually a way to overcome some of the friction that exists in the market in terms of embarking on these very large modernization projects. One thing I didn't mention is that we're pricing our software differently in a way that it is much easier to consume so it is a very kind of SaaS approach. You buy it at a relatively low price per class per month and you can use it as much as you want. So we want to enable organizations to address this problem at a massive scale. Since we're talking about migration, can you also talk about, of course, when you are dealing with customers, there may also be instances where some of their applications were closed. They have already been modernized but at the same time there are some which are still in that process. So how do you folks help? It doesn't matter whether it's already modern or still legacy. We believe that architectural observability is foundational to any modernization. It is useful, it is valuable to any application. And as I said before, if it's a legacy application, so of course you want to modernize it, maybe break it into microservices. If it's a new application, if it's microservices, we've talked to customers that went full cloud native over five years ago. And those services, those microservices are now bloated, right? They actually, the engineering velocity has slowed significantly because they've accumulated technical data, they've become very complex. So again, you want to observe also the architecture of modern application. So the applicability of this technology is really broad for all types of applications you want to address this problem. Talk a bit about when we look at architectural observability or architectural technical debt. How much role does culture within a company play? Because without right culture, some of these tools and technologies will not have the impact that you want, especially when we are talking about organizations which are in the early stage of either cloud migration or modernization, because they have a totally different culture. So absolutely, and I would focus specifically on the architect role, right? So if you think about the new culture or the new development processes, let's say, agile development, where you're releasing at a very high frequency, the architect's role is being marginalized to a certain degree, right? Because it's very hard to enforce architecture when you're releasing once a day or once a week. So the architect is actually lacking tools to participate in the agile development world, right? They can do code reviews, they can do imposed coding standards, but they don't really understand what's happening out there in the field once it is deployed, right? When the software is in production, what really is happening with architecture? And this is exactly where B-function architecture observability plays a huge role, because all of a sudden we give the architect a tool that allows him or her right to participate in this process. Our technology is able to understand architecture and generate to-dos automatically, right? These are the things that need to be fixed, and the architect is able to feed that into the development team, into their backlog, and they can prioritize it and put it in their coming experience and releases, right? So all of a sudden, I think that you're absolutely right, it's a cultural change, but we're actually enabling the architect to participate in the new development process, in the new kind of world of agile development. It's a tool that I believe has been missing for a while. Moti, thank you so much for taking time out today, and of course, great insights about architect-led observability, architectural, you know, technical data, and also the introduction of B-function architectural observability addition feature to your existing offering. Thanks for all those insights, and I would love to chat with you again soon. Let's make sure that there is no such big gap between our discussion, but I really appreciate your time today. Thank you, Supreme. Enjoy it.