Landing Page Clusters Graphic

ON-DEMAND PODCAST

7 Myths of Monoliths

Featuring Bob Quillin, Chief Ecosystem Officer at vFunction

In this vFunction podcast, Bob Quillin (Chief Ecosystem Officer at vFunction) talks about monolithic system architectures and the applications that run on them, namely looking to dispel some myths about working with monoliths, and how modernization options are not a lost cause.

Start busting myths around your own monoliths at https://vfunction.com/trial where you can get a free license of vFunction Assessment Hub, a static analysis tool that gives you the data you need to make a business case for modernization.


The Best Java Monolith Migration Tools

As organizations scale to meet the growing tsunami of data and the sudden rise of unexpected business challenges, companies are struggling to manage and maintain the applications that run their business. When unprepared, exponential data growth can tax a company’s legacy monolith Java systems and their IT departments. 

Intesa Sanpaolo Case Study (pdf)

In this case study we will describe the challenges, how Intesa Sanpaolo decided to convert one of its main business-critical applications from a monolithic application to microservices, and how a platform called vFunction helped to turn this challenge into a success.

ROI Calculator

The vFunction Return on Investment (ROI) calculator determines the key benefits – based on actual customer metrics – achieved by using the vFunction cloud native modernization platform including:

  • Time to Market Acceleration
  • Total Cost Saving
  • Total Time Savings

Video Transcript

Oliver White (OW): Good day, everyone. And welcome to this vFunction podcast. I’m Oliver White, director of communities at vFunction. And joining me today is Bob Quillin, my boss and Chief Ecosystem Officer at vFunction. Today, we’re having a conversation about monolithic system architectures and the applications that run on them and namely looking to dispel some myths about working with monoliths and how modernization options are not a lost cause. So, Bob, thanks for joining us.

Bob Quillin (BQ): Great to be here, Oliver. We’re excited to talk about how we bust some of these monolithic myths.

OW: So the “myths of monoliths” is what we’re talking about. I have a feeling we’re going to stumble over that, but here we go.

BQ: It’s a tongue twister. That’s for sure.

OW: Yeah. Before we start, can you give a 50 word bio about yourself for people who may not have met you yet?

BQ: I’m responsible for the ecosystem here at the vFunction developer ecosystem, content marketing and partners and business development. And I came to vFunction most recently from Oracle cloud. They had acquired my last company StackEngine, who was a container management product and platform for managing container systems. We’ve built out a whole range of cloud services and cloud native services in Oracle cloud. And I saw a lot of that monolithic challenge of helping the Oracle customers move to Oracle cloud. Imagine Oracle has Java, web logic. We have a lot of the Oracle database customers. Obviously those are kind of the core of the… I’ll say legacy, but the traditional Oracle customers and moving them in the cloud was very difficult. And there was a lot of lift and shift and migration that was trying to be done. But we talked a lot about move and improve.

When I left Oracle, I had worked with Moti previously. We worked together at EMC. He actually acquired one of my other previous startups. And so, we have had worked together and we kind of connected on this common view of the need in the marketplace, this next wave of moving workloads to the cloud. There’s the cloud native side between field work that’s being done. That’s kind of a known quantity, but this how you move and build less practices, make it easier for enterprises and customers to move these more traditional applications into the cloud is a challenge. It’s huge. It’s a huge opportunity to kind of engage with the marketplace and get this next wave of optimization and modernization happening.

OW: This kind of plays into the open conversation about monolith versus microservices. And it seems like, now, we can begin to think of the term monolithic application differently, so not a lost cause. It doesn’t have to be microservices necessarily and there’s options. And I think that those developments are new to a lot of people, and this is probably where these myths come in. In a nutshell, how should we be thinking about a monolithic application?

BQ: I think when we look at monolithic applications, it’s an architectural sort of characteristic and how they were built for in the last right 10 to 20 years, there was a pattern that was built around the application server construct business logic was all embedded within that middle layer of the application. And so that’s actually a key part of what made these enterprises successful and they built a lot of their backend applications, their business back ends, their supply chain, their order processing. You see it across a range of very large organizations. And even now we’re working with a lot of first generation cloud vendors and cloud companies who moved their applications or built in original application in the cloud, maybe 5, 7, 10 years ago, and those monoliths are now looking to be modernized to take advantage of this new microservice environment.

