“I have a team of developers that I have fought to justify for the past few years so there’s no way I’m “outsourcing” this transformation project. Even suggesting it is off the table.”
“We’re a software company, this is our product. Heck, there’s no way I’m having someone else modernize it.”
Both are natural responses and, in some cases, rewriting an application may turn out well but in others, well, let Dilbert speak:
[x_image type=”thumbnail” float=”none” src=”https://morphis-tech.com/blog/wp-content/uploads/2017/02/project_failure.gif” info=”none” info_place=”top” info_trigger=”hover”]
The question is what set of circumstances are going to lead to a good outcome, and what should you be looking out for as a red alert?
Our last post provided industry metrics on writing applications and generated cost/time comparisons for rewriting versus using a technology-enabled approach to application modernization such as that developed by Morphis.
Earlier in the year, we also discussed the major challenges associated with rewriting applications ranging from not having an accurate specification against which to rewrite the app, to losing the years of customer feedback built into the app and then the potential damage to customer satisfaction from freezing development of the original app while the new version is written. Obviously, in this latter case, the customer can be an internal business user or an external user.
So what are the characteristics of using an automated technology platform like Morphis to modernize an application that circumvent the limitations of rewriting applications? Before addressing those characteristics, let’s define “automated”. At Morphis we normally achieve 90%+ automation of old code to new, re-architected code. This varies based on source legacy language and complexity of the app but it is a reasonable average across the board and provides our first characteristic:
- the automated process does not introduce bugs. Only the manual code completion after automation is susceptible to developer-introduced bugs. This equates to <10% of the modernization effort being exposed to the introduction of bugs compared to 100% when rewriting the application.
- the automated approach ensures 100% coverage of the functionality between the old and new app. No danger from not having a full specification, no way to lose all of those years of knowledge and customer feedback built into the old app. All functionality is modernized. Note that the first step of the Morphis approach is to analyze the legacy application, which can reduce the footprint of the app prior to transformation by eliminating redundant and duplicate code.
- the Morphis tools generate quality code adhering to industry as well as company best practices/standards, in a fast, systematic and uniform way. Not only will this yield lower cost/time performance than rewriting, but also the pre-project estimates will be way more accurate. You can tell your customers the modernized app will be available in 6 months and be sure to deliver against that. We all know this is not the case with, even medium complexity, rewrite projects.
- shortened time to market with little variance around estimates not only drives customer satisfaction but employee morale too. Particularly that of customer facing employees.
- short time to market brings greater stability to the project too. The length of a rewrite project can be much greater than the stability of the project team which introduces the risk of constantly changing architectural decisions.
- the technology platform developed by Morphis enables some product customizations/enhancements to be built into the automated transformation process. Examples to date have included responsive design, accessibility and extensibility. This brings further economies to the transformation process when compared with rewriting which is often a two-step process with refactoring following on from the initial 1:1 rewrite of the app.
One counter argument we often hear is that developers can produce better quality code than can be generated by a transformation platform. Possibly, but now define “better quality code”. And what’s most important for your modernization project? Getting the job done in a timeframe of relevance at an affordable cost with code that works? All we can point to here are case studies of software vendors whose main product lines have been modernized by Morphis’ platform, vendors such as Ellucian.
Coming full circle, there are situations where rewriting an application will be a better option than engaging an external modernization partner. Small, low complexity, well specified, well understood applications are a case in point. A quick 2 month rewrite may be the most pragmatic solution rather than engaging outside help – particularly if new contracts/purchasing agreements need to be put in place.
Any other modernization project where time to market is an issue, or size/complexity is anything other than small/low, or where the specification is not obvious, then please contact us for a quick first order estimate of what we can deliver – for you and your customers.