Other Recommended Resources

Video Transcript

0:00:12.1 Scott Middleton: Alrighty. I think we’ll get started. Moti, do you wanna come jump on and join us? We’re gonna be talking about how to ensure modernization projects don’t fail today. We’ve got Moti Rafalin with us, who’s the founder and CEO of of vFunction. VFunction being a AOI to help with your modernization programs. Yeah, Moti, come jump on. Say hello.

0:00:42.8 Moti Rafalin: Hey, Scott. Hi, everyone. Happy to be here.

0:00:45.1 SM: Hi, thanks for joining us. Do you wanna kick onto the next slide for a second? I’ll just intro Terem. So, hey we’re Terem, so we’ve put these webinar series together. We’re on the AFR Fast 100. We’re a tech product development and strategy firm. We have done a lot of modernization work, taking monoliths and legacy code and rebuilding it into microservices and all that kinda fun stuff and in some cases, keeping parts of the monolith because it was actually performing better than other things might. So yeah, really keen to be getting into this topic.

0:01:22.4 SM: I’m Scott, so I’m the CEO and founder of Terem. I’ve been working on major, major product launches technology for years. Probably, something a bit fun about me is I love sailing, I love making sausages, which is a bit of an unusual interest, which… Actually I found out Moti is a bit of a foodie, so maybe when Moti and I connect in person, I can make you some sausages, Moti. [chuckle]

0:01:50.3 MR: I’d love that. I would love that.

0:01:53.1 SM: As my grandmother said…

0:01:54.6 MR: Spicy.

0:01:55.1 SM: What’s that? I can do spicy.

0:01:56.6 MR: Spicy. Yeah, I love spicy.

0:01:57.8 SM: I can do nacho flavored, you name it. The only thing is the… Something I figured out was the per kilo cost of those sausages. When I factored in my hourly chef’s wage was much higher than if I’d just gone to the shops and bought them. But that’s okay, it’s all for fun. So I’ll just introduce Moti. So as I mentioned, Moti is the CEO and founder of vFunction. Moti has a long, successful career building technology companies, previously served in the Israeli Air Force, currently in Palo Alto, California there. And Moti… Yeah like I was just saying, I learnt that you love your food and your wine, you’re very close to… It’s Napa Valley, right? That you’re close to.

0:02:47.6 MR: Yeah.

0:02:48.5 SM: And we were talking about wine and chardonnay I think was our discussion around. Yeah. What’s your favorite variety around wines? 

0:03:01.7 MR: Look, I love Chardonnay. I love… I also Pinot. So I kinda from both ends, so to speak.

0:03:16.5 SM: Did you get the variety in there? 

0:03:19.2 MR: Yeah.

0:03:19.3 SM: And Moti, I’m gonna hand over to you now, really to take us through. I’ll jump in with some questions and that. And by the way, if you’re in the audience and you’ve got questions, please pop them in the chat or the Q&A window. And we’ll either get to them in the flow if they kinda link up with the flow or we might pick them up at the end. Otherwise, Moti, I’m gonna hand over to you to start taking us through how modernization projects fail based on everything you’ve seen.

0:03:50.1 MR: Sounds great. Super excited to be here, Scott, and I’d love to share. We’ve actually conducted some recent surveys also to support kinda our thinking here, and I’d love to share with you, I think you’ll be the first audience to actually see some of those results.

0:04:08.9 SM: Oh, awesome.

0:04:09.1 MR: So as mentioned, we wanna talk about how to ensure app modernization projects don’t fail. And I’m gonna share with you some data about how many actually fail and why they fail. And then we’re gonna try to unpack it and think about how to do that better. But first, let’s share some stats about app modernization. And we were chatting before the webinar, Scott. And you were mentioning how you are seeing more and more companies that are kinda reaching the stage that they need to modernize. And the truth is that modernization has been around for, I’d say, forever.

0:04:47.3 MR: And as long as you’re developing software, at some point, you need to modernize because the code keeps growing, it becomes complex, your velocity slows down, you need to modernize. However, in the past years, because of COVID, you’ve seen companies doubling down on modernization in order to be more competitive, in order to be able to be agile and be able to compete with new start-ups that are entering their space and have modern stacks that allow them to be super agile and rapid and responsive to the market. So you can see here some of the stats from 2022 activities that are the CIOs are focusing on 40% of them on app modernization. And you can see this is one of the top three initiatives. So it’s really not something unique. We keep seeing it more and more out there.