So the pattern is not a good or bad thing, because there’s still some reasons why certain kind of use cases should use a monolith. But as you’re looking to, you know, you look at scalability, take advantage of the cloud, it’s pretty clear those next set of cloud native best practices require you to take that monolithic application and begin to modernize it towards this new set of capabilities from containers to serverless, to Kubernetes, to all the CI/CD container security, all the new things that are being implemented that are available in the cloud, like the scale and be more agile, et cetera. And there’s a lot of confusion over the last 20 years because modernization is not a new thing. It’s been going on since even before monolith, even back in the mainframe days. So modernization has a lot of, has confused a lot of people which has led to this whole question about, is it a lost cause to even try to do it? And we talk about the seven Rs or there’s many, many Rs around modernization.

From rewriting to refactoring to retiring and every time I look, there’s a new R in there too. So there’s a lot of confusion that’s put into the marketplace and sometimes people have given up, I think that’s kind of the issue. And part of our message out there is that there’s new techniques. You think about just AI automation, machine learning and all the learning that’s gone into, in tech has gone into apps in the last 10 years. We need to apply a lot of that tooling and a lot of the best practices that have happened from domain driven design and from, you know, how you do it on a manual basis and then begin to automate that use a lot of these tools. And that’s really where our vFunction has applied itself to look at that business logic part of the monolith itself. So I think that’s why we’re trying to shake the industry up and, and wake them up and say, Hey, it’s not a lost cause. There’s new ways to do it. And let’s start trying those and start looking at how we actually move this part of the industry forward.

OW: Let’s start with the first myth of the monolith, which is what we’ve just been saying, modernizing your monolith is not a lost cause. Can you develop that a little bit more?

BQ: It is kind of an overall theme is that, as we look at all the complexity that people have kind of laid on top of modernization, there’s been a lot of fits and starts, people have tried to do on a manual basis using domain driven design and event storming. And I think, that’s led to some very good best practices that are all very manual, very people intensive architects in a room, putting sticky notes on a board. So now, so the opportunity is, how do we improve on that? How we build on that? How do we understand that business logic is really the key here, we’ve actually bust that open, begin to decompose it, for busting myths, for busting monoliths too, and start to… That opens up so many different things, we move into cloud native architectures, we start to decompose our database, decompose micro front ends.

But really, we’ve talked about that business logic as the first place to go. And to open people’s minds up around, let’s apply new techniques, new technology, we see there’s a lot of reticence to do this, sometimes a great lot of skepticism, because people tried it and failed. And we just finished up a survey where 79% of application modernization projects have failed. And that’s actually a pretty big number. And it creates a lot of, like I said, skepticism and people’s for, waiting to be, have this proven to them. Many people, we hear as, we work with customers that the first thing they tell us, as they complete their project is that, number one, “Hey, this really works.” And that’s exciting things. And that’s the message, we’re trying to get out of this, try this new tech, it’s going to move things along, it’s going to open up, get catalyst for modernization. That’s what we’re trying to actually provide here.

OW: Doing our best to remove long-term manual efforts with a bunch of people in a room with stale doughnuts and cold coffee and so on.

BQ: One of the byproducts of a series of failures, and a no clear methodologies to do this, that are otherwise expensive, or having to outsource it to a very expensive contract, kind of led to the next myth too, which is, now people start just lifting and shifting or kicking the can down the road, not doing it all, or maybe trying to do migration. That’s really… That leads us to the next myth. Let’s jumps in.

OW: The myth number two of the monolith, that’s because you’ve moved some stuff to the cloud does not mean that you’ve modernized.

