February 16, 2022

How banks should leverage the power of automation

Mainframes are widely considered the backbones of many global financial services firms because they deliver unparalleled security, stability, and processing power. From credit card payments and ATM transactions to loans and mortgages, mainframes are relied on by 44 of the top 50 banks to host core applications that deliver secure experiences based on real-time data analytics.

Phase Change President Steve Brothers recently penned an article for TechBullion.com titled, "Banking automation: How banks should leverage the power of automation," in which he examines how these critical mainframes systems also present modernization challenges.

Mainframe systems are complicated and require meticulous processes to continue providing core operational value. While they are fully capable of running newer applications and systems to create new products and revenue streams, their ongoing support and modernization are challenging.

Brothers believes automation and artificial intelligence (AI) could greatly assist banking firms in maintaining and enhancing their mainframes because the key to sustaining these systems is precisely identifying the functionality created by the source code that is intertwined throughout the system — and changing that behavior without unintended consequences. Using a new AI approach that's designed to sift through large quantities of code in the same way humans do, AI-powered tools can aid developers in their frequent search through the deluge of code to rapidly identify where they need to make a change.

Read the entire article here.

Todd Erickson is a Technology Writer with Phase Change. You can reach him at terickson@phasechange.ai.

January 25, 2022

How AI can improve software development

Transforming business operations is a constant need, and the pandemic-prompted emphasis on modernizing legacy computing systems has forced organizations across industries to accelerate their modernization plans. The problem with mainframe modernization, however, is that today’s code search tools, linters, and program analysis tools are deficient when it comes to mitigating the risks associated with improving and even simply maintaining legacy systems.

Phase Change President Steve Brothers recently authored a contributed article for DevOps.com about how artificial intelligence (AI) tools can help developers work more productively and decrease the risks associated with legacy system modernization and maintenance.

The article, "How AI Can Improve Software Development," explains how today's bug localization, code visualization, and error detection tools don't actually identify specific lines of code that require change. And, once the code is identified, developers are still required to build mental models of their applications to make sure any source code changes don't make even more bugs or crash the entire system.

Through intelligence augmentation, AI can automate the identification of specific lines of code that require change – developers simply ask the AI-driven knowledge repository where unwanted behaviors are coming from, and the AI quickly identifies the code associated with that behavior. Also, before the developers compile or check in the new code, the AI can forward simulate the changes and validate that they won't create more problems or break the system.

Read the entire article here.

Todd Erickson is a Technology Writer with Phase Change. You can reach him at terickson@phasechange.ai.

February 24, 2021

Legacy system failures expose the application knowledge gap’s harmful risks

February 24, 2021

by Steve Brothers

Government system failures during the rush to provide public benefits to alleviate the economic effects of the COVID-19 pandemic publicly exposed the mainframe knowledge crisis that also threatens financial institutions, healthcare providers, and many other organizations foundational to the world economy.

Several states discovered the knowledge-gap’s potentially devastating consequences when waves of unemployment-claims poured into their systems as COVID-19 ravaged the economy in early 2020. The states’ unemployment computer systems crashed trying to process the deluge of claims using mainframes and decades-old programming languages.

But it wasn’t the mainframes or the legacy programming languages that failed, despite what you may have read. It was the lack of available expert programmers necessary to maintain and update these systems to handle the voluminous claims.

According to The Verge’s article, “Unemployment checks are being held up by a coding language almost nobody knows,” Colorado employed exactly one full-time programmer to maintain the state’s COBOL system prior to the pandemic. Back then, Colorado processed roughly 2,000 unemployment claims per week. In March and April 2020, that number rocketed to as high as 104,572 claims per week.

Now governments, non-profits, and private organizations are reviewing their systems’ strategies to learn from these mistakes. If your business relies on legacy systems, you probably should keep reading – and schedule some time with your IT people.

Mainframes are cornerstones

Legacy mainframe systems and software bedrock many of our most trusted institutions, including government services, finance and banking, healthcare, and insurance. In a substantial number of cases the expert developers that created and maintained these systems and software are retiring without a supporting workforce to replace them.

Besides the people that make your business run, your software is potentially the most important resource your organization has. Internal applications likely drive your employees' capabilities and productivity. Customer-facing programs attract new customers, close business deals, and increase revenue. New applications and features can open new markets and opportunities.

