What is MVA (Minimum Viable Architecture)?
In software, an architecture defines the software structure, and the physical environment that will support it. Architectures are predominantly based on the Quality Attributes Requirements (e.g. scalability, performance and security) specified that the system needs to meet.
There are always several possible architectures to meet the requirements, with various levels of complexity.
An MVA, or ‘Minimum Viable Architecture’, is a “just enough” solution: it strictly meets the QARs without trying to go beyond. An MVA also tries to be the most cost-effective and time-effective solution, whilst still providing some flexibility to allow for QAR changes and feedback from the monitoring once in production.
This “just enough” contrasts with a more traditional approach, where architects design a system that not only suits today’s needs, but also tries to cover what needs might arise in the future. This approach might provide a “gold-plated” solution, but it comes with high complexity and costs. It’s worth noting that it’s very difficult to accurately predict what Quality Attributes Requirements the future will bring, so agility is desirable.
How do you create an MVA?
As with any architecture, an MVA derives from the QAR specified for a system. Thus, the first step to defining an MVA is to determine the minimum QARs. For instance, one should not ask for a cloud-agnostic solution if a cloud provider has been chosen and there is no plan to change it for the next few years. Designing a cloud-agnostic solution introduces much complexity.
As another example, one should not architect an availability of 99.99% if 99.9% would be sufficient for the end-users. Again, the higher the availability required, the more complex the architecture.
Once the QARs are specified and realistic, the technical team will work on defining an architecture that meets them with the lowest complexity and cost. This usually relies on a risk-based approach with clear logging of the decisions made with frank discussions on the different designs considered and why they were discarded or retained.
For instance, one may choose to have synchronous calls between two micro-services instead of asynchronous ones because they are easier to implement and require fewer moving parts but accepts the risk of being less scalable. This could be the “minimal” option as long as the scalability requirement is met.
QARs evolve over time, e.g. the number of concurrent users increases because the product becomes more and more popular. Also, the introduction of new features can have an impact on the quality of the solution. Therefore, an MVA does also need to be able to evolve.
A common pitfall with an MVA approach is building a system that cannot accept QAR changes. An MVA should be able to be modified without having to rewrite the entire system unless this is a known risk assumed by the business.
The risk-based approach should consider the QARs that are most likely to change and, thus, which areas of the design are most likely to change.
What is the link between MVA and MVP?
With a Minimum Viable Product, a company aims to provide the minimum acceptable number of features to end-users at a minimum cost and, most importantly, enter the market as quickly as possible to learn more about it and get user feedback rapidly. The company wants to know whether the product can be successful and, if similar products do not already exist, be the first on the market.
In this light, MVA is an excellent approach to building an MVP since the technical team tries to design the most cost-effective and time-effective system.
Who needs an MVA/When do you need an MVA?
An MVA approach is also suitable for established products. When new features are introduced, existing ones are modified, or the QARs change, the architecture should be reviewed to determine whether it needs to be amended. In fact, MVA is increasingly recognised as the recommended whenever a system needs to be built or modified, even in the context of migrating from a legacy system to a new one. In an Agile environment, MVA perfectly suits the incremental and iterative approach.
MVA is unlikely to be suitable in a Waterfall approach where feedback loops are very long: any shortcoming from a “minimal” decision in the architecture cannot be changed quickly.
Conclusion
MVA is an approach gaining in popularity that is not only suitable for building MVPs but also for established products. It is a methodology based on making considered, logical decisions about what’s necessary and what’s desirable.
It requires to be coupled to a well-documented risk-based approach with risk registries and decision logs.
On first look, MVAs might appear to be incomplete or lacking in depth. As long as the decision to embrace an MVA approach by the business in question is rational and in accordance with the business’ technical strategy, MVAs can be very beneficial.
We anticipate seeing the Minimum Viable Architecture methodology adopted by more and more of the companies we assess as teams benefit from a ‘just enough’ approach to designing and architecting their solutions. The reductions it brings in cost and time will be attractive to growing businesses.
Thanks to Technical Consultant Jorge Migueis and Chief Technical Architect David Bamber for their contributions to this post.