BQ: Correct, correct. And I think that’s, like I said, all the frustration, all the failures up to date are really led to people saying, “Oh, I’m just going to lift and shift it.” It’s simple, that there’s a clear path to do a migration, and then some people, clean their hands of the whole process. And they stop there. So, you’re trying to also then begin to open minds up and say that, “Migration is not modernization as you lift and shift.” You should think of modernization, as a broader strategy and migration could be part of that. It’s nothing wrong with migrating to the cloud. But don’t just stop there. So the fact that migration does not equal modernization is a myth, we’re trying to, we’re going to bust into this mindset. And it’s super interesting, I think, it kind of surprised me too, over my two plus years now, at vFunction, that there’s a large number of companies that have done that lift and shift. Or maybe they’ve even built a genuine application into cloud over years ago, and that is still a monolith. And all these folks are in the cloud and that are looking to modernize. And that’s a big part of where we see the market is today.

So, now migration can have benefits. There’s DevOps benefits, there’s some cost benefits. But still, monolith in the cloud is still monolith, you haven’t really changed anything or potentially, if you want to scale it, you got to scale it vertically, or buy a whole another systems here. Many customers are redlining their CPU memory and just running that at a constant level. There’s no elasticity, there’s no scalability and agility, you’re supposed to have made is not there. So there’s lots of lost, kind of lost opportunity, kind of regret, kind of like, lift and shift regret or migration remorse.

OW: Migration remorse, yeah. Yeah. By moving a monolith into the cloud, you’re actually introducing new problems, that you didn’t have before when it was on a mainframe somewhere or in a server room. So is it mainly that, cost efficiency is identified, is that one of the primary drivers?

BQ: Well, there’s a component to that, where your costs are rising on the cloud side and they’re supposed to be cheaper but now it’s more expensive. That’s one element. But, a lot of it comes down to engineering agility, more release cycles, be able to respond to features on a more activated system. Application owners are coming to us, that are trying to get more business agility and have more scalability. I mean, you can’t really adjust for seasonality, you can adjust for what happened with the pandemic, and COVID. Suddenly, all your customers are coming in virtually.

And it changes the dynamic, you want to be able to scale certain parts of your application. If it’s a monolith, you have to scale the whole thing and very expensive, and it’s not very intelligent, how you can orchestrate that, bring it up, bring it down and take advantage of all that built in, value the elasticity of the cloud. So the more you modernize, the more you take advantage of the cloud. That’s not one of our themes here. And the people that moved to the cloud, after a couple of years either see, one or more of these issues in terms of lack of agility, technical deck continues to grow. They can’t innovate, you can’t release fast and the business suffers. So people suffer too. You’re still, Hey, I’m in the cloud and I’m still trying to maintain this monolith. It does drawdown also, in the people side of things too, culturally.

OW: So you mentioned that migrating what you can to a certain extent where it makes sense and costs aren’t getting out of control and you’re not dealing with even worse problems than you had before. You mentioned that this is part of a larger strategy. And that sounds like you need to get buy in from a lot of different teams and executive sponsorship and so on. That seems to be a perceived a challenge for a lot of people. Why don’t you tell us why it shouldn’t be that hard anymore?

[laughter]

BQ: Yeah, yeah. That’s a good lead in because there’s a growing demand for application modernization, we kind of established people think it’s hard, but I think what we’ve seen over the last couple years, there’s a tipping point with the technical debt they’re carry whether in the cloud or on-prem. So what’s holding people up? And another part of our research, we just completed was the fact that, what are some of the biggest hold ups of having a successful application, modernization project, and what kind of what’s stopping people from getting going and across the board, it was the inability to build an accurate business case for application modernization. And it’s kind of if you take a, think of a monolith, it’s a ball of mud, it’s a tangled ball of string. It’s really hard to deal with like complexity there.

Sometimes it’s just hard to actually accurately say how long it’s going to take, how am I going to do it? How many people do I need? What is the cost, et cetera. So and so we’ve tried to put together much more data to drive that and create help people create data driven plans. We say, you got to have data, you got to do assessment upfront, analyze, get the data, get the metrics, get the before and after. So you can begin to talk about kind of what you’re trying to do. And but we just released a new product about a month ago called Assessment Hub, and really is focused on that particular problem set, which is building up the data around complexity, around risk and using those deep metrics, those calculations that we’re doing, and we’re doing that on a very dependency driven basis.

