Musings of a Trust Architect: Minimum Viable Architecture (MVA)

ABSTRACT: Minimum Viable Architecture (MVA) is an alternative to the Minimum Viable Product (MVP) approach, emphasizing the importance of a robust, scalable, and expandable architecture. The MVA methodology mitigates risks associated with reputation, competitiveness, and architectural deficiencies, and fosters collaboration among competitors. Real-world examples, such as SSL/TLS and the Gordian system, illustrate the successful implementation of MVA in software development.

A business methodology focused on producing a Minimum Viable Product blossomed in the 21st century. Unfortunately, it can set businesses up for future failure because it doesn’t properly define the larger architecture that is needed to evolve a product past its earliest, minimal state.

The Old Methodology: Minimum Viable Product

A Minimum Viable Product (MVP) is a business methodology that advocates creating the simplest possible version of a product as a first release, to see if the market responds positively, or else to understand why it doesn’t¹. If an MVP is successful, possibly through iterations of the initial work, the product can then be grown and ultimately find large-scale success in the market.

Twitter has long been used as an example of an MVP that did great, with Dropbox and Facebook being other examples of MVPs² (to various extents). By the criteria of these companies, MVP would seem to be a win-win methodology.

However, they’re not the full story.

MVP Biases

Unfortunately, current literature about Minimum Viable Products suffers from Survivorship Bias. We hear about the success of companies that used MVPs, but we don’t know that their doing so actually led to success. In fact, the successes that we see might just be a false signal.

How many hundreds or even thousands of companies pursuing MVPs failed for each Twitter or Facebook that succeeded? How many companies found that they couldn’t scale their MVP, realized that they couldn’t take commercial advantage of an otherwise successful MVP, or simply were beaten by competitors with even more viable products?

We can’t measure the success of the MVP methodology by the anecdotal success of a few individual companies.

Survivorship bias image by Martin Grandjean (vector), McGeddon (picture), Cameron Moll (concept). Released under cc by-sa 4.0.

MVP Dangers

The MVP system also has other dangers.

Some of these are related to company brand. Though a new company doesn’t have a reputation to damage, a series of unsuccessful MVPs could nonetheless curtail their future opportunities. Meanwhile, a more mature company might find their existing reputation blemished by a poor MVP. This is especially true today, as companies are increasingly saying that MVPs can be poor-quality releases³. That didn’t work out that well for Cyberpunk 2077, one of the highest profile and most controversial computer game releases of recent years, even though (like many modern-day computer games) it wasn’t quite released as an MVP, but not in a fully complete form either⁴.

There are also competitive dangers. Within a developmental niche, MVPs only work if everyone pursues them; otherwise, an MVP built on solid ideas could easily be out-competed by a firm who produced a slightly more mature prototype. Similarly, a company with more resources might be able to scoop up the ideas in a MVP and replicate them to their own advantage⁵.

However the biggest dangers of MVPs are probably architectural. By defining an MVP, a company can easily ignore the larger architecture issues that would have once been considered before starting work on any serious release. This can cause problems with scaling, with missing features that can’t easily be added, and with locked-in decisions that become part of the final product.

Twitter (“X”), for example, didn’t finalize its network architecture design until 2010⁶, four years after its advent. It would have been easy for a better architected social-medium system to get in there first; the fact that no one did is one of the pieces of luck that led to Twitter’s ultimate success. In fact, one of the developers at Twitter has noted this, saying: “In the end, Twitter barely made it, and product progress was slow for years due to post facto infrastructure investment.”⁷

The biases and dangers implicit in MVPs suggest the need to at least experiment with other methodologies for product releases. The huge problems implicit in the potential lack of architecture in an MVP also suggest what that alternative methodology should be: a Minimum Viable Architecture.

A New Methodology: Minimum Viable Architecture

Minimum Viable Architecture (MVA)⁸ is a methodology that has been discussed in somewhat different forms over the last several years. It doesn’t focus on the simplest product that can be released to consumers, but instead on the simplest architecture that can support future development within a product’s technological ecosystem.

