Facilitating the Spread of Knowledge and Innovation in Professional Software Development

Write for InfoQ


Choose your language

InfoQ Homepage News An Introduction to Minimum Viable Architecture

An Introduction to Minimum Viable Architecture

This item in japanese

Agile is to balance the minimal required product with the minimal required architecture. In contrast to that in waterfall development, writing down all of the requirements on paper and then building software to those specifications is a long process that often ends with a product that lacks real user feedback. Therefore is the need of developing minimum viable product using minimum viable architecture.

As per one of the Kavis Technology blog, challenge in developing minimum viable product is the lack of appropriate architecture.

I have also seen teams lead with a series of sprints focusing entirely on architecture (we call it plumbing). This approach can be overdone and create months of design and development with nothing tangible to show to an end user, which defeats the purpose of agile. What we need is a balance of speed to market and architecture. What we need is a Minimal Viable Architecture (MVA).

In Kavis Technology blog, author recommends some questions to be asked to product owner, which help architects in creating minimum viable architecture.

  • How many users will be on the system in the initial launch? Within the first 6 months? Within a year?
  • Will the users at launch be internal users, external users, or both?
  • How many transactions per second do we expect at launch? Within the first 6 months? Within a year?
  • At launch, is the expectation that the product will be an alpha, beta, or production ready?
  • How will users be added to the system at launch?
  • What level of security and auditability is required at launch? Within 6 months? Within a year?

Randy Shoup, consulting CTO at Randy Shoup Consulting describes minimum viable architecture in his recent presentation. He explained architecture with respect to search, execution and scaling phase of the products in startup.

Randy says that during search phase, “Prototype” architecture should be used.The goal is to explore the space as rapidly and cheaply as possible. In the execution phase use “Just Enough” architecture. The goal is to meet near-term, evolving customer needs. Team can use monolithic architecture and minimal infrastructure for this. Benefits of using just enough architecture are:

  • Simple at first
  • In-process latencies
  • Single codebase, deploy unit
  • Resource efficient at small scale

Randy says that while using just enough architecture, team should keep in mind about modularity, detailed logging and continuous delivery. He quoted concept of sacrificial architecture given by Martin Fowler, author and consultant at Thoughtworks, in the context of just enough architecture as:

The best code you can write now is the code you will discard in a couple of years time.

After execution phase, comes the scaling phase of startup. At this stage team use “Next –Gen” architecture. Goal is to stay ahead of rapidly growing business. This includes scaling the team, scaling the architecture and take care of concurrency and efficiency.

Building the perfect system is rarely the correct approach.Don’t try to build the architecture, which is over-engineered. As per Randy:

If you don’t end up regretting your early technology decisions, you probably over engineered……Rearchitecting is a sign of success; if you never need to, either you overbuilt or nobody cares.

Rate this Article