The Application Modernization Plan is a comprehensive plan for extending the value of your legacy systems by updating their infrastructure and performance. We will focus on the existing business value in the existing system, and enhance it to add years the useful life of your investment.
A word of caution: an Application Modernization Project can be a far reaching effort and can easily get out of control. Fixing one part of the system leads to another, which leads to another, and the business value can get lost in the never-ending spiral. Therefore, the Application Modernization Plan has 3 guiding principles, and is broken up into very distinct steps with specific goals that follow these principles.
It’s easy to go down the rabbit hole of technical debt reduction and lose track of the business value we’re trying to create. The modernization plan has specific rules of what debt should be cleaned up and what should be left for later efforts.
In each step of the plan we provide specific business value for the tasks we take on during the sprint, while also reducing technical debt along the way by introducing automated testing and other quality controls.
All modernization efforts are aimed at keeping the system up and running at all times. No tasks are created that can leave the system in a unpublishable state at the end of a sprint.
How Does It Work?
When starting an Application Modernization Project, there is a small amount of up-front work that must be done before we begin. Once this initial review is done and the overall business goals defined, we work in a 2 – 4 month projects where each project has specific deliverables agreed upon by management and the technical team.
Note that these projects do not have to be synchronized with external release schedules. All work is done with the goal of incremental improvement and fully releasable software at the end of each sprint.
The scope of each project is determined by business goals and deadlines, external release schedules, and other business factors. We define the scope to take about 3 months in order to help stay focused on the task at hand. Each project will have a fixed price depending on scope, and will have a specific set of deliverables so we know when we are done.
After each project, I will meet with management to go over performance metrics and exchange feedback, then we plan the next project. This process can go on as long as necessary until the modernization effort is complete.
Who Does the Work?
There are 3 possibilities for who does the work necessary, depending on the project budget and urgency.
Your internal team does all the coding, while my involvement is limited to technical coaching, project management, and Jira task creation. This option can fit tight budgets while still getting the job done, however it is common for internal teams to be distracted by feature requests resulting in the modernization timeline suffering. This is a good option if you have sufficient internal staff available, or the modernization project is time insensitive.
I provide a small number of developers to work with your team to achieve the modernization goals. My team is experienced in the challenges presented in a modernization project, and knows how to solve them while working closely with your internal team to ensure feature requests are continuing to be implemented without interference. This is a good option for critical applications that must be modernized quickly.
For back office or supporting applications that are critical to the business but do not comprise a competitive advantage, outsourcing the modernization completely may be the best choice. This keeps your internal team free to focus on the technology your business is centered around, while still improving the back end processes that keep the business functioning.
Initial System Review
Before getting started, I must perform an initial system review to determine the most pressing issues with the existing code base. This review results in technical recommendations on issues found and recommended resolution, as well as business priorities and what can bring the most value.
There is a very long list of technical details I check for, but they all checks are in the areas of
- System Security
- Error Handling
- Architectural Structure and Maintainability
- Unit Testing and Quality
- Ease of Enhancement
Depending on the current environment, there may be some preliminary updates necessary. This step is only required if the existing app is having stability problems, or the internal development process needs enhancement.
Preliminary updates may include
- Ensure the development process is predictable and repeatable
- Ensure Production deployment processes are secure
- Evaluate pressing security concerns
- Establish necessary supporting infrastructure
- Validate the QA process
If any issues are identified, we must first correct those problems in place to make the system stable and ready to accept changes. We also get any supporting infrastructure installed and configured, like build servers, code repositories, bug trackers, etc.
Team Skill Update
Depending on the technical level of the internal team, there may be some training necessary before we get started on the modernization effort. I have prepared classes to present on all the necessary skills. See my Team Skill Update Training page for details.