The goal of an MVA is still to create a product that doesn’t strain the resources of a company and that doesn’t create a situation where a company’s ultimate success or failure depends on that singular release. However, that simple product must be created with the understanding of a larger architecture that has enough flexibility⁹ that designers can fill in gaps in that architecture in the future. It’s just that the decisions for filling in those gaps are delayed as much as possible¹⁰. It’s a melding of agile methodologies with architectural concerns.

Though an MVA could be created with a full understanding of future expansions that may or may not be ultimately accomodated, it’s more powerful to create an MVA that is modular and expandable — that doesn’t depend on the architect thinking of everything, but instead future-proofs itself so that the architecture could include unthought-of elements in the future. As Jorge Lebrato says: “The architecture remains cohesive and each piece cooperates with the others, despite having had different rhythms.” The best MVA is a compromise between entirely ignoring the architecture (as is likely in an MVP) and designing it entirely (which would likely result in time cost and waste)¹¹.

MVA Examples

The following examples contain some real-world usages of MVA instead of MVP.

SSL/TLS

When I co-authored the TLS spec in the ’90s, I did my best to future-proof it by simultaneously constraining the design and giving it enough flexibility to be expanded in the future. This is an example of a Minimum Viable Architecture whose usefulness has proven itself: TLS is now the most deployed security system on the internet, at the heart of almost every shopping, financial, or banking transaction.

This future-proofing was thanks in part to our architecting elements that we suspected would be required in the future, but which couldn’t be deployed in the then-present, primarily due to CPU limitations. Perfect forward secrecy¹² is an example. Users were able to simply turn it on when its usage became viable on standard hardware platforms.

However, our more notable work in creating an MVA came from our inclusion of ciphersuites. These are powerful encryption and decryption rules that do the actual cryptographic work of TLS. By defining them as modular plug-ins, we supported the future innovation of TLS, even in ways that we could not envision. And, there was considerable innovation. TLS 1.2 had 37 ciphersuites, though that dropped back to five with TLS 1.3¹³.

The Gordian System

One of my most recent endeavors is Blockchain Commons’ Gordian system¹⁴, which is a layered architecture for protecting digital assets and identity that has seen early successes with the protection of seeds with systems like SSKR¹⁵ and CSR¹⁶ and that focuses on the Gordian Principles of independence, resilience, privacy, and openness.

Blockchain Commons’ Mission: Advocating for the creation of open, interoperable, secure & compassionate digital infrastructure to enable people to control their own digital destiny and to maintain their human dignity online

In order to create an MVA that future-proofs the Gordian products, the Gordian architecture identifies points of potential interoperability and breaks the architecture into discrete components across those interoperable interfaces, thus allowing individual elemetns to be replaced. This was done both at the large-scale application level and at the small-scale programmatic level. It’s important everywhere.

At the large-scale application level, the Gordian system achieves interoperability by the careful architecting of both discrete applications and the ways that they can interact. Airgaps are a traditional methodology for introducing security into a digital asset system¹⁷, but the Gordian system has expanded that to include Torgaps¹⁸, which is a way for making transactions between connected applications both secure and non-correlatable. This modular approach is one way to enable future-proofing, and it’s only strengthed by systems such as airgaps and torgaps that tightly constrain communications between the modules.

At the small-scall programmatic level, the Gordian system introduces a layered stack of specifications that together enable the private and secure transmission of sensitive data. This stack includes dCBOR¹⁹, Bytewords²⁰, URs²¹, Animated QRs²², Envelope²³, Gordian Transport Protocol²⁴, and Gordian Sealed Transaction Protocol²⁵. Together these specifications allow for the deterministic storage of binary data (dCBOR), the alphabetic representation of binary data (Bytewords), the tagged display of that representation with functionality to support multipart data (URs), the QR display of multipart data (animated QRs), the structured & smart storage of content (Envelope), the communication of Envelopes (GTP), and the secure communication of Envelopes (GSTP). But we didn’t know what all the layers would be when we got started: this is another example of future-proofing, and one that easily arises from carefully layered specifications.

Similarly, when Blockchain Commons creates its progressive use cases we focus first on the requirements without needing to know the technology. The technological specifics can be filled in by ourselves or individual vendors in the future.