To maintain and improve your critical applications, your software team relies on individual engineers that developed an expert understanding of your programs through years of experience. They know the applications and all the accumulated system changes and challenges.

When those experienced engineers depart your business, the developers that replace them must acquire the same application knowledge through training, mentorship, and on-the-job programming. This exercise introduces several material business risks.

Learning on the job

Developers new to software applications typically require 6-12 months of on-the-job learning to become productive, depending on the size of the source code base. To become proficient, programmers may need up to 3 years.

Without qualified software developers knowledgeable about your applications, you endanger your business's operations, reputation, and security. You also risk a significant decrease in your software teams' productivity and efficiency.

Consider the monumental task confronting newly hired or transferred IRS developers last March. Congress passed the CARES Act on March 25, 2020, and then Treasury Secretary Steven Mnuchin announced that individual stimulus checks would be mailed in early April.

To assist with the delivery of economic stimulus payments, the new developers were required to immediately start working with the agency's source code base, which, in 2019, was estimated at nearly 20 million lines of code and includes over 60 years of legislative and system changes. As of mid-May 2020, nearly 20 million people had not received their stimulus checks, and some recipients had problems throughout the year.

These engineers didn’t have 6-12 months to become productive. They had to hit the ground running on day one. And without the benefit of weeks or months of training and on-the-job learning, they didn’t have the application knowledge necessary to understand how even simple changes could affect entire applications.

And let's not forget the productivity loss due to the remaining IRS's experienced engineers for training, mentoring, and supervising the new recruits.

What’s your risk?

Your situation may not be as dire as what the IRS faced – for now. But how much time can you really give your new developers to learn the system, and how much productivity can you afford to lose while your experienced programmers train and supervise them?

How much do you trust the developers that have just started working on your critical applications?

How confident will you be when your CEO or Board of Directors asks for assurances that the next customer-facing application update will not result in outages and lost revenue – especially if the update was programmed by a developer you hired just weeks ago?

Your software is a critical part of your organization, especially if you rely on legacy mainframe systems. You must have a plan or tool that keeps the code running and bridges the gap between retiring and departing developers and the people that will replace them.

Steve Brothers is the President of Phase Change Software. You can reach him on LinkedIn or at sbrothers@phasechange.ai.

December 11, 2019

How short-term maintenance practices can double application size in 5 years

December 11, 2019

by Todd Erickson and Elizabeth Richards

Software must evolve to stay effective, which makes application maintenance a persistent and growing obligation, especially for organizations with large, legacy systems.
Changing marketplaces, compliance updates, security patches, hardware improvements, bug fixes, and process updates all drive code changes.

In his book, Building Maintainable Software: Ten Guidelines for Future-Proof Code, Software Improvement Group Co-founder and CTO Tobias Kuipers says that in larger codebases, 15% of the source code is changed each year.

And software maintenance isn't cheap. Kuipers says that some of his clients spend up to 90% of their IT budgets on program upkeep.

A common problem is the technical debt that piles up when the software team doesn't understand the code they are modifying and its system interdependencies. Combine that lack of knowledge with time and resource demands and the team often resorts to short-sighted modification techniques that add code instead of modifying it in place, which only increases the codebase size, complexity, and technical debt.

Maintenance Challenges for Legacy Code

Legacy applications can have massive and complex code bases created by hundreds of developers throughout decades of work. For example, in 2012, The Bank of New York Mellon reported that its core banking system contained 323 million lines of code and 112,500 COBOL programs. With that size and complexity, even an experienced developer can’t know the whole system.

One issue is the lack of useful documentation. A Catholic University of Brazil study found that between 40% to 60% of maintenance activity is studying the software just to understand it, and the impact analysis required to make the changes without breaking functionality.

Updating documentation can shorten time-to-competency, but it's frequently a low-priority task when stakeholders are demanding that bug fixes, security updates, and functionality improvements be completed yesterday.

Another challenge is institutional brain drain. Inevitably, experienced developers depart the software team, and the loss of that expert knowledge extends the amount of time it takes new developers to understand the applications because there are fewer experienced colleagues they can rely on for assistance.

How do software teams cope?

Application change is required but the lack of understanding introduces risk. To decrease immediate costs and risks, developers and managers may choose to use short-sighted strategies.

