We will see what so-called sacrificial architecture is and why sometimes it’s better to build something from scratch instead of trying to improve what …
Join the DZone community and get the full member experience. One of the toughest decisions your software development team may face as you scale is deciding between keeping your current codebase and rebuilding on new software architecture. In this article, we will see what so-called sacrificial architecture is and why sometimes it’s better to build something from scratch instead of trying to continue and improve what already exists. Sometimes it takes less effort in terms of time and money to build a solution from scratch. The key here is to rethink, restructure and rebuild. Of course, it may bring a bit of frustration that the previous work “goes to the rubbish bin”, but in reality this know-know that you got, these lessons that you learned to lead you to develop a much more powerful and scalable product, using the latest and fastest technologies. Many companies work on sacrificial architecture strategically. Often, companies build sacrificial architecture when creating a minimum viable product to test a market, anticipating building a more robust architecture if the market approves. Building a sacrificial architecture implies that software architects aren’t going to try to evolve it but rather replace it later on. So, sacrificial architecture means accepting now that in a few years’ time the team will need to throw away what they are currently building. In other words, sacrificial architecture is a short-term solution to the current needs, which in most cases is used to go to market faster and test MVP. Martin Fowler mentioned one curious thing about sacrificial architecture: he says that it is also about thinking now about the things that can make it easier to replace when the time comes, but software architects rarely think about how to build an architecture to support its replacement. For very famous tech companies, deciding to rebuild their software systems from scratch was a brave decision and massive success. For others, it ruined them. It is all about trade-offs, it is all about seeing the big picture and accurately calculating all the options, finding optimal solutions to your specific situation. So, let’s see some case studies where replacement leads to exponential growth. eBay, one of the most successful companies in the world started as a set of Perl scripts built over a weekend 20 years ago. After 2 years of operation, it was all torn down and replaced with a system written in C++ on top of the windows tools of the time. And 5 years later the application was rewritten again in Java. The first question that pops up is were these early versions an error because they were replaced? What would you say? In most cases, leading software architects believe that it was the right decision at that time.
