What news from AWS re:Invent last week will have the most impact on you?
Amazon Q, an AI chatbot for explaining how AWS works.
Super-fast S3 Express storage.
New Graviton 4 processor instances.
Emily Freeman leaving AWS.
I don't use AWS, so none of this will affect me.
Operations / Platform Engineering

MVP or TVP? Why Your Internal Developer Platform Needs Both

Use the concept of the minimum viable product to introducing new ideas, and the thinnest viable platform to direct the lifespan of the product.
Oct 13th, 2023 10:00am by
Featued image for: MVP or TVP? Why Your Internal Developer Platform Needs Both
Image via Pixabay.

There is an important challenge in the world of platform engineering that is not getting enough visibility. The challenge is not how to grow your platform capabilities or how to provide onboarding and support to users. These are challenges, but they are also widely discussed. The issue has nothing to do with Day 1 for either the platform creation or customer requests for resources. The issue is Day 101 (and Day 1,001).

The concept of the thinnest viable platform, or TVP, presents itself as a way to balance the value provided by your internal developer platform with the long-term cost efficiency and maintainability as the landscape around your platform changes.

Understanding How to Use Both MVP and TVP

The traditional minimum viable product (MVP) approaches encourage teams to build the smallest set of features that will drive product feedback. In some cases, the features may not be integrated into a usable product at all, but instead track interest. Some well-known examples are to put up a landing page to compare branding ideas or to lean on a process that won’t scale but reduces upfront investment until the idea is validated. An example in platform engineering is collecting the process for creating a new service into self-service documentation.

When it comes to building a feature, the minimum viable approach should seek to validate the feature, only aiming to address the core business value and not support all use cases yet. It should also look to gain rapid feedback from your customers, keeping in mind that in platform engineering, those customers are your engineering colleagues.

Building software is expensive, but maintaining and extending it to ongoing needs is the real challenge. Since an internal developer platform is software, it too suffers from this challenge. “Team Topologies” authors Matthew Skelton and Manuel Pais defined the powerful idea of the “thinnest viable platform” or TVP as a way to visualize the need for more effective long-term maintenance through continuous refactoring and improvement.

Curating the thinnest valuable platform is the act of only ever maintaining custom platform documentation, processes and tools that improve your business’s ability to deliver value and is unique to your business.

What constitutes this minimum bespoke platform changes over time as both business needs and industry capabilities evolve. For example, the value in effectively managing physical data centers has reduced significantly with the introduction of both public clouds and managed data center offerings over the last two decades. But if one of the differentiators for your business becomes low latency compute, you may need to revisit this common trend. Regardless of your key capabilities, the ability to manage internal compliance and collaboration processes continues to be custom for each business and should always be included in your internal platform.

The idea of continual investment in a TVP builds beyond the already-popular minimum viable platform or product or MVP.

Using TVP to Unlock Innovation

MVP speaks to the initial phase of an idea, while TVP speaks to the lifetime of a product. MVP is applied at the beginning of an implementation, whether the idea is for a brand-new product or a new direction on an existing offering. In contrast, TVP is about the ongoing maintenance of that minimal concept until it is sunsetted, regardless of if, or how much, it grows in complexity and use.

While MVP has been referenced for over 10 years, TVP was first introduced in 2019 by the book “Team Topologies”:

“The simplest platform is purely a list on a wiki page of underlying components or services used by consuming software… If an organization needs to build custom solutions and integrations into the platform to meet the needs of Dev teams, then the activities of the platform team increase further in scope… A TVP is a careful balance between keeping the platform small and ensuring that the platform is helping to accelerate and simplify software delivery for teams building on the platform.”

This definition focuses on the start of a lightweight platform as one or a few lightweight capabilities, for example documentation or service cataloging, and then the platform extends as and when the complexities increase.

“If that’s all you need, don’t build anything else, you’re still running on a platform, but you don’t make it any thicker than necessary so that’s why it’s kind of the thinnest viable platform,” Skelton said in a video offering a TVP definition. But that’s just a starting point. “Obviously, as your enterprise gets bigger and bigger, or you’ve got more complicated challenges, you’ll need to build some stuff out.”

