Minimum Viable Architecture for MVP

The Minimum Viable Product can provide value beyond the startup ecosystem. As Wikipedia says which is true also : "If the focus is more on creating the MVP then developers don't want to go through a long process of developing the product. They want to get started with a minimalistic demo then improve it by iterations and feedback loop. That makes complete sense too, if you think about it, you will take years to build the perfect product but in the end you will find that it's not deployable, that will heart to the core of heart.

One thing may get missing in the hurry of building the MVP is the MVA(Minimum Viable Architecture). It should be influenced by QAR(Quality Attribute Requirements) rather than the Functional Requirements. After sometime when the MVP will turn into a full fledged product then sustainability will cause an issue because initially the developers didn't pay that much attention to the MVA. Following this they have to refractor some code, tech debt will be there, time & effort will be required for this so that the old MVA will fit into the updated MVP. Well here are some points to ponder about the MVA :-

• The specific decisions which will impact the MVA at a large scale and support mostly to QAR, sustainability and viability. Those decisions should include few of the characteristics :- Concurrency, Throughput, Latency and responsiveness, Scalability, Persistency, Security, Monitoring, Platform and User interface.

• While building the MVA alongside the MVP with agile approach(sprint, scrum etc), developers should keep in mind that both these should support to the QAR of the product. Unnecessary features shouldn't clutter the structure. Later which will help to build the Continuous Delivery of the business area.

• Following the feedback loop the team should build the MVP and MVA simultaneously by keeping the MVA flexible using the Continuous Architecture Principles. As the team learns more about customer requirements with facts, they should add the functionalities instead of adding them based on guesses.

• Hypotheses and Experiments are also effective in keeping the sustainability and QAR in track. A belief based on some observations is fine to think that it will lead to somewhere if implemented. Whereas what the Empirical Approach does is, it provides proper experiment plans based on the hypothesis in a hope that it will succeed to provide the expected value. Rather than building the whole feature, a team can build the feature small enough to prove/reject it's value. And these kind of items should be there in the product backlog so that when the team plans for scrum or sprint these key points will be added there too.

Keeping the architectural decisions transparent helps the organization to have a better clarity on why this decision have been made, helps to add value to the product as it evolves, add more stuff to it as per the customer demands.

Thanks for reading up to here😊

source

InfoQ Article