Don’t touch the black box

One technique programmers use to avoid breaking unmanageable applications is building separate subsystems (Figure 1).


Just copy the whole damn thing

Another tactic is to duplicate the applicable code (Figure 2). Good development practices recommend editing code rather than duplicating it, but if developers don't understand the code they are editing or its interdependencies, they risk breaking the old functionality.

Instead, developers leave the applicable code in the application, but copy it and place the copy in a new location. Then they modify the duplicate code, hopeful that by leaving the original code in place, they won’t break its functionality.


Duplicating code reduces the risk of breaking the application in the short-term but increases maintenance costs and program complexity in the future. By adding 15% to the code base annually, it will double in just 5 years, making maintenance that much more difficult, expensive, and risky.


Conclusion

Companies face a difficult situation when they choose short-terms strategies that avoid immediate cost and risk but end up creating long-term technical debt.

The solution is to ensure that developers understand the code completely to make sound development decisions. However, the speed of business and technical change affords few organizations the time needed to completely understand their applications.

To learn more about how Phase Change's COBOL Colleague helps developers understand complex COBOL-based applications and make changes quickly and confidently, visit Phase Change's product page.

Elizabeth Richards is Phase Change's Director of Business Operations. You can reach her at erichards@phasechange.ai.
Todd Erickson is a Technology Writer with Phase Change. You can reach him at terickson@phasechange.ai.

May 25, 2017

Why is COBOL cool again? – blog

May 25, 2017

by Todd Erickson and Elizabeth Richards

Discover why the recent spotlight on COBOL systems and the shortage of qualified COBOL programmers isn’t due to a lack of qualified engineers, it's due to a lack of knowledge.

At Phase Change, we pay attention to legacy systems and their challenges. So, why was a mainframe language developed in 1959 suddenly the topic of multiple news articles?

Reuters and The New Stack recently published articles about COBOL, an often-overlooked programming language that was developed before John F. Kennedy became the 35th President of the United States.

Organizations like the Department of Veteran Affairs and large financial companies, such as Bank of New York Mellon and Barclays PLC, are examples of the types of institutions that rely on COBOL applications for nearly $3 trillion worth of daily transactions. But they’ve used COBOL for decades, so, that doesn't explain the recent attention.

A little history

The U.S. government developed the common business oriented language (COBOL) in conjunction with Rear Admiral Grace Hopper and a coalition of industry and higher-education envoys. It's simplicity and portability have stood the test of time, and are the main reasons why 50-year-old COBOL applications continue to play a critical role in finance, banking, and government operations. That plus the inertia that characterizes large, critical systems.

It's because the engineers that maintain COBOL-based systems are leaving the workforce, there aren't qualified developers available to replace them, and these institutions are freaking out. The COBOL brain drain is threatening the organizations that economies are built upon.

Brain drain refers to how departing software engineers leave with all of their system and domain knowledge supposedly locked away in their brains. That knowledge is thought to be lost from the organization forever.

The average age of a Cobol programmer is somewhere between 45 and 60 years old and they are retiring. The problem is that few programmers are interested in replacing them, and the availability of COBOL training resources has dropped precipitously because it's just not a cool language anymore.

We won't repeat all of the statistics that show how much COBOL code is still in use and how important those systems are. Read the Reuters and The New Stack articles, which both mirror a series of comprehensive feature articles published by ComputerWorld in 2012. The metrics and themes haven’t changed much.

Basically, these companies have three options to deal with Cobol brain drain, and all involve high risks. First, they can simply replace their COBOL systems with systems built on more modern programming languages. That project took the Commonwealth Bank of Australia 5 years and $749.9 million, which was 30% over budget. The risk associated with implementing such a massive new system has kept most financial institutions from doing it.

Second, they can engage consultants like the Cobol Cowboys, or hire and train new programmers to support their COBOL systems. This option also involves a great amount of risk because companies have to find engineers that have the skills and interest to support COBOL applications, and then hope they can unravel the layers of modifications and system integrations that accrue with five decades of maintenance, usually with little documentation.

Third, they can completely stop modifying core systems that nobody understands, but are too critical to risk changing or replacing. The USDA faced that choice.

It's not a people problem

