What is minimum viable architecture?
The architecture behind software is fundamental. It covers all the software components, how they interact with each other, the principles incorporated in its design. It’s the structure that guides ongoing development and keeps focus cohesive.
Architecture, then, is an enormous undertaking. And the drive to have it all squared away right from the beginning is strong. But there’s another way.
Ladies and gentlemen, we present minimum viable architecture (MVA).
The definition
Minimum viable architecture is also known as ‘just enough architecture’. It’s an approach to your software architecture that starts with the bare-bones basics — focusing only on what’s good enough to get the software out there. From there, you continually improve and expand your architecture alongside your software product during its lifetime.
The idea of minimum viable architecture is related to agile development. Essentially the idea is to start small and be responsive to changes in the software direction, the technological landscape, and anything else that comes along.
MVA applies MVP to the entire enterprise
Another way to think of minimum viable architecture is to compare it to a better-known idea: the minimum viable product or MVP.
An MVP, done well, is the bare bones of a software product. It offers the core functionality without any bells, whistles, or extras yet. An MVP is more than a prototype — it’s a working foundation of your planned product, which is usable by customers (early adopters) as is.
MVA is the same idea, but applied to software architecture, rather than a product.
See also: What makes for a good MVP?
Why adopt a minimum viable architecture approach?
When you adopt an MVA approach, you’re prioritising agility. That is, you set your software growth up to adapt to the fast-changing landscape of technology with comparative ease. Your architecture is more fluid — it’s going to grow and evolve alongside your software products.
There’s also the benefit of facilitating a quicker release. As with an MVP, an early release means you get more feedback to shape your product from the off. You also get an early start building a customer base — meaning you get your footing sooner in a market where the winner often takes all.
Finally, there’s also a cost-related benefit to following an MVA model. Minimum viable architecture means that you aren’t over-engineering your architecture from the start. Instead of a big expenditure to cover the creation of your architecture, you pay and build in small increments.
How to adopt an MVA approach
Adopting a minimum viable architecture approach means focusing on the core, foundational architectural components of your software and systems. It’s about making a working base. Over which, and over time, you can construct the rest of the architecture.
You need to identify your must-have components and features. Approaches such as the MoSCoW method and YAGNI can help here. In short, stick to the idea that you only build, outline and design what you need to solve the problems you have now.
A successful MVA approach is one based on concrete needs. That is, build for the most likely. Focus on core goals, not edge cases and ‘what if’s.
Minimum viable architecture
Minimum viable architecture, like its cousin, the MVP, is essentially stripping back efforts to focus solely on what is needed at that moment. It’s applying the MVP mindset across the enterprise. It’s about avoiding overengineering and getting straight to the core of your software and your business.
