Minimum Viable Architecture (MVA) and how it is different from MVP

Engineering has always been problem-oriented, and the newest solution to today’s business problems has taken the form of the MVA – Minimum Viable Architecture. Minimum Viable Architecture (MVA) is an unfolding discussion among leading CTOs. For instance, the CTO of an ad-tech company with her article on the topic in Forbes just this year argued that 

“The MVA approach can turn a company into a powerhouse of products”. 

Another example is Randy Shoup, Chief Architect at eBay, with his speech during the YOW!2022 conference. He states that MVA – “Just Enough” architecture is what 99% of apps need to operate successfully. In the speech, Randy Shoup insists on setting the MVA concept against the microservices architecture.  A year after this speech, the internal case study surfaced stating that a company actually had to reverse from microservices to a monolith to reduce costs by a whopping 90%. The screenshot is provided below.

Overall, Minimum Viable Architecture is a foundational concept that can underpin any product development from “Ideation” through “Starting” to “Scaling” and “Optimizing” stages. It can work for an MVP or more complex solutions like an MMP, MLP, or even a systemic solution. 

In general, the Minimum Viable Architecture emerges to be invaluable in two directions. 

• One is launching your startup in a market where each solution embeds a range of complex functionalities. 
• Another one is when MVA helps to avoid over-engineering. 

Read on for more details!

MVA for competing in multi-product segments

For quite a few segments, there is simply no narrow subgroup of core functionality that can be viable. In physical product terms, what would be a minimum viable product for a Vision Pro or a work of art by a professional? In the same vein, there are such digital platforms and solutions that if you want to compete with them, there is no simpler narrower version you could go for. 

Industry examples

Let’s break it down by industries:

• Marketplaces. Amazon is an ecosystem that is built on top of an online marketplace. It’s been extended to include cloud services, IoT for smart homes, and groceries. 
• Healthcare technology. Take for example Philips Health Suite. It is a complex digital health platform designed for clinical personnel to monitor patients via devices and applications. It combines telemedicine, remote monitoring, work with patient data, and health analytics.
• Fintech. Consider PayPal. It is now more than an online payment system. It added a layer of working with crypto, savings, investment, and insurance. It is set out to become a one-stop financial hub. 
• SaaS. Let’s look at HubSpot. It is a suite of software and services that originally started as a marketing tool for small businesses. Now it has grown to become a platform to manage a variety of marketing pipelines and includes a Customer Relationship Management system. 

Realistically, there is an example in every segment. 

Therefore, it is viable to consider a family of products that your startup will grow simultaneously yet the pace may differ. You don’t want to launch several independent MVPs for each bit. You need to launch it as a single unit so that they can share inputs-outputs and a user base. Yet, each component must preserve its “independence” and preferably have the option to be on or off for a particular user. Therefore, the question is which architecture can ensure this? MVP’s approach is not enough, microservices/distributed system is often too much. This is where the MVA architecture becomes the most optimal solution. 

MVA and blitzscaling

As a side note, in the realm of venture capitalists and investors, there is a trend of blitzscaling. This is when you prioritize the speed of scaling over efficiency. Generally, it occurs in two cases. 

1. When to become competitive, a startup needs to gain “critical mass”. 
2. Or, when there is a high risk of competition appearing so that you need to get to market faster. 

Therefore, you need to build out all possible solutions/functionality to take up the market. This way you block the way for competition to emerge and redirect users to their product. When such high-paced growth is in need, you will generally spend upfront on a larger team and digital infrastructure.  Yet again, in this case, your user base must be a platform for all parts of your startup. They need to create synergies to power up your growth. MVA is yet again the best option and MVP with its reliance on organic growth and lean feature set won’t suffice.

MVA to counteract over-engineering

There is an S-curve that describes how the business grows (the graph below). At Ideation, you might get your first 100 customers signed up for a prototype. It starts to take shape during the Starting phase, and your user base grows yet slowly. At Scaling, the user base might grow exponentially so your infrastructure is nearing its limits and starts buckling under pressure. It is when you rearchitect. At the Optimizing stage, some of the services might dwindle down, so you repurpose some codebase, discard some, and realign the rest to match evolved user demand.

In this business journey, it’s important to highlight that only around 1% of apps reach the Scaling phase. But the problem is that knowing that at this stage your infrastructure will need to change, some make a decision to implement this infrastructure early on. 

Randy Shoup in his talk gives an example of Amazon’s and eBay’s first infrastructures. Even though they were hard to maintain, he says that nobody starts with a distributed system. Arguably, there probably were other startups like Amazon and eBay who foresaw the challenges of a monolith at scale. They probably went on to make a “better” solution. Yet, we’ve never heard of them. The bottom line is that if you start with a distributed system, you are likely overengineering. It robs you of speed and undermines success in the present, ultimately killing off any future prospects. 

Lastly, looking at Amazon and eBay’s early days example – to implement a distributed system back then, the companies would have had to rely on experimental and bleeding-edge technology and write a ton of custom code. That’s a huge risk. The MVA approach is against that. 

So let’s look at the MVA approach for business growth. 

Idea Phase – Prototype Architecture

At the Idea phase, your business is figuring out the problem it is going to solve for the customers. Your startup is finding answers to the following questions:

• Are people willing to pay for solving this problem?
• What business model is best?
• Is there a product-market fit?

