A journey starts with a single step, any motivational poster can you tell you that, but what about all the steps after? Even if you know where you're going, are you getting there in the most efficient way possible? Before you start an application modernization quest of your own, it helps to get an idea of the road ahead.
You don't have to have everything mapped out from the start, and chances are high your plans will change. Enterprises can learn a lot from teams that modernized their legacy systems successfully, but there are also valuable lessons from those that failed.
Why legacy modernization projects fail
Enterprises that dive into the application modernization process are trying to solve big problems, but great intentions rarely guarantee success. In 1999, Carnegie Mellon researchers dove into 10 reasons why legacy re-engineering efforts fail that are still very relevant today:
- The organization adopts a flawed strategy from the start.
- The organization relies too heavily on outside consultants.
- The team is tied down to old technologies and inadequate training.
- The organization thinks it has its legacy system under control (it doesn't).
- The needs of the organization are oversimplified.
- The overall software architecture isn't given enough consideration.
- There is no defined application modernization process.
- Inadequate planning and follow through.
- Lack of long-term commitment to the strategy.
- Leaders pre-determine technical decisions.
Every team faces legacy modernization challenges. Committing to the process is the first step to meeting those challenges head on. As teams go through the modernization journey, use these best practices to avoid common pitfalls and ensure long-term success.
1. Create a modernization team
Groups can learn a lot from each other and a variety of voices at the table can point out weaknesses and improve the modernization process. When choosing a team or developing an innovation group, avoid thinking along legacy lines which divide teams by stages of the software lifecycle. Think about building a cross-functional team of 8–12 people who can focus on developing the culture, process, and tools needed to continuously deliver software.
2. Disagree, commit, and disagree
With more voices come more opinions. It's a powerful way to innovate and generate great ideas, but it's also the most effective way to be ineffective. Decisions sometimes have to be made without a 100 percent buy-in. Everything can be questioned but as long as a decision is in place, we should expect people to commit to executing it. "Disagree and commit" is one of GitLab's core values and it's a common business principle that keeps projects moving forward.
Whether decisions are left to one individual or distributed will largely depend on the size of the organization. For all final decision-makers during the application modernization process: listen to other points of view, thank those who contribute ideas and feedback, consider options carefully, and commit to a course of action.
3. Map the development workflow
Many organizations have been bogged down by the sheer number of tools, plug-ins, and platforms they use to accommodate everyday tasks. Some workflows have more in common with a Rube Goldberg device than a logical order of operation, but mapping out the development workflow is a necessity when undertaking a legacy modernization project. This step is usually when the headaches of toolchain complexity come to light.
Look at every tool being used across teams and identify dependencies. More handoffs present more opportunities for single points failure, and any new applications added to the mix need to be able to play well with others. Even if you don't mind teams finding their own solutions so that they can work creatively, it's a good rule of thumb to identify all privately used tools that might be in the mix.
4. Set small modernization goals
Having an entire timeline mapped out months in advance sets you up for failure. Why? Projects inevitably change once they get started. Trying to map moving targets months in advance is an exercise in futility that ends in projects that are rushed, incomplete, or late anyway. Reducing the cycle time and focusing instead on iterating towards smaller goals will have a much higher likelihood of success. Teams that master iteration respond to feedback faster, adapt more quickly, and complete their projects faster than their large-scale counterparts. By shortening the timeframe and reducing the scope of each goal, you're able to respond to changing needs, adjust your long-term plans with the feedback you receive along the way, and radically reduce engineering risk.
When planning for major milestones (when certain tools will be retired or migrated, when updates will occur, team training, etc), focus instead on the many small steps between them. A smaller deploy introduces less changes that can potentially introduce issues, ensuring that each steps moves smoothly.
5. Prioritize legacy data
Preventing data loss is a key priority during the modernization process. Evaluate the data being processed, moved, and stored and put it into categories. Whether it's "high, moderate, or low" or "green, yellow, and red," make sure the team understands each data category and what safeguards to have in place for each.
6. Don't modernize bad habits
Many organizations have squandered a clean slate by infusing new tools with old habits. Take a close look at your development workflow and identify instances of duplicated data, manual tasks, inefficiencies, and other habits that could derail your application modernization process in its tracks. Many of these practices are due to a lack of training or documentation – both easily fixable problems. A new tool doesn't solve bad habits, but bad habits can derail new tools.
7. Close the skill gap
The number of programming languages, tools, systems, and methodologies that developers have to know is immense. It's a challenge for teams to develop the knowledge they need to work quickly, and adding a new system to the mix should be considered carefully. Keeping teams in the loop on changes and then dedicating resources to make sure they understand how to navigate the new workflows will be the most important part of the application modernization process. Make this an ongoing, long-term commitment to organizational success and continue to document best practices long after legacy systems are turned off. Tools are only as good as the people who use them.
Are you ready to tackle application modernization? Just commit.