Looking at communities and dependency change and clusters of activity and entanglement and modularity and rolling those up into a technical debt score. All that data provides a very clear path of what are the benefits from a PCO perspective kind of before and after we identify even the top 10 classes to go after when these are very, very important elements to kind of build a much more grounded plan for modernization. And it might tell you that this is a very complex app. It’s going to take you a while. Maybe that indicates you may want to then iterate through there and pick one or two out. Don’t do it as a big bang, do it on an iterative basis or selective basis. And we’re seeing that also happen. A lot of customers who are maybe pulling one or two services out their monolith, maybe leaving some behind but they have a clear idea that there’s… They’ve done the analysis.

These are the things you want to do upfront, and this creates a much clearer path and a way to communicate between the technical side, the architect side, and the decision maker side, who has the budget. So you got to be able to say, here’s the clear data, let’s have a common language for that and build it around real data, which says, this is the complexity. This is the problems we’re going to actually encounter and compare that on an app by app basis too. So maybe I have 20 apps and I want to do these five, which ones should I do first, second, third? Where I’m going to have my biggest business bang for the buck, which the customer can help us with and understand that. But also then that’s what’s going to take time from a technical perspective and a modernization perspective.

OW: So it’s fair to say that executive teams are really looking for concrete actions or actionable areas. So that includes project length. That includes identifying how much technical debt is really there, how it’s hindering, how it hinders innovation and looking at a score so that you can begin to prioritize, like you said, maybe one app is incredibly complex and it might not be worth going after in full all at once.

BQ: Yeah. If you think about debt, similar to financial debt, I mean, you get a bank statement, you get a credit card statement, you kind of know how much debt you’re carry you could choose not to look at it. But in the case of technical debt, it’s kind of it’s there. You kind of, and it’s weighing down on you. You could feel it, and all the different symptoms of we mentioned slow agility, the costs are going up, I can’t release fast enough my cut, even my developers are getting demoralized.

Because it’s just so hard to work on all this debt is pulling us down. So you’re not getting a monthly statement telling you what it is. This actually provides that monthly statement to actually say, here’s the numbers, here’s what you’re carrying. And here’s how you compare it. And here’s some ways to fix it. And that’s the other thing that that’s important is to be able to be actionable, like you said, and lead that if you do want to go there, go into the modernization with your eyes wide open and knowing having a plan in advance that helps you be data driven and kind of aware of what you’re going to be focusing on.

OW: So what if somebody has two apps, one of them looks to be very, in fact, not very complex, not caring, terribly much technical debt, and another one is just mired and one of the worst anyone’s ever seen and so on. I believe there’s another myth that we can mention now, which is all monoliths are created equal, but in fact, we’ve seen across our customers that some monoliths are on mainframes, some of them are in the cloud. So all monoliths are not created equal. And maybe you could tell us a little bit more about how this is a myth for engineers.

BQ: A lot of people say that they look at all their monoliths, it’s been an impossible job to actually prioritize and work this through. But in reality, as you get into it, you start looking at one, the business relevancy of each of these. So what is the engineering load? What’s the feature back load? How many bugs do I have? How many new feature requests? How long is it taking? And you can kind of get sense that just the activity around, the business activity around applications, and even the size of the team begins to separate some applications from others. And through that scoring and through that stacking, you begin to see that there’s maybe a large part of your applications are business critical, your team is still dedicated to it. You have a backlog, you have work you want to do that’s not being met and features aren’t being delivered as quickly as possible. So there’s a business prioritization that we actually see upfront or in parallel to a technical and technical debt evaluation. The idea of understanding and measuring technical debt, using risk and complexity and building up those measurements then could be laid on top of that to understand that if it’s highly business critical, and there’s a lot of technical and there’s a certain amount of complexity, but not too much, you could really quickly modernize those.

And automation could be a quick answer for those. And sometimes that could be a very quick run, and we see working with some customers, they have very some monolith, but they’re very simple monoliths, but they haven’t been able to see through them once we actually provide that visibility and that complexity analysis, looking at the dependencies, it could be a straight line crew. There’s other ones that are much more complex, millions and millions of lines of code, thousands of classes, high complexity, a lot of entanglement, the risk we talk about is around dependency change. So if I have a change here, what’s the possibility that change is going to happen and affect something downstream? So automation could help untangle those and pull out the appropriate amount of services that could be decomposed.

