The Balance of MVP ( minimum viable Product ) and MVA ( minimum viable Architecture )

No matter what you do, you will end up with an architecture. Whether it is good or bad depends on your decisions and their timing.

In an agile approach, architecture work has to be done as a continuous stream of decisions and experiments that validate them. The challenge is how to do this under extreme time pressure.

Developing a system in short intervals is challenging by itself, and adding "extra" architectural work adds complexity that teams can struggle to overcome. Using decisions about the MVP to guide architectural decisions can help teams decide what parts need to be built with the future in mind, and what parts can be considered "throw-aways".

The concept of a "last responsible moment" to make a decision is not really helpful: teams rarely know what this moment is until it is too late. Using the evolution of the MVP as a way to examine when decisions need to be made provides more concrete guidance on when decisions need to be made.

With an agile approach, there is no point at which "minimum viability" as a concept is abandoned.

Which decisions should architects make?

"A decision that you wish you could get right early"

Now there are 3 ways to look at it :

1> Architectural decisions directly or indirectly determine the non-functional characteristics (or qualities) of a system.

2> Each decision describes a concrete, architecturally significant design issue (problem) for which several potential solution options exist, and provides rationale for the decision outcome (the selection of the chosen solution option, that is), for instance by arguing whether and how the desired quality attributes will be achieved.

3> Architectural decisions concern a software system as a whole, or one or more of the core components of such system (whatever the “core” is).

What makes an issue architecturally significant?

Below seven points can be used to assess significance quickly:

1> Impact on business value and risk?

2> Key stakeholder concern?

3> Unusual quality-of-service requirement (at least one order of magnitude more advanced than previous ones)?

4> About external dependencies that are uncontrollable, unpredictable or unreliable?

5> Cross-cutting, system-wide impact?

6> First-of-a-kind character (novelty for team)?

7> Caused bad experience and trouble in the past?

So What questions the Architectural decisions focus on ?

1> Scalability: will the product perform acceptably when workloads increase?

2> Security: will it be acceptably secure?

3> Responsiveness: will it provide acceptable responsiveness to user-initiated events? Will it provide acceptable responsiveness to externally-generated events?

4> Persistency: what are the throughput and structure (or lack thereof) of data that must be stored and retrieved?

5> Monitoring: how will the product be instrumented so that the people who support the product can understand when it starts to fail to meet QARs and prevent critical system issues?

6> Platform: how will it 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.

7> User interface: how will it 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.?

8> Distribution: Can applications or services be relocated, or must they run in a particular environment? Can data be relocated dynamically, or does it have to reside in a particular data store location?

9> Sustainability: Will the product be supportable in a cost-effective way? Can the team evaluate the quality of their architectural decisions as they develop the MVA, by adding sustainability criteria to their “Definition of Done”?

What could be the outcomes with each MVP delivery ?

With each MVP delivery, there are several possible outcomes:

1> The MVP is successful and the MVA doesn’t need to change;

2> The MVP is successful but the MVA isn’t sustainable;

3> The MVP is partially but not wholly successful, but it can be fixed;?

4> The MVA is also partially but not wholly successful and needs improvement;

5> The MVP isn’t successful and so the MVA doesn’t matter

Finally, we should assume that every architectural decision will need to be undone at some point. Make options for yourself and design for replaceability. Isolate decisions by modularizing code and using abstraction and encapsulation to reduce the cost of undoing decisions.