carloscastilla - Fotolia
Application modernization can be a time-consuming and costly initiative, but ultimately, it also can slash expenses and streamline tasks. Integration problems and mismatched skills are typical of the challenges legacy infrastructure can present, said Rick Oppedisano, vice president of global research and development and marketing at Modern Systems Corp., headquartered in Seattle.
By submitting your personal information, you agree that TechTarget and its partners may contact you regarding relevant content, products and special offers.
How does an organization know it's time to deal with its legacy infrastructure and engage in an application modernization project? There is no clear-cut answer, Oppedisano said. However, common factors come into play.
In this interview, Oppedisano offers advice for pinpointing common modernization project barriers and updating legacy infrastructure.
What are some common legacy system challenges?
Rick Oppedisano: The first one is integration. We know that [certain] legacy applications -- for example, [those] written in COBOL and some Natural dialects -- don't always play nice with others. If you want to integrate a BI or analytics solution, it will be a challenge simply because those new technologies weren't written in 3GL/4GL languages. Companies with core applications running legacy codebases also experience visibility challenges pertaining to business logic and technical inventory. This makes it hard to develop new features quickly, or create reports on the fly. These core applications are handling a huge part of the business, but they can hold business back.
The skills issue is well-publicized. College graduates in computer science no longer know COBOL; it's not in the curriculum. The Baby Boomers are retiring and there is a lack of people with these skill sets.
How do you know it's time for infrastructure modernization?
Oppedisano: The answer will be different for everybody. A year or two ago, it would be all about cost savings. Companies saw infrastructure modernization as a legitimate cost-savings option. Today it's more than that. Companies are using agile development techniques like DevOps to increase efficiency and bring new products to market faster. They're leaving non-relational databases behind, using data warehousing to get more intelligence from core applications.
In the past year or so, we've seen 10 to 15 businesses all of a sudden do legacy modernization. Everyone is doing the cloud, big data and collaboration. Companies are looking for something new to increase competitive advantage and save money. Many have latched on to modernization as the next big thing.
What are some common mistakes made in app modernization projects?
Oppedisano: The first mistake is not understanding and having full visibility into what the legacy system entails. The problem is that these legacy systems aren't connected to other legacy systems [or] applications throughout the company.
The next big mistake is how you perform testing. There is a lot of need for testing tools out there, but in reality these applications have been written with a great deal of specificity for the business. If they were easy to convert, or you could buy something off the shelf that had the same capability, people would have done it. No one knows these applications better than the customer. There are times when the customer will say they want us to do the testing, write the test cases, or say they will get one source internally to write the test cases. That is a big mistake because we'll never know the business as well as they do.
Another mistake is having one resource or group of people write the test cases. That is a misstep because you know that if these things have been around for a while they are pretty far-reaching. Does that resource or group have the knowledge and organizational pull to flesh out these use cases worldwide?
The last mistake is thinking you have to go all in. A lot of businesses have the mindset that they want to go from COBOL to Java and they want to do it in a year or two, but it's risky. People just tend to think that is the way to do it, but there are alternatives.
For customers who want to go big with a more comprehensive strategy, that is when you look at re-platforming. Mainframe rehosting is the act of taking the code envelope and wrapping it around the legacy applications that's COBOL and putting it on an open system like OpenStack. It allows you to modernize the database and the infrastructure, but it leaves the legacy application in place so the customer doesn't have to change its support model or hire new people.
What advice do you have for starting an app modernization project?
Oppedisano: Know the details and reduce the risk -- that is the ultimate end game for application modernization. In a lot of cases, architects can get distracted. Sometimes they get distracted because they want to maintain the legacy code to a degree that is unreasonable; they don't want to do enough change. In other cases, they want to do too much in the name of progress.
When you think of what has to be done to successfully modernize core apps, there is a lot of work there. Testing can take up 60% of your time. Make sure there is a proper testing plan in place that reduces the time of the project and increases your chance of success. The shorter a project is, typically the less it costs.
Maxine Giza is the site editor for SearchSOA and can be reached at firstname.lastname@example.org.