Transcript
Rob Anderson: Good morning, afternoon and evening, everybody, And welcome back. Thanks for joining us. I have Simon Michaelides, one of our resident openvms experts with me to talk today about openvms modernization and the state of things in that universe. We've been doing openvms modernization here at Advanced for quite some time. And most of you who are watching or listening today have been involved with it in some capacity, whether it was VAX, VMs, Dec, Alpha, Itanium or its current home with VMs software, it does have quite a colorful and interesting history and there are a lot of things to consider when it comes time to make a change. And I'm hoping that Simon can explore what it means to consider making a change with us today and and hopefully give you guys some information that you can use. So, Simon, can you tell us a little bit about the present climate for for people and companies with Openvms in their estate today? Simon Mikellides: Thank you, Rob. Good question to start with. So just taking a step back. Openvms is an operating system originally designed in the 70s that runs on VAX, Alpha and Integrity Machines, or Itanium Hardware. Vms is a bit before my time. It dates back to the first release by Digital Equipment Corporation or Dec in 1977. Um, and it's decent technology. It's still around today and there's a number of mission and safety critical applications still running on Openvms. At one point it used to be said that 50% of the worlds and text messages were all processed via openvms. And we've certainly encountered Openvms in many places all over the world with some of our customers and in virtually every vertical. They used to talk about a lot of the Paris metro running automatically at one point on Openvms. So decent technology and you still find there's there's a fair few sites around running critical applications, but it's certainly a dwindling market. When I've been with the business ten years now and coincidentally shortly after I joined HP had announced End of Life of Openvms. Um, that was a pretty big event and I think for a lot of organizations that had critical workload on Openvms, it was almost a catalyst to accelerate some of their long held plans to move some of that critical workload into other places and to future proof some of their key strategic bespoke systems. Um. I mean, since then, it's had a stay of execution. An organization took over the development rights in 2014. An organization known as VMs software. So VCI So it's kind of VMs is still around. Some versions are still supported. But really, I think what we've witnessed was over the years and bearing in mind we've been doing this kind of work and helping organizations with Openvms and other technologies since the early 80s, we've seen with Openvms a steady stream of organizations looking to replace Openvms eventually with something more strategic and relevant for their business today. And certainly following the announcement, initially there was a there was an exodus and a real acceleration, particularly from some of the big boys out there. You know, we've worked with large banks, government agencies and all sorts. And so that was a real trigger for change. Rob Anderson: Interesting stuff and it is definitely a cult favorite. We still see folks hoarding hardware. Et cetera. Among the chief modernization catalysts that you run into when you talk with folks who are looking to make a change. What are the most common? Simon Mikellides: Well, I think it's fair to say not everybody embraces change. Um, I think that's particularly true when you're talking about something that's been in place for for a long time. And it's especially true when it's very important to the organization. And, and certainly clients with that kind of profile of application, which is most of them, and it's a very reliable, available operating system. You know, they are incredibly risk averse. So but eventually time catches up with you. So I think you need the right drivers for change and you need the right backing in at all levels. We used to talk about it as the stars need to align. You know, you need a business imperative. Maybe the technology you've got is inhibiting the change that you want. Maybe it's proving difficult to integrate or consolidate. Maybe you simply can't have the resources to look after those applications anymore, and that's posing a critical risk. So, I mean, just to come back to your question, so what's kind of impacted modernization timelines? Yeah, very much cultural. And we and we would say with something that which is very technically important. You've obviously got the techies that look after the applications and the environment. You now have a big say. They can certainly say no to something or voice a strong opinion that it can't be done or shouldn't be done, or you're going to run into this problem or that problem. Rarely they can say yes, but their opinion is very valuable. We've found over the years that, you know, initially some groups that look after these applications on older technologies are very reluctant for change, very skeptical that it can be done in a safe and efficient and cost, you know, costly and and safe manner. And then you've got others which really embrace the change. You know, you've got some of these applications that have been around for 20, 30, 40 years. They're very bespoke. They serve the business. They've been fine tuned and people want them to live on. You know, they're still as relevant today, if not more. Than anything else that's out there. So, you know, we find a lot of the techies that are closest to these applications want the change and want those applications to live on. So it's a real, real mixed bag, to be honest. Rob Anderson: Yeah. And it does seem as though, just like with the rest of of the the large estates that we run into, that bespoke aspect really helps determine the direction that that folks want to go. Um, when it comes to choosing a direction, what are the options that you typically see people take? I mean, you know, especially with the operating system being such a key component of the modernization process. What are you seeing out there? Simon Mikellides: Well, it's well publicized. There's a number of hours when you look at what's right for your organization. And I think that's kind of key. There feels like a lot of options when you first start looking at what you might want to do with a with an important application or an environment. And then it soon scales down to what is actually going to work within the context of your available budget, your strategic goals, the importance or strategic importance of that application to your business. So we find that most of our conversations are either around the rewrite versus replace with a package type conversation. And when you talk about replacing with a package, you're always talking about replacing with a package. And a lot of customization as well. It's very, very rare that you're going to find something off the shelf from another vendor that suits your business to replace a bespoke application that's been in there for decades. So that has to be considered as well. And we do a lot of work to modernize that application in terms of either rehosting to a modern stack or refactoring some of the code. And migrating to modern stack. So we get involved in a in refactoring in migration in that kind of modernization type space. Um. And really it depends on what's suitable to your business. I think it's probably worth volunteering and maybe it won't be a surprise to to most people, but since the 80s. We've probably picked up at least 50% of our business. And the projects that we've got involved in off the back of a failed rewrite or a replacement project that's just for whatever reason, just not got there. You know, and in some cases, actually people use a combination. You may want a longer term strategic replacement strategy to rewrite an application with all the kind of modern functionality that you envisage at this time is going to be right for your business. But in the short term, you might want to save money, reduce risk and move something to future proof it so you can have tactical and strategic together. Rob Anderson: Excellent, excellent answer. And I totally see the same thing. You know, it's good intentions to begin with, and then things get really, really big, really complex, really fast, and then we get the call. Um, and I think it's, it's a great follow on to my next question, which is, is there a a for folks who are considering Openvms modernization, It's very likely that this is the first time that they're going through a modernization process at all. Certainly very likely that that's the case on their Openvms estate that they're working with. Can you give us a glimpse into how that modernization process works with a company like Advanced that's been doing this for so long? I know that. And I think everybody on the on on the webinar today realizes that that the bespoke nature of these systems commands a customer process. But generally speaking, how does that usually go? Simon Mikellides: Yeah, I mean there is a fairly straightforward process. Um, and. I would start by saying. You know, as much as we support or would be involved in 1 or 2 of the technical approaches. The the client has to do what is right for them. You know, that's that's absolutely critical. And it will become very evident what is right as well. So normally there is a process that you would need to go through internally or with some consultancy or with some informed input from specialists like ourselves to determine what is right at a high level or to to maybe reduce some of your options before before you then take a next step. So and a lot of that depends on, you know, whether you're talking about a complete environment exit, you know, multiple applications in a short, relatively short space of time, whether you're looking to reduce risk for one critical system because of lack of resources or or any of the other reasons I've mentioned. Um, and then you want to start really then diving into some of those technical approaches in more detail. Um, we would encourage after some initial fact finding, I mean if, if in the first instance, if you were to work with advance, all we need to know is some answers about the system or about the environment, particularly what languages exist, what they're written in, if it's Openvms, whether they've got DCL, FMS, Dec forms, you know, whether it's a Fortran system, a basic COBOL is usually in there somewhere. You know, we'd like some system information initially and if you're working with us off the back of that, we could very quickly give you an initial view in our experience of roughly how much it would cost for our services. And we bring professional services, but more importantly, we bring the heavy lifting equipment so the tooling and software to safely migrate or modernize certain assets. Um, and we'd be able to give you a view on timescales, end to end timescales. So an assumed amount of testing as well, which is another important part of any kind of project like this. Um, so that's kind of the first step, a bit of initial fact finding, if that fits. And that's right. And it's in the right kind of ballpark and makes sense. Um, then really, you want to do some technical due diligence from a client perspective. You want to do that and from a company perspective, Advanced wants to do that as well. So then that's looking under the cover and doing a technical feasibility study. So this is what we understood on paper. What's the reality like? Let's look at it in terms of complexity. Is it all there? How many SMEs, if any, are still around to support the application? Is there any documentation? Probably not. You know, all of these things need to come together, you know, how does it relate with other systems? All the interfaces need to be considered what's the operational environment? So, you know, that technical feasibility study is essential and at the very, very least, you learn more about that system or it's a nice refresh, it brings you up to speed with documentation. Then you have, in some cases I've had for ten, ten plus years, so very worthwhile. And then you can make an informed decision. So, you know, it's technically feasible. And you know roughly how much it might cost. You've got a view of all the other items around, other factors you would need to consider. You know, you're in a position to make an informed decision about what's right for your company. Rob Anderson: Excellent. And I think it is important to point out that, you know, all of our surveys and feedback that we've gotten from from clients and prospects as well, is that the the key to success in any given modernization project is having modernization expertise to help guide the path. And with that in in at top of mind, can you tell us a little bit about why advanced is uniquely. The best option for Openvms modernization. I think you've touched on it quite a bit with just the process that we follow. Speaker3: Right. Yeah. Simon Mikellides: Um, well, I think, number one, you've got to know what you're doing. You know, we've we we would confidently say that we're a market leader in this space, if not the global market leader, with probably the largest modernization specialist group that can do openvms migration modernization projects. We have people that understand the source technology, the languages involved, the environment. We also have and this is absolutely key, you have to have the right equipment, the right tooling to do this kind of work safely and efficiently to time and to budget. And and we've got mature, very proven, battle hardened industrial strength suite of tooling to effectively look after people's code and data and to make sure that any move or migration or modernization of that system. Limits the impact on the business to the point where it's business as usual. And then there's no disruption to that key activity or service when you go live. So we've got a professional service team really strong. Capable, proven software to do the job and probably more references of a of a of a greater variety than I'd argue probably anyone else out there. Rob Anderson: Yeah, definitely. Can you can you give us a glimpse into a couple of of the, the projects that we've done and what success looked like for those folks? Simon Mikellides: Yep. Um. So ten years ago, going back to when I started, one of the first projects I got involved with was for a very large Scandinavian bank. There was a core business application touched multiple parts of their business, really right at the heart of their company. And like the profile of most customers with important applications in this kind of legacy space, they were very risk averse. They also had previously been on a journey with another technical approach. You know, going back to what I was saying earlier, that there's different ways to solve some of these that hadn't quite worked out for them. So we were sort of picking up the pieces with a team that was pretty big. I think in total they had something like 70 people that were responsible for the application maintenance and development of that system. So a big team to keep happy. Just bearing in mind what I said about some people being incredibly skeptical because they know the system, the complexity is and and how it's been worked on over decades. So we had all of that scenario with them. Plus, we embarked on a project where we did a major language refactor for them. So a major language translation. So we went from an older language to something that was much more mainstream and maintainable. So it's modernization and coming off the platform as well. And for them maintainability had to be. Um. Had to be up there. You know, it's absolutely critical with such a big team. And also, it's one of the drivers. You know, you find that as good as the older technology can be, modern development environments and the choice of new tooling and the art of the possible is so much better. And. Many have said more fun in different environments than in the older environment. So for them, that kind of journey, you know, to be able to maintain the system, also considering their a financial services organization, you know, they've got to be very competitive. The speed of market is incredibly important and it's a very, very highly regulated industry. So the ability to be able to maintain the system, make changes was equally, if not more important than making sure that everything was smooth and and exact functional match. But also, of course, you know, being a finance system performance was absolutely critical. So all of those as well as did it occur within an acceptable and agreed time frame and budget. With with a key success criteria. And that was a very successful project. We're still very friendly with them today. And and that's not uncommon for many of our customers. Yeah, we've we've also done work in the British nuclear industry where that was an incredibly it was a mission critical as well as safety critical application. I suppose the success is that half the north west of England is still standing. It's been no no issues there. Um, but we've done safety critical applications, we've done mission critical applications for, for a number of financial organizations, banks all over the world, very large manufacturers. Um, even Swiss air traffic control was a previous project and people have a choice of what they want to do with that application in terms of the technologies they go to. So success can be slightly different in terms of technical targets, but really the risk mitigation in many cases cost reduction. But the fact that you're kind of giving new breath to these applications and letting them live on and future proof them while you either consider something more strategic for the future. Um, or just deal with an immediate problem. It's kind of what most people are aiming for. Rob Anderson: Sure that makes perfect sense. And and along those lines, from your perspective, having seen so many of these through, um, what would you say? And I think I know your answer to this one, but we'll see. What would you say the most common mistake companies make in the run up to a modernization project like this is? And how could our watchers and listeners potentially avoid that mistake? Simon Mikellides: Yeah. Um. Speaker3: Yes. Simon Mikellides: I do have a top answer on this one. We see a lot of paralysis. You know, and I know it sounds a very flippant answer. But you've got to start. Yeah. You know, quite often these are. There are long held ambitions to make a change. And they're left and they're left to the point where you may have a deadline. You know, at the moment with Openvms, you know, we talk to a lot of customers that need to be off that platform because the hardware they've got is going to be out of support by December 2025. So there's a compelling event there. And the later you leave it, the less opportunity or less choice you have to mitigate that risk. And so we see and it's not just this platform. You know, we see that right across the board. Normally, there's a number of stakeholders. They all need to be satisfied, but not starting a project. As crass as that might sound, is probably my top tip and the biggest risk to successfully delivering a project like that. Rob Anderson: That is a really great insight. Thank you. When when the pivot happens and the choice is made and folks are weighing their options, as we mentioned before, you know, bringing in if you don't have modernization expertise, certainly bringing in modernization expertise, who have industrial strength, tooling to help. Do this safely when they're when they're shopping around, when they're looking at their options. What's the most important question or questions that they can be asking, those vendors that they're considering so that they can de-risk themselves through that process as well? Simon Mikellides: I think I think they need to ask, are you guys the real deal? Can you can you really do this? Can you really help us? You know, have you done it before? How many times have you done it before? Have you dealt with systems that are, you know, either this critical or deal with hundreds of thousands, if not millions of transactions? You know, you've got to start exploring these questions and then you've got to make sure that they can back it up, not just with customer references, which are really important, not just to check whether that supplier is is credible, but also to learn about the project, because other customers can give you a real insight that peer to peer learning is is great for the success of your own project, but they really need to be backing it up as well. I mean, you can go down a manual approach, you know, you can have people replace some of these applications, but it's it's we all know very expensive, very time consuming. Things change. But with automation and software, you know, you can control that process. You can reduce the time, you can guarantee a level of quality and you can have a repeatable process. So check and make sure that they have software that can do that job. They have the automation and that it exists and it's not just something that they're going to build for this particular project for you, you know, make sure it's proven. And then the other thing I would say is make sure they're a good cultural fit. You know, we've done a lot of these projects, so believe it or not, we actually come in with quite a we've got a strong proven methodology that works. It's not inflexible, but it's pretty robust and and solid, and we can follow that to deliver these projects successfully. But make sure the principles of how you're going to interact with each other are are correct and in place. So we like to say and we like to deliver our projects. With these principles in mind, you need the right level of transparency because these projects are, although they, they are technically, technically challenging and complex, but they are entirely doable. But they do involve people working together in the right spirit, you know, and at times rolling your sleeves up together and collectively to make sure that things are successful. So transparency, automate where you can. And just communicate really well. And those are kind of three very obvious but sort of guiding principles. So yeah, experience. Are they the real deal? References Automation and are they a business? Has the right culture that you can work with so that you're both successful? Rob Anderson: Outstanding. And I think we are at the end of our time, and that is a great way to leave it. Thank you, Simon. Really appreciate the time that you've taken with us today. Hopefully all of you have gotten as much out of this conversation as I have. If you want to learn more, head over to Modern systems dot one advanced.com. Check us out on LinkedIn and have a conversation with with Simon and the team and let's talk Openvms. Thanks again. Have a wonderful rest of your day, everyone. Speaker3: Thank you, Rob. Simon Mikellides: Hi, everyone.
