devopsy.kinsta.cloud

Tag: application modernization

  • 5 App Modernization Best Practices

    5 App Modernization Best Practices

    An organization’s digital transformation is ineffectual if it doesn’t bring out the best from its applications. This is a near-universal concern since most enterprises still have core applications that are architected primarily to work in legacy IT landscapes in an on-premises dedicated environment, slowing down IT and business performance, stymieing innovation and increasing vulnerability to risk. Businesses are paying the price of their technical debt by forsaking agility, adaptability and competitiveness. That’s bad enough in regular times; in a post-pandemic scenario, this can have devastating consequences. 

    Acquiring a few cloud-native applications that are not integrated with existing systems is of limited value and, at best, provides just part of the answer. On the other hand, overhauling the legacy application landscape is usually out of the question. The only reasonable solution, then, is application modernization. But where does an enterprise begin?

    Pick and Shift

    A great place to start is by examining existing applications. Understanding every application’s function, performance and issues and what it can gain from modernization will help to establish a ‘universal set’ to pick from. The candidates for modernization can be prioritized based on technology factors—for example, when the architecture adds cost, vulnerability or complexity—as well as business considerations, such as compromised agility or value potential. Finally, the enterprise needs to weigh the potential benefits, especially ROI, against the difficulty of modernization.  

    Typically, the biggest, most important applications at the core of the enterprise are the hardest to modernize. But without their involvement, the transformation will most often be incomplete. Rather than lifting and shifting these monolithic applications and their vast data to the cloud, the enterprise can enclose them in an API layer to connect them to all the other applications that are being migrated as well as any new applications that are deployed. Using APIs to expose the functions and data of a legacy core system, such as ERP, allows it to be widely used, reused and modified, as well as leveraged to build new solutions and services. 

    Split Into Microservices

    Refactoring is a useful way of modernizing legacy applications that involves breaking them into microservices, which are then connected to cloud infrastructure such as Docker or Kubernetes. These microservices, which are loosely coupled, can be ‘called’ and scaled individually. Since refactoring requires significant rewriting and restructuring of the code, it is best done progressively over several iterations to make sure everything is functioning properly.  

    Provide Full-Stack Visibility 

    Even when an application is modernized into microservices on the cloud, it needs to communicate with other legacy systems in the enterprise. The problem is that now there are more services and environments to monitor and secure, not to mention single points of failure, which not only increases complexity but also denies the enterprise full-stack visibility. But visibility across environments—edge to core (on-premises) to cloud—is imperative for success. This is achieved by ensuring that the modernized applications fit within the organization’s data fabric. The enterprise needs to capture data across the stack, from end to end, and process it in real-time to have an uninterrupted view of the performance and availability  of its applications.

    Modernize the Process Landscape

    A perfectly executed application modernization program can fail to deliver results if the surrounding requirements—for example, planning and meeting quality standards—are not met. Legacy processes can be a drag on modernization efforts. It is therefore necessary to address this issue by rearchitecting processes to fit a more automated setup by supporting code developers with teammates who understand the business requirements, adopt best practices and follow the example of successful digital natives. 

    Track Performance Metrics

    Going back to the point about visibility; enterprises need to establish key metrics to track so they can monitor the performance of applications right down to the code level. And it’s not just applications—the entire infrastructure, from cloud to databases to networks, needs to be tracked continuously to identify problems before they blow up. The performance of applications needs to be compared with the corresponding pre-modernization values to understand the benefits as well as identify areas needing optimization.

    Balance and Act

    Application modernization approaches range from rehosting and refactoring to rearchitecting and replacing, which are progressively costlier and riskier, but also progressively more impactful. Enterprises need to decide what’s best for them based on considerations of effort, cost, risk and result. While some enterprises may go slower than others, eventually they will have to modernize all their applications to be competitive and meet their customers’ needs in the most effective way.

  • The Next Phase of Pandemic Tech Transformation

    The Next Phase of Pandemic Tech Transformation

    Last spring, we were inundated with headlines, tweets and Medium posts applauding the rapid digital transformation that businesses were going through—almost overnight—due to the pandemic and the shift to remote work. It made for an interesting feel-good narrative at the time, but it didn’t paint the full picture. Companies were thrown into the deep end; many barely staying afloat by implementing quick-fix, surface-level changes that they assumed would only be needed for a short time. Turns out, the “transformation” touted was just the tip of the iceberg.

    More than a year later, the workforce is still in flux. The reality is, some form of distributed, hybrid work is likely here to stay. Employees will continue to expect remote options and customers will want seamless, digital ways to interact with businesses, pandemic or not.

    As a result, companies must move past the temporary, band-aid solutions of last year and make those sweeping changes permanent. It’s time to move forward with true, sustainable change: Technical, experiential and, most importantly, cultural. Every company will need to become a modern technology company capable of delivering first-class digital solutions to customers, partners and employees—or risk becoming obsolete.

    Transactional Vs. Transformational Change

    The good news is just about every company understands the value of leveraging technology. A recent 2021 State of the CIO survey found that 82% of CIOs said they implemented new technologies, new IT strategies and/or new methodologies over the past year. The issue is how companies go about their technology deployments.

    People talk about digital transformation all the time, but it’s been used so much that it has become an unhelpful misnomer. More often than not, the change that companies are implementing isn’t truly transformational, but rather transactional or just slightly incremental.

    When companies have a transactional mindset, the focus is on immediate, simple and predictable changes. The purpose—or, more importantly, the outcome—is simply to continue business-as-usual. This is reminiscent of many companies last year turning to technology just to keep the lights on. A transformational mindset, on the other hand, aims to disrupt this business-as-usual and fundamentally change the paradigm in how the company operates through ways of working, use of technology and culture. It’s purposeful, aiming to solve business problems holistically and spur long-term growth.

    To be successful in today’s climate and to gain a competitive edge with customers, companies must strive to be transformation-focused.

    How to Move Toward True Transformation

    Here are three examples of how companies can shift from a transactional mindset to a transformational mindset.

    Cloud Migration vs. Modernization

    Often, when companies talk about their use of cloud, they tout that they’ve “moved to the cloud.” But all too often, it’s treated as a one-time event; a destination to reach and a box to check. At the outset of the pandemic, we saw so many organizations quickly mobilize to shore up their digital strategies and ensure they were thinking about the limitations of doing business in a virtual context, but their cloud strategies didn’t evolve to rethink these paradigms, as well. They simply accelerated their migration strategies to get out of their physical data centers and into the cloud.

    The opportunity to leverage the cloud is so much bigger than that. It can unlock greater efficiency, flexibility and growth and underpin new digital experiences and revenue opportunities—exactly the kind of strategies most companies envision. For example, health care leader InnoCare was struggling with outdated clinic management software. Instead of just moving the old bits to their cloud provider, they adopted a broader digital strategy to modernize their delivery capabilities and reimagine both the patient and clinician experience, setting new industry standards in the process. This is what we refer to as modernization and it is what leads to transformation.

    Software Engineering vs. Product Engineering

    With the rapid growth of software, it’s no surprise that software engineers are in high demand. The U.S. Bureau of Labor Statistics projects that software engineering job openings will grow 22% through 2029. And while software engineers will play an irreplaceable role in helping build innovative solutions, transformational-focused companies know to bring more people under the tent. By combining software engineers with other cross-functional experts who bring a different level of artistry, design and audience understanding, the end result is a more engaging, customer-centric product that evolves and grows over the entirety of its useful lifespan.

    This is exactly what fitness giant Nautilus did. They brought together a team of engineers, data scientists and machine learning experts to help bridge the gap between their equipment manufacturing prowess and their digital experience and software development goals. Collectively, they produced a total platform that integrated hardware, software and data to create a dynamic workout regimen that impressed users and fended off competitors.

    Moving Beyond Proof-of-Concept to Long-Term ROI

    A proof-of-concept (POC) is a rite of passage in the tech world. It’s how a company or team demonstrates that their idea is feasible and can work in a real-world application. But POCs alone are insufficient; they are transaction-minded and don’t focus on achieving lasting business outcomes or generating deeper ROI. Rather, they mostly focus on technical feasibility. The key to upleveling toward transformation is by focusing on the processes, not just the end product. When testing features in a real-world setting, make sure that you’re proactively measuring not just that they work—but that they contribute to business imperatives, meet customer expectations and strategic outcomes. And if they don’t, go back to the drawing board and optimize with those higher-level goals in mind.

    Culture is Key

    As you can see, the difference between a transactional and transformational mindset is more about culture than technology. A culture of innovation and modern ways of working leads to transformation that fundamentally shifts the way technology is conceptualized and created. It isn’t solely about gaining efficiencies or cutting costs—instead, the focus is on making the lives of customers, employees and everyday users better. Transformation-focused companies believe in the promise of technology advancements, but they believe that it also can make operations smoother, customer relationships more meaningful and increase revenue when implemented with the right combination of skills, disciplines and organizational buy-in over time. It’s those companies who will thrive in this new era.

  • 3 Reasons Your Digital Transformation Stalled

    3 Reasons Your Digital Transformation Stalled

    The more a company modernizes, the more value it gets from the cloud, but not all digital transformation efforts are created—and executed—equally. According to Gartner, “87% of senior business leaders say digitalization is a company priority, yet only 40% of organizations have brought digital initiatives to scale … [and] without a shared vision across the organization, digital transformation efforts will continue to stall.”

    CIOs and other senior technology leaders are constantly looking for the best way to lead and scale modernization efforts that positively impact the business and generate the most value from the cloud. Here are three factors to consider to make sure digital transformation efforts don’t start to slow or stall out entirely.

    The Price of Ignoring Technical Debt

    Any CIO should be able to say how much of their development efforts are invested in innovation and how much is going into maintenance. A harder number to take into account is how much their innovation development effort is slowed down by technical debt.

    A good way to gauge this for CIOs—if you can say that your development organization dedicates more than 50% of its effort to innovation and that your development velocity is exactly where it was a couple of years back, then technical debt is not dragging you down. However, chances are that’s not the case.

    Why is that? A major reason is that the vast majority of business applications and business logic still reside on-premises in legacy applications and infrastructure with a once-solid software architecture that is now showing signs of wear.

    The technical debt these applications accumulated takes a toll. It is a ‘tax’ that many CIOs know they need to pay; know what is required, but choose to ignore until it’s too late.

    Many organizations delay modernization because they believe that it reduces the capacity for effort that can be spent on innovation, assuming that legacy maintenance can just carry on as usual. With the potential for a lengthy and risky modernization project, delaying innovation for that length of time is not even an option. The only way to stop ignoring technical debt is to find a way to reduce the risk of modernization and accelerate the modernization project so you can go back to doing what you love about tech: innovating.

    Managing App Modernization as a Tactical Project

    It’s amazing that application modernization is so often viewed as a tactical project—time- and materials-based, cost-focused—versus a strategic imperative driven by business goals. This approach also explains why many projects fail to meet expectations, are half-finished or abandoned or never even get started in the first place.

    The business logic and processes embedded in your legacy application estate are your core intellectual property and competitive advantage, and they need to be treated as such. These applications, and the business processes they encapsulate, require a strategy that continually modernizes them, starting now and continuing into the future. A one-and-done approach is a recipe for disaster and disappointment.

    So be strategic, make sure your modernization plan is aimed at reducing technical debt, restoring velocity and focusing on innovation. Once you get there, make sure you continuously manage your technical debt and keep your velocity high.

    Reliance on Lift and Shift for Cloud Migrations

    Cloud migration projects are most often critical parts of digital transformation initiatives, and yet, many outside advisors or quick-win focused insiders will push for the “easiest” approach.

    A rational plan to transform and modernize your applications for the cloud requires a critical assessment of your application estate to determine which applications should be refactored, lifted and shifted (rehosted or platformed), rewritten or just retired. Skipping this critical step and categorizing the majority of your apps into the “lift and shift” category is a common mistake that too many enterprises later regret. A lift and shift strategy may be fine for a subset of your applications, but for the most important ones it will result in a transfer of your technical debt to the cloud, increase your maintenance costs and take another bite out of your organization’s ability to innovate.

    Digital transformations are getting bogged down by technical debt, tactical decisions and modernization shortcuts. Organizations need to directly address these issues and reduce the significant drag they are incurring on modern transformation initiatives. By attacking them head-on, enterprises can accelerate their cloud migrations, application modernizations and business agility goals.

  • Modernizing Continuous Integration

    Modernizing Continuous Integration

    In the duality of continuous integration/continuous delivery (CI/CD), CI focuses on build automation. Leveraging CI practices for software delivery is normal for most organizations and can be seen as a solved problem. However, the demand for increasingly distributed applications has risen with the expansion of microservices, and development teams have the expectation that every commit should be a build.

    Continuous integration has, surprisingly, become an unexpected bottleneck with these expectations. To begin modernizing CI, it’s important to first understand some of the challenges. Let’s dig in.

    Challenges of Continuous Integration

    Given that build and release candidates follow advancements in development technology closely — such as new languages, packaging and paradigms in testing the artifact — expanding the capabilities in continuous integration implementations can be challenging. With the introduction of containerized technology, the firepower and velocity required to build greatly increased.

    Scaling Continuous Integration Platforms

    The infrastructure required to run a distributed CI platform can be as complex as the applications they are building because of the heavy compute requirements. Consider how much a local machine’s resources are tied up during a local build and test cycle. Now, multiply that by the number of folks on a team or in an organization and you start to understand just how much compute power is being used. Distributed build runners are just one area that can be complex, and managing when new build nodes are spun up and spun down can depend on the platform/end user.

    Keeping Up With the Technology Velocity

    The adage of “the only constant in technology is change” is true. New languages, platforms and paradigms are to be expected as technology pushes forward. The ease of including new technologies in a heterogeneous build or accepting new testing paradigms, however, can be difficult for more rigid CI platforms. These legacy platforms were designed for only a small subset of technologies. With legacy or rigid approaches, the dependency management required to maintain technical velocity becomes a significant burden.

    What it Takes to Modernize Continuous Integration

    The simplest way to change continuous integration practices and platforms is to take what I call the four-pillar approach: platform infrastructure modernization, engineering efficiency strategy, test optimization and rapid pipeline development. Making strides in any of these pillars will put you on the path toward modernizing your continuous integration platforms and practices. Making strides in all of the pillars will set up your DevOps teams for significant success.

    Platform Infrastructure Modernization

    The location where the actual builds and packaging take place (e.g. build nodes/runners) do most of the heavy lifting and have a fairly elastic workload nature. Builds (e.g. a JAVA JAR build) and packaging (e.g. a Docker Image Compose) are compute-heavy tasks. Once the build and packaging are complete, the runners can sit idle. This shows the importance of having an ephemeral build node. The build node spins up during the task, then spins down or is destroyed after the build task is done, so as to not drain resources.

    Engineering Efficiency Strategy

    A core tenet of engineering efficiency is meeting your internal customers where they are. For software engineers, this means being as close to their tools and projects as possible. Like many modern pieces of application infrastructure, shifting left to the developer means being included in the project structure in source code management (SCM).

    A common disconnect in CI platforms is dependency management. Over the past decade, for software engineers, this problem has been solved with package or build tools such as Maven, Gradle and NPM. Engineers need to simply define implicitly or explicitly what they need, and the dependencies will be resolved. Continuous integration tools can suffer from a disconnect, since we are leveraging several tools that potentially don’t have a common syntax. So, again, it’s important developers have close oversight on all the tools they need to complete their projects to reduce this friction.

    Test Optimization

    While initial confidence in getting tests into the CI pipeline expands, more tests — and sometimes inappropriate test coverage — is introduced by the ease of integration with the pipeline. An even harder problem to identify and rectify is flaky tests. A flaky test is one that both passes and fails periodically without any code changes. This becomes a twofold problem: increasing execution time and lack of confidence with flakiness. The most logical solution to avoid these issues is adding test optimization. A modern continuous integration solution should be able to visualize pipeline order, timings and overall execution to help identity (and eventually rectify) excessive coverage and flakiness.

    Rapid Pipeline Development

    Software is an exercise in iteration. The lower the barriers to entry for iteration to occur, the more gains in engineering efficiency and agility are achieved. Local builds happen dozens of times before reaching a committable stage, moving them forward to a dev-integration environment. It’s here where having a local environment is key. Oddly, most continuous integration pipelines are designed to run externally from a local machine. So, the ability to move to a local CI pipeline helps build confidence that the externally run pipeline will be successful.

    Continue on Your Continuous Integration Journey

    Continuous integration might seem like a solved problem for many organizations, but as with any technology, there is always room for improvement and modernization. Like any engineering efficiency paradigm, CI is a journey and the destination ever-evolving.

  • 3 Common App Modernization Pitfalls to Avoid

    3 Common App Modernization Pitfalls to Avoid

    Application modernization has been a consistent theme for organizations year after year. Businesses today still rely on their legacy applications for the majority of their revenue generation, from mainframes to Java EE. New digital transformation initiatives and mandates have pushed application modernization back to the forefront, as a new generation of automation platforms and best practices are helping these organizations avoid the pitfalls of the past and accelerate their journey to cloud-native architectures.

    Here are the three most common application modernization pitfalls and how to avoid them.

    Lack of a Clear Organizational Destination

    Application modernization journeys need a north star – a destination point that development, infrastructure and DevOps teams can rally around. In order to establish a clear, unified direction, everyone must share a precise understanding of that destination. That journey starts by defining a set of business goals you are trying to accomplish (such as cost savings, business agility, resiliency and/or competitive advantage) that can guide and prioritize the technical decisions.

    Next, you need to decide which application modernization technologies, platforms, and infrastructure will help you deliver on those business goals (e.g., Red Hat OpenShift, Kubernetes, serverless, hybrid, private or public cloud, etc.). Setting common architectural standards will help avoid disparate future stacks and ensure a common shared platform for microservices architectures. For example, if an application starts with Java WebSphere, should the goal be to move to a modern container framework like Spring Boot, or a specific microservices Java framework like Quarkus? To avoid analysis paralysis and internal drag, set tangible objectives and targets that prescribe how teams are expected to prioritize, select and modernize these applications and how their progress should be measured, communicated and shared.

    Taking Shortcuts – Don’t Fall For the Old ‘Lift and Shift’

    The more one modernizes, the more value one gets from the cloud – but not all modernization efforts are created equal. For example, ‘lift and shift,’ putting a monolith into a container and application refactoring into microservices are all called “modernization.” But only refactoring allows enterprises to realize the true benefits of the cloud, including elasticity, regained engineering velocity and cost savings. Don’t fall into the quick-and-easy modernization temptation with lift and shift or brute force containerization. You will still have a monolith, in the end; you’ll simply end up paying more and trading one set of monolithic problems for another.

    Not Bringing Everyone Along – No Developer Left Behind

    Modernization is never just about technology. Modernization requires that your team’s processes (for example, agile practices), structure (vertical domain teams as opposed to horizontal teams – UI team, for instance) and skills must all adapt. The organizational culture needs to grow to adopt DevOps and cloud-native best practices to take advantage of the deep development, build, deployment and operational benefits that are available. Take the time to train and educate so everyone is brought along. Modernizing legacy applications can introduce a whole new set of technologists, responsible for those applications and the supporting infrastructure, into the cloud-native world. This is a win-win for everyone.

    In other words, the organization needs to have crystal clear answers to the where (destination), why (path) and how (team) to ensure success and avoid the three most common pitfalls of application modernization.

  • Set DevOps Free With Modern Application Security

    Set DevOps Free With Modern Application Security

    Development teams increasingly use technologies like cloud computing and microservices, in conjunction with DevOps principles, to innovate faster and remain competitive.

    But such progress comes at a cost. The fast pace of DevOps has left security teams scrambling to keep pace and install appropriate security guardrails. Traditional security practices used to occur in the final stages before release. The rapid release cycles of agile software development often make this difficult, if not impossible.

    The speed of development is outpacing the rate at which security teams can check configurations and scan for vulnerabilities, especially as developers now outnumber security professionals 500 to 1 and modern application environments represent a vast attack surface.

    The pressure to keep up, and do so securely, has led to a gradual reframing of DevOps as DevSecOps, where security is “shifted left” and introduced earlier in the software development life cycle.

    Unfortunately, while most businesses understand the intent of DevSecOps, they are still unsure how to translate that intent into action. In fact, just 14% fully integrate security throughout the software development life cycle.

    Recent research also shows that, while 65% of security teams report shifting left, less than one fifth are doing the scans necessary to verify that shift is actually happening. The same report suggests that most security teams don’t have the processes in place to monitor and protect cutting-edge application technologies, such as microservices, APIs and cloud native/serverless.

    This lack of visibility leaves security organizations blind when problems surface in production. The longer vulnerabilities go undiscovered in the development cycle, the more costly they are to fix. A study by IBM System Science Institute suggests that fixing a defect found during implementation can cost six times as much as one identified during early design phases. A defect uncovered in production can cost 100 times as much. Even more disturbing, nearly half of enterprises admit to deploying vulnerable applications, just to meet tight deadlines.

    It’s clear that compliance and security oversight are often overlooked, and even deliberately avoided, in favor of faster, more frequent deployments.

    The Great DevOps-DevSecOps Divide

    One of the most significant issues lies with developers’ ingrained perceptions. In the past, teams worked independently, with rigidly scheduled handoffs between distinct phases of development. Security operations (SecOps) teams often introduced security functions during the final stages of the development and release process, which resulted in delays.

    Successfully putting the “Sec” into DevSecOps depends on changing older cultural biases, reinforcing the need to embrace security and empowering teams with the right tools and automation to make smarter decisions without slowing down the entire organization. In essence, DevOps and security teams are all aiming for the same goal – a high-quality, timely product. The difference lies in how they measure and define “high quality” and “timely”.

    The truth is, development won’t be slowing down any time soon. Thirty eight percent of developers now release monthly or faster, and 54% of containers live for five minutes or less. Viewing security as a separate entity bolted onto the code, instead of a key feature that must be embedded end to end, slows down development processes and reduces efficiency.

    Delivering Speed and Security

    The core questions organizations must answer to improve application security are: What makes it easier for DevOps teams and application security teams to collaborate? And what does built-in security really look like?

    For organizations that want to improve their DevOps security, here are some tips:

    • Automate security as much as possible. Invest in security solutions that can be automated and embedded directly into the CI/CD pipeline. This makes it easier to secure applications without sacrificing development speed for the sake of security. Adopting technologies like static code analysis, dynamic analysis and penetration testing reduces risks and alerts developers to potential problems. There will never be enough security professionals to handle all security issues on their own, so use automation whenever possible.
    • Build security as a guardrail, not a gate. Provide appropriate guidance and tooling, so that security becomes a guardrail rather than a gate. For example, ensuring that DevOps teams have access to templated policies enables them to align applications with security requirements from the outset, without adding unnecessary time to development. Applications and security policies can also be tested as part of the CI/CD pipeline, so they are checked like any other functional specification. In short, it’s important to provide developers with everything they need to create and test applications with the appropriate security controls applied, or they won’t do it. Empowering development teams with a better understanding of security and self-service compliance reduces vulnerabilities and risks to the organization. Developers always want to move faster, so make it possible for them to “speed” safely.
    • Enable more proactive responsibility. The average developer cannot be expected to have the level of expertise necessary to stay current with all the latest security trends—they have enough trouble keeping their programming skills up to date. Reduce complexity and make it easier to gain developer buy-in by selecting solutions that provide simplified, easy-to-understand insights within the CI/CD feedback loop.
    • Make security adaptable, scalable and reliable. Secure applications with solutions that offer consistent, centralized and self-service security for any environment. For example, AI-driven security policy engines are one way to enable the adaptability necessary to support rapid change in applications resulting from CI/CD methodologies. Being able to adapt security policies in response to the latest attacks and identify dependencies makes it easier to assess risk and take action faster.

    The dawn of frictionless and adaptable security

    Security can no longer be an afterthought, bolted on to a process. Today, integrated security must become a normal part of any DevOps implementation. Making security frictionless and adaptable enables development teams to power ahead without fear. Modern application security can be a robust support system that empowers organizations to reach their business goals securely.

  • Application Modernization Video with IBM’s Rosalind Radcliffe

    Application Modernization Video with IBM’s Rosalind Radcliffe

    Application modernization is the process of updating existing legacy applications and modernizing their infrastructure, architecture and features, by using modern technology stacks. Monolithic applications are difficult to update and expensive to scale.

    In response to today’s business requirements of growth and innovation, enterprises must deliver new applications in an agile fashion while minimizing risk. Many have turned to a hybrid or multicloud strategy where choice and flexibility are foundational.

    In this interview, Rosalind Radcliffe, distinguished engineer at IBM, explains the benefits of modernizing applications and how IBM provides all essential components to update your legacy applications.

    Rosalind will take a deeper look at application modernization during her session at IBM DevOps Virtual Summit. During the virtual event, attendees will learn how to keep their applications running smoothly with automation and data-driven solutions that can reduce mean time to resolution and explore IBM solutions to help innovate hybrid environments, disrupt cloud native development and transform existing mainframe infrastructures. The free virtual event will take place on Oct. 29 at 10 a.m. ET.

    For more information and to register, please visit the IBM DevOps Virtual Summit website.

  • Accelerate Your Digital Transformation with IBM

    Accelerate Your Digital Transformation with IBM

    DevOps practices, processes and solutions help businesses accelerate their digital transformation by improving the speed and quality of software development. DevOps tools enable teams to do their job more efficiently by embracing automation, increasing agility and building speed, versatility and security into the framework.

    At the IBM DevOps Virtual Summit, attendees will learn how to keep their applications running smoothly with automation and data-driven solutions that can reduce mean time to resolution and explore IBM solutions to help innovate hybrid environments, disrupt cloud native development and transform existing mainframe infrastructures. The free virtual event will take place on Oct. 29 from 10 a.m. to 2 p.m. ET.

    IBM leaders will discuss the benefits of DevSecOps, how to increase business value, SRE best practices and how IBM Cloud software and services can help organizations succeed on their DevOps journey.

    The virtual event will feature four educational sessions from leading DevOps technologists:

    • “Application Modernization Enabling Hybrid Cloud with IBM Z,” by Rosalind Radcliffe, distinguished engineer and chief architect for DevOps at IBM.
    • “The Modern DevOps Manifesto,” by Andrea Crawford, distinguished engineer at IBM.
    • “DevSecOps in a Hybrid Multicloud World,” by Sunil Joshi, executive architect at IBM.
    • “Common Tooling Approaches from Kubernetes to the Mainframe,” by Eric Minick, program director at IBM.

    For more information about the virtual summit or to register, please visit the IBM DevOps Virtual Summit website.

  • 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.

  • How to Modernize Mainframe Applications

    How to Modernize Mainframe Applications

    It’s easy to understand the current disillusionment around the term “digital transformation,” as it has been thrown around vaguely as the ultimate answer to business innovation without much recognition of the nuances of technological change.

    When it comes to mainframe systems, the issue here most likely can be traced back to the word “transformation.” The perceived challenge inherent in the transformation of a vital business process is that it involves a paradigm-shifting, instantaneous “big-bang” overhaul of IT, with no recognition of the complications involved in modernizing a complex web of intertwined systems and data.

    It is this perceived challenge that has seen large enterprises reluctant to change and modernize legacy technology, as the pressure to throw out the old and bring in the new is seen as simply too risky. Horror stories, such as the infamous failed IT upgrade at UK retail bank TSB in 2018, have dampened the spirit of many enterprises to modernize with the perception that a big transformative leap may be required.

    Many businesses seek a solution to this “all or nothing” conundrum and would benefit from modernizing legacy IT in small steps—carefully considering the modernization of infrastructure and applications as separate processes. This more graceful approach delivers gradual benefits while reducing risk and acknowledges that modernization is a continuum, not a destination.

    What is the Reality of a Modernization Process?

    Applications developed to support business requirements are never static; they change along with the business. Modern development environments, infrastructure and DevOps processes have benefited from tremendous innovation in recent years, enabling IT to more rapidly evolve applications to support these changing business requirements.

    There is mounting pressure to integrate mainframe applications, which house critical business processes with these approaches. The aim of this modernization is to enable legacy applications to take advantage of the innovations spearheaded by the modern world of open source—and, therefore, respond more rapidly to the needs of the business. To achieve this, organizations would benefit from a two-phase approach:

    1. Modernizing IT infrastructure: Moving legacy applications, in their original formats, to an environment where they can benefit from the scalability benefits of cloud deployments, exploit open source solutions and significantly reduce cost once legacy systems are replaced.
    2. Modernizing mainframe applications: Rewriting or transcoding into modern languages only those legacy applications or programs that are most in need of modernization, while enabling them to communicate with those still in legacy languages.

    Infrastructure Modernization

    The foundation of infrastructure modernization is the movement of legacy applications, written and compiled to run on the IBM Z mainframe, to the Linux operating environment running on x86 architecture computer, either on-premises or in the cloud. Using conventional methods to re-host these legacy applications into x86/Linux requires all programs that make up a legacy application to be recompiled and, in many cases, changed. This approach has often resulted in budget overruns and a high risk of failure.

    If an organization is able to move these applications and data to a modern environment without the requirement for recompilation or reformatting, this migration risk is significantly reduced.

    Once moved to a Linux environment, and despite remaining in original languages, these applications can now benefit from a vast array of tooling to optimize their ongoing exploitation. They can take advantage of cost-effective scaling options, modern monitoring, high-availability tools and many other facilities available on Linux on x86. For those legacy applications that continue to be maintained, modern development environments are now available, meaning their management is no longer restricted to a diminishing mainframe workforce.

    Application Modernization

    The goal of many companies is to have their entire application portfolio based on modern languages or packages. Where legacy applications are concerned, attaining this means converting the individual programs from COBOL or PL/1 (and, in some cases, even more arcane languages) into modern languages such as Java. In so doing, an organization can tap into much larger pools of development talent and tooling. Furthermore, the door to an entire world of open source innovation is opened, which alters entirely the trajectory of application development for these legacy applications.

    Yet modernizing mainframe applications in this way, using conventional methods, is not a process to be taken lightly.

    Infrastructure vs. Application: The Chicken or the Egg?

    When looking to modernize an application, many organizations question whether to start with the infrastructure or the application itself. The answer is infrastructure.

    Of course, the organization could attempt to first modernize the applications in place. At a glance this method may seem the least disruptive, but very quickly the effort would run into many of the challenges previously highlighted that have caused the mainframe to be abandoned as a contemporary platform for application modernization. Using a modern programming language such as Java is one way to enable modernization with those programs being completely rewritten. With the whole process conducted on a legacy mainframe, costs and resource contention become practical issues. Organizations that run mainframes carefully control access to mainframe resources due to the punitive costs of exceeding licensed capacity; indeed, this resource contention point is another reason for companies to move ongoing development off the mainframe.

    When taken collectively, it is easy to understand how these factors have conspired to thwart most modernization initiatives that choose to modernize applications first. By modernizing the infrastructure first, the issues identified above are circumvented.

    Once mainframe applications and data are re-hosted on modern, open environments on x86, Linux and the cloud, the real process of application modernization, as outlined above, can begin.

    The modernization journey is not easy, but continuing to depend on a declining skill set and diminishing vendor community in the mainframe world is no longer an acceptable alternative. By breaking up the modernization journey into manageable pieces, moving forward over time to the desired end state is the most realistic approach. After all, to quote a Chinese proverb, “A journey of a thousand miles begins with a single step.”

    — Dale Vecchio