The application modernization services market is set to grow to $25 billion by 2025. At Polaris, we start the app mod process by looking at business priorities, not technology, as a means of ensuring resources go to the right place. But there’s another area of focus that sets our approach apart: people. By putting people first throughout–from discovery past delivery–we’re able to find the fastest path to achieving those critical business priorities.
Most of my background is in rewriting software. In other words, I help companies whose software has atrophied find ways to rebuild quickly, by leveraging current development standards and technologies. When managing a rewrite, I look to work with the people who know the business best. These are the end users, the employees or customers who use your software regularly. Below, I’ll break down how a people-first approach plays out in key stages.
Make a Collective Call to Modernize
Multiple factors can inform the decision to modernize, and one or more are likely to affect any organization with custom software over 10 years old. Custom software may be built on top of another platform–hardware, third-party software, or an older operating system–that has become outdated. Then, the cost of maintaining it spikes. Or, technical staff who supported the legacy system have moved on, and it can be an HR challenge to find job seekers who know that older technology.
In both scenarios, most organizations wait too long to decide to modernize, doing so only when they feel they have no other choice. It’s not unlike personal health. We all know consistent wellness checkups, healthy eating, and exercise can keep our hearts healthy, yet some will avoid addressing it until the time comes for major cardiovascular surgery.
Just like patients putting off checkups, organizations might avoid app mod because of fear of the unknown. Software is complicated, change is scary, and accountability can also play a part. A lot of teams have a “if it’s not broken, don’t fix it” mentality, especially with software they’ve built themselves. The challenge is to reconsider what “broken” means. Even software that employees are using daily should be considered ripe for a rewrite if it’s full of inefficiencies. Broken software often looks more like 1,000 tiny cuts rather than one large tear.
Once you’re ready to own the problem and modernize, it’s important to consider the following:
- Teams – Communicate and get buy-in from all departments involved. An IT Director or CIO may be spearheading the project, but the end users of the software in question might be Marketing or Sales. Make sure everyone is ready to be part of the discovery process.
- Technology – Start working early on to target the new set of platforms and frameworks you’re going to use. If you’re going to get surgery, you don’t want this to be the first time your surgeon has used his/her tools. Most of the time, an in-house team is maintaining the existing system, but in this case you may need to bring in experts with a deep understanding of the new technology.
Deepen the Application Modernization Discovery Process
Some businesses go into an app mod project simply wanting the new software to do exactly what the old one did. In spite of this, the rewrite should involve asking hundreds of existential, exploratory questions. Why? Because there are often unexpected wins lurking in the answers.
Even some application modernization experts with decades of experience just aren’t interested in the people part of the process. In the case of consultants, it can be easy to focus attention on leadership, the people who hired them in the first place, and deprioritize the end user. But it’s the end user who can help unearth things the business doesn’t know it needs, and that can make the new software exponentially more efficient and high-performing than the original.
Access to the end user can be a challenge. If the end users are employees, they probably have a full plate and their day job certainly isn’t building software. My team starts projects with this understanding, with a conversation about how much access we can have to those people, and by setting a cadence for communication with them (daily, weekly, etc.).
This conversation alone can push the business to innovate and find ways to free team members up. It can help us identify the manual processes eating up employees’ time, and get everyone thinking about ways to transform the business. When you find or build a rewrite team with a people-first attitude, they’ll dive into the discovery process the right way and find the shortest path to your critical priorities.
Engage Beyond Delivery
Successful application modernization isn’t only about engaging with end users in early-to-mid stages of the process, but being in it with them for the long haul. If we return to our healthy heart analogy, you’re not done post-op. There’s recovery and rehab that follow.
Usually, when we deliver a rewrite to a client for the first time, it’s a slight culture shock. We’ve completed a transformation, and the culture must carefully adjust to a new-and-improved normal. We keep an eye on this stage and maintain open communication with leadership, to ensure the business’ processes and practices are in line with current trends in Agile.
It’s not unusual for rewrites to take multiple quarters if not multiple years to complete, so use some of that time to set a learning plan with the experts you work with. Typically, they will prioritize delivery first (performing the surgery), then slowly hand over the tools as staff become comfortable with the new software. By the end of the rewrite, existing staff should be confident about supporting the new software in the same way they supported the previous one. Once staff is maintaining the new technology, your last step is to make sure they have a community that will support them over the lifetime of the new system.
Putting people first throughout the app modernization process can help you avoid common software design problems and achieve your mission-critical priorities. I’ve been in custom software development consulting for over 15 years, and with Polaris for more than 10. By far my favorite thing about rewrites is improving the lives of people who depend on software to do their jobs. Building great software can help keep an organization healthy and set it up for long-term success.