But you want to do that probably more on a selective iterative basis. And that’s the other thing we recommend is that for a very, very complex application, pick out the services that are most business critical within that application, most architects know what they are. They can stack rank that within the monolith and they do that. So for very complex one, we’re seeing an iterative approach and pulling out one or two services at a time, you might leave other ones behind, you may end up with just a set of mini services and you’re not even going to go to a microservice architecture, that might be sufficient for what you’re doing over time too. So I think there’s ways you need to prioritize it from a business perspective and also then using that information to help inform on the technical side, technical side could tell you how long it’s going to take and also what approach you should use, which then drives the more accurate business case also.

OW: So this sounds like the Strangler Fig Pattern is something that we often… We recommend and also see our clients using. This is a very successful way to at least AB test your new proposed architecture and test performance with traffic being split between one service and the cloud, one service, or rather one monolith somewhere and a decoupled service elsewhere, ideally in the cloud.

BQ: Yeah. And that’s a great point. It is also a perfect example of a technique that’s been established, Martin Fowler and all the folks who have been working on monolithic design and rearchitect refactoring processes and patterns and practices for last 10, 15 years, these are documented manual processes. Now the automation has come into play where I can actually begin to use AI machine learning, a lot of visibility, a lot of observability, think all those tools have been out there, apply that, those services like AWS Refactor Spaces, which actually helps automate some of that process too. And automate the Strangler Fig Pattern from an infrastructure perspective. So how do I load balance? How do I shift the networking load, et cetera, and do this in a very consistent and systematic way? So it’s a lot of these features and techniques are coming together and we’re seeing all of them accelerating the process, automating it, and then pushing what has been a very kind of stagnant part of the industry. Well defined from a manual perspective, best practices are there, they’re documented. Now they’re being embodied in a lot of automation and a lot of tooling, and that’s helping this take off in the next level.

OW: Earlier you mentioned first generation cloud-based applications that were actually pushed into the world as a monolith–maybe due to they wanted to get this app into the world as quickly as possible to attract investment or whatever the cause may be. And it’s interesting because one of the myths that we want to dispel is that monoliths are not an on-premise problem only. And in fact, if you’re struggling with a monolith in the cloud, then you may in fact have a harder time wrapping your arms around the modernization.

BQ: Yeah. I think what we found is that there’s an equivalent amount of interest for folks who’ve already done either they lifted and shifted, or they’ve been in the cloud five, 10 years, and they have a monolith or an architecture that’s semi monolithic, and they want to now modernize that. The proximity to the services that are in the cloud I think is also a large part of the draw here is that I have all the issues I had with the monolith before in terms of agility and scalability and all those things, but I’m so close to being able to turn on a container service, a Kubernetes service to do some elasticity, do some orchestration to use all those components. I typically… These customers have other applications that are using a, some CI/CD a lot of DevOps capabilities.

I love the container security has gotten so much better that you want to take advantage of all these capabilities and plug your monolith into that set of engineering and software engineering tooling, the modern tooling, and also have consistent tooling because you don’t want to have AIC tooling over here, which is what I used to use, and also have this container DevOps and in cloud native tooling over on the other side. So bringing those together it really helps to optimize an engineering mobilization, but also then begins to… Everything can start working together on a much more clean basis. It moves these products and these applications into a whole new realm. And I think they are…

Until they do that you’re basically set with, like, in order to scale, I’ve got to buy bigger, bigger images. The Cloud providers also are getting more and more interested in getting people to plug into these services too. Because, if you’re just using CPU memory, and your data sent in the Cloud, you actually may be more mobile and be able to shift to a cheaper service somewhere, where the competitive nature of serverless capability. The container services who has the best Kubernetes services orchestration, all the open source tooling and it’s now available out there. Those are ways for Cloud providers to also take advantage of their best practices and all their advantages and competitive differentiation and pull in these customers further. So, I mean, I think both the customers are wanting to do it now, and also the Cloud providers too.

