Minimum Viable Architecture for Agile Development

The Definition

Minimum viable architecture (MVA), also called ‘just enough architecture’, is an agile approach to software architecture and a concept akin to the minimal viable product (MVP).

In the traditional waterfall approach to development, the code would start being written after every aspect of the development lifecycle had been detailed and accounted for. The architecture would take time to be set up and would probably be irrelevant by the time it is ready. The development team would either recreate the architecture, which would be just as time-consuming or make do with it to build solutions for current needs.

Given today’s fast-paced business environment coupled with ever-changing requirements and rapidly changing technological developments, this approach will be highly ineffective. The upfront designing of architecture in the waterfall-style approach will slow down development, will be unable to take in feedback, and will not keep pace with the business’s changing needs.

Unfortunately, until recently, this approach has been carried forward to agile development too, in anticipation of the what-if scenario.

The solution to this lies with MVA. MVA is a more suitable approach where a bare-bones, basic architecture is initially built, with features that can set the software development process in motion. Just like in the MVP, where developers start small and respond to varying needs, MVA architecture too is started small and built based on the changing needs.

Faster Time to Market at Lower Cost of Development

With MVA, the risk of over-engineering the architecture from the beginning is minimized and can be built in small increments, thereby lowering the cost of development. MVA allows software developers to focus on the core, foundational architectural components of the software and systems by creating a working base and building the rest of it as you go.

One of the greatest benefits of this approach to development architecture is that it lowers the cost of the architecture, enables businesses to invest in technologies that are relevant, is flexible and scalable, enables the release of features, and updates faster. As a result, feedback starts flowing in early, making every release and enhancement over the previous one with minimum rework.

Best Practices for MVA

To successfully implement the MVA approach, architects must ensure the following:

• Identify the most likely scenario and build for that, instead of building for the least-likely, worst-case scenario.
• Identify and choose must-have features that solve the customer’s problems rather than choose to good-to-have features.
• Have a well-defined strategy and metrics to measure success and remain focused.
• Build incrementally over a period and evaluate the programming languages and other technologies best suited for adapting to changing needs. They should not be changed mid-course.
• Collect and document requirements and build based on that, rather than on assumptions.

As an architect, one must:

• Know the Product: Have a clear understanding of the functional requirements to ensure that the architecture can support the features and their expected usage.
• Focus on Performance: Understand the nonfunctional requirements of the product. A product with many releases planned may have a different set of nonfunctional requirements for each release. The architect must know this and build only for those needs.
• Requirements of Codes: Understand the code and the modules to build a suitable environment that facilitates programmers to develop without facing challenges.
• Plan Just Enough: Strike a balance between the speed of building the architecture and having just enough components to get going. Architects must remember to not aim for a perfect solution.
• Mindset Change: MVA requires all the developers, architects, and other stakeholders to be open to this new approach and not look for a lasting solution. They must be made aware that if something is not working, it can be fixed as they go.

What is Just Enough?

Although we say that architecture needs to be just enough, arriving at what is enough can be challenging. Product viability and sustainability are the fundamental criteria for determining whether the architecture is enough or not.

In addition to that, factor in the number of concurrent users/devices/sensors that are expected to use it at the same time. Calculate how many transactions or data the product will be expected to be processed in any given time for improved throughput. Understand the speed at which the product must respond to events. Knowing how quickly and by what factor the infrastructure must scale up during peak periods. Ensure that the MVA is well-protected from malicious intruders and can maintain privacy, safety, confidentiality, integrity, and availability.

The MVA must enable tracking and monitoring of the product’s performance and alerting if the product fails to meet QARs or prevent critical system issues. It should have sufficient resources such as memory, storage, and signaling, among others. The user interface must allow the product to communicate with users effectively.

Also Read: Enable Increased Revenue using Rapid Application Development

How Indium Can Help

Indium Software is a cutting-edge technology company with wide experience in software and architecture development, testing, and providing data solutions. The cross-domain expertise helps Indium understand its customer’s pain points and design and develop bespoke solutions to launch them on an accelerated growth and innovation journey.

At Indium, we begin by.

• identifying our customers’ business needs
• mapping the customer journey
• identifying the features that need to be built first.
• defining the strategies
• establishing metrics for measuring success
• defining a development methodology
• zeroing in on the tech stack
• identifying the processes and roles that will be affected by the change.
• defining the MVA model

FAQs