devopsy.kinsta.cloud

Tag: app modernization

  • How to Navigate App Modernization Strategies for the Cloud

    How to Navigate App Modernization Strategies for the Cloud

    In today’s fast-paced digital landscape, organizations continuously seek ways to innovate and enhance customer experiences while optimizing efficiency. One of the most transformative strategies is modernizing applications for the cloud. App modernization isn’t just a technology upgrade. It’s a holistic business transformation. The cloud’s elasticity and scalability present opportunities to create deeper customer engagement, foster seamless partner integration and unlock valuable data insights. However, this requires a thoughtful approach that aligns with business goals and technological aspirations.

    Let’s look at some best practices for modernizing apps for the cloud and navigating potential challenges.

    The App Modernization Process

    It’s important to determine whether the cost of migration will lead to better efficiency and customer engagement that will yield an increase in return on investment (ROI). This approach allows businesses to address current issues and future-proof their data stacks.

    After assessing the cost and ROI considerations, organizations need to follow a systematic process to successfully modernize an app for the cloud. The first step is to evaluate the existing app’s strengths, weaknesses and areas for improvement. It’s crucial to assess an app’s compatibility with cloud platforms and set clear modernization goals.

    Following the assessment, design a cloud-native architecture that aligns with the cloud’s scalability, elasticity and distributed nature. This may involve rearchitecting the app to include such cloud-native components as microservices, containers, or serverless computing. Once the architecture is in place, migrate the app’s data from on-premises or legacy databases to cloud-based storage solutions to ensure data availability, scalability and ease of management in the cloud environment.

    The next step involves rewriting or modifying the app’s codebase to take advantage of cloud services and APIs. Specific modules or functionalities may need to be re-engineered to enhance performance, scalability and integration capabilities. Perform comprehensive automated load and security testing to verify reliability and performance in the cloud.

    Once the modernized app has been tested, deploy it on the selected cloud platform. Implement monitoring and logging mechanisms to gain insights into the app’s behavior, performance and user experience so it operates effectively in the cloud environment.

    Navigating App Modernization Challenges

    While the benefits of app modernization are significant, challenges can arise during the process.

    One of these hurdles involves dealing with legacy constraints. Legacy applications often have complex architectures that complicate modernization. Careful planning is required to update outdated technology stacks and move from a tightly coupled system to a loosely coupled one.

    Another obstacle pertains to data migration complexities. Transferring large amounts of data from on-premises systems to the cloud demands meticulous planning and execution to maintain data integrity, security and minimal downtime.

    Integration presents another potential difficulty. Modernized apps often need to integrate with other systems, both on-premises and in the cloud. Many cloud vendors offer tools and programs to aid in migrating data. These, coupled with credits to be used as apps are migrated, can significantly reduce costs.

    Security and compliance are critical considerations when moving to the cloud. Cloud environments require robust security measures to protect sensitive data, and organizations must comply with relevant regulations and industry standards.

    Effective change management strategies are another aspect to consider to ensure a smooth transition for users and stakeholders. App modernization is a business process modernization representing a significant change in business operations.

    In-House Vs. Outsourced App Modernization

    Choosing between in-house and outsourced app modernization depends on several factors.

    First, if an organization has skilled developers with cloud expertise, handling app modernization in-house is a viable option. On the other hand, if a team lacks the necessary skills, it may be more practical to outsource the task to a cloud service provider or a specialized development partner. It should be noted that if the development work is outsourced, it’s important to keep the app business owners involved to ensure that the modernized solutions yield the expected benefits.

    Another consideration is the availability of resources, such as time, budget and staffing. App modernization projects require dedicated efforts, and outsourcing becomes appealing if internal resources are limited. By entrusting the project to external professionals, organizations can ensure it receives the attention and resources needed without burdening the internal team.

    Evaluating whether app modernization aligns with an organization’s core competencies is also essential. If the application is not directly related to the core business, outsourcing can free up internal resources and redirect them toward more strategic initiatives. This allows an organization to concentrate on areas in which it has a competitive advantage and expertise while still benefiting from the app modernization expertise of external partners.

    Pioneering the Future

    Modernizing an app for the cloud is a transformative journey that holds the potential to enhance customer experiences, optimize processes and unlock valuable insights. Navigating challenges through meticulous planning, robust testing and adherence to standards are crucial, whether opting for in-house expertise or external collaboration. By embracing cloud-native principles and using advanced technologies, organizations can position themselves at the forefront of innovation, ensuring lasting success in the dynamic landscape of the digital era.

  • EvolveWare Further Automates App Modernization Tasks

    EvolveWare Further Automates App Modernization Tasks

    EvolveWare today announced it has added an Agile Business Rules Extraction capability to its Intellisys application modernization platform.

    EvolveWare CEO Miten Marfatia said the Agile Business Rules Extraction capability eliminates the need to freeze code development while applications are either being shifted to the cloud or refactored. Instead, the Intellisys platform will now keep track of updates to code and apply them once the application has been modernized, he said.

    Code updates can now be transferred automatically into the extracted business rules repository without affecting the rules that are not impacted by the updates. For rules impacted by the updates, a report is generated that highlights the changes. IT teams can now also update business policies and modernize applications concurrently via the repository that also keeps track of documentation such as diagrams, logic, database details and critical dependencies, said Marfatia.

    In addition to presenting logic in multiple formats, including pseudo-code, flowcharts, decision tables and business analyst language, it enables consolidation and optimization actions to be reverted to their original state if required.

    In general, IT teams have been struggling with application modernization efforts that require them to either lift and shift a monolithic application running in an on-premises IT environment into the cloud or refactor it into a set of microservices that run natively in the cloud. Eventually, most organizations will refactor monolithic applications, so the debate becomes to what degree to undertake those efforts before lifting and shifting an application into the cloud. Most monolithic applications were not designed to run in the cloud, so when the app is shifted it’s not uncommon for any number of performance issues to be encountered.

    EvolveWare claims that its Intellisys platform reduces the cost of application modernization by as much as 60% by eliminating much of the manual effort that would otherwise be required. Modernization efforts, in general, are hindered by manual processes that should be automated, said Marfatia.

    The issue that most DevOps teams encounter when modernizing an application is that it is not a task they regularly perform. As such, many of the processes required have not been automated with the same level of zeal they’ve applied to more routine manual tasks. The Intellisys platform is designed to enable IT teams to automate the most common tasks associated with migrating an application to another platform.

    The biggest driver of those migrations these days has been digital business transformation efforts that have accelerated since the start of the COVID-19 pandemic. Organizations of all sizes are moving applications to the cloud to ensure greater availability and resiliency to limit the amount of disruption that might be encountered should the pandemic worsen, or in case some other unexpected event makes accessing IT services difficult.

    The challenge, of course, is moving applications—and the database they depend on—from one platform to another is not easy. It can take some organizations months, sometimes even years, to make the transition. Given the backlog of applications that many organizations are looking to migrate to another platform, it’s clear there is a need for much higher levels of automation to accelerate a transition that, on its present trajectory, might take years to complete.

  • 3 Steps to Jumpstart Your App Modernization Journey

    3 Steps to Jumpstart Your App Modernization Journey

    Like organizing your garage, modernizing your applications can seem daunting before you start, but you know it will pay off once done. So, instead of thinking about this project as a technical challenge, let’s look at it in the wider context of the business. Just as getting rid of old junk in your garage frees up the space you need for things you actually use, modernizing your apps helps your business run more efficiently and scale more easily. Based on my experience with many application modernization projects, here’s how developers can best approach app modernization, including what you’ll need from your team and technology, six key ways to tackle the task and how to prioritize.

    Start With a Business Assessment

    Before you can make any changes to your applications themselves, you need to lay out a plan based on your company’s needs. That means assessing every application in your portfolio, not just as individual properties but in the way they interconnect.

    Like most developers and engineers, when you have a technical background, it’s tempting to build a strategy around the most exciting technical opportunities. But the purpose of all the applications your company uses is to enhance the business. For example, your organization is likely considering an app modernization initiative to better serve customers and clients; to increase revenue or cut costs.

    That means when you approach modernization from a business perspective, you should prioritize apps based on business value. Large modernization projects can get complicated, so you won’t necessarily be able to complete this process for every app.

    When it comes to large-scale, complex applications, the effort required to modernize every piece is significant. So, it’s important to decide what applications are of the highest value and plan your modernization efforts starting there.

    There are several business-focused questions to consider, such as:

    • What are the business’ needs now and in the future?
    • Which problems are we trying to solve as an organization and as a department?
    • What capabilities does the business need to add in order to grow?
    • What does the business need to do to better support customers?

    Smaller organizations may be able to modernize every app and component. But if you’re in a large business or an enterprise, you will have to choose the apps and components that are most critical to the business goals. Of course, if you’re successful with the first crop of applications, it’s more likely you’ll get the go-ahead to move on to other apps and components.

    It’s important to stress how important this kind of assessment and planning process is. You need to get that business buy-in for that ultimate alignment and for delivering the most value for your business in the shortest amount of time.

    Choose Your Application Modernization Program

    Different applications require different modernization approaches, some of which are more labor-intensive than others. Here are six methods (the six Rs) used to modernize an app and how to assess which one is right in each case:

    • Retain: If an application is working as well as it possibly can in its current environment, leave it alone. This is rare, but it does happen.
    • Rehost: In the case of apps that already work well, you’re more likely to want to move them to a new platform than leave them completely untouched.
    • Retire: If an app no longer serves a useful purpose, is outdated or runs on technology that no longer exists, retire it.
    • Repurchase: Switching apps from perpetual licenses to software-as-a-service (SaaS), subscription-style models means less hardware maintenance, easier access to updates and cloud storage for all users.
    • Replatform: Transfer an app from a hardware-based option to the cloud, with a few small changes.
    • Refactor: The most work-intensive option—and the most interesting! This is the coding equivalent of a movie remake, in which you update the code to improve performance, availability, security and more.

    Follow App Modernization Best Practices

    All right. You’ve got leadership buy-in and you’ve categorized all your business’ apps according to the six Rs we mentioned above. Now, the real work begins. There are app modernization best practices to follow as you continue on this journey. Most importantly, remember that the effectiveness of your modernization efforts comes down to two key components: Your team and your tech. Here’s what you need from both for a successful mission.

    Deploy the Most Advanced Technology

    The underlying purpose of application modernization is to bring your apps up-to-date with the latest cloud technology. For the best results, you need to use the best available tech. There are a few elements of modern cloud technology you should consider. Serverless infrastructure is one. With serverless, you can make large-scale changes in real-time without having to maintain servers.

    Data management is another area where you should employ cutting-edge tech. You can use purpose-built databases that best suit different types of data for faster and more efficient processes.

    Autoscaling is also a key benefit of moving to the cloud. Be sure to factor in the need to scale from the start of your modernization project to avoid bottlenecks further down the line.

    Hire an Agile Team

    The most advanced tools in the world are useless if the people using them aren’t sufficiently trained or skilled. When hiring a team, look for agility. Application modernization processes are a lot of work. You need a team that moves quickly in order to hit your deadlines.

    Culture and responsibility, as well as ownership are also important. A demanding work environment requires open communication and people who will take responsibility for their part in the system. Consistency is another crucial factor. Involve the people who will be responsible for managing the apps from the start of the modernization process. This makes it easier for them to continue the work once the app is ready.

    Summary

    Getting the most out of your application modernization project requires the right tools, personnel and services. And while taking your first steps into the cloud can seem intimidating, by following tried-and-true best practices, you can stay on the right path toward a big payoff in the cloud.

  • Best Practices for Modernizing App Modernization

    Best Practices for Modernizing App Modernization

    Modernizing legacy systems to embrace a loosely-coupled microservices architecture is the biggest predictor of success for continuous delivery, according to Google Cloud’s 2021 Accelerate State of DevOps report. Studies continue to show that the most elite DevOps performers enjoy more frequent code deployments, faster lead times to deploy, low change failure rates and faster time-to-recovery. 

    Leading enterprises like Netflix, Tesla and Starbucks proved that a microservices architecture minimizes fine-grained dependencies between services, which can then be independently tested, deployed and scaled. Combined with DevOps best practices, this reduces technical debt and allows for modernization based on a factory model approach that incorporates automated analysis and deep observability. 

    That said, application modernization to date has been a manual process requiring multi-year projects that suffer a high failure rate. How can we apply modern tools, known DevOps best practices and desired business benefits to improve and accelerate a company’s modernization efforts? In other words, how do we make modernization more modern? 

    By using automation, AI and data science, building repeatable pipelines and shifting architecture left, architects can get in front of technical debt before it becomes unmanageable. In this article, we’ll explore these practices in more detail.

    Intelligently Automate Everything Possible

    DevOps methodologies have taken manual steps and applied automation to create repeatable processes that scale. Modernization teams today are in dire need of these methodologies, as they are stuck with manual approaches that don’t scale across an entire application estate. Thus, applying intelligent automation, AI and data science to modernization—and creating a repeatable pipeline for refactoring—is a natural extension of DevOps successes over the last decade.

    Continuous Integration, Continuous Deployment, and Continuous Modernization

    CI/CD methodologies are a core best practice for DevOps teams and are already familiar patterns that development organizations are using for their application life cycles. But, there is no continuous delivery without continuous modernization. Elite teams continuously monitor technical debt accumulation and address it at every application release cycle, thereby implementing continuous modernization in their application life cycles.

    Deep Application Observability

    Observability, defined as monitoring, logging and tracing, is a foundation for cloud-native architectures. Modernizing an existing monolith requires deep observability beyond simple static code analysis to include deeper domain-driven behavior analysis and dynamically tracking dependency interactions. This is also the secret to uncovering dead code that is no longer used.

    Ensure Architectural Parity

    You must understand your infrastructure architecture to inform your application architecture and your modernization options. Lift-and-shift causes headaches for many organizations because the traditional three-tier architectures of monolithic applications have a completely different topology than cloud-native applications, which are designed from scratch to leverage the efficiencies of the cloud. 

    Whether it’s a hybrid approach (part on-premises, part cloud), public or private cloud, it’s important to ensure that your modernization strategy ensures architectural parity between the target application and its ultimate destination in the cloud. Also, it’s important to understand your modernization options: Rehost, replatform, refactor, rewrite, etc. What can you lift-and-shift and what needs more attention? 

    To find the answer, incorporating data science-driven analysis, automated service extraction and, more importantly, people, to help you understand the possibilities is critical. 

    Get Executive Support for Your Modernization Project

    This isn’t about simply churning through your backlog; your executive sponsors for a project of this scope need to understand, in business terms, why this is crucial for the organization. There are plenty of metrics showing the financial and opportunity costs of maintaining mission-critical applications that are aging and problematic. 

    To get executive buy-in for your modernization initiatives, you need to formulate a business case that communicates the cost of maintaining the legacy apps, both in time and resources to maintain, but also the negative impact on innovation, customer acquisition and retention and speed to market.

    DevOps practices emerged to improve how IT organizations reliably and efficiently deliver software from development to operations and out to customers. Applying these emerging technologies of automation, pipelines and deep observability to application modernization initiatives will enable teams to accelerate how they deliver application transformation projects. By investing in training application teams in these methods and providing modern tooling to support that training, organizations more reliably and more efficiently move both people and projects forward into the next generation of cloud applications.

  • IBM Shifts Mainframe App Testing to the Cloud

    IBM Shifts Mainframe App Testing to the Cloud

    IBM this week revealed it has added the ability to set up testing environments on the IBM Cloud for z/OS mainframe applications.

    In addition, on March 15, IBM will make available an IBM Z and cloud modernization stack to make it simpler to modernize mainframe applications by adding application programming interfaces (APIs) using a cloud-native set of DevOps tools that run in a Kubernetes environment.

    Tarun Chopra, vice president for the IBM Z Hybrid Cloud, said IBM Z as-a-service on IBM Cloud for development and test eliminates the need to dedicate mainframe capacity to an application testing environment. Instead, mainframe application testing can now occur in the IBM Cloud, he added.

    Currently available as a closed experimental today, IBM plans to make IBM Wazi as-a-Service (Wazi aaS) for z/OS generally available in the second half of this year. That offering will enable DevOps teams to self-provision an instance of a z/OS virtual server on a secure private space running on IBM Cloud.

    That hybrid approach means application testing no longer disrupts mission-critical applications running in production environments on a mainframe, added Chopra. The overall time required to gain access to a z/OS development and test environments will drop from days or weeks to six minutes or less, he said.

    At the same time, it will become easier to modernize mainframe applications by making them more accessible to other applications via a set of secure APIs. Many organizations today increase their technical debt by duplicating functions that already exist within mainframe environments simply because those functions are not easily accessible to developers. The IBM Z and cloud modernization stack makes it simpler to modernize mainframe applications to drive a digital business transformation initiative without increasing the overall technical debt an organization needs to service, noted Chopra.

    While many workloads over the years have been migrated off mainframes or simply retired, the applications that run on z/OS today are still among the most mission-critical that organizations run. A recent IBM Institute for Business Value study found 71% of respondents said mainframe-based applications are still central to their business strategy. Four out of five respondents also noted they needed to modernize those applications, as well.

    Modernizing mainframe applications is a less complicated endeavor than migrating them. The challenge is that building, deploying, maintaining and securing all the APIs required to do so represents a significant amount of effort. IBM said it is committed to simplifying the mainframe app modernization process.

    One way or another, mainframe applications are becoming part of the larger distributed computing environment. Most organizations that have invested in mainframe applications continue to run them in on-premises environments because of the unique transaction processing capabilities a mainframe provides. Mainframe applications that have been migrated to the cloud generally run more slowly than they did when running natively on a mainframe. There may still be circumstances where migrating a mainframe application to the cloud makes sense as part of a larger IT strategy. However, like every other application being accessed over a wide area network (WAN) there will always be performance tradeoffs to consider.

  • The Role of APIs in Mainframe Modernization

    The Role of APIs in Mainframe Modernization

    Mainframes are historically clunky systems. They are incredibly secure and can process impressive calculations, yet they are complex to manage and challenging to extract data from. This reality is at odds with modern cloud-native infrastructure, which emphasizes distributed computing and portable microservices. So, how can existing mainframes adapt to this connected, data-driven economy?

    I recently met with Dr. Alex Heublein, president at Adaptigent, to talk about the state of legacy modernization. According to Heublein, many mainframes are here to stay for the foreseeable future. However, enterprises are continuing to get value from these systems by adding an integration layer on top of them. By using a REST API layer on top of a mainframe, enterprises could finally open up these systems. This could facilitate bidirectional communication with newer cloud-native services, enable phase migration and edge closer to real-time processing.

    State of Mainframe Modernization

    The software industry changes every day. “Nothing in the tech field is permanent,” said Heublein, yet some legacy technologies will persist into the foreseeable future. In terms of mainframe adoption, Heublein sees a couple of categories of users. First are the large financial services organizations, such as large banks and insurance companies, which are considerably invested in their mainframe architectures and which will likely continue to rely on mainframe environments for their policy management and core infrastructure. “I think there’s a lot of good reasons for that,” explained Heublein. “If you want to process billions of transactions a day, [mainframe] is still a good option.”

    That said, regulations and market pressures are influencing a global movement toward open banking. For example, PSD2 mandates open banking in Europe and industry consortiums like Financial Data Exchange (FDX) are directing it in the U.S. market. These initiatives are encouraging financial services to transform their legacy environments and spurring cloud migration, especially for applications that aren’t mission-critical.

    Heublein pointed out a few different patterns in enterprise mainframe modernization. One approach is that enterprises are rewriting or re-architecting old COBOL applications and keeping them on-premises. Or they are porting and re-platforming the application; moving a COBOL app to a Windows or Linux system, for example. Finally, some are shifting straight to the cloud. For solutions that don’t need to be on the mainframe, enterprises may shift toward cloud-native to free up capacity.

    APIs Enable Legacy Modernization

    Distributed cloud technology is helping businesses scale to the right level. Yet, it’s difficult to jump off the mainframe entirely, noted Heublein. “Very rarely can you take all your stuff and move it all at once,” he said. “It’s a tough pill to swallow.” It’s especially difficult to move core banking infrastructure to a distributed environment—an instant shift could introduce security risks. For this reason, he recommended a ‘phase migration’ approach in which individual components are slowly migrated. For example, an insurance provider may shift their claims engine, policy engine and ratings engine to the cloud one at a time.

    As a result of phase migration, however, engineers must simultaneously support both on-premises and cloud-based applications. They must also ensure bidirectional communication so that these systems can exchange data. This is where a REST API transactional layer is necessary, Heublein explained. Such a layer could enable bidirectional communication between the mainframe and cloud-native applications, abstracting complexity when calling out to the modern world, or intercepting cloud data and filtering it into a format mainframe technologies can process.

    To increase developer usability, abstracting complexity from the mainframe integration process will be the key to building out connectivity. This could involve a codeless development approach with a COBOL sub-routine to call external systems, Heublein said. Automatic restructuring of data will be necessary to enable fluent bidirectional communication, too.

    Four Business Drivers of Mainframe Integration

    So what is the end result of putting an integration layer on top of mainframe systems? According to Heublein, there are four key business benefits of using such an abstraction layer:

    1. Orchestration: Software ecosystems often need to make multiple calls to different applications to collect and transform data. Yet, mainframe environments are very complex and challenging to integrate with. More usable integration fabric for mainframe systems could enable better orchestration of workflows in a developer-friendly manner. By using a REST interface, all apps could be calling the same interface, thus greatly simplifying orchestration between disparate services.
    2. Sustained Adaptability: The world is rapidly accelerating, and enterprises need to maintain and modify these APIs very quickly. Organizations require “sustained adaptability” to adapt and survive in the digital world, said Heublein. Mainframe systems, however, were not designed for the 21st century. Thus, low-code integration layers are critical to empowering rapid development.
    3. Data Transformation: Data is powerful for the business. Data is not only a commodity in and of itself but also is required for AI and machine learning. However, mainframes have a completely different way of encoding data. Thus, there is a need to transform this data into a modern format that businesses can consume. An integration layer between these systems can deliver an improved data consumption model.
    4. Real-Time Processing: You may think online payments happen in real-time; however, payment apps like Venmo are really just an abstraction layer over bank transactions, which may clear as little as twice a day. In short, mainframes are not great at real-time processing. However, more usable integrations to this infrastructure could enable user-facing applications to interact more closely to real-time.

    Another concern is security. Opening up mainframe environments that house core financial infrastructure must be done with extreme care—especially as API attacks remain the number-one rising threat in the software landscape. All organizations building out new integrations will require a secure layer from an outbound standpoint. Heublein said this often involves placing an API management layer or gateway in front of the integration layer. This system enables authorization and functions like a firewall between the internal and external world. It can also enable logging and prevent denial of service attacks, he explained.

    Improving Agility for Legacy Systems

    Legacy systems are entrenched in older technology and carry lots of technical debt, forcing operations to move at a slower pace. Maintainers are also culturally a bit different than the newer breed of cloud-native engineers. “Mainframe people are not … fast,” said Heublein.

    DevOps folks want to build, test and promote projects to production very quickly and, arguably, this agility is necessary to satisfy rising digital innovation demands. Improving integration capabilities for on-premises systems could enable businesses to better utilize preexisting investments while also improving agility.

    Low-code/no-code capabilities could also increase collaboration potential, Heublein added, which could bridge the gap between on-premises engineers and fast-moving business folks. When adopting low-code/no-code tools for mainframe integration, he cautioned against general-purpose citizen developer frameworks. Whereas universal integration layers can work well for many situations, he stressed that a very specific boundary box is best for building APIs for mission-critical applications.

    How is your organization approaching modernization for legacy systems? Let us know in the comments below!

  • EP 4: DevOps and the Mainframe

    EP 4: DevOps and the Mainframe

    In this fourth episode of our DevOps Unbound streaming broadcast on TechStrong TV and devopsy.kinsta.cloud’s sister site Digital Anarchist, Mitchell Ashley of ASG and Alan Shimel are joined by Gerta Sheganaku of Tricentis, Rosalind Radcliffe of IBM and Sam Knutson of Compuware to discuss app modernization, mainframes and DevOps. Find out what’s the right way to modernize your applications and how to do app modernization in a Z environment.

    The video is immediately below, followed by the transcript of the conversation. Enjoy!

    Transcript

    Alan Shimel: Hey, everyone. This is Alan Shimel. Welcome to another episode of DevOps Unbound. This is episode four of DevOps Unbound, and then we’ve also done two DevOps Unbound roundtables. So this is actually the sixth DevOps Unbound event that we’re presenting. They’ve all been great, and I think this one is gonna be as good or better than any of ’em.

    Today’s topic is app modernization and mainframes, along with DevOps, of course. It’s DevOps Unbound. We’ve got a great panel lined up for you. Let me introduce you.

    First of all, we have Sam Knutson, and Sam is the product manager — is a product manager for mainframe and agile DevOps at Compuware, a BMC company. Sam, did I get that right?

    Sam Knutson: Pretty much, Alan.

    Shimel: Correct me. Get it right for the record.

    Knutson: So I lead product management at Compuware. We are a BMC company, and we are focused on enabling agile and DevOps on the IBM z/OS platform.

    Shimel: Fantastic. And the lesson I have learned here is I’ll let each of you introduce yourselves. My next guest is the one and only Rosalind Radcliffe. If you want to know about DevOps and mainframes, there’s no better person in the world to go to.

    Rosalind, welcome, and why don’t you give them a little bit of your title and background?

    Rosalind Radcliffe: Thank you. Glad to be here again. Rosalind Radcliffe, IBM distinguished engineer, responsible for DevOps for enterprise systems. I help clients with their transformation to DevOps for z/OS applications as well as application modernization and bringing z/OS into the rest of the world so you can do your cloud-native development for z/OS as well.

    Shimel: Excellent. Then we have – I’m gonna do my best here – Gerta Sheganaku of Tricentis. Gerta, how bad was that?

    Gerta Sheganaku: Thank you, Alan. That was perfect, really.

    Shimel: Okay. Gerta, your background and title?

    Sheganaku: I’m with Tricentis, as you said. I initially started at Tricentis in the customer experience space, where I was leading our customers through their digital transformation journeys, really helping them understand how they can enable testing as a catalyst to really get DevOps working.

    Then I have moved into the product organization, where I’m currently leading a team where we’re releasing our first AI-based test automation solution, which is really about tackling the problems that we see out there, especially when it comes to app modernization, and testing of old applications and new applications and really making testing easier.

    Shimel: Excellent. And then last but not least is my sidekick, well, partner in crime, Mitchell Ashley, CEO of Accelerated Strategies Group and also my co-host here on DevOps Unbound. Mitchell, good to see you.

    Mitchell Ashley: Good to join you.

    Shimel: All right, guys, today’s topic is app modernization, mainframe, and DevOps. It’s interesting. I’ve been kind of binging on Netflix that AMC show, oh, “Catch Fire”? I forget the name of it now. Anyone else watch this show? It’s an AMC on Netflix.

    Knutson: “Halt and Catch Fire”?

    Shimel: “Halt and Catch Fire.” You’ve watched it, Sam?

    Knutson: I’m familiar with the instruction. I’ve seen the previews for the show.

    Shimel: It’s a pretty good show once you get into it. So the company that started in Texas bets everything ’cause they’re tired of paying the timeshare people, and they buy an IBM, what is it, 3030, that’s based in Daly, San Francisco, or Daly, California, near San Francisco. They literally have to move the whole company to where the mainframe is versus moving the mainframe to where the company is. Well, it’s TV. But that was the late ’80s, right, and we don’t live in those worlds anymore.

    Mainframe applications are running on your phone, right, or at least the front ends of them are, on your tablets, on your computers. The mainframe doesn’t necessarily fill up – this was a whole basement that was one mainframe. It was pretty funny. The guy was sliding cards in and stuff like that. If you get a chance, watch the show. It’s an interesting, interesting look back.

    Certainly the modern mainframe has come into the world of DevOps. Rosalind, I think the work you have done with IBM has led the market with that. Quite frankly, Sam, the work Compuware has done has led the market in agile and DevOps on mainframes. How would you assess where we are currently in mainframes in the world of DevOps?

    Radcliffe: You mean where the mainframe is or where people are? I think those are two very different things.

    Shimel: You’re right. But what we’re not moving the whole company to the computer anymore, thank God. But let’s talk about where is the mainframe, and then we’ll talk about where the people are.

    Radcliffe: So you’ve got to remember, the mainframe itself, IBM Z, is the most modern machine out there. The IBM Z platform has evolved every few years for the last – ever since it was invented, and we keep evolving the machine.

    So the machine itself is the most modern system, and we’ve evolved the operating system. We’ve evolved things such that open source tools work there. We’ve done everything to remove the barriers from the system so that you can do exactly the same kinds of things, whether or not you’re doing z/OS development or another environment. And the Z hardware itself, we all know it runs – well, we all know on this call it runs Linux on Z.

    And so it’s a very large Linux server. It runs containers, and it runs OpenShift. So from a systems standpoint, it provides – there’s nothing keeping it out of the processes and practices. There’s nothing separating it from a systems standpoint. It’s the way people interact with the systems. It’s their existing applications that make it harder.

    Shimel: Sam?

    Knutson: I think Rosalind makes some great points. The current generation of IBM mainframes, the z15, is an engineering marvel, and the compilers and the operating system produce this amazingly efficient platform. It is the most efficient hyperconverged system in the world today.

    But I think the elephant in the room is the word that you used a minute ago when you said “modernization.” We alluded to this a little bit in the way that the practices that people and businesses have today. Well, modernization doesn’t mean moving off platform, because we already talked, and we could go on for an hour, about how great a hardware and software platform this is for running business computing. It is amazingly efficient, especially when you look at the large-scale, global business applications that the Fortune 1000 run, which is where the platform has its largest footprint.

    But the perception is that modernization is moving your application into a cloud-native application off the platform, hosted by another provider, or rewriting it in Java, and nothing could be further from the truth. The COBOL compiler alone is a perfectly paired piece of engineering with that platform, and it lets you wring every last ounce of efficiency out of it.

    But people need to get past that confusion and say, “What if I could work on the platform in the same way I’m working on every other platform?” It’s that normalization. We’ve kind of coined the phrase “mainstreaming,” “mainstreaming the mainframe” to make it different in syntax only, and Rosalind alluded to this. It’s being able to work on this platform in the same way that you work with any other platform. So when you think about DevOps, then you have a DevOps toolchain that looks like other toolchains, that you can connect all of the ecosystem partners that you’re probably already using in distributed development.

    People are definitely the problem, people and practices and culture. More than three-quarters, in fact 78%, of customers say it would be useful if they could update their mainframe applications more frequently than they do today. So there is an aspiration to change and to get better outcomes. You can see what they want. They want to be able to deliver value to customers more frequently, and that’s just one of the improvements that they want to make. But far too many people are not making progress on that.

    Shimel: Gerta, so you’re not a mainframe specialist, but certainly app modernization and testing of this. I’m wondering if you have any kind of information regarding people using Tricentis to test mainframe-based applications. How big a market is that?

    Sheganaku: That’s a very good question. One major thing that you always have to keep in mind, as we just said, especially when talking about app modernization, it is such a wide word, and it can mean so many things, too, to different people. It’s definitely something that’s challenging for our customers looking at their current system landscape. You see customers that are having everything in their landscapes from mainframe applications to also often very legacy mainframe applications that are trying to move onto more cloud-based environments. That is something that we see very often.

    Mainframes are still there, but the thing is that people really want to abstract away from the mainframe. Also thinking about where we are today, I think an important question we have to ask ourselves is why is everyone so into app modernization? Why is everyone into migration into the cloud currently?

    If you think about it, nowadays every company basically is becoming a software company, and not every company has the talent and the resources to maintain those mainframe applications because at the end of the day, honestly I struggle finding COBOL developers nowadays out there. I went to the Technical University of Vienna, and we definitely did not learn anything around COBOL there. It’s really hard to find the talent nowadays.

    When you look at it, basically every company, be it in retail, be it in banking, be it in the energy sector, you now want to have connected systems and so on. Really, everyone is going more towards being a software company. And with that, for people it’s becoming more and more increasingly important to have really good platform-as-a-service offerings, maybe going into serverless or software-as-a-service in the next step, but really having not really to deal with the underlying maybe mainframes and having a way of abstracting and using simpler technologies and only caring about the applications and the data that they’re running on those systems.

    Shimel: I’ll be honest with you, I don’t know if I agree with that. So here’s the premise of this, right? When we talk about app modernization, I’d love to live in a world where I could throw out an old app ’cause I want to have a new app. But we don’t live in that world, right, and no one lives in that world. That’s why we call it “app modernization.” We tend to modernize the apps we already have.

    And so when we look at – I think out of the Fortune 100, 98 are on mainframes. Or it’s some number like that, Sam or Rosalind, if you know. I don’t see 97-and-a-half of them throwing their mainframes out, right? As a matter of fact, they’re probably building more on mainframes. And so what’s happening is we’re seeing whether you want to call it hybrid cloud, VoLTE cloud, whatever you want to call it, we’re seeing where people can build maybe a front end for stuff in the cloud. But if that data is important, if security is important, if scalability is important, dollar for dollar, people who use mainframes know that that’s their best bang for the bank. Mitchell, I’ll let you chime in.

    Ashley: I have to jump in. So what’s interesting is we kind of do this to ourselves with the terminology that we use. “Mainframe” is a word for a cabinet used to house the computers the original IBM computers were stored in.

    If I said, “Hey, 71% of Fortune 500 companies rely on high-volume transaction-processing platforms. Ten out of the ten world’s top insurers, 23 out of the 25 world’s top airlines, 92% of the top 100 banks rely on high-volume transaction-processing platforms,” you would say, “Wow, that’s pretty cool.”

    “And it runs Linus, and it runs containers, and you can connect it to all kinds of applications from tablets and phones to wherever your application may be running, on cloud or on premises.”

    You’d say, “Wow, tell me about that. I’d like to learn about that.” That’s what mainframes are.

    So it’s interesting. It’s not going away. We do this to ourselves, and I say the analysts have done this to us, too, right? Today it’s all about this next shiny object, the squirrel moment. It is so vital to businesses today, and moving it into how we create software with DevOps and processes like that and tools to support it is essential for businesses’ both economic recovery, survival, and future. Digital strategies can’t happen without it for many, many, many companies.

    Okay, did I do a good job, Rosalind and Sam?

    Knutson: Mitch, those were great stats, and I think you did a great job quoting ’em. I’d boil that down to simply saying the worldwide economy and worldwide civilization runs on the mainframe. And I like the word “mainframe.” It has a little swagger. I don’t think it’s ever gonna go out of style.

    Ashley: Nostalgia.

    Knutson: And renaming the platform could make it cooler. It simply gets things done. We haven’t renamed cars yet. Well, maybe we’ll rename them to “highly efficient transport platforms,” but I think we’ll still be calling ’em “cars” when they have electric engines powered by portable fusion reactors. But customers see this as a long-term platform. BMC does an annual mainframe survey, and the 2020 edition is gonna launch soon. I can tell you that 90% of the customers see the mainframe as a platform for growth and long-term applications. Sixty-eight percent of ’em expect the size of that compute platform to grow, MIPS to grow. Sixty-seven percent of those organizations have the majority of their data on the mainframe. They trust it because, as you said, it’s highly available, scalable, secure.

    And to go back to Gerta’s key point about younger workers, that is absolutely essential. But what’s going on is that people are addressing that because – I think Rosalind and I both alluded to this – the syntax of COBOL isn’t Aramaic. It isn’t some incomprehensible script.

    If you put modern tooling around this, if you put modern process and a great, supportive culture that gives that great – you have a great developer experience, you have a great developer culture, then learning the syntax of COBOL is no more difficult than learning the syntax of Perl or Rust or Go. So we see that customers who see the platform long-term are making the appropriate investments. In the responses to that survey I mentioned this year, younger mainframe workforce definitely figures in, 43% less than five years on platform. Sixty-eight percent were under 49 years old, and 60% of that new generation see this as a growing platform.

    That really matches the experience that I’ve seen in Compuware’s journey is that we hired out of college and we have been hiring out of college, and those next-gen developers are more than a third of our workforce now in Detroit. Many of them did not know COBOL, and many of our applications are written in assembler. They certainly didn’t learn assembler in college. But what they did have was a strong bent for learning new technologies. Many of them came with computer science degrees. They had learned how to learn. They were what Gartner calls “polyglot programmers,” one, two, three, many in learning languages.

    So whether we needed to learn assembler or COBOL or C, it didn’t matter as long as we provided that supportive culture, the vehicles for learning, and we gave them meaningful work early on in their employment and made sure that they understood the vision, mission, and goals of the firm and how they were contributing to something that matters. I think our customers are having similar success in onboarding next-gen developers by doing some of these same things.

    Radcliffe: I think it’s interesting, the statement, “I can’t find COBOL developers,” because when I was hired in to work in this industry, nobody assumed you knew the language or the system you were going to work. That was the thing you learned. You learned how to develop, and then you came in and learned the company’s culture and the company’s tool choice.

    By using modern tools, modern practices, all of these things, the things they have learned in college on how to do, they’ve already got. And then the only thing they’re doing is learning COBOL.

    As I always joke, it’s just English. I know that works really well in the US and in parts of the world, and in other parts it’s, “Okay, it’s still a foreign language.” But it’s not a difficult language. It’s easy to understand. PL/I, it’s not difficult to understand. It’s just another language, and developers can learn other languages.

    I am kind of with the discussion about “mainframe” is not the word we should always use, and we really need to focus on how do we talk about our platform. I like the term “mainframe,” too. I still use it. But can we talk about our platform as this platform that provides this valuable, high-transaction server? It’s that big server as part of your pipeline. It’s not that old thing. It’s that big new thing that runs all this work, and now let’s focus on the applications that – Honestly, the best thing IBM ever did was a program you compiled in 19-whatever and still works today, and the worst thing IBM ever did was that program that you compiled in 19-whatever and still works today. It’s the best and the worst of the platform. You don’t have to change. It still just works.

    And if we can help companies understand if they start to change some of those, they can do the automated testing. They can do all those things. They can get more value out of their platform. They can help refactor and be able to move at the speed they need to.

    Shimel: Go ahead, Gerta.

    Sheganaku: These are all amazing points. I hope no one got me wrong at the time beginning with what I wanted to say. I really like what Rosalind just said, to talk about the underlying platform that is really enabling. But the point that I really wanted to make is that most companies are now becoming software companies. We don’t have that knowledge center of IBM, where there are so many smart people and you can learn from people and really develop that amazing platform that you offer other companies.

    But when I look at our customers, it’s usually self-built kind of mainframes that are sitting there that are not maintained that don’t apply current recent security standards. Those customers, what you see them do often is they all hear, “The cloud is the next thing. We all have to go to the cloud.”

    They all do this one big mistake that they just take whatever they have and they basically do the lift-and-shift approach, bring it to the cloud, and hope that everything’s gonna work. Of course that’s not gonna work at all. Also from a cost perspective that is insane, thinking about how much cloud resources actually cost you if you don’t do all the optimizations and so on. So what you see people do is kind of a step-by-step learning approach where they are taking things from not-so-secure systems, bringing them over to other systems, then starting to refactor the applications, and giving more and more also responsibility to the development teams.

    Once they do that, you see the development teams really getting that DevOps approach, really caring about the infrastructure, and so on. For the developers, of course it’s easier if they have container-based applications that they can simply deploy and so on. But of course underlying it’s very, very important that you have a secure and great platform that is enabling all of that.

    Shimel: I think that’s a great case for why you’d want to use a mainframe or whatever you call it, ’cause it’s probably more secure than the cloud is, I think, and it’s been proven. But here’s an interesting thing I’ll tell you here I see in devopsy.kinsta.cloud, right? This is devopsy.kinsta.cloud, mind you. And it was surprising to me. Our biggest article last year on devopsy.kinsta.cloud, most views, most comments, “The Beauty Of the COBOL Programming Language” by Bob Reselman.

    I don’t know, it had half a million or something, maybe more, a crazy amount of views. Most of the comments were by COBOL programmers in India because there they recognize that there’s such a need for COBOL programmers that you have a lot of young people who are studying COBOL because they know it’s basically a guaranteed job for them, right? They come out and they start working right away.

    Here’s another interesting thing, and my friends in Tricentis will notice – will appreciate this. What do you think was another huge area of interest in devopsy.kinsta.cloud? Running SAP in a DevOps world, right? We don’t think of SAP as DevOps-enabled or maybe not even agile.

    We did a roundtable a week or two ago on SAP in DevOps. I had to cut the questions off, and these were meaty questions: “How do I do this and that in this and that release?” It wasn’t just pie in the sky. They were very how-to, practical, “We’re running SAP, and we’re moving towards agile and DevOps and we’re doing these things.” So while everybody – we always rush to the shiny new trinket and the hot thing in our industry, I think the fact is certain things endure. As Rosalind said, it’s both their greatest and worst attribute. It is.

    But let’s talk a little bit about app modernization ’cause I think Gerta alluded to it. Mitchell, I’ll throw it out at you. No one wants to do shift and lift or lift and shift or whatever. It doesn’t work in 2005 when the cloud first started, and it doesn’t work now. But how do we do app modernization right in a Z environment? Sam, Compuware has made a – it was the reason for your being in a lot of these last couple years, right, something Chris O’Malley always harps on. How do you do modernization right in a mainframe world like this?

    Knutson: First, you do it on platform because – I can’t say that enough – when you see people try to avoid touching the mainframe apps that live on the mainframe, they do unnatural things from an architectural point of view, and they create these horrible kludges that are not robust, that are not scalable, that are not the most efficient implementation, and that aren’t easy to maintain. So you want to bring those practices on platform. You want to provide developers with helpful editors, with quality tools. You want to tap into the automation pipeline. So build a CD pipeline that goes right onto your pipeline so that you give developers a great developer experience, but you keep the business logic and the data on the platform.

    That goes to a number of things. When you talked about security, something that I learned a long time ago, the more copies of data you have, inherently the less secure it is, because typically when mainframe data is moved off the mainframe, the security controls that are on the platform are not replicated.

    So if you can take that core business logic, that digital DNA that a business has inscribed over 20, 30, 40, 50 years, continue to leverage that, and of course leverage systems off platform. Compuware really blazed this trail of using cloud and mainframe together with two-platform IT. We think these things are incredibly complementary. But what you don’t need to do is replicate that data all over the place. You don’t need to necessarily have a lot of on-prem systems. The term “hybrid cloud” was used, and that’s a nice, modern way to talk about that. We say “two-platform IT” because these things will pair very, very well.

    And the cloud, by the way, is an absolutely great place to host commodity applications. If you talk about your company’s e-mail system, I probably cannot run Microsoft Office better than Microsoft can with Office 365 in the cloud, and they can provide all the quality, the service, the latest updates. It’s a good solution. Can I do invoicing better than a cloud provider like NetSuite or Oracle? Probably not.

    But what I want to do is focus on those applications that give me unique business advantage, the things that I wouldn’t find in Amazon, Google, or Microsoft’s application catalog. Those applications give me a competitive advantage, and in updating them I increase that competitive advantage so I can provide new features, new capability. I want to take that on-platform application. I want to bring to it things like automated testing. Make it part of a CD pipeline. Give my developers a great set of tools and give them a great culture of development to help them help the firm be successful.

    That is the best approach to modernization I know of, and of course I work very hard to provide those things, including program understanding, so that developers can really get into code that they may not be familiar with, because when I talked about a younger mainframe workforce, that’s a good thing, but it also means that I don’t have people who have apprenticed with an application for ten years before being allowed to do important changes.

    You have people who are new to your firm, and they’re being tasked to do important work. So they need to be able to understand an application that may be older than they are quickly enough to inside a two-week agile sprint make a change, test it. Hopefully there’s already automated test present, but if there is not, they want to write some new automated tests and deliver that all as working, demonstrable code at the end of that sprint because that’s the way the world works today. So if you do that, you’re blazing down the road towards application modernization. It’s easy to talk about, but it boils down to just hard work.

    Ashley: Alan, I think to build on what we’ve said here, I look at it as three elements to the strategy here, and this is just also sharing my own personal experience with doing this. First is the people and the culture and getting our heads around new processes and new ways or additional ways of doing things. That’s what DevOps is about.

    Second is processes and tools, which Sam was just eloquently talking about. I think the third obstacle to app modernization is tackling the monolith because a lot of our applications were built differently, that we’re looking at how do we modernize. Well, why do you want to modernize? Sometimes it’s because we have to figure out a way to get in there and better maintain it ’cause it’s just too scary to tackle. The people that built it aren’t there anymore.

    Another reason, though, and I think the way to tackle that monolith part of it, is looking at our applications and saying what functionality and what business capabilities in the apps are most important to having the most flexibility or improving the speed at which we can improve that software to respond to and support the business?

    If we’re living in a world of changing how we’re delivering services into contactless, we’re living in a world where supply chains are going from inventory to on-demand, whatever it may be, examine those applications. Pick out where those elements are. And those are good candidates for going and saying, “Let’s carve out that piece and look at some new or alternative designs for how we can more easily maintain or more quickly develop capabilities in that part of the software.”

    It doesn’t mean you move it off the mainframe. It may stay there. It may be a combination of things. But that’s also part of app modernization is how we create software and the tools that we do it and sometimes how do we take on really big problems but divide ’em into much smaller pieces that we can do something about.

    Radcliffe: The application modernization of a Z application does unfortunately involve understanding it. And so having those tools for application understanding is the first key, but then actually understanding the business is the other key. And so it’s a combination of application modernization tools and understanding the business domains you’re trying to go after, really thinking about what are the focus areas and understanding what you need to run.

    Lots of discussion about microservices, and I always question, “Do you really want a microservice, or do you want a service? What level is the right componentization for this function?” And I always use a banking example because this one’s the easiest. “I need my credit card swipe to happen, and I only have a certain number of nanoseconds, whatever it is, to make that happen.”

    I’m not gonna make that a thousand microservices. I’m gonna make it a service. That service has to run fast. It has to be efficient. So it needs to be written as not a monolith, but a service itself. Where is that service? Is it bundled in the middle of something else that’s doing a whole bunch of other function? Can I strip it out? I need to look at the applications. And so using application understanding and the skills we still have today, because in many companies they actually still have a few people left that wrote those apps, not maybe for much longer, but they have ’em now. Let’s start to look.

    Use application understanding, the next generation, and learn from each other. I think the next generation, the newer developers, have a lot of skills in a lot of the new tools, and the people my age have the experience in the apps. So let’s bring these people together to help build this new culture, to help bring this together. Let’s take advantage of both sides and the tooling because even if they helped write the application, they still don’t know the whole thing anymore. It’s a monolith.

    Bring it together, and take advantage of these people. Use the people, both sides of the people, and bring all those skills together with the tooling to actually help you understand the business domains, the functions that you want to do, and split up that monolith. Maybe you’re splitting it up into a bunch of COBOL programs. It doesn’t matter. You’re providing the business value that you need to in a more maintainable, manageable way.

    Shimel: Fair. Guys, we’re running closer to the edge on time. I wanted to touch on the issue, though, ’cause it’s what Gerta does a lot of, and that’s around testing, right? As we’re modernizing these mainframe applications, we’re keeping them on the mainframe. Maybe we’re hybridizing them, if that’s a word, putting front end here and backend there or whatever. We’re modernizing the applications.

    Testing is an important part of it, as it is always. Anything special in particular that we’re doing around the testing of the modernization of mainframe applications that perhaps is different than – Gerta, go ahead.

    Sheganaku: When you think about testing, really just the whole topic of app modernization and also testing can be split into so many different bits and pieces. The one bit is really the architecture that we’re speaking about, where is everything hosted.

    Are we dealing with a monolith versus are we splitting everything up into service-oriented architectures or microservices or whatever we want to call those things, really making sure that we shift testing more to the left, that we make sure that the components are tested and such.

    Then the other side is really around the infrastructure, so really thinking about do you have those physical servers or do you have now more VMs, cloud-based environments? Do you have containers and so on where you’re hosting your _____ [break in audio] making sure that the intersections are tested properly?

    And then another point that’s also very important is really also the process side of things, so the delivery side. Are you having more of a waterfall environment or are you going more towards an agile DevOps environment? And all those things also go hand-in-hand.

    The typical approach would be especially you would have some more legacy type of applications that are running in the background that are really the backbone of your business, and then you would have more flexible applications built on top of that. For each of those you need different testing approaches.

    Something that we saw here, especially when we say “shift testing to the left,” was that while it was so far really possible to shift testing to the left when it comes to doing unit testing, doing API testing, and so on, it was always very hard when it came to end-to-end testing, especially across systems, when you have different systems, older systems, newer systems all working together, because there you really didn’t have that concept of just defining your tests up front and once everything is ready you just run your tests. It was really very difficult.

    Especially now I am focusing on the space of UI testing currently. In the UI space it was basically impossible to do that. That is also something where AI approaches can help in the future because if you look at the applications that we’re interacting with, no matter what technology is used in the background, no matter what type of programming language we’re using, if we’re having something in the cloud or on a server, it doesn’t really matter. How we interact with the applications as humans hasn’t really changed so much over time.

    When we looked at banking systems from 20 years ago and made an analysis, they look just the same like today. The applications that we work with on a day-to-day basis, although they move from one platform to the other, the technology keeps changing, bits and pieces keep changing, the way we interact with it really doesn’t change so much. So there it really helps to bring in AI-based approaches that help you take that human perspective when performing those tests to really be platform-independent.

    Shimel: Excellent. Sam, Mitchell, Rosalind, any thoughts on testing and app modernization with the mainframe?

    Ashley: I would just jump in and say it’s a great place to start, not to say you’re starting from scratch, but maybe you are, that whole CI/CD testing. As Gerta was saying, you can use cross-platform approaches, right? It doesn’t have to be one set of tools for this, one set of tools for that, et cetera.

    It can be, but there are some advantages to leveraging that knowledge base that Rosalind was talking about. You’ve been doing testing. Now how can you take that to the next level, whether it’s getting quality up or speeding up how quickly you can do releases, whatever the driver might be? As Gerta talked about, those are some fantastic approaches to take.

    Shimel: Rosalind?

    Radcliffe: Yeah, testing is one of the ways that we see people getting value fast, and it in some ways takes less cultural change. It’s easier maybe to get them to do automated testing, and automated testing is actually what makes you faster. You need that ability to test the system.

    Shifting left using virtual services, shifting left by virtualizing the whole system, allowing you to test your application in the build process, and doing unit test really does help in the mainframe space to get that feedback. It helps in every space, actually. But in the mainframe space, we seem to have forgotten this. I don’t know why. When I started, we did it. Okay, 20 years later people forgot. Getting to that unit testing, that automated unit testing, and making sure we’re doing that virtual testing, whatever it is to get that application transaction and really have that capability, and there’s lots of tools out there to do the testing.

    And the other part is it has to be cross-platform ’cause most Z applications are not Z-only. So open source tools like the Galasa framework that help you test across distributed and Z matter. Things like test data as a service matter. Use optimizations, looking at AI for data and understanding what data should you feed this.

    Multiple people have capabilities around that to look at the right data to test to make sure you get that fast feedback all the way at the beginning and get that developer that input so they aren’t waiting that six months of testing, that late-stage testing that is the reason why everybody says the mainframe is so slow because they spend too much time at the end testing. Let’s shift that all and bring it to the beginning, and then there are people delivering weekly into production because they have automated testing in place.

    Shimel: Absolutely. Sam, I’m gonna give you the last word, and then I’ve gotta wrap it up.

    Knutson: I think automated testing, and you have to underscore “automated,” is critically important. It’s one part of this. It’s not about the old, “Fast, cheap, good: Pick two.” People need to continuously improve quality, velocity, and efficiency on the platform, and automated testing is a key part of that. You will get measurable results, and you have to measure the results. So you have to put automated tests in place, you have to put quality aids in place, and then you have to measure that.

    If there’s one thing that we probably didn’t spend time today on that I think is a worthy thought for people to put front and center, it’s you’ve gotta measure from the very beginning what you’re doing, because any effort like this is going to entail some amount of spend in terms of resources. It is a worthy spend. It is the natural evolution of development for the platform.

    But you have to treat your developers like the high-performance athletes that they are. You have to give them continuous feedback. So use an analytics platform where you can understand what’s going on with your development process, what’s going on with your testing, so that you can see the results.

    When I looked in-house, what we were able to see is that as we evolved our development approach from waterfall to agile and we put these automated tests in place and we gave our developers a great developer experience, continually improving their tooling and our toolchain, we were able to get measurable results, like 25% more trapped defects that were caught before they ever escaped into customer hands.

    We were able to get twice as much code from individual developers and deliver at the speed of business. We didn’t get those results if we didn’t make the changes, including automated testing, including a great developer experience.

    None of it is optional. You don’t get a hall pass on any of this. Pick one and start, but you really have to think – this is a journey, and you’re gonna have to address all of these if you’re gonna get the outcomes that you want and be the most competitive that you want.

    I’ve seen customers getting amazing results that are measurable by outside firms where they’ve done studies and been able to see more than 467% ROI from implementing automated testing and building net-new applications on the mainframe. So this works. I’ve seen the proof points. I’ve seen the customer case studies. I would just urge people who have been sitting on the sidelines to get in because the competition absolutely is modernizing the way they build applications on the mainframe.

    Shimel: That was a strong finish, Sam. Thank you very much. Good stuff. Hey, Sam Knutson, VP of product at Compuware, a BMC company. Rosalind Radcliffe, Distinguished Engineer, IBM Enterprise Systems. Gerta Sheganaku from Tricentis on product for AI testing. And of course the one and only Mitch Ashley.

    This is Alan Shimel. Many thanks to Tricentis, by the way, for sponsoring DevOps Unbound today. This is Alan Shimel. We’ll be back in about another two weeks with another great DevOps Unbound. Stay tuned, but for now that’s it. Take care. Bye-bye.