But from our perspective, the issue is not a human-resources problem. The companies that rely on Cobol-based systems don't lack the right people, they lack the right knowledge.

If the new engineers assigned to work on COBOL-based applications could access the departing developers' system and domain knowledge, or better yet, all of the programming and domain knowledge imbued into the system from prior engineers, imagine how much easier it would be for them to comprehend these complex systems. It would be like having a personal mentor always available — even while the previous engineers are off enjoying retirement.

That's why this is a knowledge problem and not a people problem.

It's a huge opportunity for someone that can reach all of that trapped knowledge and make it easily comprehensible.

Exploiting the knowledge left behind

Phase Change's objective aim is to use our assistive AI technology to unlock all of the trapped programming and domain knowledge – as well as the human intent behind it – inside software applications, no matter which programming languages were used to create them, and make it easy to access that knowledge with natural-language interaction.

Engineers and stakeholders will literally talk to their software applications to reveal the hidden encoded knowledge they require to comprehend the overwhelming scale and complexity resulting from decades of modifications and system mergers, and hundreds of contributing developers.

Unlocking the encoded knowledge that's trapped in COBOL system will give these large institutions the knowledge they need to make informed decisions about their legacy systems.

learn more about our technology

Todd Erickson is a tech writer with Phase Change. You can reach him at terickson@phasechange.ai.
Elizabeth Richards is Phase Change's director of business operations. You can reach her at erichards@phasechange.ai.

April 10, 2017

Prevent software application knowledge from walking out the door – blog

April 10, 2017

by Todd Erickson, Tech Writer

Brain drain is a serious problem facing organizations that use software applications to run their businesses. Learn how you can seal the drain and retain all of the knowledge trapped in your applications.

At the end of every workday, your software development teams walk out the door with all of their knowledge leaving with them. Some of them don’t come back, and that loss of information and expertise, or brain drain, is a growing business problem, especially with IT industry turnover rates hovering between 20-30% annually.

Consider how much knowledge your organization loses when key members of your development team retire or join other companies. Not only do you lose development expertise, but the knowledge your engineers have regarding how your software applications work, such as:

  • How the system is architected
  • The subject-matter expertise used to implement functionality
  • The business considerations that drove product and feature designs
  • How third-party and external systems are integrated

The plight of developing and supporting older and large-scale applications is exacerbated when companies have to scramble to replace retiring software engineers with unqualified replacements. Multiple reports suggest that 10,000 Baby Boomers walk out the corporate door in the U.S. for good every day.

Many of these retirees are the software engineers that developed and maintain the many systems that still run on Cobol and other mainframe programming languages. The impact of losing thousands of mainframe engineers and their vast programming and business knowledge will be widespread. The 240 billion lines of Cobol code running today power approximately 85 percent of all daily business transactions worldwide.

Most organizations don't have the processes in place to capture their employees' business and system intelligence before they leave for good.

It’s especially difficult for engineers. Today’s software tools don't allow them to easily convey their expertise to others – or enable developers, business managers, and executives to easily discover and utilize any previously shared knowledge.

What can you do?

You might be surprised to discover that your engineers’ domain and system knowledge already resides in one other place outside their minds – your software. While creating the code, development teams pour their organization, programming, and business intelligence into your applications.

Imagine what you could do if your organization's technical and business stakeholders had access to all of the knowledge and human intent embedded in your software applications. Imagine asking your software application how it works and having it answer you back.

How can you unlock all of that untapped knowledge?

Liberate encoded knowledge

Phase Change Software is creating AI-assistive technology that unlocks the encoded knowledge embedded in your software applications.

Our assistive AI understands your software and turns it into formal units of knowledge. In essence, software is transformed into data.

Our AI assistant will liberate your software's hidden knowledge and help it understand itself. Our natural language processing (NLP) techniques will enable your technical and business stakeholders to easily interact with applications.

You will soon be able to literally have a conversation with your software, and have it teach you its encoded programming, business, and domain knowledge.

learn more about our technology

 

 

Todd Erickson is a tech writer with Phase Change Software. You can reach him at terickson@phasechange.ai.

Contact

651 Corporate Circle
Suite 209A
Golden, Colorado 80401
Phone: +1.303.586.8900
Email: info@phasechange.ai

© 2024 Phase Change Software, LLC