Video: Sammons x Rocket COBOL: Growing with .NET, API, and Containers | Duration: 3749s | Summary: Sammons x Rocket COBOL: Growing with .NET, API, and Containers | Chapters: Welcome and Introduction (6.4s), COBOL and AI (391.73s), Customer Perspective Introduction (954.6s), Architecture and Modernization (1032.9s), COBOL Roadmap and Events (2737.43s), Quiz and Roadshows (2851.25s), Quiz and Answers (3091.205s), Gartner Magic Quadrant (3218.78s), AI in Industry (3523.885s), Conclusion and Thanks (3594.11s), Conclusion and Farewell (3653.09s)
Transcript for "Sammons x Rocket COBOL: Growing with .NET, API, and Containers":
Hi, everyone. Welcome. We're gonna give everyone a few minutes to get joining us. Love it if y'all could jump into the chat. Let us know where you're coming in from. I'm in Michigan. It's actually really nice today. So, if you could, I would love to hear where you're oh, New York. That's great. Maryland. Oh, so many different places. Nice to see you all. I got another Michigan in there. Italy. Oh, awesome. France, that sounds lovely. A little bit jealous there. California, we appreciate it. There's so many people. I know just here on the rocket side, we have people from The UK, Pennsylvania, and Texas. So, yep, very excited. We're gonna give everyone just about one more minute to join so we don't start before people are coming from their other meetings, things like that. So let's hold on for a minute and get going in a second. Alright. I appreciate you all reaching out in the chat. The chat is gonna be open throughout the entirety of the session, so feel free to put in questions or feedback about what you're hearing in the in the chat as we go along. Along. California, South Carolina. We are all over the place. That's fantastic. Alright. So I think we'll go ahead and get going. Just as a welcome, my name is Keli. I will be taking you through the beginning part here. And today, we're gonna be talking with Brad Curry from Sammons about his modernization journey that they go through. Before we get started with that, though, I would like to do a little bit of housekeeping. We are going to be recording today's session That will be distributed out later on our forum. I will explain a little bit more about the forum in a minute, but it'll be a great way for you to if you find anything super interesting or a colleague of yours wasn't able to join, you can go back, check it out again in the future. The second thing we should note is that we really want this to be interactive. Use that chat, use that Q and A. I'm glad so many of you found it already over on the right hand side. Are gonna have a q and a session at the end. So if you have any questions specific to Brad or to Scot when he joins us later, feel free to put those in the q and a, and we will get to those at the very end of the session. And then at once everything's wrapped up, you will get a post event survey. We'd love to hear from you, get your feedback, what we did great, maybe what we didn't do so great on. You let us know. We want to hear from you about that. So a little about the forum. Down at the bottom there, you'll see a QR code, and we will be putting, the link to the forum in the chat as well. It's a great place for you to connect with other subject matter experts, other people using the visual Cobalt tools, but also our engineers. This way you can learn about latest releases, new updates in the products, news about the tools, but also ask questions and get feedback from other users and from our engineers who can answer some questions for you. Just a little bit about Rocket Software. We are focused almost exclusively on software modernization. We have about three over 3,000 rocketeers across the globe with 18 offices in 18 countries, and then rocketeers spread out in even more countries from that. But my favorite statistic about this is that of those over 3,000 rocketeers, over 2,000 of them are engineers. And I think that really kind of talks to why we do modernization so well. It's because the focus is on the engineering of the products and the tools that, we provide. A little bit about today's session, we'll talk about how Rocket Cobalt is turning 50. It's a pretty big achievement there. And then we'll get into a little bit about Cobalt and GenAI. There's a lot going on in the news about that right now, and so we wanna just kinda let you know what Rocket's stance on that is. But then we'll get into the part you came here for, which is the Sammons modernization journey. We'll talk to Brad, get his insights, and hear from another user exactly what it is they're they're doing. At the end, we'll wrap up with a quiz where you have a chance to win some prizes, and then we'll get into the Q and A. So please make sure you're putting those questions in there so that we can make sure we answer those for you. So just a little bit about how Rocket is turning 50. It's very exciting. We have been using these Rocket and supporting these Rocket Cobalt tools for fifty years now. We have shown that we focus on application modernization by doing thousands upon thousands of successful modernization projects all across different types of organizations from fintech to retail or travel. And we do that with the support of over 200 engineers specifically dedicated to developing the Rocket Cobalt solutions. And we do that because we understand that each modernization journey is a little bit different. What works for Sammons may not work for you, but we have solutions that will kind of cover you across any of the the journey that you're on, really. And so we're here to help you with that modernization road map. Up next, I'm going to introduce you to Susan Drennan, who is going to join us to talk about the Jet AI. Okay. Thank you, Keli. Hopefully, you all can hear me. And as Keli is done, I'm also extending my welcome to partners, customers in the COBOL space. Thank you all for joining. Special shout out to some old friends I saw coming into the group. As Keli mentioned, I'm Susan Drennan. I'm the vice president of sales for our COBOL solutions in The Americas. And before we get to the main topic, I wanted to take a few minutes to discuss yet another moment when COBOL has taken center stage in the world's news. You are probably aware that a couple weeks back, Anthropic, which is an AI research company, spoke out about COBOL, announcing that the Anthropic LLM known as Claude, and I understand, Sam Claude is tuned to be a code transformation LLM, could rapidly refactor COBOL, removing it from mainframes, distributed environments, etcetera. Their point was that Claude could rapidly read and rewrite COBOL into other languages, helping move these applications off the mainframe to other platforms. It seemed to be an announcement about killing the mainframe and perhaps killing COBOL, and this announcement caused a massive market reaction. On that day, they made the announcement, for example, IBM stock dropped about 13% in one day. So what do we make of this? What does what do we think about COBOL and AI? How should we feel about the future of COBOL? Frankly, AI is going to we don't believe that AI is going to be the final blow of COBOL and COBOL applications, but we do see how AI is going to support future modernization of these critical environments. Part of this response to the market included voices from industry experts, code watchers, market advisers. They've all stepped in with some considered opinions as did Rocket Software. What we have said, and and you can go out to LinkedIn, for example, and check out Rocket Software Software CEO responses, we've made, we've made a couple comments about the market view of this. And, frankly, Rocket Software is actually quite bullish, enthusiastic even on how AI can help support COBOL advancement and address many of the challenges such as skill shortages or code understanding that our customers are facing. And we do see analysts agreeing on this point. We do think that instead of AI being used to manage some sort of rip and replace project, which is inherently costly, risky, we really feel, as do others, that using it to understand, your environment is really where a AI should be focused. So Rocket Software, in my view, and I've said this before, is really a custodian of COBOL. And why do I say that? As Keli mentioned, we have a large investment as a company in software development. That includes COBOL. We remain committed to supporting COBOL and the advancement of the applications. And as the world changes around us, we've always moved to change with it and ensure that the assets you carry that are written in COBOL can thrive and modernize. So how should AI be used to support these existing environments? In our view, AI is going to be a positive game changer for COBOL application development. And if we focus on this left column, there are various areas where we feel large language model implementation really works well. You should use it to read the code, document it, modernize where sensible. Use AI to make the code accessible and understanding understandable to the modern developer, which, of course, addresses skills issues. You can have it basically provide Copilot like style Q and A of your code, giving code explanations and opening the code to newly onboarded developers. And what else do we see? We see understanding the impacts of code changes and using AI to clean up dead or unused code works really well. Speed encoding is also benefiting from AI, assisting refactoring, code support, code understanding. These are all great uses. So where do we feel it falls short? Let's address the right column. Rocket Software is not alone in the view that system complexity, large environments, millions of lines of code, interwoven interwoven languages, utilities, schedulers for batch runs, tightly coupled data. These are not simplistic rip and replace considerations. The issue with COBOL is not understanding the language. The issue is understanding all the complexities that tightly wrap around the code or through the code. AI is not able to provide a safe path for retuning these entire systems. So instead, we recommend you focus on the left column. This is where AI can help modernize and keep your COBOL relevant. Moving forward, let's cover some of this again. COBOL is an easy language to learn. Removing it is not what we think is useful or beneficial. Instead, let's focus on what we should be doing. Our customers are running applications everywhere. We are able to help move applications forward onto any modern system. Windows, Linux, cloud, containers, these are all environments where we see COBOL applications that might have been written decades ago now thriving. COBOL also operates as modern language integrating with Java, dot net, REST APIs, etcetera. We also see COBOL being supported by modern user interfaces, which is making it highly accessible to any newly brought on developer. And we're looking to boost developer productivity through the use of GenAI, including Copilot or Claude, and by using industry standard development tools like Versus Code. So one last slide, before I turn over the microphone. And this is just a bit of a summary on our philosophy of the use of Gen AI. While we do work to be the global custodian of COBOL environments, we aren't doing this in a silo. We are listening. And, frankly, I'd be I'd love to hear from you all on the on the chat here where you feel AI can support you, but we have been taking guidance from our customers and partners and and that excuse me, analysts on where we feel we can apply the value of AI in a sensible manner. So firstly to remember, we do not compete. We are not looking to compete with Copilot or ChatGBT or any other LLM. Instead, we're looking to complement them to make the enterprise ready for modernization and make them more accurate. Instead of leaning in on fully predictable predictive AI responses, we're blending it with deterministic approaches. And what do we mean by deterministic? Deterministic basically is a system that produces the exact same output every time it receives the same input, which is what we want from our code. We want our code to re be very accurately re replying with the right responses we expect. And what is Rocket Software doing? So Rocket Software is utilizing our tools such as COBOL analyzer. It's being tuned with verified information to provide verified results and feed those results into large land language models, the one of your choice. And we've also added COBOL context from our compilers, from documentation, as well as COBOL syntax and other sources to ensure we're getting accurate output. So this approach to AI implementation, in our view, is the right approach. It proves it provides trusted insights and accuracy and removes misleading coding responses or worse, responses with room for interpretation. Okay. So I will wrap it up. Just to say Rocket is thinking about AI and specifically how it can support COBOL advancement, we're frankly excited about this time. It's anyone's bet, really, how AI will shift our worldview. But from the perspective of COBOL applications, we see this as a reason COBOL will actually remain and thrive and continue, and we will use AI to support the customers' application needs. Okay. So with those comments, I'm going to pass to our main topic for today's webinar. Please join me in welcoming Brad Curry from Sammons Financial Group. Brad has joined alongside John Grubbs and Scot Nielsen from Rocket Software. And I join you all in my interest to hear how Sammons is working to modernize and advance their application environment. Thank you all. Thanks, Susan. This is John Grubbs. You've heard from Susan and Keli on, I guess, who we are as a company and how we're thinking about AI, where it can add value for Cobalt modernization, and where a more thoughtful approach is needed. I guess we'd like to now move to the customer perspective. And I'm, having worked with Brad for almost a decade now, I'm pleased to introduce Brad Curry, the principal architect at Sammons Financial. Sammons was, an early adopter of Visual COBOL, and they've been a key partner in helping shape how our tooling has evolved, especially around COBOL, workloads, running in Docker containers and managed by kuberneteson.net. Joining Brad will be Scot Nielsen. He's our vice president of product management, and he's been leading our evolution from our side and working closely with customers like Siemens to turn real world requirements into product capabilities. This has been a a genuine two way partnership, and and today Brad and Scot will share what the journey has locked has looked like and from both perspectives. Thanks. Thank you, John. Thanks for the introduction. Hello, everyone. Brad, hello. Thank you for joining us today. I'm looking forward to our conversation. Yeah. Thanks for, having me, Adam. got a lot in store. Thank you. Thank you. Thank you. We got a lot in store today, a lot to cover about some of the business motivations around modernization at Sammons. We're going to talk about architecture. We're gonna look at things like dot net containers. We're even gonna discuss rewrites as well. So there's a lot we wanna get through today. But I think where it would be good to start off today is just to share and reveal a little secret to the audience about actually when we first met because last week we came together to prepare for today's conversation. And what we realized is that we'd already met each other. It just happened to be eight years beforehand at a customer advisory board. in Troy, which was really interesting for us to kind of meet again and reconnect. And actually, for me, it was, you know, professionally really fulfilling to find out everything that you've been up to since in that intervening time. So we we had a great conversation. And so I wonder, Brad, actually, maybe a good way into today's conversation is just to help set the scene about your experience in IT, what you've been doing before you joined Sammons. And because I think you bring a really unique perspective to the conversation today. When you're at the cab, I remember you had only just joined Sammons Financial Group, and you were listening in to a lot of the conversations we were having at the time. So hopefully, that prepared you for what was to come, but perhaps you can just give us a quick overview about your career leading up to that point. Yeah. Sure. So I've been I've been in IT nearly twenty years at this point in my career. I've been in the architecture space, leading architecture teams, wow, maybe fourteen years at this point. So I've spent some time in the manufacturing side. I worked at a company called Pella Corporation many years ago. Feels like feels like a lifetime ago. They they're a window and door manufacturer. I managed assembly lines at warehouses and things of that nature. So wasn't really in that IT space at that time. But it gave me some unique, know, unique perspective on what it means to get a product out the door. Right? So I've sort of brought that with me in in the rest of my career. I've spent prior to to Sammons, I spent some time at a company that did virtual reality software development and command and control centers and for engineering firms and things like that. It was pretty pretty interesting. After that, I spent some time in financial services at a company called INTL FCStone. It's now now known as Stonex. And just a wide array a wide array of of financial services that those guys support. And then I've been at Sammons Financial Group now, which is insurance and annuities and wealth management primarily for the last eight years of my career. Wow. Right. It's, you know, it's when you mentioned VR, it's not the typical experience you are anticipating for someone working in what we can call legacy IT systems. Maybe you can touch on your experience with Cobalt, in fact, you know, leading up to that point in the customer advisory board. Yeah. Was there much experience in little. Right? I spent most of my time in dot net and c sharp and just as you would call them more modern languages, I suppose. Right? And but I had my during my college education, I spent a ton of time that was largely focused on COBOL and CICS and JCL. And so I, you know, had some experience there, spent spent two years essentially during my coursework doing COBOL and CICS. So it was sort of an interesting thing. And then when I moved into the industry, I did no COBOL, right, you know, for for a good number of years. And so I've had I've had the knowledge of it, a little bit of experience, not not really professionally, but just during college. And as I moved to to Sam's Financial Group, we're kind of a mix. Right? So we have some c sharp and some .net and some more modern stacks, but we also have COBOL. And our COBOL is dot net COBOL. Right? So the visual COBOL that you guys offer. So, yeah, it was a it was a little bit interesting. It's a large application that that runs our organization from an annuity perspective, two two and a half million lines of code or or more depending on how you look at it. And so just digging in and, understanding what that application does, what features does it support, and how does it help ensure that we're successfully operating our business. So it's been an interesting journey, a fun journey in the last eight years. But, yeah, a lot of experience in proper COBOL professionally until I joined CMS. Right. Well, I think you've probably had plenty since, but it. is interesting that perspective coming. Your background as an architect and leading a team of architects, I know, at Sammons, but your experience, you know, touching on COBOL at the very beginning. But then it was, you know, as you say, more modern architectures and ecosystems around dot net. And I guess bringing those two worlds together was part of your your mission at Sammons. Right. But maybe before we we kind of before we get into the tech side of things and looking at that architecture, I know we're not here to just talk about technology for tech's sake or architecture for architecture's sake. There's always going to be a business driver around modernization behind that. And so maybe you can share with us what was happening at Sammons that that kind of put the spotlight on these systems. What was happening? Yeah. I think, you know, I think most organizations land in a place where they wanna grow. Right? And Sammons is no different. We wanna grow. To do that, you got to get into sort of new markets, maybe diversify your portfolio a little bit. But speed to market matters. Growth is really the big driver there. But at the end of the day, really, Salmon's mission is to make sure that we're helping our customers, you know, for the for their future. Right? You know, how do we empower them to have a successful retirement? And so, you know, we what we're really doing is broadening our offering and growing in in those ways so that we can further help support, you know, our customers into the future of their lives. Right? So for for Sammons, that that growth means more annuities, more insurance, more wealth management offerings. Right. And so it means more volume on on a system that, you know, has had some challenges being able to support the volume that we're at today. So that's really been one of our key drivers is just thinking about how can we be more flexible and offer new products and, you know, new partnerships, but also driving scalability into our application so we can support that growth in that larger volume of product. Right. Right. That makes complete sense. I mean, these systems, the the the volumes of data that you're dealing with, the annuities, as you say, the way that your industry now is adapting and changing to the needs, you know, personalized personalizing their offerings and making them much more individual. You know, there's a a spotlight on the systems. And, you know, in my experience, that is also likely to raise questions about whether those systems are fit for purpose moving forward. And, usually, there's going to be some discussion about whether actually a new system needs to be created in some way moving forward, and you will get into the conversations of rewrites. And, presumably, these are conversations that, you know, you've had at at Sammons and weighing up pros and cons about the existing systems. Can you tell us more about, you know, your your discussions and your decision making process there? Yeah. You know, it's it's kind of the elephant in the room, right, when you're talking about, you know, something we deem as a legacy system. And legacy really just means it's been in the organization or in an organization for a period of time. Right? Even new stuff can become legacy at some point. My my perspective, and I think our perspective just in our architecture space on my team, is that, you know, we we hear the word rewrite all the time, and you can do you can do that. So, you know, you guys talked a little bit about GenAI and some of the things that have been going on in the industry. And, you know, I think everyone's really looking for an easy button. And the the problem is that the easy button doesn't really exist. You've gotta do your due diligence and and make sure that you really understand, you know, what features and capabilities exist today. You could rewrite in some other language, and we've, you know, we've all talked about that. But a simple rewrite just brings the same architectural constraints that exist in the system today into a new language. So for me, it's really about how do we architect, how do we wrap a more modern architecture around some of the legacy tooling and legacy capabilities that we have today to support the needs of the business into the future. So it's not just a let's move from one language to another. That's a huge challenge in and of itself, but it just it brings some of those same architectural constraints to the new language. So to me, when when I hear rewrite, I always say, well, rearchitect. Rearchitecture. Right? Let's use some more modern design patterns and techniques to enable scalability and and flexibility into the future. Right. So yeah. So rewrite, I guess. It it's not enough, is it? You've got to rearchitect, as you say, rebuild. And, you know, this is a whole other kind of project you're taking on. You mentioned was it two and a half, 3,000,000 lines of code or something? You you can't just rearchitect that overnight. That's right. And and this is the system you have in place. So I guess with that, you know, understanding, what was the next steps then and, you know, the the architecture that you needed to put in place around those existing systems to support the kind of workload demands that the business needed moving forward? How how did you approach this? Yeah, it's a bit of a mix. It's a huge challenge. You know, I think for us, the key and by us, my architecture team, my group at Sammons, what I think makes the most sense is look at the try to understand what the workloads are that that are happening. So what are those high volume processing capabilities that you need to have some scalability in? What are the what are the features or what's happening there? What what workloads are actually occurring in the high volume processing space? You know, sort of break down your application into more composable, well, components. Right? And you can rearchitect smaller bytes much easier than you can rearchitect an entire application. So you've gotta you've gotta sort of think about things and and categorize them and chunk them out, put them into smaller buckets. And this is where, like, dot net APIs, you know, wrapping APIs around certain types of functionality, containerizing certain components of your application into smaller bytes. That allows you to make different architectural choices rather than it being one gigantic monolithic application like we're dealing with today. Right. Right. It it certainly sounds like you're bringing some of that thinking from your experiences be before working in dot net and composable systems and applying some of that bringing some of that thinking to probably a large monolithic COBOL application, but doing it in a pragmatic way, which is not just to rewrite it all in in one fell swoop, but still arrive at something that supports the needs of the business. And maybe we can now actually get into some of that detail on the architecture. We've mentioned dot net a couple of times. I know Sava's there ready just to pop up a slide here for us to talk a little bit about dot net COBOL systems. And if I can, just in case anyone's listening today is not aware of this capability in the product, but this is the compiler can produce all different types of executable formats from native code on a variety of different platforms, including ARM recently, which we we just supported. But also something we've been, providing for some years now is the ability to take a COBOL, a regular anti COBOL application and compile it to dot net intermediate language so that it can run as the slide here. It says as a first class citizen in dot net or indeed in JVM if that's your preferred deployment platform. And I I know this is something that Sam has taken advantage of, so I wonder if, Bradley, you can just talk us through a little bit more detail about how you're leveraging dot net in your architecture and and how that's made a difference to what you your objectives. Yeah. I I would I will say that the beautiful part about it is that we had moved some number of years ago from mainframe COBOL to cobol.net with your guys' help and support. And that happened long before I was in the organization. But it was a it's a really a critical stepping stone to being able to do some of things that we're talking about. Right? And so I know that there was there's a large effort to to move away from mainframe and move into that dot net space. And we've actually you know, we've leveraged and I think Cobalt five and six and eight, and now we're, you know, talking about moving to 11. And so just the the language support and the capabilities that you guys have offered is have really laid the groundwork for us to be able to do some of this rearchitecture. So it's been a it's just a a huge massive help for us. That's fantastic to hear that. And I certainly know from other customers who've who've moved their applications into this architecture, that integration, that seamless integration they have with dot net and c sharp, just really opens up the the scope of possibilities for. modernization. One thing you're able to do is sort of interrupt between. Right? So I can write libraries in c sharp. I can write libraries in COBOL, and they can be called sort of interchangeable between the two languages. Right? Because it's at the end of the day, it's really just dot net I l. And so the things are very inoperable, and it really helps us to be able to do some of the things that we've been talking about. Right. Right. Yeah. It gives you the choice about where you kind of implement new functionality, I guess, depending on what you know, whatever circumstance you wanna look at, but whether that's written in COBOL or it's written in c sharp, doesn't necessarily matter technically because it's equally accessible to to either audience. And I I wonder actually, Brad, if you could comment on that. If I just skip forward a slide here, I think we've got, a couple of snippets showing what, COBOL looks like inside of dot net and talking a little bit to how a COBOL developer can take advantage of the dot net platform. And it doesn't mean instantly that they need to become okay with object oriented techniques. Here, we've got a couple of very simple examples of procedural where the developer can access dot net data types, which are really powerful. Just a few lines of code here doing some really powerful things that actually could take a lot more coding in a regular COBOL program. But I wonder, perhaps you could share with us, you know, what the situation looks like between your COBOL and c sharp development teams at Sammons. How how are they how are they getting on? Are they, in fact, two different teams? Yeah. Well, it's it's not. Right? So, you know, the the the teams are sort of intermingled. We've got some some folks that are that are trained and have tons of professional experience in the in just native COBOL. Right? Procedural COBOL, the the more common approach. Right? But we all the the same team members, they know c sharp. They know dot net. They're able to sort of move between the two. And there there is a bit of a challenge. Right? If you take what we've noticed is if you take a team or a group of folks that have just, you know, largely not been in the object oriented space, they've been in the procedural side of things, it's a little bit more challenging to learn the object oriented. There's just a lot there. Right? But if you take someone who has been on the the object oriented side of things and you you bring them over and, you know, they're working with COBOL, it's a little bit easier to to deal with and understand it that way. So there are challenges, I think, no matter what language you use. You know, those those techniques, there's challenges with design patterns and architectural patterns. Those are all things that, as software engineers, we just have to work through and learn and continue to grow. But I think that it's very easy to transition between the two based on the language support that exists today. So you can have them both in the same IDE. You have a mix of projects calling each other. You can have some c sharp application, you know, class libraries. You can have some Cobalt programs. They can be following each other. So it's been really kind of a nice mix for some of the things that we've been trying to do. And I actually I we're just keeping an eye on the the chat there, Brad, from our audience, and I could see some questions actually about Unix apart from, Unix to dot net. And that's actually another interesting thread for us to discuss here because not only are you deploying the COBOL into dot net platform, but we've also got to bring in the conversation around containerizing that. and the fact your intention is to deploy it, the dot net COBOL, onto a Linux environment in in the future. Perhaps you could share just a few more details about why you're doing this and the benefits. Yeah. I think, you know, if you if you start to look at how do I make an application more scalable, How do I make an application more resilient to more fault tolerant? Being in the Windows platform is is great, but you're really I don't know if you've heard the term cattle, not pets. Right? So you really have this situation with Windows and servers and virtual machines in which there's a lot of care in feeding. You gotta keep. them up to date, patch them, make sure that they're operational. And the infrastructure to scale on Windows machines, it requires, you know, could be software appliances or actual physical devices for load balancing and those sorts of things. But if you start to move into containerization, we use a platform called Kubernetes, KAIDS for short. And we can dockerize certain components of our applications and, drop them into a Kubernetes deployment. And what that allows us to do is sort of automatically load balance and get the level of fault tolerance that you wouldn't otherwise get. You'd have to build all of that sort of infrastructure out. So, you know, being able to move off of full framework dot net, which is, you know, dot net four five, four six, four seven two, four eight, four eight one, moving away from full framework and moving to, you know, sort of the new dot net, used to be called .net core. So you're talking dot net six, eight, 10. Being able to move to those allows us to move into a containerized environment. And we get just out of the box some of that resiliency, some of that fault tolerant behavior, and load balancing and scale. So if I've got a workload that is performing a series of operations, maybe I'm listening to a queue. If I put a million things in a queue, I might wanna scale my application the number of components that are reading from the queue. It's a competing consumer pattern. Right? So I have my first container reads 10 messages. My second one reads a 100 messages and so on. And I can just sort of elastically scale that. So what you get is this sort of scalability and flexibility out of the box. So I think it's an important good step. Right? And it's one of those things that I think I advocated for with with you and your team, you know, over the years. I think it's an important good step for us. Yeah. Absolutely. And I know we're working together to kinda build some more capabilities there. But I. so I think it's fascinating. The the consolidation around infrastructure, operating systems, and hardware over the years, you know, from mainframe, midrange, Unix systems, and converging around x 86. And we had sort of Windows and Linux, you know, as there's the kind of go forward strategy. But now ARM has appeared. And in fact, despite, you know, choosing dot net, which, you know, a few years ago would have anchored you into that Windows platform, that now too is available on Linux systems. And, you know, that COBOL portability actually that you're benefiting from it is still really important because infrastructure movements are still playing out. And here's a, you know, a great example of it. But in addition to that, you know, you sound like you built this fantastically scalable architecture, at least that's where you're moving to, from legacy systems that were never designed to run horizontally scalably. They were, you know, for scale up systems, as you said, for your your your pets rather than cattle. infrastructure scenario. But you are able to do that even with what the industry tends to refer to as monolithic applications, you know, which I think is a fantastic outcome and clearly how you're able to deal with that increased workload. Thank you for sharing that. And I can see some other questions. Others are interested in this in the chat as well, so we better make sure we leave time for that. Sure. Maybe we can wrap up up here, Brad. If I can just maybe ask a couple more quick questions for you. Know, thinking anyone on the on the call here who's managing a large cobalt estate, you know, and they may be at some sort of crossroads about what what to do next. What's the maybe one thing you'd want them to take away from your experiences in this call today? Yeah. I would say it's probably three things rather than just one. But maybe the three things would be, you know, take small bites. Don't try to change the universe in a big bang. Take small bites. Right? Eat the elephant one bite at a time. The? second thing would be think about the architecture. Right? It's not about just rewriting or, you know, making making those types of changes, but think about the needs of of your business and what the architecture should look like to to better support the business into the future. And I think that's one of the key components that we think about on our side. And that really is the third one as well. The business should drive should inform our technical direction. They shouldn't dictate the technical direction, but they should inform the technical direction. And so we're not changing technology or, you know, making modernization a thing because the technology is fun and cool, it really is to enable a business to be more successful into the future. And I would say, you know, those are really the the key drivers in the way we're thinking about things. Excellent. Well, thank you for those, you know, that wisdom, over those last eight years you've been here. And I think clearly bringing someone of your caliber in with that experience, you know, absolutely can bridge the gap with these systems and help them move them forward on the path that you've you you're, you know, described to us today. Sure. I know you're you're gonna stay with us, Brad, for some questions, but let me just thank you. Brad Curry, principal architect, Sammons Financial. Thank you for this session today. Really enjoyed it. It's been great to catch up with you again. Even though it was a bit of a surprise, but it's been really fascinating to hear about what you've achieved. So we're going to wrap up here and I'm going to hand back over to Sava and we'll be back on stage shortly just to handle some questions. Sava, back to you. Thank you so much, Scot, and thanks to all the speakers and especially to Brad for sharing their modernization story. It's been a great conversation. Please feel free to ask Brad and all the other speakers questions via q and a tab, and we will be answering them shortly. Just a few things from my side before we continue with the quiz and then q and a. The first thing I wanted to cover is dot net support, GenAI support, containers, ARM. All those things that we've been doing for the last fifty years is our commitment to make sure that your mission critical applications within COBOL are modern and current and drive business value for your enterprises. So we have a road map. It's our vision for the next few years with the main modernization teams that we see in COBOL. So it outlines things like AI driven development and tooling, COBOL language innovation, and how we adapt and take syntax from other languages and apply it to COBOL, develop tool chain, security, and other topics. If you want to learn more and get familiar with the road map, please feel free to reach out to your account managers, and we will be happy to share with you, get your feedback, and iterate because it's gonna be a living and breathing document that we are making sure is, reflects what's happening in the world right now. And then last thing from my side, so we love to talk about Kobo. It's kinda our thing. And last year, we had a successful Rocket Kobo roadshow from Germany to Australia to France and then to London in October, and we continue this roadshow this year in 2026. We already have a few couple days in April and May. So if you're gonna be in Milan in on April 14, please join us. Madrid, May 6. And then we have a full tour in Australia with Sydney, Canberra, Melbourne, and Brisbane. Actually, Scot will be presenting there, which is a huge deal, and we're very excited to have COBOL in under Down Under. And quick question before the quiz. Please let us know whether you want to see COBOL Day in 2026. And if you are up to see us and talk about COBOL and hear about COBOL modernization, see the product demos, and our customers' modernization stories, please let us know in the chat. Actually, I see the question in chat from Ray. No roadshows in The US. Please let us know where do you wanna see a roadshow in The US. We will be happy to explore this opportunity. So drop in a chat, and we will analyze everything after the session. Okay. I will give a few, maybe, like, thirty seconds so everyone can type in their cities and their dream destination for a Kobolday, and then we can proceed with the quiz based on today's content. West Coast versus East Coast. Love it. Love it. It. While you're typing in your cities, we're gonna have a quiz today. There's gonna be five questions based on what you heard today from Keli, Susan, John, Scot, and Brad. Each question will have you will have thirty seconds to answer. Please send your answers to the chat. And tomorrow I think early next week. That's, that's the correct timeline. So early next week, we're gonna share the quiz winners via forum, and we're gonna give you rocket gifts. There's gonna be five winners, so the most important thing is to be quick and correct. And with that, let's start. And after the quiz, we're gonna have a live q and a with Brett and rocket speakers. So the first question is what anniversary does Rocket Software reach this year? Is it June, '22, or '15? See a lot of answers in the chat. I think I see some rocketeers, our colleagues. Sorry. So we have ten seconds to go, and we'll proceed with the next question. And the correct answer is number four. Rocket Software turns 50 this year, and we're actually preparing a lot of, very, very interesting activities for you this year, so stay tuned. Next one is how many engineers are working on Rocket Software? So something we heard today, Lattice Rocket Visual Global, our main product, but how many engineers? Is it 2,200, 71, or 39? And, again, ten more seconds, and we will proceed with the question number three. And the correct answer is number two. So 200 plus engineers are actually working on Rocket Global, and Global is a language, which is also super exciting. The next one is where does JennyI drive enterprise level value today? Someone is super quick. Like, I'm not even finishing the question, and the answer is already there. So, yeah, is it onboarding and skills amplification? Is it quality and safety, including unit testing? Is it application understanding or all the above? See a lot of answers in the chat. And the next two questions will be about Sammons, so be prepared for that. Four more seconds, and we will proceed to the question number four. So the correct answer is all the above, and thank you, Susan, for walking us through the GenAI section today. The next question is what were the key goals of the rearchitecture project at Siemens? Was it to improve end user experience, improve flexibility and scalability? Was it to improve security and compliance standards, or support a new product release? So the goal, of course, there were plenty plenty of goals, but what were the key ones that Brett mentioned today? We have five more seconds, and we can and we're gonna proceed to the last question of today's quiz. So the correct answer is to improve flexibility and scalability, and it's something they achieved with .net containers and API. And the last question is, what are the two main programming languages in the bread's team? Is it COBOL and Java? Is it COBOL and AccuCOBOL? Is it COBOL and c sharp, or is it COBOL and dot net? So this is this is a tricky one. So be let's see. Ten seconds, and we'll call it a day. Okay. So while that net is a framework, Brett's team is actually using with their COBOL application. The two languages are COBOL and c sharp. That was the correct answer. And on that, I think we can proceed to q and a. Before, again, we'll calculate all the answers, and we will share the quiz winners early next week on our forum. You can find the forum link in the chat. And, yeah, stay tuned for all the other exciting things happening with, Rocket Cobo. And before we proceed with the q and a, we have exciting news that Visual Cobo, the main product that we were discussing today, was, is going to be featured in Gartner Magic Quadrant for code modernization. And currently, we are gathering the reviews for this Magic Quadrant. So as the more reviews we get, the higher we'll be in this Magic Quadrant when it's published. So if you have ten minutes to spare, please feel free to scan this code or reach out to your account executive. We're gonna share the link with you as well. And let's, you know, let's show the market that Visual COBOL is number one product for code modernization. That would be that would be amazing. That's it from my side. On that note, I suggest we will continue with the q and a. We have six minutes, and I think a few questions for Brad and other speakers. Scot, do you want to start? Sure. Yes. I was just taking a quick look in the chat before it filled up with all the quiz the steps, but then I managed to get capture a couple there that I thought would be great questions to to pass to Brad here. So really interesting one actually there about getting buy in from the business. And the question was, did you have any challenges actually with getting buy in from the development teams or the business in this new architecture you're building? Yeah. Yeah. The the short answer to that question is yes. Did we have challenges? Absolutely. I think, you know, the the key buy in comes over time, unfortunately. It it takes a little bit of time to get buy in. And I think the most effective way, at least in my experience, what I've found is sort of the show and tell. Right? So taking a bit of time to showcase what's possible and align that with why. So what's possible and why do we care, I think, is is a real key key piece of that. So to get by in with the development teams, it required a lot of one on one help. So, you know, building that trust that, hey. We're not just changing your world to change it. We're trying to help you utilize more powerful tooling and use utilize more powerful capability. Thanks, Brad. Yeah. There there really is. There's there's the development culture side here that is just important in in in the kind of modernization journey you're talking about as as much as the technology is to bring people with you and win their hearts and minds. So thanks for sharing. You know, they they definitely took one or two personal conversations by the sounds of things to get everyone on board. Yep. Let's moving down the list of questions I see here. Actually, we didn't talk about API enabling the your application, what you've done in that regard. And I saw someone in the audience had talked about how wrapping just to read verbatim here, wrapping Cobo modules with a modern dot net minimal API approach has been eye opening and a tremendous advance. Thank you for whoever posted that. Can you relate to that, Brad? Is that your experience as. well? That's a 100% how we're doing it as well. Right? So, you know, taking that that COBOL functionality, that capability that already exists, and just, you know, wrapping it into a in a in a c sharp.net API. Right? It's you know, we're we're using minimal API in pockets. In in a lot of cases, we're using the traditional API approach as well. But that's just a really powerful way of unlocking the potential of, you know, a system that that that is sort of by nature for us, you have to go through the UI in order to interact with. We're able to wrap these c sharp APIs around Cobalt functionality and sort of unlock the potential of the system that already is there today. Right? So it's it's absolutely a fantastic approach. Alright. That that that term you used there, unlocking that value, that is something I've heard so frequently about, enabling access to proven business logic in these COBOL systems. If only I could get at that. And today, maybe it's trapped behind some of the maybe it's some old UI or something. But, absolutely, there are techniques to to achieve that as you're you're sharing with us. And then but perhaps the the final question I see here for you today, there's one about HPUX that I'll handle in a moment, but there's one here about AI. And, actually, we didn't get into too much detail together today about the use of AI at Sammons. Can you tell us there? Yes. I think it has proliferated every industry right now. Right? Everyone's excited about it. There's lots of opportunities and potential. And, you know, I think we still have to be pragmatic and maybe just a little bit skeptical. Right? You know, like I mentioned earlier, everybody's thinking about AI as kind of an easy button, and it can, you know, largely shift maybe rewrite things and shift the direction that we we take our software. But the reality is we we really have to be skeptical and pragmatic about what it really can do. And we should be you know, we're using it at Sammons, just to get to the point here, I guess, for documentation and understanding of what capabilities and architecture exist in our systems today. We're not necessarily using it to carte blanche rewrite things or even rearchitect them. We're using it as a an assistant to sort of power up our ability to modernize our application. Fantastic. Alright. Brad, thank you again. It's been fascinating. And I, you know, will happily drill into more details on your architecture for many hours on end. I'll cheer you off on that. So hopefully, we'll get to meet. We're on opposite sides of the Atlantic at the moment, but I'm sure we'll get to meet again soon. There was one other question I noticed about HP UX in the chat, and we did actually talk briefly about a path from HP UX to.net and Linux. We touched on that, but someone was also asking about whether it's still a a compilation target. If you are using HPE UX platforms today and you're running your COBOL systems on there and you wanna know more about what we can do to to help you on that journey, then please reach out to any person on the call, any rocketeer on the call here, and we'll get you to the right person to have more conversations about what's on offer there. But without further ado, again, Brad, thank you. Thanks to everyone who's been presenting today. Great session. Hope and there's been lots of great feedback in the call today. Thanks to our audience for really engaging with us. Loads of chat and loads of interest in the prizes as well, noticed, Sava. But let me let me hand it back to you, Sava, to wrap things up. Thank you, Scott. Thank you, Brett. And thanks everyone for joining us today and for all of your questions and engagement. We will share the recording tomorrow, and we will share the quiz winners early next week. And there will be a post event survey launched right at this moment, so please share your feedback to help us to make these sessions as valuable for you as possible. Thanks, everyone. Have a great week, and have a great end of q one. Who is celebrating? Madosco's celebrating. Take care. Bye bye. Thanks, Bye. Bye.