0:05:42.9 MR: If you ask, IDC is kinda analyst firm, research firm. They put that as number one prediction. The majority of legacy applications will receive some modernization and it is many times tied to cloud migration. So when you’re migrating to the cloud, you probably need to modernize. And we’re gonna talk about that type of linkage and actually some confusion around the cloud and modernization. So these are just general stats there. But what I really wanna talk about are these stats. And these are new from a new survey that was conducted recently. And the facts are that 79% of app modernization projects fail, and that’s a very, very high rate.

0:06:33.7 SM: That matches my personal experience as well. You get in, you start refactoring and then you realize, not through anyone’s fault, you’ll be like, “Oh, hold on a second, this is bigger than we thought it was gonna be.”

0:06:45.3 MR: Right. And then the projects obviously average 16 months, but 30% of them go over two years and the cost 1.5 million. So I’d say the net net of this is that these are really risky projects, and many decision-makers, many CIOs really are losing their jobs either because they’re not doing the modernization, and then they’re simply not able to address the business requirements, or they embark on modernization projects and fail. So this is an acute problem that’s out there and really something that we’re talking about.

0:07:27.7 SM: And Moti, that timeline that’s come through in the research you’ve done, 16 months to two years, that’s a long timeline in technology. The world can kinda pass you by in that period. You sit out and you’re refactoring or you’re modernizing with a set of technology, that technology could even be obsolete in that kind of time frame.

0:07:51.6 MR: Absolutely. I think the length of this project is a major factor in their failure because the longer the project, the higher the chances it will fail because you’re going to already miss the market, miss the goals, the risk that is part of such a long project, the cost that’s associated with it, the longer the project, the higher the cost. So yes, I think time is a huge factor here that contributes unfortunately to the failure of this project. So I’m already kind of jumping ahead of myself. What if you were able to sort of shorten the period of time that’s associated with these projects? That would obviously help you remove some risk or cost. So I think that dealing with a time factor here is a major thing to tackle.

0:08:43.8 MR: So this is just to set the stage, and so the most interesting part is, “Okay, why do they fail?”, and these are answers from this recent survey, and we not only ask the question of, “Why do these projects fail?”, we actually try to segment the responses according to the position. And what we found out is that different positions actually have different explanations. So if you ask the C-Suite execs, they say that the expectations are not accurately set. I can buy into that, but if you ask the architects, the architects and the developers and those that are actually on the ground trying to do these projects, they say that they don’t have the tools actually to support these projects, it’s a very manual, complicated project with lack of visibility, no automation, and so forth.

0:09:40.3 MR: So as we dig into this, I want to actually keep in mind these two type of answers in mind. And so before we go and unpack that, let’s first set the stage and talk about why do you even want to modernize. I think that eventually ties to setting the right expectations. So you need to have the right reason to actually embark on these modernization projects. So one category of factors or reasons why you would want to modernize really has to do with the accumulation of technical debt, and technical debt is a little bit sort of… I’d say abstract, maybe term, and I’d rather not talk about technical debt, but rather the symptoms. How does it manifest itself, the technical debt? 

0:10:34.1 MR: And technical debt manifests itself in very long test and release cycles that we all are familiar with. These applications keep growing and then you need to test millions of lines of code, a very complicated monolith, then of course, the test cycle is very long, and if the test cycle is very long, then the release cycle is to be very long. You’re unable to meet your business requirements in those cases. Something that we found out from customers that we didn’t think about initially was that they were complaining that when you have this large monolith, it’s very hard to ramp up your new developers. So you have 10 million lines of code application, you have a new developer coming on board, now you need to get them up to speed. It’s really difficult until they become productive when we have such a complicated code.

0:11:20.2 MR: Now, of course, imagine if you had that as microservices, you can simply ramp up developer on a very specific kind of well-defined portion of your application. That is why you want to modernize in that case. So at the end of the day, all these things, the long release cycles, inability to meet the business requirements, long and hard to ramp up, developers leads to poor customer and user experience. And that is a fundamental problem that you want to deal with as you think about modernizing applications. So that’s only one category, and then we have another which has to do with the limited scalability. When you have these large monolithic applications, they don’t scale out very well. So they’re heavy, big. Yes, it can replicate and have multiple instances, but this is not really elastic, you need to maintain all of them all the time. It’s not very efficient, at some point, it doesn’t scale up anymore. So the whole scalability problem is an issue unless again, you refactor, you break it into microservices.