By abstracting and separating architectural elements—whether they be large-scale components, layered specifications, or additional requirements found in progressive use cases—the Gordian system will be able to incorporate options that we are not even considering. The ultimate goal of all of these designs is to ensure that our MVA architecture does not limit itself, but instead remains flexible for the future.

Other MVA Examples

This type of MVA thinking is a pattern that can be widely successful and that doesn’t create some of the limitations that appear in MVP thinking. For example, when I was supporting the creation of the earliest specifications for Decentralized Identifiers (DIDs)²⁶, I was pleased to see us arrive at a compromise where core DID specifications were separated from specific DID methods and from signature suites. It’s an architecture that allows for a lot of future expansion.

Similarly, some of my earliest Blockchain Commons work was with a company who was adapting the Gordian architecture. Even though they weren’t planning to initially implement multi-sigs, I ensured that they don’t make decisions that would lock them out of multi-sig usage in the future, because I was thinking of a MVA that went beyond the MVP they were focused on.

Coda: The Benefits of Coopetition

It can be quite hard for a single company to figure out an MVA. Thus, it’s great to work with other companies in your technology space.

This is particularly true if your industry supports coopetition, where business competitors can work together for a mutually beneficial good. If an industry supports interoperability, or one company adding services to another company’s products, then it’s a great candidate for coopetition—and thus MVAs are even more likely to be successful.

Blockchain Commons has been able to take advantage of this. A variety of companies have participated in the Gordian Developer Community community²⁷, each contributing their own ideas and requirements for the Gordian architecture. In turn, they’ve then gone off and created open-source libraries that adapt the architecture²⁸, before beginning work on their own wallets that use the MVA that we cooperatively designed. A not-for-profit organization can be a great support for MVA work of this type; that’s what Blockchain Commons does.

Conclusion

Hollowing out spaces in architectures for future development and creating flexibility for the future through modular designs are two of the most successful methods for turning an MVP into an MVA. They give you something that supports minimal investment and agile development, while simultaneously maximizing the ability to scale and expand in the future.

We don’t always know the right solutions. We can’t predict what will work best. So the best we can do is create architectures that won’t lock us in to specific decisions about the future. By doing so, especially by working in coopetition to do so, we also ensure that no one company will lock us or our users into futures that we don’t agree with.

This article was originally drafted in 2021, and then back-burnered for various reasons. It’s been great to see a real exposion in discussion of MVA in the years since by authors such as Ekaterina Novoseltseva ⁹, Jorge Labrato¹¹ and Murat Erder and Pierre Pureur¹⁰, much of which reflects my own thoughts on MVA. Hopefully that means we’re moving in this direction!

1. Various. Retrieved 2021. “Minimum Viable Product”. Wikipedia. https://en.wikipedia.org/wiki/Minimum_viable_product. ↩

2. Michael Sweeney. 2015, 2020. “5 Successful Startups That Began With an MVP”. Clearcode. https://clearcode.cc/blog/successful-startups-minimum-viable-product/. ↩

3. Allan Kelly. 2020. “The MVP is broken: It’s time to restore the minimum viable product”. TechBeacon. https://techbeacon.com/app-dev-testing/mvp-broken-its-time-restore-minimum-viable-product. ↩

4. Frank, Allegra. 2020. “How one of the biggest games of 2020 became one of the most controversial”. Vox. https://www.vox.com/culture/22187377/cyberpunk-2077-criticism-ps4-xbox-one-bugs-glitches-refunds. ↩

5. Andrea Contigiani. 2018. “The Downside of Applying Lean Startup Principles”. Knowledge at Wharton. ↩

6. Mazdak Hashemi. 2017. “The Infrastructure behind Twitter: Scale”. Twitter blog. ↩

7. Evan Weaver quoted by James Governor. 2017. “Minimum Viable Architecture – good enough is good enough in an enterprise”. James Governor’s Microchips. https://redmonk.com/jgovernor/2017/06/13/minimum-viable-architecture-good-enough-is-good-enough-in-an-enterprise/. ↩