And the fact that, it kind of sounds like a on-premise problem and there’s still a lot of stuff left on-premise that needs to move to the Cloud, but also there’s a many monoliths that are in the Cloud already. And that’s a myth that I think we need that, customers have actually, helped me understand that don’t just look on-prem, help me solve my problems in the Cloud. I’m so close to being able to take advantage of the rest of the Cloud that I just can’t do it now when I’m ready. So I think it’s kind of a fun part of the market.

OW: It sounds intriguing. It’s interesting to hear these stories. Let’s move on to myth number six, which is monolithic dependencies are impossible to untangle. Now, you touched on this a little earlier about using AI and automation to do what is pretty much infeasible from a manual human perspective. But that’s what plays into the complexity of understanding technical debt. Why is it perceived that dependencies contain in a big ball of mud or spaghetti, whichever phrase you want to use, why is it perceived that these are impossible things to deal with?

BQ: Yeah. Every time I go out fishing I get these spooling disasters where all this line comes out or I get this huge tangles and I’m spending half hour trying to untangle these things. Eventually I just cut it and start all over again, it reminds me of monolith or anytime you’ve done holiday lights, you take them out of the box. [chuckle] Why didn’t I actually fold them up nicely and just spend all your time trying to…

OW: Oh, you did, but that’s what happens.

BQ: Yeah. And then I pull the wrong side and never comes out the same way. So there’s so many good entanglement metaphors out there, but… And they all kind of stick in your mind in different ways. Sometimes it’s not your fault. And I think that’s one of the things we’ve seen with architects and developers, is that with monoliths, sometimes are 10, 15, 20 years old, and you have inherited them. You come into the organization now you’re trying to understand it. So you need a way to view the application in a way that’s helps you understand it. You have a good sense of the code, you understand how it works. You kind of set off the code locks but architecturally, what was going through people’s minds, where are the domains hidden? Why did they write it this way? And how am I going to get from A to B?

And so the fact that much of the challenges that this is new code, this is for new code for people to actually understand and they’re not the original owners, they didn’t have that benefit. So that’s one issue that we see happening that’s causing a lot of wide dependencies very hard to untangle. And the second is just that as you are trying to get inside the code itself and the dependencies are so entangled, there’s no automated way to do what-if analysis, if I move this, I combine these, I split these, I put an API here or entry point there, what happens? So I think that what-if mode is something that a studio and B function helps you with that allows you to give it a try, if it didn’t work, go back and retry it again, reset it, and try some different ways and be able to understand as I do this, am I reaching my goal? And exclusivity for our purposes is how independent these different services, microservices are many services are. And you can look at it as, you know, what you’re trying to do is become more and more exclusive and trying to get to a hundred percent level.

And it’s a goal directed thing kind of looking at, if I do this, will I get more and more exclusive, like lose those dependencies and create a more independent service that could become a microservice that could operate on an independent level? So without all the dependencies I’ve had, so having that visualization being able to understand it from a dependency perspective and looking from an architectural point of view is important. One of the insights and kind of the intellectual property elements, the aha moments for me is understanding how we use Graph Machine Learning. And Graph Machine Learning builds a graph where you look at communities activity and those communities activity, those graphs are dependency graphs, and they have classes and memory and the different objects which have other objects in them. And as you look at those graphs, these communities begin to indicate potential domains and present those up to the customer.

And you’re looking within those domains, how, what are the dependencies versus the degree of entanglement? How are they connected? And how can we continue to begin to separate those out? So that Graph Machine Learning is a real key part of how AI is being deployed and utilized to help, to enable an architect to better work through these issues. So it’s an enabling technology. It’s assisting the architect, sometimes very simple architecture if we get it right the first time, but a lot of it’s around, here’s a potential architecture. How would you like it to move forward with it?

OW: Based on the data science used?