0:12:26.9 MR: And in fact, I have a great example. I can’t mention the name, but it’s an Australian bank that went ahead and added APIs to an existing system, banking system, to provide access to a new mobile app. So by doing that, you had the users accessing their accounts, depositing checks, and doing all those activities through their mobile app, and all of that through new APIs that they added to an existing system. What happened is that traffic went up 10X, and all of a sudden, that backend couldn’t actually address the traffic and the scalability challenges that were presented. And so they had to go back, refactor that application, break it into microservices, obviously utilize some of the modern services in the cloud, get the elasticity to be able to address that type of traffic. So again, this is another aspect of why you would want to modernize.

0:13:29.7 MR: So with that in mind. I want to go back to the two sort of reasons that executives and architects are talking about. Let’s start first with setting the right expectations, and I have here three examples that I want to dig into. So the first one really has to do with a definition of what are you trying to achieve. Are you just trying to migrate your application to the cloud? Or do you really want to modernize them? And the problem is that many people confuse these terms and they say, “Okay, I take this application, let’s say I re-platform it, put it in the cloud, maybe upgrade some of the frameworks. I “modernized” it.” But the reality is that you haven’t really done much in terms of addressing the core problems, and a good way to think about this is this chart that I’m sharing with you here. And that is that the more you modernize, the more value you get from the cloud.

0:14:35.6 MR: Let me break it down for a second. If you re-host or re-platform, yes, you’re going to improve your security posture, you’ll improve some of your DevOps, your import-ability of the application, but you haven’t gone deep into the application, you haven’t re-architected it, so of course, you’re not getting the scalability advantages. You’re not getting the engineering velocity gains that you would gain if you truly break those applications into microservices. And so if you re-factor or re-architect, or re-write any of those strategies to modernization, of course it’s more complicated, and we’re gonna talk about this, then you’re able to gain those benefits that I’m talking about.

0:15:15.1 MR: And so if you’re saying that or setting the goal and we’re going to be on this public cloud by, let’s say, 2023. And you move all your applications and you re-platform them, and then you don’t see the gains and basically you experience the disappointment that has to do with not setting the expectations correctly, ’cause if you’re just migrating, you’re not going to gain those benefits. And we see this with many customers that are rushing to move their workloads to the cloud without actually modernizing them. Only to find out later that it actually costs them more, and they’re not getting the benefits.

0:15:57.2 SM: I was about to say a lot of my experience of those lift and shift operations has been, Let’s call them, where you’re just taking something from what’s on existing infrastructure, putting it in the cloud, you almost go backwards in some instances where costs become higher, it becomes a little bit more difficult, it’s quite… Yeah, yeah.

0:16:20.5 MR: Absolutely, and to be honest, the cloud providers are seeing this and they’re tackling this, they’re actually encouraging customers to embark on these modernizations many times they fund them. We can talk about that later as well, but that is one…

0:16:40.0 SM: We’ve just got a question here around what you’re talking about. Around… Could you maybe just go a bit deeper on what’s the difference between re-hosting and re-platforming and then the difference between re-platform and re-factor, say, could you just talk through each of those in really, kinda, really simple, simple explanation? 

0:16:58.0 MR: Sure. Yeah, yeah, yeah. Look, re-host let’s say you just take a VM that is running in your data center, and let’s say you just move it to a VM in the Cloud. Let’s just re-host that. Re-platform could be something a little bit more advanced, for example, you take some application that is running in the VM. But now you’re actually put it in the container. So that requires a little bit more work. Adjustment. It may have to do with also upgrading some of the frameworks, let’s say, you were running on Java 6 you move to Java 8 or more advanced that is better for the cloud. These are the types of modifications that we don’t see, or it’s not we, I’d say this is a universal project. You’re not actually going deep into the code. You’re doing things that are peripheral to the actual code of the application. And so yes, you get applications running in the cloud, and that is… All of these fall under the lift and shift as you mentioned.

0:18:06.0 MR: But when you move to the higher degree of changes and modernization, where I sort of bucketed here, re-factoring, re-architecting or re-writing. You may take an application and completely re-write it from the monolith and rewrite into microservices, or re-factor, which may have to do with, some of you I’m sure familiar with, the strangler approach. Where you start identifying domains within the application and then you’re extracting one service at a time or multiple… One after the other. And slowly you’re strangling, so of speak, the monolith and taking out the functionality into separate domains that are maintained separately. That have their own interfaces. That also has to do sort of overlap some re-architecting, so that may include changing from synchronous to asynchronous application. Making all those changes that are truly cloud-making. Now you’re taking a monolithic application and you’re breaking it into a microservices architecture where you can scale those services separately.

