5 Myths About Legacy Modernization

Myth 1: Legacy applications are dinosaurs that just need to be replaced.

There seems to be a cult of modernity surrounding software, but in other areas of life we like to say “They don’t build ’em like they used to.” The truth is probably somewhere in between. Old houses and old furniture are often of superior quality not because the skills of craftsmen have since declined, but because it is the good things that we keep. An inferior piece of furniture became firewood, but something really good survived to become an antique. The same is true with legacy software. Unimportant or poorly designed applications were likely discarded years ago. The applications that survived long enough to become legacy applications are central to operations and contain decades worth of vital business logic. These are heirlooms left by a previous generation, but if we want them to be functional–not metaphorical museum pieces–we may need to replace the knobs and oil the hinges.

Myth 2: Modern programming languages can’t handle batch processing.

Just as many believe legacy applications aren’t good for anything, there are also a lot of legacy programmers who don’t believe it is possible for modern languages to handle batch processing as well the legacy applications that were purpose built for such functions. The truth is, until quite recently, they were right. But starting in 2009 with the release of Spring Batch, a number of lightweight frameworks became available that brought the reliability, robustness, and functionality of legacy batch processing to Java environments. At Blu Age, we have developed an open-source solution that brings this functionality to .NET environments as well.

Request a demo.

Myth 3: Legacy modernization takes years before you see results.

Okay. Okay. It’s not fast, but it can be made faster and it can be structured so that it allows for incremental results. Modern tooling automates the modernization process, increasing speed. Furthermore, at Blu Age the first step to any modernization process (perhaps after the initial proof-of-concept) is to analyze the overall code environment to plan an incremental approach. With an incremental approach, supported by modern tooling, you get results in weeks or months, not years. Your budget can be broken down into discrete projects instead of having to allocate for multiyear expenditures.

Myth 4: Legacy modernization is too expensive.

Well, it’s true, it’s not exactly cheap, and if it is, the result will probably be something like JOBOL, i.e. modern code like Java that still retains the legacy or procedural flair of the old code like COBOL. But the real question is: what is not modernizing costing you? Each time you kick the can down the road, your firm’s technical debt increases. You may be able to wrap your COBOL and get it to the cloud, but will it be ready to integrate with the next step in your company’s digital transformation?

It is also important to remember that modern toolchain approaches not only increase the speed of the process, but also reduces cost.

Myth 5: Legacy modernization projects always fail.

So this is the big one, and, unfortunately, there are a lot of statistics to back it up. The key here is to plan your project to minimize the risk of failure. Long multiyear projects often fail, because financial priorities change in the meantime and big line items with no results to speak for them often get axed during lean budget periods. Moreover, big multiyear projects are an integration nightmare. An incremental approach breaks large projects down into smaller units and breaks these units down into unique iterations which are integrated and tested continuously to insure functional equivalence throughout the process, reducing the risk of failure.

A Quick Guide to ADABAS/Natural Modernization

What are ADABAS and Natural?

ADABAS stands for “adaptable database system.” It was launched in 1971 by Software AG using an inverted index architecture and is thus a nonrelational database system. The system was known for its speed and reliability outliving many of its contemporaries (rival inverted index DBMS Datacom eventually transitioned to a relational architecture.

In 1979 Software AG developed a fourth generation (4GL) application development platform for the ADABAS ecosystem called Natural. Applications utilizing ADABAS as a database are, therefore, often built using Natural. Natural supports both procedural and event-driven programming.

Summer Batch – A New Season for .NET Batch Processing

The Need

The worker’s compensation board for major North American government had a problem.  An early adopter of cloud computing, the organization had begun replacing its legacy systems with web-based solutions based on Microsoft’s .NET framework back in the early 2000s. It replaced its claims system in 2001 and began with its policy administration system in 2015. However, the organization was left with a missing piece; its Case Information System (CIS) was an ancient COBOL relic which remained on the IBM mainframes and had complex functionality that few individuals within the organization could still support. Further complicating the issue was the fact that it required both online and batch processing.

Core Banking Systems

Data held by banks represents one of the world’s most valuable assets, but what use is that data if it is trapped in aging mainframe systems that are unable to meet the demand’s of today’s consumers?

Mainframe systems literally enabled the rise of modern commerce. Their robust batch processing capabilities have allowed unprecedented growth in the financial sector during the last 70 years but now cause challenges for banks trying to scale to meet the demands of a modern banking customer who requires 24/7 realtime access and control of accounts from any device. As fintech disrupters and digital-first banks experiment with blockchain and other innovations of the digital era, established banks are in danger of being left behind. Established banks must modernize their core banking systems if they are to compete in our new digital-first reality.

Knowing your legacy modernization options

Most companies today have a strategy for—or at least some goals surrounding—digital transformation. But as much as a coherent digital strategy is recognized as a necessity in today’s business world, many companies still struggle to achieve their digital goals. One common barrier they face is their dependence on legacy software. Removing this barrier has the potential to accelerate a company’s digital transformation, but it is important to understand that there are a number of options when dealing with legacy applications:

Iterative, Automated, and Incremental – A DevOps Approach to Legacy Modernization with Blu Age

Way back in 2001, a small group of people issued a manifesto that came to revolutionize the world of software development. The principles underpinning this movement, known as agile development included a commitment to the end user, an ability to adapt to changing requirements, frequent delivery, collaborative work environments, results orientation, maintainability, simplicity, and constant improvement.

The secret behind successful modernization projects

Migrating applications from aging programming environments (e.g., Cobol, Pacbase, etc.) to modern Cloud-ready technologies (Java EE, .NET…) is a challenging task both at functional and technical levels. Unlike classical software projects -usually initiated from scratch- modernization projects start with millions of lines of code to be explored, understood and transformed.

Functional Equivalent Modernization of Legacy Applications

Technology is evolving at an exponential speed. So do applications, code and the complexity of IT legacy. Maintenance costs for legacy applications are constantly increasing, and require rarefying IT skills. Modernizing business strategic applications, freeing them from aging technologies and opening the way to new functionalities and Digital is now key to sustainable growth.

Blu Age Community

The Blu Age® Community
Application modernization & Generation

bluage.com

Categories

Archives

About

All trademarks and registered trademarks referreded in this website are the exclusive property of their respective owners.
MDA, UML and MDD are either registered trademarks or trademarks of OMG, Inc. in the United States and/or other countries.