Modernizing Enterprise Software Applications: Myths About Modernization (part 4 of 7)
There are prevailing beliefs that persist in the engineering ethos, which can be counterproductive to a holistic understanding of what is needed to modernize.
Modernization Can Happen In The Background
Good engineers will always endeavor to leave things in a better state than they find them. As such, especially when there is a strong sense of ownership, businesses can think of technical improvement as things that will happen behind the scenes, by virtue of good engineering practice. Such efforts can be game changing at times, but without a business wide buy in to the needs for modernization, they will most likely be localized efforts with limited impact. In the face of serious technical debt, they may represent at best a success in avoiding the accretion of yet more technical debt.
Modernization Is A Need Created By Poor Engineering
It is important to think of the need to modernize without a sense of finger pointing. In a reality where agile processes have largely taken hold, choices of short-term gain over architectural soundness involve everybody from stakeholders down, and all understand deliberate compromises. Sound choices are overtaken by industry trends, and product acquisitions can catch out the most deeply planned architectural roadmaps. It is important to facilitate honest and open communication at all levels about technical impediments, so that different perspectives and experiences come together.
Modernization Can Be Delivered By A Tech-Debt Sprint or Percentage
Agile development will sometimes think of technical debt as something to do in an otherwise “slow” sprint, or something that can be addressed by giving over a percentage of velocity to the effort. However, serious modernization is something that needs time for proper analysis as much as novel feature development (often more since by definition it won’t have an easy pattern to follow). Moreover, by limiting the scope of what can fit into a specific sprint, the true ROI consideration of desired outcomes gives way to a more engineer-story size view driven by what is feasible.
Difficulty In Estimation Means Modernization Should Not Be Undertaken
Modernization’s resistance to accurate estimation can’t be overstated. A unique legacy set of challenges means the engineering required will be a little different every time. Estimation is going to involve some guesswork, and excessive optimism only increases the risk. When an organization is being hampered by the status quo, the ROI remains a reality even if the error margins in estimation are necessarily higher than in some projects.
Technical debt can be crippling to a company, and without the understanding of the difficulty of the problem, a vicious circle of inefficiency can easily become a default outcome.
Rewriting Is More Sensible Than Modernizing
The uncertainties and challenges in modernization mean that some believe a complete rewrite of a solution makes more sense than working with what already exists. In the case of a poorly executed solution, perhaps further hindered by poor testing and documentation, it truly can make the most sense to begin again, starting with capturing requirements.
Most well-established enterprise solutions survive because they serve needs with some degree of effectiveness. Functionality is almost always added over a long period of time, whereas a rewrite project is encumbered with needing to deliver most or all of that functionality from the go-live date. The risk is accordingly higher, even more so in cases where what the outmoded application does in fact is the de facto documentation of what it should do.