What is a Minimum Viable Architecture (MVA) and why an iPaaS such as Anypoint Platform can help you achieve it

By now we have all heard about what a MVP is (or should be), a Minimum Viable Product. This hackneyed concept should allow us to get a product into the hands of users quickly and, at least in principle, at a low cost. The sooner the product is used, the sooner we learn about its uses and the sooner we can start improving it. According to this, the best way to evolve a product is to make it accessible for use as soon as possible and to extract information as soon as possible. This improves the result obtained from a sometimes eternal phase in which we design the product imagining any type of use it may have and which, inevitably, is bound to end in a product that does not meet the needs of the users.

Associated with this concept we can start talking about a MVA or Minimum Viable Architecture. Intuitively it seems that the name alone tells us what it should be, and we are probably right, adapting the previous sentence: the best way to evolve an architecture is to make it available for use as soon as possible and extract information as soon as possible. It would be an architecture that is good enough for the product to be released and that will need to be continuously improved. It involves implementing the basic architectural components that form the basis of the architecture in such a way that the end result is good enough to be released. The rest of the architecture can then be built on this foundation. In this way, the most important end-user requirements, both functional and non-functional, are prioritized and met.

MVA and MVP

It is common that when developing an MVP, promoted by the speed we are looking for, consciously or unconsciously we are making decisions that lead us directly to the lack of an architecture, or at least a defined one.

The reason for this could be the pressure to deliver functionality, focusing everything on the short term, looking for the famous TimeToMarket.

The other side of the coin would be trying to design the whole architecture in advance, trying to think about what might be needed a year from now, two years from now, and so on. And then most of it ends up in the wastebasket because the work is based on assumptions rather than actual requirements.

If you notice, in this last point we just described one of the problems that Agile was coming to solve and that should not make much sense when we are talking about building an MVP.

The reason for this happening may be that we don’t see that too much architecture can get in the way of precisely the speed we want. We may be spending too much of our precious time on getting a bomb-proof architecture when maybe what we need is a life jacket.

Characteristics of an MVA

· We should not build with the worst-case scenario in mind, but rather the most likely.

· You build in small increments over a period of time. Nothing new under the Agile umbrella.

· The main technologies should have already been evaluated and decided upon. Iterative, evolutionary, agile and re-evaluate does not mean constantly changing.

· It is built on concrete requirements, not based on assumptions.

· Focused on concrete non-functional needs and requirements. For example, if we have to support 10,000 users, even if in the future we need to support 50,000, in the first iteration we will focus on the first number.

· The architecture must support the needs and day-to-day operations of the development teams, and the development teams must understand the architecture that is being created. A misalignment between the parts is the best recipe for failure.

· Do not look for the perfect solution, as this inevitably leads to delays. Better to use Pareto and his 80/20 or, better yet, be aware that the perfect is the enemy of the good.

· It is understood that architecture is a living entity that will change over time and is not seen as something resistant to the passage of time.

· Speed is not confused with lack of quality.

· The architecture remains cohesive and each piece cooperates with the others, despite having had different rhythms.

MVA and an iPaaS

Now comes the question of how this Minimum Viable Architecture relates to an iPaaS (Integration Platform as a Service), such as Anypoint Platform.
If we start from the question of what an iPaaS is, we define it as a cloud-based platform that connects various applications, systems and technologies within the cloud or on-premises. It enables the deployment and maintenance of integration flows without the need for hardware or middleware.
If we extend it a bit further to Anypoint Platform, we can say that it is a hybrid platform that tries to solve, out of the box, all the most well-known problems you might have when implementing your integration architecture. It tries to solve things like:
- Deployments.
- Design.
- Development of integrations.
- Security.
- Communications.
- Monitoring.
- Visibility and discovery.
- Governance.

And it is in these box solutions that we can begin to see the relationship with an MVA. The implementation of one of these iPaaS can be taken as, at least the basis or the principles, of this MVA. These already known and tested solutions begin to form the list of those basic architectural components that we have said form the MVA, and on which our own architecture begins to form. Having these components available from the beginning can be a huge advantage in order to achieve the desired speed to make our architecture available and start evaluating it as soon as possible.

It is easy to see how, in an Integration Architecture context, the implementation of an iPaaS, with the necessary adjustments for the organization, product or specific system, gives us the basis to start creating our solutions in an agile and fast way, being able to build products on a firm foundation that will evolve over time.

Even in the case of Anypoint Platform, MuleSoft and its API-led Connectivity approach we can start building with a concrete and defined mindset to create a logical architecture ready for change and for the holy grail of reusability.

But let us not forget the characteristics that we commented that these MVAs had, which are based on concrete and known requirements. Surely, if the future is uncertain, it will be better to tackle the initial problems as they are, but at the same time, we should not give up on quality.

As always, we will have to think about the type of trade-off we will have to make.