Transcript
Good morning, good afternoon or good evening, depending on where you are. And thank you for joining another tech strong learning experience. My name is Jared and we want to welcome you back to our tech Strong learning programs. As always this program this session is going to be recorded and will be available on demand. Afterwards, we will send you a link to your inbox for you to watch it for all the rest of the days to come. Please go ahead and send your questions to the panel on the right side of your screen. You can also join us in the chat. Tell us where you're tuning in from. Share your experiences, your comments, your understanding on the matter we want to hear. We want to engage with you throughout this program. Um, so please go ahead and do so. We've got quite a few people who have already, uh, started in the chat. We've also got the resource panel on the left side of your screen. Um, we've got a quick survey in there for you. And towards the end of the presentation, we're going to upload the slides that you can see on the screen right now for you to download and, um, rewatch, use those to rewatch the program with Finally, after the program ends, we will be giving away $250 Amazon gift cards. Uh, so be sure to send in your comments, your questions, fill out the survey, all of that good stuff to be eligible. Let's go ahead and kick off today's topic. We've got Accelerating application modernization with AWS. Uh, on the resource platform today, we're joined with Steven Hodges, director of solutions at Avery Source. Uh, Stevens is the director, um, at director of solutions at Avery Source and has been, uh, doing application development for the last 40 years and information technology management within 25 years of application modernization. So he's very well equipped to talk about this topic. We've got Sunil, um, solutions architect at AWS. Sunil is the senior solutions architect at AWS with a focus on x86 and mainframe migration, as well as AWS Solutions Architect. He currently focuses on bridging. Bridging legacy systems in the with the AWS cloud technologies and facilitating smooth transitions to cloud native solutions. Thank you, Steven and Sunil for joining us today. Um, as I mentioned, the today's topic is accelerating application modernization on AWS with the resource platform. Modernization has become a very popular subject within many IT focused industry. Uh, news articles and related media coverage. What we've largely heard from these outlets is that modernization is now a strategic priority for many IT leaders, and most are moving their applications to the cloud and examine AI technology to assist that, to assist in that modernization effort. The focus for many modernization discussion, um, has been a core business application, often running on the mainframe, mainframe and midrange systems. We're here today to discuss this topic in more detail and uncover why organizations are modernizing modernizing these mainframe and midrange applications, the choices, the choices that they have available, um, and how to create how to accelerate modernization process to the AWS cloud using the a resource platform. But before we get started here, I want to ask Steven, could you give us a little more of an overview and introduction to Avery Source itself? Sure, Jared, and thanks for the introduction. Good morning, afternoon or evening, depending on where you are. Thanks for joining and welcome. I'll hit the high points. Uh barosaurus has been in the industry for over three decades. We have parsed over 2 billion lines of code for over 250 major industry clients. We have various industry analyst accolades, including the new Intelex Digital Innovator Award, of which we're very proud, and AWS competencies for Migration and Modernization and their new discovery and planning. We have one goal at a source to accelerate client application analysis business rule extraction, optimization and modernization efforts. All right. Thank you Stephen I'm going to go ahead and launch a poll here. Um, and just so everyone knows, we're going to share the results of the polls towards the end of the program. We want to give all of you ample time to answer these. Uh, so with that, you should see that. And Sunil, I'm going to go ahead and start the presentation off with asking you a question. Why are customers modernizing mainframe and midrange workloads today? Yeah, absolutely. Um, so first of all, um, good morning, good afternoon or good evening, wherever you are. And thanks for joining this webinar. Yeah, sure. Like, see, um, we are witnessing a growing trend of customers migrating their mainframe and midrange workloads to AWS. And this momentum has exploded, uh, since the beginning of the pandemic. And it's not just new like, it's not happened only after the pandemic. And we have been seeing this trend of even before pandemic. But post pandemic, after seeing the bottlenecks of having these legacy applications running on these legacy environment like mainframe and midrange customers started thinking about like, okay, let's explore the avenues to migrate. And we are seeing that in a significant quantity. Okay. And when we are talking with them to understand why they want to modernize, and here are some of the reasons that they are coming up with. So first of all, cost reduction. So we all know, uh, mainframe and midrange systems are very expensive, expensive to maintain, and even it costs millions and millions of dollars for customers to maintain on a year by year basis. And customers are looking for avenues how they can reduce their mainframe cost or like midrange, uh, power systems by reducing their like, for example, mainframe. How how they can reduce their mainframe cost by reducing their mainframe consumption or like see the revenues, how they can reduce the software licensing fee or even also they they are exploring in revenues. Okay, let's explore the pay as you go model. And that can give me a good appetite to save the cost and all that. So these are some of the common reasons why we are seeing customers want to reduce the cost of running these mainframe operating systems. And based upon the number of migrations happened so far on AWS, we have seen customers saving anywhere between 60 to 90% of their mainframe and midrange cost after migrating or migrating it on to AWS. That's one reason. And another predominant reason like is agility. So we all know, like these legacy systems were being built over a decades of time, which are built with a heap of like, uh, monolith, large monoliths with huge volumes of code. Even if customers want to introduce a small change, they have to go through a long process identifying where they have to fix the change and then do the rest of the testing and all that. So they want. Customers want to reduce time to market and move faster to deliver their new business functions to their customers by leveraging probably like a CI, CD pipelines, or like implementing some microservice based architectures and also embrace the benefits of the cloud. Okay. And that's another reason. And we all know we have been hearing this. There is a significant skill shortage happening for these technologies like mainframe and midrange and a lot of, uh, skilled, uh, talented, uh, uh, talented staff are like talented resources are retiring because of this, uh, legacy. And customers do not want to take a risk of, like, uh, having a vacuum in that space. And customers want to attract the new talents and also embrace the cloud benefits and leverage these modern technologies to build the modern applications on AWS. And a couple more I want to tap it on like that digital strategy. Um, modernizing these mainframe and midrange workloads on AWS aligns with customers digital strategies to embrace their cloud benefits, accelerate innovations, and adopt best in class software for their customers. Last but not least, um, performing data analytics and building new business functions so data is hard to access for analytics. If you are in the legacy environment and customers often want to unlock its core business data for analysis and build new business functions in AWS environment, and also deliver better value to their customers and enhance their overall customer experience. So these are some of the primary reasons why we are seeing customers want to migrate and modernize their, uh, mainframe and midrange workloads on AWS. Awesome. Thanks, Sunil. So these are some good insights and good reasons why customers would modernize mainframe and midrange systems. Stephen, I've got a follow up question here. Um, what are the key considerations for those starting or revisiting their modernization strategy? What would you recommend. When planning an application modernization? There are several key considerations to ensure a smooth and effective transition. These would include business goals and strategy. Uh. Ensure that the modernization efforts align with the overall business goals and strategies. Identify what the organization aims to achieve with these, whether that be cost reduction, agility, performance such as Sunil mentioned. Uh, engage all stakeholder relevant stakeholders early in the process to secure buy in and address any concern or expectation. Uh, assessment of the current environment. You have to conduct a thorough inventory of the existing applications, infrastructure and dependencies and assess the current performance metrics, including reliability. Scalability. Response times. Identify any technical debt and existing code. Third party products that may complicate the modernization process. Choose the right modernization pattern. We'll talk more about this, but it is not a one size fits all. It may be that you move the entire portfolio in a particular direction, or you may have a different direction per application depending on how it fits the business. Technology and tools. Select the appropriate tools for code analysis, migration, and testing. Evaluate cloud options for public, private, or hybrid and ensure that the new system can integrate with other enterprise systems and third party products. Skills and resources is a big thing to consider, and you need to assess the skill levels of current IT staff and identify any gaps. Plan for training programs to upskill existing staff or hire new talent with necessary expertise, and consider engaging a third party vendor or consultants with experience in modernization, risk and change management. Project management. Identify potential risks. Develop strategies to mitigate these, such as phased rollout, comprehensive testing, robust backup plans and develop detailed project plans with clear milestones, timelines, responsibilities including RACI charts, especially when using system integrators, data management and governance. Plan for the secure and accurate migration of data to new environments to maintain data integrity. Implement governance practices to ensure the data quality and security testing and validation. Conduct thorough testing at every stage and benchmark performance metrics before and after the modernization to ensure improvements. Monitoring and maintenance continuously monitor the performance and stability of the modernized application. Establish a process for continuous improvement and plan for ongoing support and maintenance to address any issues that arise post modernization for financial considerations. Conduct a cost benefit analysis to understand the financial implications of modernization, and establish a realistic budget that accounts for all aspects of the modernization process, including potential unexpected costs, which is a great reason for picking up an experienced service partner. So by carefully considering these factors, organizations can increase the likelihood of a successful application modernization, resulting in a more agile, efficient, and future proof IT environment. That's that's great advice. There's clearly, clearly some considerations for those that wish to modernize and mainframe midrange applications. So know from your experience at AWS. And given the considerations that Stephen just shared, how how would customers typically modernize these systems and what options do they have? Yeah, sure. See, uh, moving these mainframe and midrange applications onto AWS involves, uh, several modernization patterns. Okay. Again, as Stephen said, there is no one size that fits all. So, uh, each pattern has its own pros and cons. So we typically hear in the industry like, uh, some people say seven hours, some people say six hours. So here are the list of patterns that we are most commonly seeing and what our customers are doing on AWS. So treating these legacy mainframe and midrange workloads are migrating them onto AWS are modernizing. So one of the pattern is like the Replatform. So this is a purely like a lift and shift. Some people call it a lift and shift or like it's a replatform. So this pattern, this pattern is like, uh, it's a straight forward pattern. Like in this pattern, customers move their entire application code base onto AWS environment with minimal or no code changes. Compile the code base and generate the x86 version of the binaries, or like a executables, and deploy them into the production. So this is a straightforward approach, like take the code and uh, from the main mainframe and midrange and then the mainframe, and then compile and generate the binaries and run it on AWS. And this pattern is, uh, often chosen by customers where they see they want to exit the mainframe or like, they, they are good with their, uh, they have enough, uh, skilled people. Okay? They can still run these legacy systems on AWS. And in this space, uh, AWS offers, uh, we have a service called AWS Mainframe Modernization Service, which provides access to various our partner tools. So, um, since Amazon is a customer obsessed company, we always work backward from our customer's legacy environment and recommend best tool that fits their business requirements. That is one pattern. And coming to the automated code refactoring in this approach, like customer, take the entire legacy code base from their legacy environment, both mainframe and midrange, and seamlessly transform automatically transform that code to modern technologies like Java, DotNet, Python, and so on. And this preserves the functionality, the original functionality and which often referred as a functional equivalence. So in this case, again, like AWS mainframe modernization service offers a group of tools from our blue services for customers to automatically refactor these legacy applications. And another key pattern that we are seeing is, uh, like re-architect and rewrite. So again, like, uh uh, I see there are different ways. Again, like, uh, this pattern is typically chosen by, uh, chosen by the customers, and the existing architecture is, uh, no longer suitable to meet the customer. Current or future requirements for future business requirements. So the trend we have seen is like in the rewrite pattern, like there are three different trends we are seeing. So in the rewrite pattern, like uh customer uh go back to their legacy environment understanding, understand the entire legacy code, create the business requirements from that code or extract the business rules, create the requirements, and then pass it on to the modern developers who can develop these requirements in modern technologies on AWS. That's one pattern. The other pattern is uh re-architect and rewrite. So customer goes maybe like let's say if they have ten business functions on their legacy environment, they go and rewrite. They go and extract the business rules for five of them, and they completely, uh, design the new requirements for the other five business functions. So it's a hybrid approach. And Re-architect is completely again, like customer has, uh, created these all the requirements without going to the legacy and then build those requirements in the modern technologies in either of these case. Okay. In either of these case, in all these cases, like even the re-architect space customer still go back to the legacy environment while building the new functions on AWS to make sure like the results are matching to whatever the existing functions that they are building. So in all these patterns, like, we always encourage our customers to accelerate their manual rewrite or like Re-architect approach by recommending some of our partner tools, including every source, because every source, uh, is one of our partner who has, uh, a migration modernization competency. And also we have some of our partners who are, like, evolving their, uh, technologies with AI powered, uh, offerings. Okay. That's another area. And replace is pretty much like customer has, uh, I mean, like, their applications are running currently on the legacy environment, which has a product, a Cots product, and they have a similar product in the AWS environment. And they can go for a seamless migration of the data, and they can implement that product and enhance it based on the new requirements. And that's like a pretty much a commercial off the shelf kind of deployment or like a software as a solution as well. And another two patterns where we are seeing is replicate or like retain this. This pretty much comes in the hybrid integration. So let's say like a customer has a different set of business functions running on these legacy environments. And they want to partially they want to migrate only partial applications onto AWS or modernize it onto AWS. So they would like to have a handshake between both the environments, either from the data perspective or from the integration perspective with an API and all that. So in that, in that scenario, in that scenario, like these kind of patterns are being consumed by our customers. And last again, like while doing this, uh, approach. Uh, there are a couple of other patterns we have seen. Like wherever they feel, customer feel, there is no value coming out of that application running on these legacy systems. They will just go ahead and retire or like if customer has a very short duration to migrate. So what we typically recommend and what customers are doing is we ask them to rehost to one of our managed service provider, who can just lift and shift your mainframe workloads onto their mainframe, and then from there, they start the migration journey or modernization journey onto AWS. So so each pattern can be applied based on a specific needs, goals, and also constraints of organizations. And the choice depends on factors such as applications, criticality, complexity, cost and also complexity, cost and also desired speed of modernization. So some portfolios may use multiple patterns as well, or some customers may even use multiple patterns among these what we discussed. Yeah that's great Sunil, I'm going to go ahead and get another poll, uh, started here. And with that news, it appears that there are many patterns available for those that wish to modernize. Stephen, let's dig a little bit deeper into the topic of the patterns, specifically to manual rewrite. What are the obstacles with manual rewrite? Re-architect approach modernization and how would you overcome them? Well, manually rewriting mainframe midrange applications for cloud deployment presents several significant challenges. These include complexity and scale. These applications are typically large, complex systems that have been maintained over decades. Rewriting these applications manually requires deep understanding of the original code, which is often poorly documented. Skills gaps. The mainframe midrange applications are often written in COBOL assembler PL one RPG. And many of these. In many cases, the subject matter experts are gone. Finding developers with expertise in these languages as well as modern cloud technologies can be difficult. Business logic and dependencies. These applications contain critical. Business rules that must be validated and preserved during the modernization. So. Extracting, understanding, and correctly implementing these rules is a. In a new environment is crucial. Data migration. Legacy data often uses specialized formats and structures, and migrating this data to the cloud requires careful planning and to ensure the data integrity, consistency, and security. The volume of data can be substantial and adding to the need for acceleration and close process management. Aws does provide data migration acceleration products and Sunil will tell us about those a little later on. Performance and scalability. Mainframes are known for performance and reliability, so ensuring the rewritten cloud application meets or exceeds performance and scalability requirements can be a challenge and requires target architecture, understanding and experience. Security and compliance. Ensuring that the rewritten application meets requirements requires vigorous planning and testing. Testing and validation. So comprehensive testing is required to ensure that the rewritten application functions correctly to avoid disruptions. Cultural and organizational resistance. As mentioned earlier, stakeholder engagement, change management, and training are crucial components to any modernization project. Cost and time rewriting applications is a time consuming, risky, and expensive process. Accelerating the timeline and automating processes, where appropriate, reduces risk, time, and cost. Tooling and automation. Rewriting, by its nature, is a people oriented process, but using automated analysis tools and code generation products like Amerisource helps improve quality and shortens task durations. System constraints. The systems may include proprietary technologies that do not have direct equivalents in a cloud environment. Identifying these in the assessment or inventory stage helps accelerate replacement planning and interoperability issues, ensuring that the new cloud based application can seamlessly integrate with other existing systems and third party services is another challenge. This often requires creating new APIs or modifying existing ones, which can be complex and risky. So addressing these challenges requires a well-planned approach, including thorough assessment and planning, leveraging modern tools and frameworks like Amerisource and often incremental modernization strategies to mitigate risk and manage the transition effectively. Amerisource accelerates each stage of the modernization, analysis, and preparation and can reduce risk and cost while standardizing the code being implemented. So part of our topic today is exploring how to accelerate modernization on AWS using various source technology. Could you tell us a little bit more about Avera's source solutions, and how to address the challenges that we've discussed so far? Stephen. Sure. A big differentiator for us is that we provide structured, maintainable, object oriented Java or C sharp with no proprietary runtime platform or vendor lock in. We not only generate the code, but also test data frameworks, test data APIs, and generate test screens for Crud or data access interaction with data microservices. We provide test registry for deploying and testing these microservices. We render the green screens in HTML and provide angular projects to give the UX developers a leg up when working with clients. For interface redesign, we generate YAML configuration files for things like building sonar cube servers for testing code quality using test tools like cucumber, and deploying to container management products like Docker. The source platform provides distinctive products to accelerate each stage of the modernization journey. Scan is our free Pre-project Self-Assessment product. Inventory builds the analysis repository and is the first licensed product. Discover delves into the application architecture, analyze, enables technical debt reduction and business rule extraction and transform. Accelerates application Re-architecture. So as you move from left to right on this slide, each product includes the former, simplifying the buying process. So there's only one line item on the order form. All right. So the source platform seems like it's a very good, flexible approach to mainframe and midrange modernization, especially for those that are wishing to rewrite any of their applications. What's the benefit of utilizing the Vera source solution specifically with AWS? Aver source has built its knowledge base processing rules and custom algorithms over the last 30 years, having parsed over 2 billion lines of code for over 250 clients in most every industry vertical. This has enabled us to parse over 70 tech stacks on over 20 platforms, providing accelerated application understanding with reports and diagrams that help accelerate each stage of the modernization journey, expediting each of the use cases mentioned earlier by Sunil. We ingest 3 million lines of code an hour and greatly improve accelerated onboarding and application understanding. We provide dynamic documentation and minimize the learning process for architects, business analysts and developers by auto generating these testing frameworks to test data APIs and test screens, we enable immediate verification of the Re-architecture design. We enable clients to deploy to container management environments on AWS, like Red hat OpenShift, or deploy to AWS EKS Managed Container Services or AWS EKS Kubernetes services. You can take advantage of AWS products like Fargate and CloudWatch, and implement elastic load balancing and Load and auto scaling. All right, so for those that are listening to the webinar and planning to, um, planning their mainframe modernization strategy to AWS, it seems that the um, Eversource and AWS are preferred platform for application modernization. Steven, is there a common application profile that you would target for this type of modernization effort. And maybe tell us a little bit about what some of those application characteristics are. So Eversource supports the majority of mainframe and midrange platforms and languages and databases, enabling partners and customers to adopt many modernization patterns and accelerate their application analysis. The business rule extraction and code transformation projects on AWS. As I mentioned, we cover over 70 tech stacks on these platforms. Target languages include Java, Spring Boot, and. Net core, C, sharp and Angular for the user interfaces. So we accelerate several modernization patterns and improve and expedite application understanding, roadmap planning and re-architecture and development process execution. Reducing risk, time and cost all within the platform. Thanks, Steven. So the average source platform provides a lot of optionality for customers that wish to modernize mainframe application. And given that what you've described, are there any typical or common cases for where Eversource and AWS can be utilized? So as I mentioned, we cover several modernization patterns, including the Accelerated Application Assessments for modernization, roadmaps for replacement with analysis for data migration and business rule extraction, for functional gap analysis, for data replication analysis, for edge data, for hybrid applications, for retiring those applications, data access pattern analysis for when decommissioned applications need query and reporting systems for viewing historical data reengineering, or what we call accelerated rewrites. We lead the industry in business rule extraction for application documentation or deployment to rules engines, and we can even help if you replatform your legacy COBOL, for instance, by accelerating your ongoing maintenance and enabling down the road. Re-architecture. All right. So seems like that customers can address many of their cases with the Azure Resource Platform on AWS. So, Sunil, I want to continue the same theme here. If organizations were modernizing their mainframe or mid-range applications on AWS using the Azure Resource Platform, what AWS capabilities can we can we leverage here? Yeah, absolutely. Um, see, once once customer is thinking of like migrating on to AWS or even customer is on AWS. Customer has access to all 200 plus, uh, AWS services from the diverse area of our platform and so that they can, uh, embrace all the benefits of what our services is being provided and build the modern architecture. So let's look at an example of like for example, data analytics service. So once the customer data is on AWS, customer can leverage Amazon Redshift or like Amazon S3, Amazon RDS, Amazon Glue, AWS glue, Kinesis QuickSight, and so on. So they can leverage, uh, all these services to build a data lakes or enterprise data platform or VA solutions. So these services enable customers to modernize their legacy data infrastructure, to unlock advanced analytics and drive, uh, intelligent decision making for their customers. And another space, I mean, like, multiple spaces can be tapped into once they're on AWS. So maybe like, uh, machine learning and artificial intelligence services. So, uh, customer can enhance their business capability and functionality by leveraging our AIML services such as Amazon SageMaker, Amazon Comprehend, and Amazon Rekognition. And even like they can leverage our Amazon Bedrock services, which is our generate powered, uh, services, uh, to empower organizations to infuse their application with advanced ML models or pre-trained a capabilities and custom model developments. So this, uh, going this way, it opens the door to intelligent decision making that from predictive analytics and also automation and implement automation and drive innovation and competitive advantage and take a competitive advantage of the industry and serverless computing. We have been hearing this for several years now, and we have services such as AWS, Lambda, SQS, SNS, and many more so customers can leverage these services. Uh, these services, uh, allows organizations to break down their monolithic applications into smaller, more manageable functions that can be scaled and deployed independently without the need to manage underlying infrastructure or provisioning. So this approach, uh, fosters agility, uh, cost efficiency and the adoption of modern architectural patterns as well, and customer can even leverage our managed container services like Stephen was mentioning, like, uh, Amazon Elastic Container Service, like ECS, and also Amazon Elastic Kubernetes Service EKS, as well as like a Fargate and so on. And these services simplifies simplify the deployment and scaling the containerized applications. So by container, by containerizing their applications, their modern applications, organizations can improve portability and they can increase the scalability, scalability and the adoption of microservice based architectures and also further modernization efforts. Um, and coming to like another couple of areas like event driven and serverless integration, uh, services like we have uh services such as EventBridge, which enable a seamless communication and data flow between different components of modernized applications. And these services, uh, facilitate, uh, the decoupling of legacy In monoliths under the adoption of event driven, microservices based architecture, promoting more scalability, elasticity and flexibility. Last but not least, like we have a bunch of like monitoring and observability and DevOps based services like CloudWatch, X-ray, AWS Codecommit, Codebuild, Code deploy, and all those things which enhance visibility, uh, and also enable troubleshooting and enables the continuous deployment capabilities. So these services are crucial for effectively managing and optimizing their modernized applications, ensuring they deliver maximum value to the business. So in summary, uh, right, like AWS offers a wide range of advanced services and technologies that can empower organizations to modernize their, uh, uh, legacy monolith applications, modernizing onto AWS by unlocking new level of agility, scalability, and innovation. Um, so Organizations can further, even further prove their IT landscape and stay ahead of the curve in the ever evolving digital landscape of the technology. All right, so before I ask you a question, Steven, I'm going to go ahead and launch our final poll here. Just leave that open for you guys. And like I said, just a reminder. We'll go over those um, as soon as we right before we close out, do Q&A. Uh, so, Sunil, it sounds like those were some of the strong drivers for modernization to AWS. I assume these modernization projects do take some time to deliver. Steven, can you tell us what would you advise regarding the expected timeline for an accelerated rewrite with our resource on AWS, and how long does it actually take? Uh, we mentioned some of the benefits, but as to timeline, I'll give the standard consulting answer. It depends. Uh, there are several factors to consider, including the size and complexity. Uh, applications can range from a few hundred thousand to 100 million lines of code and can involve multiple languages, transaction managers, databases, file systems, third party products, and various screen interface types. The duration for re-engineering projects also depends on the level of re-architecture being done, how much of the old code functionality is still relevant, how much technical debt redundant and dead code is there? Are there business rules still valid? Will the application flow change for the new platform and environments? How many new functions are being added? Are new architectures and technologies and operational management processes being implemented, such as Sunil mentioned? Um, examples. I'm sorry. Experience of the team obviously using partners seasoned in the concept, issues, processes and tools of modernization are very important. You want to avoid making mistakes or having problems that experience can foresee and solve many of the enhancements that can be made to mainframe. Midrange applications can streamline processing and management, and some can greatly improve user interaction, cost of operation, speed of execution, and ease of operational management. A virus accelerates each stage of the modernization journey. For instance, we ingest the code and provide assessment and planning information in hours to days. What could take weeks to months with manual analysis, so that alone can improve the discovery and analysis stages by greater than 50% conservatively. Having all the information at their fingertips. Modernization and data. Architects can identify, plan, change, enhance and test application and data frameworks using our registry to run microservices generated test data APIs and test screens to immediately validate their reengineering designs. Automatically generating these items accelerates the re-architecture design validation by more than 50%, again conservatively. Then, having generated most of the code test screens rendering HTML renderings of the green screens and angular projects, we give the UX and development teams a leg up. B because the code is generated, we standardize the applications to improve ongoing maintenance, and teams can expedite the development process of polishing the code and connecting the dots with products like AWS Codewhisperer those points being the reasons we call it an accelerated rewrite. We don't prescribe what Re-architecture should be done, but help expedite the process by laying the tracks and greasing the rails for the modernization train, so to speak. That doesn't directly answer your question, but imagine a manual rewrite taking 7 to 10 years. Our acceleration can reduce time, cost, and risk for each stage of the modernization by a pretty good margin. We basically resolve those issues that have caused some companies to avoid rewrites in the past, and we've seen a lot more activity lately as the pendulum is swinging back toward what companies want in the first place, which is rewriting their applications to use modern technologies. Keeping the good in their applications, such as business rules, removing the technical debt, and opening new doors for support, resource markets, for instance. So that's pretty valuable information for anyone who's planning an application to rewrite in AWS. In my opinion, um, a resource platform delivers a faster path to modernization and accelerated rewrite. Before we wrap up today's program, I would like to pose a few additional questions from our audience to see if we to see, you know, just involve you guys. What questions do you have for us? We'd like to, um, continue on with this, with this chat if you guys have anything. So one of the questions is where can I download the slides from today's webinars? I'm going to go ahead and I'll share those with you guys here in just a second. Let's see. Let's share those. You should have those in in your um handout section on the resource. Actually I believe that's where it is. It's where we've also got the polls. Another question is, uh, what are the primary benefits of using the resource platform for application modernization on AWS? Uh, I think we addressed that a little bit, but I would say acceleration of the process and having a quick and deep understanding, especially when you have lost subject matter experts. All right, let's see the next one we've got. Um, what I centric use cases involving the source platform and AWS capabilities. Might there be. I'm sorry. Could you repeat that? Yeah. What AI centric use cases involving the average source platform and AWS capabilities might there be? Okay. Well, the, uh, as I mentioned earlier, with our knowledge base built over 30 years and our rules and custom algorithms, uh, knowing the business rules and the data requirements for fields, uh, helps map and control, uh, a better generation of code. So when we generate the APIs and the test screens and the the test data. All those things are taken into consideration so that, you know, in the test screens for that immediate verification of the re-architecture, it makes sure that you enter those fields, for instance, which have been referenced in a business rule. And then so we've got a few more. What? And you guys, please keep them coming. This is this is what this is all about. Um, what are some of the common pitfalls to avoid in legacy system modernization? Uh, so, Neil, you want to talk about general, uh, for those pitfalls? Yeah, yeah, maybe I can take it. Um, I mean, like, see, uh, first of all, uh, modernizing these legacy systems requires a proper planning. Okay. Um, unlike the assessment, uh, again, like, assessment includes both portfolio assessment and also like, uh. Um. Uh portfolio assessment and inventory assessment. So that's pretty much, uh, essential. And also like uh at the earlier stage, make sure like you have a proper buy in from your leadership and organization and, uh, point of context and a few things which you should be very careful in doing is like the planning, planning and like a wave wave planning and also like, uh, identifying in case if you have, uh, what is the volume of the missing source code that you have? So some of the consideration definitely needs to be taken care. Um, and uh, and couple of other aspects I would tap on is like, uh, uh, how are you going to, again like this, this should this shouldn't go in the overnight, right? I mean, all these things cannot go in the overnight. So there should be a proper strategy of like how you are going to, uh, augment the data between both the environments is AWS and the legacy environments. So mainly like a proper planning, proper assessment and also like identifying in case of missing source at the early stage and see what kind of, uh, approach you would like to take. Uh, and uh, coexistence of both the environments, uh, until, until the sun sets of legacy environment happens and all those things, uh, has to be considered as part of the modernization journey. All right. So these these keep coming in. This is great. Um, how can the platform help me through the due diligence and planning from an M&A and integration standpoint? Uh. Well, I mentioned the, uh, accelerated assessment capabilities that we have. I would say initially start with our free scan product, which you can download from our website or the AWS marketplace. I was going to comment on that at the end as well, and that's typically what we use as a Pre-project pre-sales tool to help understand what the clients have. So it's a free way for you to understand what's in the portfolio, how many components are there, whether there are missing components or unreferenced components, and how many lines of code you have. Do you guys have a trial available? If someone wants to get started with a source platform on AWS, how would they go about doing that? I mentioned that you can use scan for free. We also have demo sites that you know we can give access to, and we're more than willing to do workshops to even with your code to help you see and understand how quickly and the depth of understanding that our product provides. Is there a link that we can pop in the chat for that, or is that all just through the QR code? Um, just. Contact us and you know hello at Verizon. Com and we will start that conversation and make sure that we know what you need. Okay. Excellent. And then um, let's see what are what if what if I want to keep some of, of my code on the mainframe and some on AWS. Is there a hybrid model model possible? And how does a source platform support that? Uh, absolutely. As Sunil mentioned previously, the several times we've talked with clients who, uh, primarily their business runs on the mainframe, but they have applications that they want to use new technologies and, uh, features that AWS provides that some that were mentioned before. So in doing that, creating a hybrid application, we can help with, you know, screen understanding and the migration of the screens with APIs. We work with companies that generate APIs to connect the dots with mainframe operations, and as well as we can help with daily maintenance of the code, especially if you're optimizing reducing technical debt. So, you know, depending on what stage you are in the process, you know, we can help accelerate the understand where the connections are, where the cross reference data access patterns are all all of those. Yeah. So what. And and this may be unless more questions come in I think this. Oh there we go. They're coming in. What are some of the best practices to determine whether you re-engineer or lift shirt legacy apps? Yeah, maybe I can take this. See like Again, it all depends upon the current situation of your organization. So let's say like if you have a significant shortage of skills of, uh, maintaining these legacy applications, then definitely you have to go for a re-architect or rewrite. And if you feel like, okay, I have, uh, enough staff to manage these legacy applications, then if you want to fit this, exit this platform, then ideally the replatform or lift and shift is a ideal path. And let's say like we are even seeing customers doing like this, like, uh, customers, uh, take this approach of like, completely, uh, lifting and shifting or like replatforming it onto AWS as a first step. And once they are on AWS, then they keep starting modernizing. So at least like they are taking one, one step ahead. I mean, they are taking step by step approach, uh, first, like, uh, exiting the legacy platform, like exiting the mainframe and midrange platform. So be on cloud. Uh, um, I mean, like. Leverage all the cloud benefits and eventually plan to modernize or migrate. Modernize your workloads onto cloud native architectures. So it all depends upon the scenario and. Uh, organization's situation and condition. And, Stephen, earlier you were talking about COBOL. Uh, what versions of COBOL do you support and what limitations are there, if any? Uh, so. Cobol pretty much runs everywhere, and we support all versions of COBOL, like 65, 78. Uh, 2000 and beyond. Uh, we support IBM, Unisys, HPE, tandem, Nonstop, OpenVMS, you know. Cobol, pretty much anywhere, um, including the I series, IBM. So the the through business rules and code. Transformation COBOL is more or less COBOL. The limitations or restrictions could be, depending on the platform that it's running on. If there's special, uh, calls or references to system utilities or different database or data file systems that we haven't yet, uh, encountered, uh, we can still add patterns for those depending on, you know, the level of detail and what you need. Uh, we would just have to work with you and see, you know, what, your code and what those interfaces look like. So we've got a follow up to that to someone says, um, they're an IBM, I shop. Is it possible for both COBOL and RPG based applications? Absolutely. Uh, our, uh, transform is, uh, certified to, uh, convert or generate Java or C sharp from COBOL and RPG, any version of RPG and, you know, any version of COBOL. All right. Um, we have a lot of third mainframe softwares. How does the platform support a better understanding of what's being used today? Uh, so. Our inventory product, when you parse your source code into understand what you have, uh, one of the things before you do a modernization project, you always want to make sure that your analysis repository is as complete as possible. So those missing items or unreferenced items are very important to resolve as much as possible. And then we also include identifying those platform utilities or third party products. And that's that can be crucial depending on what they are, what the functionality is because if you go into Java, for instance, you have to make sure there's a Java library or some third party product. You know, it's possible that AWS provides some facility for those. So you may have to do some re-architecture to fit the new platform. So before we jump into too many more questions, um, I just want to go over these poll questions and responses and get your guys's feedback on these. So the first poll question was where are you on your mainframe or mid range modernization journey? I'm going to maximize this so everyone can see this. Here are the results we had. Um, quite a few people saying that they were considering my considering your guys's options. They were implementing the strategy more or less with where you guys are talking. No one had, uh, quite a few people haven't even started. Um, and some people have already modernized your applications or my applications. What do you guys share your thoughts on that? What's what's going on here? Sunil, you want to comment on that? I mean, um, yeah, the good news is like, uh, uh, like some customers are considering and also like some are implementing for the people who haven't started, like, I mean, uh, we are happy to help you. Um, we have, uh, various services that we would, uh, that we offer to our customers. And we have, uh, uh, lot of experience, uh, specialists in this specialist in this specialized area. So, uh, feel free to reach anytime, uh, to us. Look, uh, mainframe at Amazon.com. So we'll be able to help you. Yeah. And I would also say that, you know, anyone who hasn't already modernized your applications. Uh, you know, we can help in most any stage that you're in, uh, to do that rationalization and selection. Uh, and I would highly recommend taking a look at scan if your architecture fits those patterns that we mentioned. Yeah. Just want to add one more point here. Like, um, let's see. Uh, not every customer is well versed with this migration approach and patterns. So that's where like we have our competency program. So we have, uh, vetted several partners and identified a list of partners who are above 15 or between 15 to 20. So they are they have proven track records in migrating these kind of workloads. So we are happy to work with you. And we have our own professional services team who can do these migrations. So uh, anytime, please feel free to reach at Mainframe at Amazon.com. All right. So the second poll was which legacy language are you or are your applications using today? Uh, let's share the results and let you guys comment on that. I think this is pretty typical of what we've seen there. You know, some people say COBOL runs the world. There are 2 billion, 3 billion lines of COBOL out there. And there's new stuff being written every day. There are pockets of, you know, PL one assembler natural that companies have adopted. Um, you know, we can help with all of those. Yeah. Um, maybe my take on that is like, yes, definitely. The AWS mainframe Modernization service can help you with pretty much like COBOL, PL one, RPG, JCL, and all these programing languages. Uh, which is a fastest route? I mean, like, uh, in case if you are considering the replatform or like, automated code refactoring. Um, yeah. All right. So the last one. Let's maximize that is do you already have applications running on the AWS cloud? Not sure that that's a big surprise. Stephen. Sunil, are you guys surprised on that? You guys, what do you think? I would applaud. What do you guys. Say about the people who are unsure or the people who do not have it on there yet? Yeah. I mean like, yeah, definitely. It's a time to, uh, look, look and explore the opportunities of migrating to the cloud. So that gives all the benefits of agility, scalability, elasticity, security, performance and whatnot. So. Way ahead. All right. Um, so let's go back to the questions. We we did have one more that came in. Uh, what services does Avera Source and AWS offer to help with modernization, planning and deployment to AWS? So, Neil, you want to start. Yeah. See, um, I mean, like, uh. Yeah. Yeah. See, um, uh, so basically, like, uh, we have our, uh, our own framework. Okay. It's called, uh, Migration Acceleration program, and this program has been built, uh, it's a comprehensive and proven cloud migration program developed, uh, from AWS experience in migrating thousands of enterprise customers to the cloud. So this program also has been, uh, tailored to fit exactly for the mainframe workloads as well. So it offers various kind of funding mechanisms, uh, funding options to help customers to offset their, uh, additional cost incurred during the migration process known as the double bubble cost. So with the assistance of AWS experts and mainframe migration competency partners who have substantial experience in migrating such workloads, customers can confidently migrate their mainframe workloads to AWS. And in addition to that, like I was talking about, uh, some of the services, right? Like, uh, our AWS mainframe modernization service is one way for you to explore, and we have our DMs service for you to migrate the data from DB2 technologies. And we have a file transfer, uh, solution as well. Automated testing and all that. So all these features can be leveraged, uh, while transferring these workloads to AWS. All right, Steve and Sunil, we are pretty darn close to the end here. Um, before we wrap up, I want to know if you guys have any closing thoughts for our audience, especially if anyone's planning to manually rewrite or consider application modernization on the AWS using the, um. Source platform. So you want to go ahead and start. Sorry. Yeah, yeah. No problem. I mean like, yeah. Um, so first, first of all, thanks for. Staying tuned, uh, for the one hour and yeah, as I mentioned, like we have the multiple programs to support these kind of migrations, uh, like, including the one which I talked about, migration acceleration program and, uh, the customers, like the other partners who are not, uh, having the competency program at we have other programs to support and help in these kind of migrations. Stephen, any closing thoughts? Uh, yeah. I'd like to thank all for your attendance and attention today. Our message is simple. We can accelerate help with and across each stage of your modernization journey. And we support multiple modernization patterns. Uh, we provide a rapid assessment program for partners who can do multiple assessments for for one price. You can even start for free. As we mentioned with the resource scan, download it from the website or the AWS marketplace and run it yourself, or with help from our Customer Success team, just reach out to us at hello@verizon.com and we're happy to discuss, answer all your questions and provide a demonstration. When you download scan from our website, you can check the box that says you want a demo and we would love to talk to you. All right. Excellent. So, um, I want to thank everyone for joining today. But before we do close out, I do want to remind everyone there is a survey in the resource section. There's also the handouts in there. If you can fill out the survey, it's going to take you less than 30s unless you want to write us a story in the comments area of that, just let us know how we performed, what we did, what we can do in the future. Your input is invaluable to us. It's very appreciated. It helps us guide and direct our flow or everything that we do here at Textron Learning. And one more reminder the recording for this will be sent to you shortly after. After we conclude here, you will get a link in your inbox. And once more, Steve and Sunil, thank you for the discussion and the insights on accelerating application modernization with AWS and a resource, a resource platform. For those of you that wish to learn more about the resource platform on AWS, you'll find a copy of our slide where in the handouts again, just to remind you once more and and check out the Resource Comm website and visit the YouTube channel to take a closer look at the latest in the application modernization, technology and available resources. Once again, thank you for joining the Textron Learning Experience. Have a great day and you may now disconnect. Thank you all. Thank you Jared.
