A Minimum Viable Product Needs a Minimum Viable Architecture

The concept of a Minimum Viable Product can help teams focus on delivering what they think is most valuable to customers, early, so that they can quickly and inexpensively gauge the size of the market for their product before investing significant time and resources into something that may turn out not to be successful. Briefly, an 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 requirements.”

The MVP concept is useful beyond the startup context, however. Every application has an initial release that can be thought of as an MVP. Stories abound from nearly every organization of how they spent months or years developing a new system, then deploying it only to find that it did not meet the needs of its users. Releasing an MVP earlier helps to prevent investing lots of time, money, and effort on the wrong requirements.

To better understand the goals of an MVP, consider what it means to be “viable.” The MVP must demonstrate that it delivers value in sufficient quantity, for a sufficient number of people, for it to be economically viable. In short, it must be something that enough people will buy so that it provides a good return on investment. In other words, you have a problem that is large enough—and for enough people—to be worth solving. But economic viability has another dimension: cost. The product must be both affordable, and its total lifecycle cost must be within limits defined by the desired profit margin for the product.

And using modern agile approaches, the product must be able to evolve incrementally based on feedback and changing needs over time; unlike mere prototypes, the MVP is not intended to be “thrown away.” This is where a Minimum Viable Architecture plays an important role.

What is a Minimum Viable Architecture?

When people use the term “Minimum Viable Architecture” (MVA), they usually mean one of the following:

• A design involving a minimal set of components. When teams focus mostly on implementing an MVP as rapidly as possible, their MVA tends to be influenced mostly by its functional requirements rather than its Quality Attribute Requirements (QARs) which may yet be poorly understood. Their design decisions tend to be tactical, since speed is their primary concern, and they generally expect the MVA to need to be reworked should the MVP turn out to be successful and evolve eventually into a full-fledged product. The sustainability of the product is not a priority. Components used to assemble the MVA may be sourced from the off-the-shelf offerings provided by a commercial cloud vendor, low-code or no-code products, or reused from an existing system with minimal changes.

The flaw in this approach to MVA is the belief that “the architecture of the solution is not important to the customer.” But customers do care about the sustainability of the solution, which makes the architecture important to them. As we pointed out in a previous article , this approach may involve significant refactoring of the initial design, resulting in wasted time and effort, and potentially creating significant technical debt. Deciding to put delivery speed ahead of architectural concerns (which is, in itself, an architectural decision that should be documented) may be the right thing to do, especially if the team’s current cycle time is too slow to provide an effective feedback loop. But the team should be willing to accept the possibility that much of what they deliver might need significant rework at a later time.

• A small set of fundamental choices that the development team has made about the solution. This definition focuses on the sustainability, the long-term viability, of the MVP by considering how the product will meet its QARs in addition to its functional requirements while minimizing technical debt to achieve sustainability. As we pointed out in another article, software architectures are driven by QARs, not by functional requirements. The MVA in this approach consists of a minimal set of technical decisions that are tested and evolved using empiricism over time. These decisions are complemented by a minimal set of architectural practices that help the team to keep the product architecturally viable while they evolve it.

What kinds of decisions shape the MVA?

Answering the question of “what is just enough?” depends on whether an architectural decision must be made in order for the product to be viable. If making (or not making) a decision will affect the product’s viability and sustainability, or if changing the decision would be so costly in terms of money or time that doing so would make the product uneconomic, impractical, or impossible, then that decision must be made a part of the MVA.

These decisions include how the product will handle QARs that are associated with product/system characteristics such as: 

