It May Be Time to Rewrite Your Software. (Yes, We Said Rewrite.)

Posted on Thu, Mar 1, 2018 @ 10:17 am

To rewrite or not to rewrite? That is the question. You have an aging solution that is core to your business, whether it be an internal CRM solution or an externally facing customer solution.  This solution has treated you and your business extremely well, however it is aging. Maintaining it is getting more difficult, and it’s next to impossible to add new features to it — a.k.a., the “Big Ball of Mud” effect. Perhaps you might be in a situation where the technology or framework that the solution was built on is no longer popular or is obsolete. At some point, there is a realization that a difficult decision needs to be made: Do we rewrite this solution or not?  This is not a question to answer quickly, and there are a number of things to think about before an answer can be reached.

While you will find enthusiastic support for a complete rewrite among your young developers, you are sure to get scorn from your VP or CTO. A complete rewrite path has historically been fraught with strife around the project- people management, time to market, cost to deliver, and even market shifts in the technology of choice during the time it takes to rewrite the solution. We also have seen situations where the new solution can never fully replace the old one (due to the high level of customization that took place over such a long period of time), leaving two solutions that now need to be used and maintained. History has many examples of failure when it comes to a complete rewrite:

  • Netscape 6 (rewrite of Netscape 4)
  • Project Pyramid (rewrite of Microsoft Word)
  • McKesson Horizon (rewrite of EHR system)

Ultimately, when all of this is discussed and analyzed by a project/oversight team, the realization is often reached that the benefits of a complete rewrite are often too modest to justify the costs and time.  

So, what’s different today? Why can we successfully complete software rewrites now, when just a few years ago, these endeavors often crashed and burned?  In the past decade, we have seen technology disrupting every factor that affects a project’s outcome, from improvements in software project productivity tools such as version control systems (Git, Bitbucket, GitHub), to modern build systems (Jenkins, Bamboo, Travis CI), and effective defect and task tracking systems (Atlassian JIRA, Trello).  Development processes such as agile and the use of dedicated DevOps people and practices also have evolved to be more effective, with a higher yield of productivity.  Most importantly, we have seen large improvements in the development technologies we can use to accomplish these previously daunting tasks. Take a look at our comparison below:

 A Decade Ago Today
Monolithic web application using frameworks like CGI, J2EE (JSP, Servlets), Classic ASP or ASP.NET, Struts, etc. JavaScript frameworks like Angular decouple frontend from backend, microservices frameworks, PaaS platforms like Heroku, serverless platforms like AWS Lambda
RDBMS dominated everywhere. Variety of NoSQL DB available (document, columnar, key-value) and In-memory data grids
On-Prem, Bare-Metal Mature public cloud with pay-as-you-go model in compute, network, storage, messaging, machine learning, big data
Build servers existed, but no adoption of CI/CD yet   Mature DevOps–CI/CD practices, build as service

We believe that the rapid phase of innovation in cloud ecosystems like AWS, Azure and GCP in the past few years is the real enabler to reimagine and rewrite older applications. What cloud platforms do is free us from the hardware and software infrastructure drudgery. You don’t need several days to stand up an application server or a messaging server or a database server or a build server. It’s right there in the cloud, ready to go, and you can now focus on what you want to do with it. PaaS and serverless architectures abstract the underlying complexity even more and make it much easier to start working on the meat (the business logic) of the problem/product. We really could divide a software engineering timeline into before cloud (BC) and after cloud (AC), and in an after cloud world, you have a much greater possibility of successfully rewriting your legacy software; not just meeting business requirements, but also innovating new products.  

How do you know when it’s time? In addition to the considerations of business value and technical quality, we recommend adding age as a parameter and treating the greater age as another degradation of technical quality, and by extension, its ability to solve the needs of the business and customers.  For example, a decade-old custom search application that is robust and has a high business value most likely needs to be migrated if you take age into account.  

Recent technology innovations make it imperative to evaluate software more than 10 years old for rewrites, not only to improve operations, but to innovate and solve modern business problems as well.  

Lastly, it is important to aim high with your rewrite aspirations and expect to provide leapfrog benefits with the new solution (10x not 10%).

What should you consider when deciding whether to rewrite? There are a number of things to take into consideration when making a decision to rewrite a core business solution or product.  

Requirements: As is the case with most successful projects, the first thing to consider is the list of requirements. Collect requirements from the business, users, support, sales and other major stakeholders. The source code cannot–and in our opinion should not–be treated as the only reliable source for requirements. Too often, people think all they need to do is deliver a new solution that exactly mirrors the existing one. This is a mistake. Think about it: The original solution was coded 10 years ago, but the needs of the business have changed dramatically over the past 10 years. Why would the requirements be the same?

