One should not say never, but the odds are really against big-bang-style transformations.
Transformations and dealing with legacy is one of the most difficult decisions made by businesses and organizations today. Legacy is on the rise with aging organizations and affects the health of businesses and investments. Whether the transformation is motivated by cost optimizations, customer needs, the need to innovate, security compliance, or growth needs, the plan has to be well thought out, and the execution cannot be taken lightly - a solid plan and a commitment to be persistent have to be in place. Too many modernization initiatives end up failing, costing a great deal of money, and time, setting companies back.
Completely re-writing legacy code into something modern is rarely successful and a less strategic choice. A big bang is the decision to just embark on throwing away legacy and starting fresh with a greenfield. As reasonable and sometimes tempting as this may sound, it is a very difficult thing to do. It is far easier to build a new house than renovate an old house. But imagine deciding to run a 100 km marathon after leading a sedentary lifestyle for 20 years. The odds are really not in favor.
This article offers a few case studies and examples of how modernization decisions materialized with lessons learned, along with the top reasons why big bangs are likely to fail.
11 Reasons Why Big Bangs Are Not Great
Those reasons below are the same whether the legacy product is an external one that customers use or an internal one that supports the organization.
The Customers Needs: The customers will not pause while you re-write new code. Support, bug fixes, and expectations for new features will continue and drive your R&D spend on top of the modernization costs. The team will essentially be running two products with less focus.
The Competition: While you are rebuilding the same product, the competition will continue to innovate, outpace, and acquire customers. You have to continue to drive the ship.
The SDLC Culture: Big bangs emphasize speed of execution to minimize market risks. However, rebuilding with newer technologies requires a shift in the execution culture and ways of working to accommodate different technology stacks, modern tools, and SDLC processes. Those take time to build in an organization and are difficult to happen in a big-bang timeline. It’s a journey.
The Market Use Cases: Customer needs to evolve with time. The use cases and market opportunities when the product was built are not the same at present as they were when the product was initially built. Rebuilding a copycat product on new technology is not likely to be good enough.
The User Feedback: Great products are built incrementally and leverage positive and negative user feedback reinforcements to evolve. This is not possible in a big bang.
The Talent Pool: The likelihood is that the talent in place is more optimized and has more expertise on the legacy systems and technology stack in place. Ramping up new talent or upgrading skills does not happen overnight.
The Portfolio: Many companies grow through acquisitions, have a portfolio of products, or even a single product with an integrated suite of related products and services. The portfolio dependency complexity will create surprises along the way with integrations and compatibilities that may not be visible at the beginning of the journey.
The Technology Shift: Technology does not stand still. The change will happen during the time you are building. Incrementally building allows you to adjust course compared to going dark with a big bang for an extended period of time. An example is Angular version 1.0 (AngularJS) was released in 2010 by Google, and then Angular version 2.0 was released in September 2016 as a complete rewrite from the same team that built AngularJS. The drastic changes created considerable controversy among developers and negative backward compatibility implications for companies that were doing large migrations.
The Sudden Change: Even if what is being built provides the same features, there are changes (e.g., User Experience) that will come with using a different technology stack. These can sometimes be enough to risk customer churn due to sudden vs. gradual change.
The Quality In Place: In many cases, the existing product code that has been built over the years has some level of quality embedded in it and has been market-tested over the years. Not leveraging the pockets of quality code can be a waste.
The Architecture: Software is a continuous process and is never really finished in an always-changing environment. The software architecture in a big bang style execution is often rushed, and development on top of it moves at fast speeds, which makes the ability to evolve and fine-tune the architecture incrementally difficult. This typically results in shortcuts and sacrificing performance and scalability.
How to Modernize Successfully?
Companies typically embark on a big bang when they feel they are running out of time and beginning to shed customers at a faster rate. Even if a product is sticky and customers have built and integrated their entire world around it, there is an eventuality where enough is enough, and a decision to bite the bullet and go with a competitor may be a reality. This can be avoided by not postponing a transformation investment to ensure there is enough lead time to do it properly.
It begins by carefully understanding the current and future states before starting the journey and choosing the best option based on the situation. There is no doubt that any modernization path is risky. The odds of success increase by choosing the most adequate path with the least amount of risk.
The path of least risk may include leveraging what’s possible, breaking larger plans and development chunks into smaller modules and tiny services, and carefully considering the roadmap, future use cases, and trends to prioritize better. It also includes as much attention to the execution process, governance, training resources, and the team who will execute.
Modernization is possible, and many companies succeed in their endeavor, but they strategically plan it, incrementally execute it and keep going at it. It’s a multi-year plan, and execution discipline takes into account the full picture, not just the technology stack.
Dealing with legacy offers a few alternatives instead of going for a big bang. Complete code rewrites are not practical and are littered with risk. The exceptions are building in parallel with chunks of services and APIs which is a more viable approach that slices monoliths into smaller services. Built-in time and budget and strategic cultural changes planning are all part of making it work.
Case Studies
About the Author
Hazem has been in the software and M&A industry for over 26 years. As a managing partner at RingStone, he works with private equity firms globally in an advisory capacity. Before RingStone, Hazem built and managed a global consultancy, coached high-profile executives, and conducted technical due diligence in hundreds of deals and transformation strategies. He spent 18 years at Microsoft in software development, incubations, M&A, and cross-company transformation initiatives. Before Microsoft, Hazem built several businesses with successful exits, namely in e-commerce, software, hospitality, and manufacturing. A multidisciplinary background in computer engineering, biological sciences, and business with a career spanning a global stage in the US, UK, and broadly across Europe, Russia, and Africa. He is a sought-after public speaker and mentor in software, M&A, innovation, and transformations. Contact Hazem at hazem@ringstonetech.com.