The MVA for this stage is called “Prototype Architecture”. Whatever coding you do is going to be discarded. It has to be fast and cheap. And, actually, the perfect solution to this phase is no code at all. You can launch fake ads, show paper designs for your UI/UX, and whatnot. At most, you can put together something from existing services to test your idea, validate your hypothesis, and get your first clients. This aligns with the concepts of lean MVP development.

So, the minimum viable architecture (MVA) at the Idea Phase is Zero Architecture. You should first explore non-technological solutions to test/validate.

Starting Phase – “Just Enough” Architecture

“The best code you can write now is code you’ll discard in a couple of years’ time.”

By Martin Fowler

So if you look at S-curve, ideally, in a couple of years’ time your business will be scaling and moving to more advanced infrastructure. So, it all adds up. MVA is called “Just Enough” because your business will use it as a stepping stone and will move on from this. As such, there are several key rules to follow.

• Using simple and familiar technology rather than newer and as such evolving and less stable technology;
• Prioritize frameworks that are easy to use for prototyping. Usually, more secure and reliable languages require multiple layers of abstraction which translates into a lot more code, files, practices to organize them, documentation, and such;
• Monolithic architecture: single codebase, single application; yet you should enforce modularity inside the monolith. 

Architectural Guidelines for Minimum Viable Architecture (MVA)

Reasonably, if you are going to discard that codebase, you want to spend as little money, time, and effort as possible. How can you ensure the development is ‘cheap’?

• Don’t build services from scratch if you can purchase ready-made solutions; 
• Don’t invest in your own infrastructure when you can pay for cloud services and other pay-per-use options;
• Similarly, don’t invest into your own data centers;
• Check out open source technology first – it’s often much better than its paid counterpart;
• When it comes to security and cryptography, rule number one is also to utilize the existing solutions. They are better, tested, proven, and maintained at a higher level than any custom one;
• Always utilize third-party solutions instead of reinventing the wheel. There are reliable third-party solution for all common functions, such as:
  • Authentication, 
  • payment gateways, 
  • automated billing software, 
  • fraud prevention/detection software, 
  • loggers and error handlers, 
  • monitoring and alerting and so much more.

The goal of MVA is to focus on core functionality, and purchase all the rest.

Enable Experimentation with your MVA

1. Within “Just Enough” architecture you need to acquire great tooling for motoring the user behavior. The Starting phase relies on learning and fast iteration. Therefore, it is a must to check out open-source solutions as well as paid solutions for that purpose depending on your project’s needs. 
2. Additionally, setting up CI/CD pipelines is applicable at this stage and will benefit your business greatly. The faster you can iterate: deliver those changes and recover/rollback if needed, the better. When you automate the release process, you can allow for smaller sizes of work to be submitted and ‘pushed’. 
3. Go for feature flags that are available as part of AWS config, or with other tools like split.io, or open-source FlagSmith, and others. This allows you to detach your code works from operations and business considerations. You can deliver and turn on/off certain functionality for a selected group of users. It also enables you to do the experimentation so that you can see how much each feature is adding to the user experience.

Minimum Viable Architecture and A/B testing

In Grace Hopper’s words:

“One accurate measurement is worth more than a thousand expert opinions.”

In MVP methodology, you often find yourself having expert interviews, but it is often an activity for an “Idea” phase. After that, every MVP iteration within MVP development relies on measurement. And so, the MVA architecture emphasizes tooling for conducting A/B testing.

The power of A/B testing becomes obvious in the examples of the industry’s tech giants. Microsoft conducted an A/B testing where part of the users who clicked on Hotmail had a new tab opened instead of opening in the current one. The test showed a substantial almost 9% engagement increase. After the testing was repeated with a different user base, the results were confirmed and the feature released. 

A/B testing allowed Bing management to put a price tag on performance optimization. Bing conducted testing when it set different wait times for several groups of users. As a result, a 100-millisecond delay had a 0.6% loss of revenue. For Bing, it would have amounted to $18 million in annual revenues. So they decided that funding a team to optimize performance would pay off. 

Moreover, A/B testing can actually be used to track how “smaller” functionality impacts the performance of the overall system. It is done by turning it on/off for different user bases and comparing the results of interactions. Such testing often produces actionable and revenue-improving insights.  

Overall, A/B testing is widely adopted among the best companies. It is estimated that Microsoft, Google, Amazon, Facebook, and Booking.com perform at least 10,000 A/B testing experiments every year.  Alike, all modern and professional Startup Services include effort to enable A/B testing on your project.  

Scaling Phase – Redesigning

The main takeaway when considering investing into long-term architectures is that only around 1% of all apps worldwide actually need it. And even if your project has great funding available at the start, it still will not make much sense to skip through the monolith infrastructure as described above. There is a separate checklist to re-engineer the previous “Just Enough” MVA. The three major criteria:

• You cannot release features as fast;
• You have several development teams and their effort becomes counterproductive;
• When adding new engineers, it takes a lot of time for them to start being effective.

Additionally, the MVA approach is to re-engineer a module one at a time. It is worth noting that you should start with the one that has the higher ROI – Return on Investment. 

If you want to make sure your product is ready to scale, check out “When to Scale a Startup or What Comes After MVP?“

Final Words

To conclude, MVA is the enhanced version of MVP to cater to a family of products, complex functionalities, create synergies within the product, and capitalize on your user base. MVA follows the lean iterative MVP development principles, yet it adds even more flexibility and agility along with a roadmap for several products.

FAQ: Minimum Viable Architecture (MVA)