Data Model: The next item to think about is data migration. You have 10 years of historical data to consider in this rewrite exercise. A number of questions should be discussed and answered prior to the rewrite, as the answers will dictate the architecture and timeline of the new solution. Do you migrate it all or just parts? Do you keep all historical data in the old system and start fresh with the new?  Certainly in most cases, a new data model has to be designed, and older data might not even fit into the new model.

Integration:  A solution that is core to a business and/or its customers is most likely going to have integrations into other solutions. Evaluate the need to integrate your rewritten solution with downstream-dependent applications like back-office systems, CRM, billing, authentication services, warehouse management solutions, etc. In our experience, you should consider yourself lucky if you find legacy applications integrating via files. A database integration is messy and obviously, the ideal integration solution  is via a service layer (API). Thinking about these integration points ahead of time will drastically reduce the time and resources spent on integration after the fact.

Leapfrogging Opportunity: One of the main reasons we have found that rewrite projects fail is because the business loses patience and believes the rewrite is not worthwhile. So, we found the primary factor that can make a rewrite successful is to find leapfrogging opportunities  that will dramatically and positively affect the business by reducing cost and time to market. It could be…

  1. Eliminating major code by using cloud-service/off-the-shelf software
  2. Reimagining the application in a totally different way – a mobile app, a chatbot or an API
  3. Migrating to public cloud, leveraging scale and agility of cloud

OFS has shared in the successful rewrites of some solutions that have been core to our customers in the recent past. Here are some helpful examples of how we accomplished these rewrites:

Example 1. Responsive Web App for World’s Leading Device Insurer

  • Problem: The client, a leading provider of smartphone device protection, experienced heavy call volumes and low first-pass yield, which was a result of customers frustrated with a non-responsive web claims application.
  • Solution: OFS digitally transformed the web claims processing app into a multi-tenant, configurable, responsive web app with integrated VoIP.
    • FROM: A 2008 tech stack of TO: A 2014 tech stack of Angular & Spring Boot
  • Customer Business Benefits:
    • 5% improvement in FPY produced $1.5M in annual labor savings (1% = $300K CSR labor savings)
    • $400K/year savings in new carrier onboarding costs

Example 2. Cloud Native CRM Web App for World’s Leading Device Insurer

  • Problem: The client is a leading provider of smartphone device protection who experienced heavy call volumes. The existing off-the-shelf CRM product had poor usability and performance issues that negatively affected the call center representatives’ productivity.
  • Solution: Our team of engineers and client architects collaborated on a project to slowly replace off-the-shelf CRM products with a custom-built CRM web application that integrated with all internal systems
    • FROM: A 2010 tech stack: Custom Java and JBoss TO: A 2016 tech stack of Angular, Sprint Boot, Docker, Amazon Web Services
  • Customer Business Benefits:
    • OFS improved usability of the CRM application, which positively impacted call center representative productivity.
    • Agile change management led to faster feature deployment, doing 3 releases per week.
    • The project had low maintenance cost because OFS leveraged cloud and SaaS.

Example 3.  Rewrite of Legacy Cost Rollup System

  • Problem: The client is a leading American clothing manufacturer whose cost roll-up system was a legacy platform built in the late 1960s using COBOL and PLSQL
  • Solution: The OFS team was involved in re-architecting and rewriting the platform using some of the latest technologies that could support the client’s expectations for performance
    • FROM: A 1960 tech stack using COBOL TO: A 2012 tech stack using .NET
  • Customer Business Impact:
    • The re-engineered platform was highly scalable, giving the flexibility to add new features and capabilities in the future.
    • The reduction of the cost roll-up process from 24 hours to 2 hours made for a better inventory process and lowered production cost.
    • The system’s cloud support improved adoption and accessibility from the client’s different manufacturing centers across the world.

OFS is an expert in Architecture Review and we would be happy to meet with you to discuss your current architecture, and collaborate with you on defining a roadmap to modernizing your current  architecture.

Abdul Rafay Mansoor is a technical architect at ObjectFrontier, Inc., and his work primarily involves presales consulting. Abdul has been a developer for more than a decade, and he began taking on presales consulting roles a few years ago. Abdul’s area of interest is cloud native development, and you often will find him passionately advocating cloud adoption to our clients.

Leave a Reply

Your email address will not be published. Required fields are marked *