devopsy.kinsta.cloud

Tag: application modernization

  • BMC Adds More Tools to Modernize Mainframe Applications

    BMC Adds More Tools to Modernize Mainframe Applications

    BMC this week added a BMC AMI DevX Code Insights tool that makes use of machine learning algorithms to break apart monolithic COBOL mainframe applications into subprograms that are easier to update and refactor.

    In addition, BMC is now making available BMC AMI zAdviser Enterprise, a commercial instance of a previously announced free tool that uses machine learning algorithms to collect telemetry data from mainframe applications. The commercial version of the tool adds a dashboard built and maintained by BMC that makes it simpler to consume that data.

    John McKenny, senior vice president and general manager of Intelligent Z Optimization and Transformation at BMC, said BMC AMI DevX Code Insights visually maps a mainframe application to analyze data flow and debug applications made up of millions of lines of code in real-time that would otherwise be too complex to unravel. Armed with the insights gained, IT teams can then isolate business logic, refactor subprograms, add application programming interfaces (APIs) or remove dead code as they see fit, he added.

    BMC AMI DevX Code Insights also makes it simpler for organizations to onboard new developers to a project at a time when many of the original developers of COBOL applications are retiring, said McKenny.

    In the coming year, BMC is also committed to adding generative artificial intelligence (AI) tools to its portfolio for reengineering mainframe applications, added McKenny. Those tools, for example, will make it simpler to create documentation for legacy applications, he noted.

    It’s not clear how quickly organizations that have mainframes are looking to re-engineer applications, but as more of them adopt DevOps best practices, they are being updated more frequently. The less monolithic the application, the simpler that task becomes. The issue is that mainframes tend to run large applications that access large amounts of data, so many IT teams are naturally fearful of breaking them if they are reengineered, noted McKenny.

    While there is no doubt that the process of reengineering applications will become more automated in the years ahead, software engineers will still be needed to manage the overall process, said McKenny. The role of the software engineer will undoubtedly evolve, but it’s not likely software development and deployment will be wholly automated any time soon, he noted.

    In the meantime, IT organizations that manage mainframes continue to embrace DevOps best practices to varying degrees. There may be some applications that they continue to build and deploy using waterfall methodologies, but as mainframe applications become integrated into digital business workflows, the need to update them faster becomes more apparent.

    The challenge, as always, is not only providing IT teams with the tools to make that transition but also navigating the cultural issues that inevitably arise any time a change of this magnitude is made to the software development life cycle (SDLC). Regardless of the approach, the building and maintenance of mainframe applications are evolving. The only issue that remains to be resolved is finding ways to reduce the level of friction that transition creates as quickly as possible.

  • Application Modernization: A Catalyst for Fixing Sub-Optimal UX

    Application Modernization: A Catalyst for Fixing Sub-Optimal UX

    Today, some of the biggest government programs in existence are Medicare and Medicaid with the two health care insurance providers serving over 43% of the U.S. population. The Centers for Medicare and Medicaid (CMS) spent $1.6 trillion in 2021 and continue to grow in both size and cost on an annual basis. With this type of investment and permeation into the American populace, one would assume that this program would be running on the most up-to-date applications available. However, both public and private health care insurance carriers continue to operate on legacy systems.

    Recently, Andrea Fletcher, the digital services director of the CMS, described their system as operating on technology from the 1960s, which is alarming considering the responsibilities of the program. In fact, the Biden administration has only recently announced plans to modernize their organ matching system. This announcement came from a study conducted in February, which showed that only 26% of organs were procured from donors on average. This is just one example of how efforts to improve legacy systems, which are currently being used by over 40% of the population, allow both public and private organizations to operate in a more efficient manner as well as satisfy user needs. Further exploration will show how modernization improves other areas of business, such as creating user experiences that are both easier to navigate and more personalized as well as the ability to incorporate the latest cybersecurity updates.

    Modernizing as a Means to Improve User Accessibility and Personalization

    Given the size and diversity of the United States population, a modern flexible system is necessary for creating a smooth user experience for every individual. Today, users connect with insurance carriers using a variety of different devices while communicating using different languages and possessing different levels of technical expertise. The ability to create a personalized user experience for each individual will require a level of modernization that legacy systems were not built for. The importance of this flexibility is accentuated when considering that the purpose of Medicare and Medicaid, in particular, is to serve the elderly and underprivileged.

    Prioritizing the modernization of the consumer experience is not limited to just government organizations. In an independent survey conducted by Evolveware, 46% of private organizations measure the success of their application modernization efforts through an expected improvement in customer experience. As health care insurers continue to rely more heavily on analytics and the population continues to adopt digital technologies, the process of creating a streamlined and targeted approach to purchasing and managing health care becomes essential to staying competitive. For a multitude of companies in the marketplace, having an agile system that can be customized to each individual user can be a major differentiator, especially given the variety of factors that each individual has when it comes to making decisions about their health. Moreover, by prioritizing the user experience, organizations can improve their brand loyalty and customer retention, which are key factors when dealing with a competitive marketplace with a lot of players. Insurers have recognized this, as a recent survey of CIOs by Gartner showed that improving the customer experience and application modernization were listed as the highest priorities in the insurance industry. As customers become more judicious with their money due to current macroeconomic trends, providers will need to make sure their platforms’ user experiences are on par with their competitors.

    Modernization to Mitigate the Impact of Hidden Costs and Security Vulnerabilities

    The costs of not updating legacy systems should also be taken into consideration when making the decision to modernize. While the expense and process of moving away from legacy systems can seem like a significant obstacle, these systems, due to on-site maintenance and operational costs, are already expensive to maintain on a continuous basis. In fact, health care IT teams spend around 60% of their time trying to maintain and manage legacy systems. Furthermore, the opportunity cost of IT teams focusing on maintenance over innovation is significant, especially given the potential of the latest technologies to deliver a more intuitive user experience. There is also an understated but pressing labor cost with legacy systems, as members of the workforce who are familiar with these systems are aging and retiring, and the replacement workforce is not well-versed in legacy languages and technologies.

    Finally, legacy systems can also contain blind spots that are prime targets for cybersecurity breaches and hacks today. Legacy applications were built at a time when these types of attacks were not common and, therefore, don’t have the most up-to-date security capabilities embedded. Many of these systems also do not have up-to-date documentation, resulting in a high potential for hidden vulnerabilities. For health care organizations that have access to sensitive data, understanding and then shoring up these vulnerabilities using modern security features is critical.

    Health Care Modernization Example: Chatbots

    One prominent example of how application modernization can lead to organizational success is the integration of chatbots. As technology expands and businesses identify new ways to reach consumers, the addition of chatbots has become more prominent on platforms across industries. For the health care insurance industry, the bots provide both a cost-efficient way to process insurance claims as well as an enhanced user experience through ease of use. Recent estimations show that bots can handle the workload of two to five claims processors and can deliver 20 times the production relative to cost, allowing industry employees to focus on less tedious and more innovative tasks. Using generative AI models, chatbots will continue to become more sophisticated and varied in their responses to user input. As a result, modernizing legacy systems to optimize the integration of these bots becomes integral to remaining competitive in the marketplace.

    Legacy Systems and the Future

    As we look to the future, both government and private insurance carriers have plenty of internal and external factors that incentivize application modernization. As Medicare and Medicaid continue to grow due to the increasing number of eligible users, an agile system is integral for user accessibility. Meanwhile, macroeconomic factors such as high costs and an increasingly competitive marketplace will force private organizations to adopt systems that can integrate and adapt to the newest technologies for a better and more secure customer experience. With serious challenges facing both the public and private sectors of healthcare insurance, the necessity to modernize has never been greater.

  • Grafana Labs Delivers Open Source Code Profiling Tool

    Grafana Labs Delivers Open Source Code Profiling Tool

    Grafana Labs this week released version 1.0 of an open source tool that collects data about an application’s code to aid debugging, troubleshooting and optimization efforts. The tool makes it simpler to identify the specific lines of code driving a process or task within an application.

    Ryan Perry, engineering director for Pyroscope at Grafana Labs, said Grafana Pyroscope 1.0 combines a tool acquired last year from a company he led with Grafana Phlare, a code profiling tool that Grafana Labs previously developed. The combination of the two tools provides a more precise code-tracking capability with an underlying database that is designed to scale horizontally, he added.

    For example, Grafana Pyroscope 1.0, which supports extended Berkeley Packet Filtering (eBPF) running on Linux systems, can now ingest, store and query workloads from any project of any size. Grafana Pyroscope 1.0 has already been used to profile more than 50,000 application instances at a rate of more than 6,000 unique profiles per second.

    The code profiling tool was added to Grafana Cloud Profiles, the hosted continuous profiling tool that Grafana makes available as a service, earlier this month.

    While the primary use case for Grafana Pyroscope is to troubleshoot applications, organizations are also using it to identify and then remove dead code within an application as part of a larger application modernization initiative, noted Perry. As updates to applications are made over several years, organizations frequently find that subsets of the application code are no longer needed, said Perry.

    The goal going forward is to add support for features such as flame graphs in GitHub pull requests, canary deployments, profile-guided optimization (PGO), integrating profiling with load testing tools such as Grafana k6 and integration with visual editors such as VS Code.

    In addition, Grafana Labs is committed to working with the OpenTelemetry project led by the Cloud Native Computing Foundation (CNCF) to ensure Grafana Pyroscope remains aligned with the OpenTelemtry effort to develop an OTel-native profiling tool. Grafana Pyroscope 1.0 will provide the ability to ingest data from that tool and contribute client-side instrumentation capabilities the company has developed.

    Grafana Labs is also working toward improving client-side software development kits (SDKs) to add more real-time agent management features, such as sampling controls, ad hoc profiling capabilities and alternative instrumentation options.

    Finally, Grafana Labs plans to improve eBPF integration for languages such as Python, Java and .NET.

    DevOps teams naturally spend a lot of time trying to optimize application performance and troubleshooting issues that arise long after an application is initially deployed. Code profiling tools are emerging as a tool that makes it much simpler to aggregate metrics, logs and traces and surface actionable insights that make debugging and troubleshooting applications much less tedious. The challenge is finding the time to identify and proactively address potential issues before they become another incident to manage.

  • Google Adds App Modernization Tools to Generative AI Platform

    Google Adds App Modernization Tools to Generative AI Platform

    Google this week added automated refactoring capabilities to the generative artificial intelligence (AI) tools it makes available to write code on Google Cloud.

    In addition, Duet AI for Google Cloud is now integrated with Google’s Apigee API Management and Application Integration services. This makes it possible to design, create and publish application programming interfaces (APIs) using simple natural language prompts.

    These additions to the preview of Duet AI for Google Cloud were announced at the Google Cloud Next 2023 conference and are scheduled to be generally available later this year. The new capabilities promise to reduce the time and effort required to modernize applications.

    For example, DevOps teams can now convert code written in C++ into Go and migrate that application to Cloud SQL, the managed relational database service that Google provides. Via a natural language interface, these tasks are launched via a prompt from directly within a development environment.

    Priyanka Vergadia, a developer advocate for Google, told attendees these capabilities will reduce the need to rely on consultants to migrate applications and take up much less time. In addition, the overall quality of the code should improve using large language models (LLMs) that have been trained using code written by Google developers and best practices defined by Google software engineers.

    Organizations will save time and effort because the need for developers to understand how existing application code was constructed is eliminated, she noted.

    Google has also started to work with select enterprise IT teams to allow Duet AI to incorporate knowledge from their libraries and codebases to generate more context-aware code suggestions.

    In addition to writing code, Google is making a case for also using Duet AI in Google Cloud to monitor performance and troubleshoot IT issues by identifying correlations across application environments. For example, natural language prompts can be translated into PromQL queries to analyze time-series metrics. Duet AI can also provide intuitive explanations of complex log entries in Logs Explorer for easier root-cause analysis and provide suggestions for how to fix issues that surfaced in an error reporting tool.

    Duet AI is also incorporated into the Google BigQuery service to help developers write SQL and Python code to access and analyze data. It can generate full functions and code blocks, auto-suggest code completions and explain your code and SQL queries. Via a single SQL statement, a query can connect tables with the foundational AI models Google makes available via its Vertex AI service.

    At the same time, IT teams can optimize prompts using BigQuery Studio tools, perform text analysis or generate new attributes to enrich a BigQuery data model. Duet AI also enables IT teams to generate vector embeddings in BigQuery to create semantic searches and recommendation queries.

    It’s not clear whether generative AI capabilities will automate entire DevOps and DataOps workflows just yet, but many of the tasks that once required automation scripts will soon be automated by AI models embedded within DevOps platforms. The challenge and the opportunity is to determine how to make those capabilities available to drive DevOps workflows at unprecedented scale.

  • IBM Previews Generative AI Tool for Converting COBOL to Java

    IBM Previews Generative AI Tool for Converting COBOL to Java

    IBM this week announced it will preview a generative artificial intelligence (AI) tool for converting COBOL code running on mainframes into Java. The preview will be available next month during IBM’s TechXchange learning event, IBM said.

    Kyle Charlet, CTO for Z software at IBM, said watsonx Code Assistant for Z makes use of large language models (LLMs) that IBM has trained to both convert and optimize Java code for z/OS running on IBM mainframes.

    Rather than converting COBOL into Java code line for line, the watsonx Code Assistant for Z improves the syntax of Java code generated using object-oriented techniques, he noted.

    IBM’s watsonx.ai code model, which will have knowledge of 115 coding languages, is based on 20 billion parameters that will eventually be applied to other programming languages such as PL/1, added Charlet.

    That model is the same core LLM that IBM used to create Red Hat Ansible Lightspeed, a tool to generate code for an IT automation framework that is scheduled for release later this year. In the future, IBM will also most likely employ generative AI to convert REXX code into Ansible code, said Charlet.

    IBM expects the final offering will combine generative AI tools with its existing Application Discovery and Delivery Intelligence (ADDI) inventory and analysis tool to streamline the modernization of legacy mainframe applications.

    The goal, however, is not to move COBOL applications off the mainframe. Java applications created using watsonx Code Assistant for Z will still call the same data sources, such as an IMS database or CICS transaction processing system, as the original COBOL application.

    That approach will make mainframes more accessible to a wider pool of developers that know Java, which should increase the overall pace of innovation for application development, noted Charlet.

    There are billions of lines of COBOL code currently running on mainframes that, in one way or another, need to be modernized as the pool of developers that know COBOL continues to shrink. Generative AI will make it easier to quickly assess, update, validate and test code, which should accelerate code conversion efforts that otherwise would take years to complete, said Charlet.

    It’s not clear how quickly organizations might move to modernize COBOL applications, but as the time and effort to do so decreases, so should the cost of modernizing legacy code. Most organizations still running z/OS on mainframes are committed to the platform, but if they can transition to Java, the overall cost of building and maintaining mainframe applications should decline.

    In the meantime, it’s not likely that AI will replace developers. IBM recommends that developers further optimize the Java code generated by watsonx Code Assistant for Z.

    Most developers are already using some form of AI to accelerate application development. The next wave of AI will see more widespread use of LLMs that are optimized for specific tasks and that generate more reliable results. After all, the quality of any output from an AI model is always directly related to the quality of the data used to train it. The narrower the set of vetted data, the more trustworthy the AI becomes—the opportunity for erroneous data to create AI hallucinations is a whole lot less than any general-purpose AI model could achieve with customization.

  • Technical Debt? No Sweat!

    Technical Debt? No Sweat!

    As a product manager, I dread the moment a developer says, “Wait a minute; I need to refactor …” (I wish it was just a minute). Something that should take two days starts taking three days and then a week. Over an application’s lifetime, the app starts accumulating technical debt. At that point, innovations become a smaller and smaller percentage of the work due to the vast efforts invested in the extra time required to support new developments.

    It is okay and natural to get into technical debt. As in finance, some people will take out loans to invest in something because they know that later they will be able to sell it for a higher price and pay off the loan with ease. Same with code. You take on technical debt because you want to develop the application faster and get the product or updates out as soon as possible. But in the end, the technical debt has to get paid. This creates friction between R&D and product, and although we both understand at some point that modernization is needed, it is difficult for the team to quantify. Due to all the long cycles, the complex QA, the increasing number of bugs and security issues, engineers start to feel frustrated. And as a product manager, I also feel frustrated when dealing with missed deadlines and inflated estimations.

    It’s not that we don’t want the developers to be happy and to invest in the code (and, let’s face it, in their own mental health, too), but we never know how much time and money is actually spent on technical debt versus how much is reallocated to innovation. For me, that was always a big question, but I never managed to move the conversation from, “I have a feeling,” or “The code looks ugly …” to “For every $1.00 I invest, X% is dedicated to maintenance.” How do we stop guessing and feeling we are in debt and actually start measuring it? And once we make technical debt tangible, when and where do we start modernizing?

    Every application’s innovation cost is affected by its level of technical debt. It’s important to determine how much money invested in the application is put toward innovation and how much is used to repay technical debt. In addition, there are classes of debt that add more complexity and risk overall.

    The newest versions of a monolithic application’s framework can be tagged as modern, aging or unknown (if the jar file isn’t found). This adds another layer of information when deciding what a modernization effort would entail and helps you focus first on aging frameworks that pose the greatest risk to enterprises due to the accumulation of technical debt and security concerns.

    Complexity, Risk and Debt

    The complexity of an application is determined by the degree to which class dependencies are entangled, reducing the level of modularity. A code risk relates to the length of the dependencies: How might a change in the application affect some of its seemingly unrelated components?

    These two metrics affect the architects’ ability to decouple functionality and create independent, isolated microservices in the future. At the end of the day, that is what forms the overall technical debt. Using the average of these three metrics, we can further prioritize applications in the portfolio. This provides insights into immediately actionable areas, such as our next metric.

    The process of modernizing takes time and money and, unfortunately, is a high-risk and often unsuccessful project. To make this process successful, it is first necessary to understand the cost of innovation, the complexity of the application and the risks involved. With these metrics at their disposal, R&D and product are well positioned for a comprehensive, data-driven conversation about modernization.

  • Survey Surfaces Application Modernization Challenges

    Survey Surfaces Application Modernization Challenges

    A survey of senior IT leaders suggested the level of confidence in application modernization projects that many organizations initially had is now starting to wane.

    The survey polled 200 senior IT leaders at organizations with more 1,000 employees and was conducted by Global Surveyz Research on behalf of EvolveWare, a provider of platform for automating application modernization processes. The survey found 70% of respondents reported they were confident or very confident in their understanding of their applications when they prepared for modernization. However, that level of confidence dropped to 41% at the planning stage and even lower (28%) at the point the project began, the survey found.

    More than half of respondents (51%) are already experiencing or anticipating critical issues that need to be addressed immediately, the survey found. The top areas of importance are understanding the parts of the code that contain business policies (47%), database access details (43%) and understanding the complexity (40%).

    EvolveWare CEO Miten Marfatia said the survey makes it clear organizations are encountering issues associated with capturing tribal knowledge that has been lost mainly because the teams that initially built an application are no longer with an organization. In fact, the survey found a full 81% of respondents reported they currently have or anticipate challenges hiring or retaining talent to support legacy applications. Nearly half (46%) currently don’t have enough talent available to manage legacy applications.

    The survey found the primary reason these initiatives are launched is to boost employee productivity (40%), followed by retiring mainframe infrastructure (37%), reducing the dependency on legacy code (36%), reducing maintenance costs (30%), improving customer experience (29%) and cloud migration (22%). Most of these projects are generally focused on critical applications (55%) as well as applications that have few or no dependencies (55%), the survey finds.

    The primary success metrics for assessing these projects, however, are improving customer experience (46%), the readiness to migrate to the cloud (46%) and meeting the performance requirements of the modernized application (45%).

    Less than a third of respondents (31%), however, reported having access to modern tooling. More than half would like to automate code transformation and business rules extraction (BRE) while 40% would like to automate documentation.

    Nearly two-thirds (64%) said freezing code during the modernization process would have significant business and financial consequences, with 59% noting that finding a way to modernize applications without freezing code is at the top of their technology wish list.

    Application modernization efforts usually have multiple goals. IT teams are usually motivated by a desire to reduce the amount of time and effort required to support legacy applications that are generally less efficient than modern applications. In addition, many IT teams are also looking for ways to reduce the total cost of running those applications, especially during uncertain economic times. Business leaders, meanwhile, are funding digital business transformation initiatives that typically require some level of modernization of legacy applications.

    Regardless of motivation, it’s apparent many IT teams initially underestimate the amount of effort required to achieve those goals.

  • Organizations Prioritizing Java Application Modernization

    Organizations Prioritizing Java Application Modernization

    A survey found that modernizing existing Java applications is a higher priority than other projects for 87% of respondents, with more than 80% of these applications expected to be re-engineered over the next five years. The survey polled 450 IT professionals working in organizations in the U.S. and United Kingdom that have more than 500 employees.

    Conducted by the market research firm Vanson Bourne on behalf of Diffblue, a provider of a generative artificial intelligence (AI) platform for refactoring applications and generating unit tests, the survey also found enterprises plan to invest nearly half (45%) of their software development resources on modernization of existing applications versus developing new ones. A full 90% of respondents expected to rely on automation to accomplish those tasks, the survey found.

    Specifically, survey respondents reported they planned to rely on automation to improve security (50%), increase development velocity (45%) and improve developer experience (42%). Well over half of respondents (58%) said they had already been working on these projects for more than 12 months.

    If organizations don’t modernize Java applications, more than half of respondents (51%) said too much time would be spent on unproductive coding, while 50% said development velocity would be adversely affected. The biggest obstacles cited are choosing the right technical approach (45%) and securing budget (42%).

    More than half of organizations (59%) have created a dedicated modernization budget to support their efforts. Nealy half (48%) said funds are being provided by business teams for projects, while 49% said general operating budgets have increased.

    Diffblue CEO Matthew Lodge said it’s clear there is a huge commitment to application modernization. The reality is the majority of work IT teams do involves applications that have already been deployed. The challenge they face is that the effort required to modernize these applications is still far too dependent on manual processes, he added.

    Overall, the survey found 96% of respondents considered Java applications extremely or very important to their organizations. On average, 65% reported additional Java applications are still being developed. Only 4% said they planned to migrate away from Java as part of a modernization effort.

    Over half of the respondents expected to use Java 11 (53%) or Java 17 (56%) in their applications, compared to 19% using Java 8. More than a quarter (27%) expected to use a forthcoming Java 21 release. A full 100% expected to use the Spring framework to build these applications, with more than half (54%) planning to upgrade to the latest version that supports Java 17. A full 97% said unit testing is an “extremely” or “very important” element of their application modernization effort.

    After experiencing something akin to a mid-life crisis, Java has itself been modernized with the release of Java 17, noted Lodge. The Java community is now adopting many concepts that may have been pioneered in other programming languages, he added.

    Regardless of whether organizations are modernizing existing Java applications or writing new ones, the one thing that appears certain is the venerable programming language isn’t about to disappear any time soon.