0:19:22.1 MR: You can take advantage of the Advanced Cloud services, for example, Serverless or Kubernetes is in the cloud, or whatever advanced services that the public clouds have to offer. Once you do the true modernization that I’m referring to here. You can actually take advantage of those services. By the way, if you just do the re-platforming or the re-hosting, you can’t really take advantage. Let’s take for example, Serverless. Let’s talk about, for example, if it’s AWS it’s Lambda. If it’s Azure, it’s Azure functions. You can’t take a monolith and just run it on a Serverless infrastructure, right. That wouldn’t work. You need light weight services, and you can do that only by re-factoring the application and then you can deploy on those services. Hopefully, I’ve addressed the question.

0:20:14.2 SM: Yeah, yeah, James said, “Thank you.” So it looks like you addressed it really well.

0:20:19.8 MR: Okay. And by the way, I would mention something that is even more futuristic, and that is that, when you modernize an application, you actually don’t modernize it once, let’s say you’ve adopted a new kind of agile development methodology, you have CICD, you’re deploying at a much higher frequency, and so if you don’t get rid of technical debt, if you don’t pay attention to the increased complexity of the application the more you deploy it, you’ll be back in the first problem where, all of a sudden you have a complicated monolith that doesn’t scale. So when you modernize, the holy grail is eventually doing continuous modernization as you deploy, you want to remove technical debt, you want to get rid of complexity, you may need to break certain services over time, 2 multiple services, so one service keeps growing at some point you want to split it. So that is an ongoing approach to making sure that you continue to be agile and innovative.

0:21:22.9 SM: So Moti, that kinda makes every single engineer and architect in the world probably overly excited hearing you say that [chuckle] and Maybe this is based on asset, but I think that the challenge is often that continuous reflector, hanging on technical debt, or that kind of thing. Often, good noises are made and “Hey, we’re gonna do modernization,” but then once the start and end point of modernization is done, the, I guess stakeholders around this will say, “Well, no, I need functionality now, no, I need you to deliver on customer experience, no, I don’t wanna talk about technical debt again, take that out of the screen, on a very simple basis, get it out of the screen.”

0:22:06.3 MR: Scott, that’s exactly the point that I’m making. Let’s say you do the initial modernization, you take the monolith that you always kick the can down the road, like you didn’t want to do, at some point you’re forced to do that, once you do that, you actually want to do continuous modernization, and that means using technology and other tools, so you do 10, 20% of every release cycle that you do those small changes, to make sure that the code quality stays high. And you remove dead code and things like that, so if you do it that in on an ongoing basis when it’s small, you actually don’t feel it. If you don’t do it and you keep releasing at a very high frequency, yes, you’ll be back in that position where, you all of a sudden tell your managers, actually the release cycle you know how it keeps growing and being longer, and we actually need to invest in technical debt.

0:23:02.3 MR: No manager likes to say, “Okay, no functionality, let’s just deal with technical debt.” And that’s why, again, this is not my invention, and Gartner and others are talking about this, that at the end of the day, if you have CICD, you have continuous delivery, continuous integration, you need to have continuous modernization. That’s the right way to deliver software. And I did preface this with saying it’s futuristic. I don’t know how many people are actually doing it right now. Okay, let’s move to the next one, if you don’t mind. And that is the push… And I know this slide is busy so I’m just gonna talk about it so you intuitively understand what I’m talking about.

0:23:52.6 MR: Many times, you’ve got these legacy applications, and users have this old UI, and it’s kind of slow, and you’re not able to add features, and it looks clunky, it works, it doesn’t work very well and so you say, “You know what, we’re gonna focus on building a completely new UI.” And you put all the resources and you develop this shiny new UI, and the boss is happy, the CEO is happy, because now the customers can see that they have a new UI. Problem is, that two weeks into it, now you need to make changes. But since you didn’t deal with the back-end, now you’re actually… You’re not able to innovate You’re not able to move fast. Again, still every feature, even though you have a nice shiny UI, will take a very long time. And that is why setting again, the expectation if you don’t deal with the back end, with the actual business logic behind the UI, you’re not gonna get the benefits that you’re expecting.

0:24:54.6 MR: So that is another kind of setting the expectations correctly. If you want to get true agile, innovative, but sustainable UI, you need to deal with the business logic first, I would argue. So you first break the business logic into separate services, and then you build micro-front ends for each of those services. And that is the right approach. Again, it requires more resources. You need to do more, and you don’t get to see the benefit immediately ’cause you need to first do the business logic, which the user doesn’t see, and only then you need to deal with the front end, with the UI, which is what the users actually see. So again, I know this is hard, but that is why these projects fail, because people rush to show the shining UI.

