This article is part of a series that provides practical advice and guidance on how to leverage the Continuous Architecture approach. All these articles are available on this blog. Here we will discuss the “Minimum Viable Architecture” concept that we introduced in our original “Continuous Architecture” book1. A full discussion of this concept, including some examples based on a simple case study, is included in that book.
Think “Minimum Viable Architecture”
Software architects and engineers are often challenged when deciding how much architectural design they should do upfront instead of at a later stage, after delivering the initial releases of a software system and when requirements, especially quality attribute requirements, are better understood. How does a team evolve their initial architecture design to handle new requirements as well as requirement changes that are quickly accumulating in their backlog?
The Continuous Architecture (CA) approach provides a proven path to answer these questions. It suggests to think in terms of “Minimum Viable Architecture”, and to start with an architectural design driven by a small number of decisions based on known facts by applying CA Principle 3 (“Delay design decisions until they are absolutely necessary”), in order to avoid including unnecessary capabilities based on guesses or vague requirements. The objective at this stage is to quickly create a software system viable enough to be used in production. Then the team needs to continuously make design decisions in order to add capabilities to their initial design as soon as new requirements or changes to existing requirements are known. In addition, it is important to communicate the plan, progress, and decisions to all the stakeholders of the system.
Let’s first explain what we mean by “Minimum Viable Architecture.” This concept is often associated with the concept of “Minimum Viable Product” (MVP), so we will start this article by providing a brief overview of this concept.
A minimum viable product can be defined as follows:
“A minimum viable product (MVP) is a version of a product with just enough features to be usable by early customers who can then provide feedback for future product development. A focus on releasing an MVP means that developers potentially avoid lengthy and (ultimately) unnecessary work. Instead, they iterate on working versions and respond to feedback, challenging and validating assumptions about a product’s requirements2.”
The concept of a minimum viable product has been actively promoted by proponents of Lean and Agile approaches, and it has worked very well at countless startups. The concept is attractive, as it enables startups to quickly and inexpensively create a product to gauge the market before investing significant time and resources into something that may turn out not to be successful.
The Minimum Viable Architecture (MVA) concept is inspired by the MVP concept but has different goals. Using the MVA approach, a team delivers a software system quickly, building it in small iterations over time. At any point in time, their software system is designed to just meet its known, factual quality attribute requirements. The approach avoids burdening the design with unnecessary features based on guesses and assumptions and helps us achieve continuous delivery of business capabilities in a sustainable way.
Using a Minimum Viable Architecture strategy is an effective way to bring a software product to market faster with lower cost. But what exactly do we mean by “Minimum Viable Architecture”? In simple terms, creating a minimum viable architecture involves the following steps:
- Initially designing just enough architecture to exactly meet the known quality attribute requirements of a software system, in order to quickly create a system viable enough to be used in production.
- Then the MVA can be continuously augmented to meet additional requirements or requirement changes as they are defined over time. Keeping the architectural design flexible is essential, and leveraging CA Principle 4 (“Architect for change – leverage the “power of small”) is an excellent way to accomplish this objective.
A sample utility tree3 for a fictional software system illustrates this point:
Under each of those quality attributes is a set of specific quality attribute refinements; for example, “latency” further refines “performance.” Each quality attribute refinement is illustrated by an architecture scenario in terms of stimulus (how the scenario is activated by an external event), response (how the system reacts to the stimulus), and measurement (which quantifies the response to the stimulus). Architecture scenarios are a great way to express quality attribute requirements because they are concrete and measurable and should be easy to implement in a prototype. However, within the context of an MVA, architecture scenarios should only capture information about known requirements.
A good way to ensure that this happens is to add a time/release dimension to the utility tree, in order to answer the following simple questions:
- How many concurrent users would be on the system at the initial launch?
- How many concurrent users would be on the system within the first 6 months?
- How many concurrent users would be on the system within the first year?
- How many transactions per second is the system expected to handle at the initial launch?
- How many transactions per second is the system expected to handle within the first 6 months?
- How many transactions per second is the system expected to handle within a year?
The time/release dimension (1 year in this fictional example) should be selected in order for the utility tree to express known, factual requirements and avoid guesses.
Many software architects and engineers tend to consider the worst-case scenario when designing a system; they may ask their business partners for the “maximum number of concurrent users the system should be able to support” without mentioning a time frame. They often add a “safety margin” on top of that number just to be on the safe side. Unfortunately, they may not realize that the number of concurrent users provided by the business could just be an optimistic guess, as business stakeholders would like the system to be successful and widely used.
As a result, the team ends up architecting the new system to handle an unrealistic number of concurrent users, which may not be reached for several years, if ever. This sometimes adds unnecessary complexity (e.g., caching components) to the architectural design. We are recommending instead to adopt a “Minimum Viable Architecture” approach based on realistic estimates at launch time and evolve that architecture based on actual usage data. Keep in mind CA Principle 3: Delay design decisions until they are absolutely necessary, and design the architecture based on known facts, not guesses!
Limiting the budget spent on architecting can be useful as well. This forces the team to think in terms of a minimum viable architecture that starts small and is only expanded when absolutely necessary.
As we move away from traditional application approaches involving large upfront architectural designs and evolve toward the rapid delivery of viable software products, we need to leverage Minimum Viable Architectures to support the continual delivery of those products in a sustainable way.
To that effect, limiting the budget spent on architecting is a good thing; it forces the team to think in terms of a Minimum Viable Architecture that starts small and is only expanded when absolutely necessary. Too often, a team will solve problems that may not exist for a long time, if ever, and yet fails to anticipate a crippling challenge that kills the software system. Getting to an executable architectural design quickly and then continuously evolving that architecture is essential for modern applications.
 Continuous Architecture: Sustainable Architecture in an Agile and Cloud-Centric World, Murat Erder and Pierre Pureur
 Minimum viable product
 Utility trees are an excellent way to document quality attribute requirements – see Software Engineering Institute, Architecture Tradeoff Analysis Method Collection https://resources.sei.cmu.edu/library/asset-view.cfm?assetid=513908