• Concurrency—relating to the number of concurrent users, sensors, and other devices that create events to which the product must respond.
• Throughput—relating to the volume of transactions or data that the product must be able to process over a defined time period.
• Latency and responsiveness—relating to how quickly the product must respond to events.
• Scalability—relating to the ability of a system to handle an increased workload by increasing the cost of the system, general in a near-linear relationship.
• Persistency—relating to the throughput and structure (or lack thereof) of data that must be stored and retrieved by the product. Often includes decisions about different kinds of data storage technologies (e.g. SQL DBMS, NoSQL DBMS, etc.).
• Security—relating to how the product will protect itself from unauthorized use or access to product data, by achieving confidentiality, integrity, and availability.
• Monitoring—relating to how the product will be instrumented so that the people who support the product can understand when the product starts to fail to meet QARs and prevent critical system issues.
• Platform—relating to how the product will meet QARs related to system resource constraints such as memory, storage, event signaling, etc. For example, real-time and embedded products (such as a digital watch, or an automatic braking system) have quite different constraints than cloud-based information systems.
• User interface—relating to decisions made about how the product will communicate with users; for example, virtual reality interfaces have quite different QARs than 2-dimensional graphical user interfaces, which have quite different QARs than command-line interfaces. These decisions may affect other QARs noted above. (GUI, VR, command line, or other kinds of interfaces.)

This list is not exhaustive, and development teams may need to add or subtract from this list based on their own QARs.

How development teams evolve their product’s MVA 

Unlike throw-away prototypes, a development team builds their initial MVA as part of building the MVP, which is the first release of the product. Using an agile approach, just as they evolve the MVP in a series of iterations (or Sprints, in Scrum), they also evolve the MVA. At any point in time, their product should meet its known, factual QARs. In doing so, they don’t burden the product with unnecessary features based on guesses and assumptions, which helps us achieve continuous delivery of business capabilities in a sustainable way.

At a conceptual level, this approach can be described as follows:

• The team initially develops just enough architecture to exactly meet the known QARs of a software system to quickly create a product viable enough to be used by real customers.
• Then the team continuously evolves the product to meet additional requirements or requirement changes (including QARs) as they learn more about what customers really need. Keeping the architecture flexible is essential, and applying the Continuous Architecture Principles, especially Principle 3, “Delay design decisions until they are absolutely necessary,” is an effective way to achieve this objective.

In short, as the team learns more about what the product needs to be, they only build as much of the product and make as few architectural decisions as is absolutely essential to meet the needs they know about now; the product continues to be an MVP, and the architecture continues to be an MVA supporting the MVP. The reason for both of these actions is simple: teams can spend a lot of time and effort implementing features and QARs in products, only to find that customers don’t share their opinion on their value; beliefs in what is valuable are merely assumptions until they are validated by customers. This is where hypotheses and experiments are useful.

In simplified terms, a hypothesis is a proposed explanation for some observation that has not yet been proven (or disproven). In the context of requirements, it is a belief that doing something will lead to something else, such as delivering feature X will lead to outcome Y. An experiment is a test that is designed to prove or reject some hypothesis.

Every feature and every requirement (including QARs) really represents a hypothesis about value. One of the goals of an empirical approach is to make these hypotheses explicit and to consciously design experiments that explicitly test the value of the features and requirements. The entire feature or requirement need not actually be built to determine whether it is valuable; it may be sufficient for a team to simply build enough of it to validate critical assumptions that would prove or disprove its value.

In the context of an MVA, teams will validate their assumptions about the solution in every iteration (Sprint), by testing them empirically, and then making decisions based on what they learned. In the context of Scrum, for example, the Scrum Team would factor in what they need to learn by ordering the items in the Product Backlog; the Product Backlog itself would consist of both functional requirements (things like features and stories) and also QARs. 

As the team plans a Sprint, they pull items from the Product Backlog to satisfy the goals of the Sprint, which would reflect not only hypotheses about the value that the product provides to customers, but also hypotheses about how the product increment will be sustainable as it is evolved over time. The order of the items in the Product Backlog, including QARs, will therefore force the team to confront their assumptions about value and how the product will have to work to sustainably deliver value.

Conclusion

MVPs need to consider not only the market viability of a product but also its technical viability to be maintained and adapted to changing needs over time. MVPs are not limited to the startup context, since every application has an initial release that can be thought of as an MVP, and they can be a useful component of product development strategies. Creating an MVA as part of an MVP helps teams to evaluate the technical viability and to provide a stable foundation for the product that can be adapted as the product evolves. Making the architectural decisions transparent helps the organization to better understand why certain choices have been made, which helps them make better decisions about how they can adapt the product to changing market conditions and evolving customer needs.