0:25:47.7 MR: Okay, let’s move to the third one, which really has to do with, you need to have a different plan for different applications. It’s not one-size-fits-all. I would never argue or advocate that you need to modernize all your applications. What I would advocate is that, you need to assess all your applications, understand what is the level of technical debt in each of them, what is the business requirement for each of these applications, maybe it has a lot of technical debt, but you don’t have to make any changes to it, then you know what? Fine, don’t modernize it. But if the business requires new features, you need to be innovative and you have high technical debt, that would be high priority for modernization. So first, assess your application, then decide which subset you want to modernize. So have a different plan for a different application.

0:26:41.5 SM: When you say calculate, what kind of numbers do you put that in? Do you go like percentage of application, or do you go cost of fixing or… Yeah, how do you think about the calculation, what are the numbers you’re thinking about when you think about calculation? 

0:27:00.4 MR: So there are all kinds of tools. We’ll get to it in a few minutes when we talk about modern tooling. So there are tools that will help you understand the degree of technical debt within your application. There are tools that are more advanced that even use machine learning, to tell you exactly the ROI on those applications, if you were to refactor them, right? So use those technologies to be able to decide which applications you want to to modernize. You’ll be surprised how many enterprises don’t know, they have 600 applications. I won’t use names. I had a meeting with this customer, a very, very large car manufacturer. They have 600 applications. They’re about to move to one of the public clouds and they have no clue which ones they should modernize first. And of course the first step is they need to do the assessment and a good way to think about it.

0:28:02.8 MR: This is the framework that I would recommend. When you think about it, think about the refactoring effort. I wasn’t a consultant but every consultant has a two-by-two matrix. But so you think about the refactoring effort versus kind of the assessment of a technical debt. And of course when the refactor effort let’s say is low, but there’s a high level of technical debt. That that would be an easier choice to go and modernize. If for an example, the technical debt is low the factoring effort is high. Just re-platform it. Yeah. Then just do the lift shift and move it to the cloud. So each of these quadrants kind of can guide you through the right strategy. Of course, there are more numbers around this and more factors of going to the decision, but I try to simplify it and kind of suggest a framework here to think about it.

0:29:00.3 SM: Moti, just back on the setting expectations around UI versus logic one, just a thought’s just occurred to me around, is the problem that people are setting expectations around the UI and then getting burnt afterwards, or they’re setting expectations around the UI and that is taking too long to deliver? What’s the… Yeah. What…

0:29:26.3 MR: I think that the technology teams are under a lot of pressure to show results. And to show results that are impacting the end user. And that’s why it’s very tempting to go and build the new UI. So you can go and show that it looks better.

0:29:48.0 SM: Yep. You can’t demo… You can’t demo a microservice [chuckle] as well as you can demo a new button in an app.

0:29:58.1 MR: Right. And so they fall into this sort of trap of doing the new UI and then realizing that that’s not sustainable. It will look nice on the first day, on the first week, on the first month. But then when they need to add a new feature, modern… Add new stuff, it becomes much more complicated without modernizing the back end. So look… It’s human nature. I mean that that’s… I don’t blame people that fall into that position. It’s just… But if they… But if they look at this with their eyes wide open and they’re able to communicate that to their decision makers, then I think they would benefit a lot from making the right decisions and allocating the right resources and setting the right expectations.

0:30:50.8 SM: I’ll let you keep going. Thanks for that.

0:30:52.7 MR: Yeah, sure. I actually want to share a case study that I happen to be involved with, but I think it’s it’s a good one. I put here the QR code if people want read more about it. But take, for example, in Texas San Paulo, that is the largest bank in Italy, the third largest bank in Europe, more than 100,000 employees. And they had 450 job applications, their core banking applications, internet banking and so forth. And they embarked on this initiative to move to the cloud. So they’re… They want to move to the cloud. Of course they start with their own private cloud, but over time they’re moving to the public cloud and they wanted to move to microservices. They wanted much faster release cycles they wanted to get rid of some expensive licenses.

