Architecture Weekly #164 - 29th January 2024

MVP, RAT, MVA and other minimum viability approaches

Jan 29, 2024

Welcome to the new week!

"How do you implement business workflows?". I'm being asked a lot about that. I tried to cover it in my articles, but many people still sought a more prescriptive way.

That's why I liked so much the Workflow Pattern introduced by Yves Reynhout. I finally found time to get my hands dirty and try to implement it in TypeScript.

I took the Group Checkout domain we modelled in the Implementing Distributed Processes webinar to implement it in TypeScript using the Workflow Pattern.

I had much fun with it, transitioning my Saga and Process Managers sample into it, and I also learned new things about the mighty TypeScript types system. I've written my findings in my latest article:

Oskar Dudycz - How TypeScript can help in modelling business workflows

Speaking about webinars on the event-driven approach, don’t miss the recording of last week’s webinar about handling event versioning!

The benefit of blogging, or other ways of learning in public, is getting feedback on your takes. Last week, I revived the topic from my older article about When Agile is not enough. I got a few nice links back. Let me go through it.

What would happen if you wanted to buy a car and a salesman offered you a scooter? Unless you're a nineties Eurodance fan, that wouldn't work for you, aye?

The famous pro-Agile drawing is a picture of how we should deliver software.

Making sense of MVP (Minimum Viable Product) - and why I ...

And that's fine if we want to buy a vehicle, and maybe anything moving us from place A to B will be enough. But sometimes we need specific things.

I think that fixation on the only way (incremental) is actually anti-agile. You are not always able to do it. If our go/no-go decisions depend on reaching a specific milestone, then delivering something subpar for the sake of iterations will be just a waste of time.

It’s great that Henrik Kniberg, author of the drawing, did a follow-up:

Henrik Kniberg - Making sense of MVP (Minimum Viable Product) – and why I prefer Earliest Testable/Usable/Lovable

He wrote:

The key question is “What is the cheapest and fastest way we can start learning?” Can we deliver something even earlier than a skateboard? How about a bus ticket?
Will this help solve the customer’s problem? Maybe, maybe not, but we’ll definitely learn something by putting this into the hands of real users.

That’s also quite aligned with the take to replace MVP with RAT:

Rik Higham - The MVP is dead. Long live the RAT.

What’s RAT? Riskiest Assumption Tests. Rik Higham wrote:

Minimum Viable Test is sometimes used as an attempt to make smaller iterations before release. This fails to capture two crucial points, though: why and what are you testing? Furthermore “minimum” is ambiguous. (…)
A Riskiest Assumption Test is explicit. There is no need to build more than what’s required to test your largest unknown. No expectation of perfect code or design. No danger it will prematurely become a product.

Indeed, the big risk is that what we built as MVP becomes a product. I don’t fully agree, that we should always decide to do spikes to throw it away. Some clients won’t just accept subpar products. But that’s a risk we should include in our viability considerations. Is our business model worth the risk of building the first version for a long time? Or maybe we should drop that idea.

Of course, I intentionally wrote Agile with capital A. I'm a big fan of the Agile approach. In the points above, I'm referring more to dogmatic agility. I'm all for the quick feedback loop and delivering in smaller, manageable batches. But I'm seeing a lot of Agile Evangelists who are just repeating the mantra without giving people enough context. Then we're ending up doing the ceremony instead of really being agile.

That also has an impact on our architecture. Pierre Pureur wrote about yet another acronym: MVA:

Pierre Pureur - How Much Architecture Is “Enough?”: Balancing the MVP and MVA Helps You Make Better Decisions

He wrote:

The MVA is the architectural complement to a Minimum Viable Product or MVP. The MVA balances the MVP by making sure that the MVP is technically viable, sustainable, and extensible over time. (…)
Together, the MVP and MVA incrementally answer the question "Is our product (and its associated software architecture) viable, e.g. supportable and reliable over the lifetime of the product?" Each MVA attempts to satisfy the Quality Attribute Requirements.

And the acceptable quality is key here. There are many different understandings of what's "minimum viable" for different products, and we should embrace that. We should work with the clients and then shape the plan instead of focusing on the ceremony of incremental partial products.

That’s also an essential part of modernising our systems. It’s not only about building new things. The process looks quite close when we’re starting the initiative to change legacy systems. We need to plan and shape the idea and make the first modernisation effort to get buy-in for it. How to tackle that? See more on the team aspects of it:

Simon Wardley - Pioneers, Settlers and Town Planners

Still, as Mike Tyson said:

Everyone Has a Plan Until They Get Punched in the Mouth

Enough about planning for today; let’s go to execution! What can be better than case studies?

Midjourney is a GenAI tool for generating images. Well, I’m sure you know it. They’re using Discord as their UI to interact and instruct tools on what you’d like to get generated. That creates an intriguing challenge for Discord, as Midjourney's popularity caused them to handle over a million users on a single server. How did they deal with it? Read their coverage!

Pierre Pureur - How Much Architecture Is “Enough?”: Balancing the MVP and MVA Helps You Make Better Decisions

What about deployment? Would you like to decrease your spending on the cloud by 100 000$? That’d surely mean that you first need to spend more than that, but that’s what Fathom Analytics did.

Fathom Analytics - Reducing our AWS bill by $100,000

Here’s the list of their savings per year:

CloudWatch - $7,550
NAT “Freaking” Gateway - $17,162
S3 - $5,774
Route53 - $2,547
Lambda - $20,862
SQS - $23,989
WAF - $12,201
CloudFront - $4,800

Plus, some other small stuff. Read more in their article, it’s a nice assessment to consider also for your spending.

Now data processing on the scale, Cloudfront provided the lessons learned from using Kafka. As always, from Cloudflare, it’s a practical and interesting coverage. Not many companies are handling processing on such a scale and performance requirements.

Andrea Medda, Matt Boyle - Tales of Kafka @Cloudflare: Lessons Learnt on the Way to 1 Trillion Messages

See also a great coverage from Gwen Shapira on Serverless Databases. So tools like Aurora, Dynamo, etc. It’s worth knowing how they work before signing for them instead of the traditional approach

Gwen Shapira - The Rise of the Serverless Data Architectures

Check also other links!

Cheers!
Oskar

p.s. I invite you to join the paid version of Architecture Weekly. It already contains the exclusive Discord channel for subscribers (and my GitHub sponsors), monthly webinars, etc. It is a vibrant space for knowledge sharing. Don’t wait to be a part of it!

p.s.2. Ukraine is still under brutal Russian invasion. A lot of Ukrainian people are hurt, without shelter and need help. You can help in various ways, for instance, directly helping refugees, spreading awareness, and putting pressure on your local government or companies. You can also support Ukraine by donating, e.g. to the Ukraine humanitarian organisation, Ambulances for Ukraine or Red Cross.

Architecture Weekly

Architecture Weekly #164 - 29th January 2024

MVP, RAT, MVA and other minimum viability approaches

Architecture

DevOps

Databases

AI

.NET

Node.js

Product Design

Management

Industry

Discussion about this post