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


Hello stranger!

You need to Register an InfoQ account or or login to post comments. But there's so much more behind being registered.

Get the most out of the InfoQ experience.

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Community comments

  • But the key to this is...

    by Andy Miles,

    Your message is awaiting moderation. Thank you for participating in the discussion.

    You can get the technology decisions wrong as long as changing the technology doesn't mean throwing away all your business logic and starting again. There always has to be coupling somewhere; just don't couple your business logic tightly with the technology.

  • Playing devils advocate for a minute...

    by Robin Villiers,

    Your message is awaiting moderation. Thank you for participating in the discussion.

    I completely agree with this article. I can only offer one counter argument:

    Once you have delivered, you have lost your mandate for delivering something. This is a political argument and points rather to a problem with the organisation rather than the architectural design.

    What I've experienced in the past is that while you may be making the correct choice delivering exactly what is needed at the time, the political judgement once the scalability of the delivery is revealed to be insufficient is extremely negative.

  • Err, no

    by Luis Espinal,

    Your message is awaiting moderation. Thank you for participating in the discussion.

    <quote>If you don’t end up regretting your early technology decisions, you probably over engineered</quote>

    More often than not, when you regret your early technology decisions (or architect/design decisions), you probably under engineered.

    In 18 years of work, in both small or large shops, both commercial and defense, I've seen far more under-engineering (typically in the form of happy-case-only programming) than over engineering, independent of methodology (agile/scrum, iterative all the way back to waterfall.)

    <quote>Rearchitecting is a sign of success; if you never need to, either you overbuilt or nobody cares.</quote>

    This claim is even more dangerous. It is ok to do refactoring, in fact, it is necessary to maintain a healthy control of entropy.

    Re-architecting, on the other hand, that is another ball game.

    There are tactics, and there is strategy. Continuous tactical changes (represented in design and implementation improvements) are a sign of success in having a good process in place.

    Strategic changes (represented by potentially costly architectural changes), they can only come when they are truly needed, and must be minimized.

    Why? Because of the cost. If re-architecture is required because of an externally driven event (say, a merger between companies, or bankruptcy by a provider of a vital COTS component), then achieving it would be a success.

    Re-architecture because enough diligence wasn't made up front (simplest architecture == simplistic architecture), then that is a change that was preventable via greater architectural diligence up front. It is a change that costs money (and since it was preventable, it must be seen as a loss.) Thus, it is a failure, not a success.

    This is excluding the growth, extension and enrichment of an architecture that is amenable to enrichment. I would not call that re-architecture.

    Re-architecturing, the mere notion of the word, and using analogies from the physical world, implies significant, if not destructive changes to the original architecture.

    You don't go from pipes and filters to an event driven architecture and call it success on the effort if you knew a-priori that the problem statement required the later and not the former.

    That is a failure no matter how you cut it because. And it seems to me that a lot of people conflate architecture with design or implementation-level details.

  • Scale Issues

    by John Andrews,

    Your message is awaiting moderation. Thank you for participating in the discussion.

    I like the concept of Skateboard, Bike, Small Car, Large Car to show MVP. But how do I go form a skateboard to a canoe? The business logic is reusable to some extent, but as the technology will not scale, I need to start over. Starting over on different tech requires new logic. All I keep is the requirements and I lost a lot of time with my business partners. What can be done upfront to check viability of scale?

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p