8. Deepak Karanth. 2016. “How to Create a Minimum Viable Architecture”. Dzone. https://dzone.com/articles/minimum-viable-architecture. ↩

9. Novoseltseva, Ekaterina. 2022. “Minimum Viable Architecture”. Apiumhub. https://apiumhub.com/tech-blog-barcelona/minimum-viable-architecture/#. ↩ ↩²

10. Pureur, Pierre. 2021. “Minimum Viable Architecture: How To Continuously Evolve an Architectural Design over Time”. Continuous Architecture in Practice. https://continuousarchitecture.com/2021/12/21/minimum-viable-architecture-how-to-continuously-evolve-an-architectural-design-over-time/. ↩ ↩²

11. Lebrato, Jorge. 2022. “What is a Minimum Viable Architecture (MVA) and why an iPaaS such as Anypoint Platform can help you achieve it”. Medium: Another Integration Blog. https://medium.com/another-integration-blog/what-is-a-minimum-viable-architecture-mva-and-why-an-ipaas-such-as-anypoint-platform-can-help-you-f54c9791f6c3. ↩ ↩²

12. Various. Retrieved 2021. “Forward Secrecy”. Wikipedia. https://en.wikipedia.org/wiki/Forward_secrecy. ↩

13. Uncredited. 2020. “Cipher Suites and TLS Protocols”. SSLs.com Blog. https://www.ssls.com/blog/cipher-suites-and-tls-protocols/. ↩

14. Various. Retrieved 2024. “Blockchain Commons Developer pages”. Blockchain Commons website. https://developer.blockchaincommons.com/. ↩

15. Various. Retrieved 2024. “SSKR: Sharded Secret Key Reconstruction”. Blockchain Commons website. https://developer.blockchaincommons.com/sskr/. ↩

16. Various. Retrieved 2024. “CSR: Collaborative Seed Recovery”. Blockchain Commons website. https://developer.blockchaincommons.com/csr/. ↩

17. Various. Retrieved 2024. “Air Gaps” Blockchain Commons website. https://developer.blockchaincommons.com/airgap/. ↩

18. Various. Retrieved 2024. “Torgaps”. Blockchain Commons website. https://developer.blockchaincommons.com/torgap/. ↩

19. Various. Retrieved 2024. “Deterministic CBOR (dCBOR)”. Blockchain Commons website. https://developer.blockchaincommons.com/dcbor/. ↩

20. Various. Retrieved 2024. “Bytewords”. Blockchain Commons website. https://developer.blockchaincommons.com/bytewords/. ↩

21. Various. Retrieved 2024. “Uniform Resources (URs)”. Blockchain Commons website. https://developer.blockchaincommons.com/ur/. ↩

22. Various. Retrieved 2024. “Animated QRs”. Blockchain Commons website. https://developer.blockchaincommons.com/animated-qrs/. ↩

23. Various. Retrieved 2024. “Gordian Envelope”. Blockchain Commons website. https://developer.blockchaincommons.com/envelope/. ↩

24. Appelcline, Shannon, Wolf McNally & Christopher Allen. 2024. “Gordian Transport Protocol / Envelope Request & Response Implementation Guide 📖”. GitHub. https://github.com/BlockchainCommons/Research/blob/master/papers/bcr-2024-004-request.mdhttps://github.com/BlockchainCommons/Research/blob/master/papers/bcr-2024-004-request.md. ↩

25. McNally, Wolf & Christopher Allen. 2023. “Gordian Sealed Transaction Protocol (GSTP)”. GItHub. https://github.com/BlockchainCommons/Research/blob/master/papers/bcr-2023-014-gstp.md. ↩

26. Drummond Reed, Manu Sporny, Dave Longley, Christopher Allen, Ryan Grant, and Markus Sabadello. 2021. “Decentralized Identifiers (DIDs) v1.0”. https://www.w3.org/TR/did-core/ ↩

27. Various. Retrieved 2024. “Gordian Developer Community”. GitHub. https://github.com/BlockchainCommons/Gordian-Developer-Community ↩

28. Various. Retrieved 2024. “Blockchain Commons Libraries”. Blockchain Commons website. https://developer.blockchaincommons.com/libraries/ ↩