0:31:48.7 MR: And so they embark in the project and they actually followed some of the ideas that I shared with you. And they identified out of those 450 applications, 110 that they said, these are the ones that we want to modernize. And by using automation and machine learning, which we’ll go into in a minute, they were able to do it relatively quickly, relatively quickly I’m talking about two applications per week, which is a very, very high rate when you’re thinking about these projects of 18 months or beyond and that’s what we call a factory model. That you use automation, you use machine learning, you get into the rhythm and you start modernizing a large number of applications. And the benefits are obvious there. So following some of these concepts really helps.

0:32:43.6 MR: With this I want to shift gears a little bit more into the tools and the approach which is what architects were saying or mentioning as sort of the key problem or contributor to the failure of some of these projects. And I want to actually think about how do people modernize today? So what do they use in terms of tools today? They will use whatever static code analysis tools they have, all kinds of analyzers, analyzers, and whatever their idea has to offer. They work with IntelliJ. They work with the Eclipse, it provides them some visibility into the code, and there are some…

0:33:24.1 MR: Analyzers like CAST, that’s great. A lot of information, not exactly directly tied to the modernization, okay. So they may complement it with dynamic analysis tools, some APM tools like the ones that you see here, great. If you’re embarking on a modernization project, you will use whatever tool is available to you to get insight into the application, into how it works? What’s in it? What impacts it? How it runs? So you’re going to use these tools. But at the end of the day, none of these tools were actually designed specifically for modernization and you end up… What you end up doing is a very manual process, you sit in a room and you kind of do these event storming and you put the sticky notes and trying to figure out what is the domain? What are the boundaries of the domain? 

0:34:17.1 SM: I was gonna say that picture matches more of my experience of modernization.

0:34:24.1 MR: Right. And the more architects in the room, the more opinions you would have, right? And just doing this event storming to try to figure out what are the boundaries of the different domains within the application, this exercise by itself can take weeks and months, that’s what customers are saying. So that is the state of modernization today, inadequate tools, but again, I can’t fault anyone for using them because that’s what they have, and a lot of manual work, and so of course, this doesn’t scale, prone to error and then you get the numbers that we shared at the beginning…

0:35:06.1 SM: Well, I was gonna say even after that manual process, my experiences is that even after that, you still really haven’t improved the data or factual basis around the re-factor, it still kinda comes back to someone kinda going, “Alright, I’ve done a little bit more thinking and we’ve done a bit more of a debate, but I’m gonna put a finger in the air and kinda go, ‘I think it’s gonna be about that.” And we’re gonna go in that direction. So, yes, you’re still, even after months, you can almost be no better off.

0:35:40.7 MR: Yeah. So that is the state of the world today, and I would take you through, let’s say, a thought exercise here, that what if you were… You could compare this to an actual modernization platform that was built from the ground up for this type of project, that provides you the visibility, that synthesize it, to start in the dynamic analysis, that uses obviously, automation, machine learning and is really supports your modernization from end to end. I think that that is where the world is going, and that is what you should research when you embark on these types of projects. Another thing is, you have to be practical, and again, probably I’m not telling you anything that you don’t know, which is, don’t go for the big bang, the big bang problem that you have your system or you build another system and then you go… Or break it into services and go all at once, it will not work. There’s a lot of risk in it, the right approach is to do it as an iterative process, and it starts by identifying a specific service or a specific domain that should be a service, extract that, test it, run it, then move to the second one, and again, do it in an iterative way that allows you to have some predictability into the project, control the risk, and have something running and working, so that’s why I was saying I’ll keep it running, and that is to have something that works.

0:37:29.8 MR: So you don’t have to wait 18 months to see something, you work on one specific domain and you should have it running within a few weeks, of course, if you have the right tooling and automation, you can probably get to that even faster. And we talked about the continuous modernization and that obviously ties into that as well, so you need to continue to do that on an ongoing basis. And kind of my last slide here is that I’ll share with you kind of how I see the world in terms of the tooling that you should be using, I think that you should start with an assessment, with technology that will actually do a very quick analysis of your code, understand the technical debt, if it has machine learning that can quantify how much resources in time you’re actually investing in the technical debt or in the maintenance versus innovation. That is today possible, with machine learning, you can actually train algorithms to learn hundreds of applications, and then when you run the analysis on your own application, it is able to bring all that knowledge and apply the model and tell you that for your specification, let’s say you’re investing a… Take say here an example, let’s say 11% of every dollar you invest in it goes into innovation versus the rest that is going for maintenance.