A recent Mastodon conversation with Skelton confirmed that the definition doesn’t end with the initial implementation. A thin platform has an important focus on long-term maintenance:

“TVP is about ‘thinness’ to try and avoid a massive platform. TVP is something that remains throughout an organizational evolution — it should always be the thinnest viable — whereas MVP is normally the first stage of something larger.”

This shift toward investment in long-term thinness is extremely important. Gregor Hohpe calls this a “sinking platform” in his 2022 PlatformCon talk “The Magic of Platforms.” He asked the audience, “What will you do with your platform when the base platform grows? There are two schools of thought. You can leave your platform the same because you invested all this kind of money, and we call this a sinking platform as the water level rises, right; it might be justified from investment, but you are kind of duplicating things that are now available in the base platform.”

Hohpe goes on to describe how platform teams need to intentionally decide on their philosophy when it comes to supporting their platform: “Or you build a ‘floating platform’ where, when the base platform gains the capabilities you have built, you say ‘Oh, perfect! I don’t need my part anymore. I can let the base platform handle that, and I can innovate further on top. I build new things.'”

By continuing to maintain only a thin, floating platform, your company can dedicate investment toward innovation to support your unique value proposition. One useful tool for visualizing where to invest is Wardley Mapping.

Created by Simon Wardley, this mapping technique identifies capabilities a business relies on, and then classifies them based on their impact on the wider competitive marketplace. For example, in the past, taking downtime as a website to manage upgrades was acceptable. Today that is viewed as a significant risk for many businesses. The process of moving from zero downtime being a differentiator over 10 years ago, to a common practice today initially required significant investment in custom-built tooling and has since been made available as a commodity by cloud providers who provide this as a service.

Build vs. Buy Your IDP

Maintaining a TVP does not dictate how much of a platform an organization should build verses buy. In most cases, a platform is a combination of many tools and processes, which include at least some purchased components while some are custom-built in house. In general, as platform components become more of a commodity in the industry, it becomes more likely that you should purchase a solution in order to benefit from the investment other organizations are putting in to maintain their product in a competitive landscape.

A great example of this came from my time at MOO. MOO started in the early 2000s and was a pioneer among London tech startups, with a vision for making great design available to everyone. In its early years, MOO invested in custom observability tools to best support its products. In particular, tracing tools were far less common at the time, so MOO created an in-house tool to visualize and investigate site performance.

While this was originally ahead of its time, the explosion of tools in the 2010s meant that by 2018 when I worked as a platform engineer there, the maintenance cost as well as the opportunity cost not to change to a market leader tool didn’t add up.

Applying a TVP mindset, where you invest in retiring previously differentiating internal tooling in favor of vendor-provided options isn’t always easy. At MOO, there was some hope that the homemade tool was close enough and could be improved. This can be related to the sunken cost fallacy, when people are reluctant to stop working on something or change directions due to the perception that they have already invested so much and don’t want that investment to go to waste. The reason why this is a fallacy is because the previous investment has already been made, and it would be more economically sound to make the best decision given current information. In addition, there were fears around vendor lock-in, which could mean the expected cost increases at the whim of the vendor.

Despite these concerns, the switch was made, and within months it was clear that the organization could significantly benefit from accessing industry-wide improvements. Since MOO was now paying for another company to innovate in tracing, we as internal platform engineers could float higher up the stack and focus on providing more MOO-specific benefits instead of maintaining the now-outdated internal service.

The common trend of focusing more on building new features can be related to a 2021 study published in Nature, which found that people systematically overlook subtractive changes because “‘additive solutions have sort of a privileged status — they tend to come to mind quickly and easily,” said co-author Benjamin Converse, a social psychologist at the University of Virginia. You have to put effort into finding subtractive solutions, those that increase value while actually reducing a team, product or system’s footprint.

So as you look to build your products, and particularly as you build an internal developer platform product, keep in mind that you may need to invest in more Platform as a Product activities, but this can be done with your existing platform team. You don’t need to be a product expert to begin applying frameworks like Jobs to Be Done, strategies like MVP when introducing new ideas, and philosophies like TVP to direct the lifespan of the product.

Group Created with Sketch.
THE NEW STACK UPDATE A newsletter digest of the week’s most important stories & analyses.