BQ: Yes, very much so. So as we build the graph, we present it to the customer. It becomes much more possible and it’s a catalyst for moving forward. I’ve talked about that several times. Now, many times these projects are stuck, smart people they know what they want to do, they just can’t get through that process and it’s taking too long. So sometimes it’s just being able to see it, have some suggestions, being able to do the what ifs and now being able to visualize, that’s kind of what I thought, but I never saw that. I never see my application from this perspective. And that’s got to be one of the more, ah ha moments too for our architectures, being able to visualize it, try things out, look at it from this architectural dependency perspective, then have the underlying automation that can then enable you to try things out and put your architectural imprint on top of it, in addition with the AI, that’s helping you with it.

OW: So, with all of that in mind, it seems like a modernization project doesn’t have to take forever? And that’s actually something we saw in our recent survey. The average modernization initiative was 16 months with a large minority going over two years. And I believe the cost, the average cost of this project was, or these projects is one and a half million dollars, and considering nearly 80% of them fail, that’s an expensive endeavor to be unsuccessful with in the end. So why doesn’t modernization take forever anymore?

[laughter]

BQ: Yeah, well, I think of the six myths before we talked about, having the data, being data driven, planning in advance, having automation to enable you to a accelerate through the process. So assessment and cleared planning is actually very critical. We think that’s a big first step and a best practice is going to help accelerate the practices and also get more successes. So if you know what you’re doing in advance, you have a clearer path to get done and be successful at it. The lack of success in this area is many things. Many projects are just stalled or they people give up, they do the migration or lift and shift. So we’ve run into many cases where they’re just stalled. It didn’t take 16 months, didn’t take two years, it’s taking forever. There’s an infinite project that’s happening here, and there’s no end in sight. So the rescue or the relief comes from having the visibility, the tools and the actionability within that process, and planning it through and having kind of a clear way to kind of change… Bust the pattern that’s been happening of these failures, inability to predict cleanly, how long it’s going to take, how much time is it going to take or what I’m going to do.

So plan in advance. Have the tools, you know, use a common platform that can assess and modernize and kind of embrace that process and in some ways, try it out, trust it, build a factory around this and some core competencies and kind of get the flow going. So I think there’s a lot of fatigue, there’s a failure fatigue element here that you run into is that I’ve tried it several times, that’s where the skepticism may come from, but the relief and the ability to kind of move forward really comes from having the data, having a clear plan, something that you hadn’t seen before then using tools and techniques that are new and modern to get help, to take what you think is right maybe change your mind on what the perspective should be, but also then, it helps to clear up, “Ah that’s what I thought,” I had a intuition, that’s how it looked or I had no idea. I think we see that happen in all cases, there’s some yes that’s what I was thinking that, that was where the service should have been, but I couldn’t find it, or I had no idea that’s how it was written. That’s a new information to me and all that can happen at the same time. And that’s a wonderful thing to see. And that’s kind of the relief we’re providing for architects in the process.

OW: Well, that sums it up very nicely. So we we’ll add the seven myths of monoliths into the episode notes so that people can listen to those parts individually. Any final comments or ideas to share Bob?

BQ: Yeah. Well I’d say that, the call to action is to jump into this, don’t fear, don’t let failure, previous failures bring you down. If you’re an architect CTO, have your team, look at assessment hub as a free trial for one app, give it a try, understand, it gives you a taste of how we’re doing analysis from a complexity perspective, a risk, a technical debt, it can actually show you a bunch of classes really gets you started. And there’s no reason not to give that a try. I think that’s what we’re trying to do is get more people to understand the process, the techniques and from there if you do have a monolith you’re stuck with, you’re looking for help, either you’re an end user, you’re an architect, or maybe you’re a system integrator and you have a project you’re trying to work through and you need the help and need the acceleration for that. These are all use cases that we work with. And so excited to help people through all these myths and continue to bust them down one by one. And we look forward to working with you on it.

OW: That’s great. I’ll just add that if you’d like to start busting some of your own myths around your monoliths that you’ve got at home, you can visit vfunction.com/trial. That will send you to a landing page where you can get a free license of vFunction Assessment Hub. That’s good for a year and for one app. So, Bob, it was a great conversation. I always learn a lot when I talk to you. So thanks for joining us and we’ll be signing off now.

BQ: Thanks. And we’ll talk to you all soon.

Technology leaders can now evaluate the cost of technical debt, determine what to modernize first, and then take action – all in one platform.