0:38:56.2 MR: So, I would start with an assessment, there are different tools that can support you there, and then use a modernization platform that they talked about before, that would first learn the application in order to identify potential domains in it using kind of synthesis of dynamic and static analysis, present all that information through the architect and then have some interactive, I call it a studio, to allow you to actually design the services, see the impact of your design decisions, and then actually extract the code, use automation to scan the original source-code, copy it, create projects, automatically create the APIs. And then have these projects, again, do it either serially and you can decide if you want to do one or multiple services at once, and then you’re able to deploy that on to the cloud. I would use actually an example from AWS, AWS has a new service, I’m giving a plug, I’m not from AWS, or I feel comfortable giving a plug here for AWS, they actually have a service where they developed it specifically to support this approach, it’s called Refactor Spaces, where it allows you to run your monitorings and really in a very simple manner, configure it in terms of deployment and permissions, to.

0:40:22.1 MR: Divert traffic and deploy kind of services as you strangle, strangler… Basically strangle them from the Monterey’s out. So Amazon recognizes that I believe, Microsoft will have that soon. They all understand that they need to support these types of modernizations. It’s the only way for the cloud providers really, to unlock the benefits that they have. ‘Cause if you ask me, I think that in general as you think about the cloud migration and kind of where the state of the cloud is, new workloads, you write them in modern architecture, you run them in the cloud. That is 80% of what’s already in the cloud, by the way. And then you have some of the legacy workloads that are very simple that you’ve lifted and shifted. But the majority, you need to do these types of modernization in order to unlock the value of the cloud, which is these modern services. So that’s kind of what I had to share both in terms of setting expectations and some of the tooling.

0:41:27.2 MR: I have another example here from a Fortune 100 Bank running $2 trillion in assets. They had more than 3,000 job applications and the specific example I wanted to share here is that they were stuck in this analysis paralysis. When you have 10 million lines of code or 10,000 classes applications, many times you end up in this analysis paralysis or kicking the can right down the road. It’s frightening to jump into this project. No one wants to embark on a two or three year project to modernize the application. So you’re stuck. What many times you do and this is a very common practice, is that now you replicate the monolith and you’re starting to use each monolith for a specific service. And so you put a load balancer in front of it, and you say, “This part will be this service, this part will be that service.”

0:42:27.4 MR: And this is what I call a distributed monolith type of architecture. That’s not micro services, right? Still each monolith takes forever to load, it has a ton of dead coding in it. You’re really not getting operational micro services. In this specific case, again, they use AI information eventually to break from that paradigm, to actually be able to generate light-weight services that will enable them to scale out the right approach and get the results that they were seeking. I’m gonna finish here, I have another slide of, when asked people sort of the opposite question. Like top factors for successful app modernization. They don’t correlate one to one to the opposite, which is interesting, but you can see here some of these results. It has to do with organizational structure, it has to do with sufficiently build schedule or timeline. That, in other words, is setting expectations, right? And if you think about it, setting the proper resources, again, it has to do many of these things are the symptoms or the manifestation of setting right expectations. And happy to answer any questions.

0:43:47.9 SM: That was awesome. Thanks for sharing that, Moti. That was really insightful around modernization projects. Yeah, if anyone’s got any questions, please pop them in. I think one for me is, how do you kinda break that cycle of analysis paralysis? How do you see that being broken? ‘Cause I can see the issue there is people don’t wanna embark on it because they know the war stories of people who have been shot, so to speak, and lost jobs over it, or lost status and all that. So how do you break that cycle of risk? Is it really getting that more data or, yeah, just curious about your thoughts on that.

0:44:31.0 MR: I think that a way to break it is go and do the research, see which automation and machine learning kind of technologies are out there, and then do a POC. And a POC that is very limited in time and resources could be a couple of weeks, and you should push vendors to see what is the result of that POC. It needs to be something tangible that you can actually relate to and see that if you use that technology, you can actually really shorten the period of time that is needed for this project.

0:45:11.2 SM: And on the POC, do you think, if you’re trying to test out a bit of this new approach that you’re going through of really getting the right data in your hands and then also automating the modernization, is it better in your view to tackle it head on organization wide? That big kinda like, I know you said don’t go big bang, but I can also see some merit in, especially in banking for instance, where you can be seen to be playing around the edges if you’re just touching on non core-banking services and you’re refactoring those, everyone kinda goes, “Yeah, yeah, yeah, that’s all right.” ‘Cause you’re just in the playground. When you’re ready to go and play with the real boys so to speak, the real… [chuckle] We’re not sure it’s gonna… So should you jump in and even though it might be slightly harder, tackle one of those core applications that people are skeptical about or what’s your view there? 

