Sacrificial Architecture

Sacrificial Architecture

Some times, when moing fast in a development team you might encounter a situation where there’s a new feature or subsystem to develop and there are several semingly good ways to do it but not enough information or time to make a good educated choice. We can spend a siginificant amount of time trying to predict the future and engineer the best long lived solution or, given our [[bias to action]] just choose a straightforward simple solution to deliver fast knowing full well we might have to throw away that code in the future.

Delivering, and learning from the feedback we get running and maintaining the system (Pain driven development) trumps the time that would be spent trying to overengineer a solution.

Example: We were adding a new functionality - MFA support - to Twingate. MFA is conceptually separate from our main server code -basically it could be a 3rd party service we’d consume but we didnt find one that answers our need and decided to write one ourselves. On the backend decision was easy - we’d just develop a new (micro)service with h its own API, Datamodel, etc. But how do we implement the ~3 UI screens required for a user to setup an MFA code and answer MFA challenges?

• We have our admin console which a complex React+Apollo codebase - most of which is for authenticated users (where MFA calls are before authentication). We could add these views to the code base and somehow add code that supports multiple hosts (MFA would be on a different host)
• We could somehow extract all our styling into a 3rd library and use that for both Admin and MFA but there are several ways to do that and each will take a significant amount of work.
• We could develop just use django views developed as part of the new service code and, gievn the limited UI needed, reimplement the styling we needw without React

The 3rd choice makes the most sense - we can get something out in a very short time and run it production and over time figure out whats the best strategy to take regarding frontend and styling… When the time comes we could just develop new screens on some other codebase and eventually get rid of the django views.

Guidelines:

• Clearly separated into its own module that could later on be replaces

References

SacrificialArchitecture By Martin Fowler.

So what does it mean to deliberately choose a sacrificial architecture? Essentially it means accepting now that in a few years time you’ll (hopefully) need to throw away what you’re currently building. This can mean accepting limits to the cross-functional needs of what you’re putting together. It can mean thinking now about things that can make it easier to replace when the time comes - software designers rarely think about how to design their creation to support its graceful replacement. It also means recognizing that software that’s thrown away in a relatively short time can still deliver plenty of value.