Make application modernization pragmatic and useful

Ask anyone to define application modernization and you’ll hear many different answers. Here’s a generalization of what we all agree on: application modernization takes the existing applications and data sets that run businesses and makes them more useful, productive, and engaging for those who use them, especially customers. . The ability to improve the customer experience generates more business.

Some see app modernization as “putting lipstick on a pig,” but that’s not the point at all. Application modernization shouldn’t be about building apps appear modern; applications must watch and be modern.

This means changing user and machine interfaces, as well as modernizing internal architecture, public cloud platform infrastructure, application functionality, and enabling technology. It also involves moving from traditional waterfall development processes to agile and devops processes.

Is it a good idea to take valuable legacy applications, improve them, and move them to a public cloud? Sure. However, more and more, I see developers and cloud architects approaching modernization with a kind of endless checklist that often goes too far and does too much, thereby missing the business value goals and objectives of the project.

There is so much information about application modernization, including processes and methodologies, that many teams attempt to modernize by checking boxes that others believe will make their legacy application truly modern. They pursue trendy concepts like containerization, microservices, data augmentation, internal architecture augmentation, and other things that may require major surgery. This approach could put the application at risk by introducing a myriad of complexity, hassle, and expense just to check off a checklist box.

Here are two pragmatic questions to consider.

First, there’s a tipping point where it might make more sense to delete the original legacy app and start fresh. I’m always more willing to fix things than throw them away. However, I often see cases where $2 million is spent on modernizing an application when a clean new development would have cost $1 million.

Software engineers generally understand that it is often easier and cheaper to build something from scratch than to refactor and recode an existing system that must first be fully understood before it can be changed for the better. It’s rare that the teams that originally developed the app are still on staff. The knowledge base is incomplete or non-existent. The app has been changed so many times over the years that no one fully understands its full scope as it exists today.

Second, those who modernize applications go through a long application modernization checklist of things that need to be done. In many cases, they do everything on the list, regardless of the actual need. This means containerization, enabling microservices, migrating to a more modern database, portability, and mobility. These features are considered necessary because they are on the list. Why do so few people question the list?

In most cases, it is not cost effective to force everything on application modernization checklists. Even containerization, which has many advantages, is not suitable for all applications. There is a cost to container-based architectures and enabling technology, as there is with microservices and even cloud migration.

I’m not saying these features aren’t solid investments when based on application needs. I’m saying that in some cases they’re overkill and don’t really add value to the overall business goal. Again, don’t ask if you can, ask if you should.

Copyright © 2022 IDG Communications, Inc.

Source link

Comments are closed.