0:46:05.7 MR: No, you’re touching an excellent point, and we didn’t talk about this. So it’s amazing that you’re bringing this up. Absolutely, you’re right. I would very much oppose during modernization, it just… Go for where your pain is the highest, because that is where you’ll have the biggest motivation for success, that is where you’ll see the biggest gain, so don’t play with it. Go treat it seriously from day one, go for the most complicated application but again, do it in a controlled manner, do it with the right automation, not a big bang, do one service, see that it works and go from there. But absolutely, don’t try to fool yourself that… ‘Cause if you’re doing it with noncritical application, you’re fooling yourself ’cause the degree of commitment is not gonna be there.

0:47:07.5 SM: Yeah, yeah. That’s really helpful. That’s probably the biggest one for me is where do you play with it? So that’s really helpful to kinda understand that. What would you say to people who were sitting there going, “Alright, I’ve got a modernization, it’s either underway or we’re about to tackle it.” What’s the first step they should kinda take? Obviously, they should think about v-function, but what’s the first thing they should… What’s that first step for them? Should they be putting a plan together that talks about the way that one should go about, you know this future view of modernization to try and win hearts and minds, or should they jump in and do the known, just gonna go prove it out with the right team? What’s the first step someone should take? 

0:48:02.3 MR: I’m a big believer in answering the why question first, all right? 

0:48:06.3 SM: Yeah, okay.

0:48:07.0 MR: So, get… First know why you’re doing it and make sure that everyone is on board in terms of why we need to do this, and if everyone is on board on the why, I think the rest of the things will fall into place right. Yes, then you will assess which applications are best for it, and then you will test different tools and technologies and you put the right resources and commitment and all the things will fall in place if you know why you’re doing it. If you’re doing it for the wrong reasons, then you’re setting yourself for failure.

0:48:42.0 SM: And what are good whys and what are bad whys? [chuckle] And I draw on some of my… Sometimes that kind of, ” Oh, we need better velocity and we’ve got technical debt,” falls on dead ears for instance. So, I’d love to know from you what are… What really resonates and…

0:49:01.2 MR: So I would break it into… Yeah, I would break those titles, which I also used in my first slide on technical debt. How does technical debt manifest itself along relief cycles. When you’re thinking about the why before embarking on this project, why don’t you list the actual incidence and the actual impact in your organization of why you have to modernize and what are the pain points of the monolith that you’re dealing with or several monoliths. I can tell you that I had this talk to this CIO the other day, and he’s been sitting on this monolith for a year and a half, and he told me, “I’m gonna lose my job if I don’t modernize this because I can’t release any new features. So, I know that I’m gonna lose my job if I don’t do this.” Then you have the commitment and people know it and people see it and the developers know it and see. So, when you talk about the why, you need to talk about specifics. So yes, there are sort of the titles, the headlines, and then you break it into specific examples of why for each application, how does this pain point manifest itself and then move from there.

0:50:14.3 SM: Yeah. Like one example that just comes to mind for me from a large insurer is kind of like deployment times were just way too long, too many teams have to be involved, the test can’t run adequately because the monolith hasn’t been broken down, so it requires manual testing every release. So just, every release becomes this huge almost month long ordeal, [laughter] with lots and lots of investment in it, and just those incidences alone and the impact, flowing impact that has. You can just almost focus on that rather than technical debt, it’s like, “Look, each month we have a huge investment in a release, thanks for that.” Look, I think we’ll wrap up. What’s that sorry? 

0:51:01.0 MR: You know, I’ll put a plug for my t-shirt, I don’t know if people see here and that’s something we like to say that…

0:51:04.1 SM: Breaking Bad cut.

0:51:07.7 MR: Right. So this is what we’re advocating if you’re a Breaking Bad kind of a show fan.

0:51:15.7 SM: Very good.

0:51:17.0 MR: You may want to get this t-shirt.

0:51:20.3 SM: Moti, thank you so much for sharing all of this with us and thanks for sharing the research that’s come out. And thank you everyone who’s listened, whether you’re listening now live or whether you’re joining us on… Watching it again in one of the replays, thank you so much. If you wanna listen and watch more of this kind of content, please subscribe to our channel, put your email in, if you wanna go check out vFunction, you’ve got the links there and it’ll come out in the email afterwards, but otherwise, see you next time, everyone. And thank you again, Moti, for joining us. Really appreciate it.

0:51:53.5 MR: Thank you.

0:51:54.4 SM: Bye-bye.

0:51:54.5 MR: Bye.