Key Takeaways
- Like an existing road that makes travel to a desired destination easier, a platform or framework may provide a shorter path to achieve MVP/MVA goals.
- Since exact customer needs are usually unknown, the path to a successful MVP/MVA is unclear. A platform or framework may get a team closer but they will often still need to find their own way.
- Platforms and frameworks make many decisions for you, some of which you don’t need to make, and some that you won’t agree with.
- The only way to know whether a particular platform or framework helps the team make progress toward their MVP/MVA goals is for them to experiment and gather feedback.
- Three questions (Is the product worth building? Will the solution perform and scale? Will the solution be supportable over time?) help frame these experiments.
Developing software is like taking a journey on which a team is continually making decisions about which way to go, both about the functionality of what they are building (the MVP), and also about what sort of architecture they need to support the MVP (the MVA).
The main challenge in using this approach is building something quickly enough to release so that the team can get important feedback as soon as possible.
As they seek ways to obtain faster feedback, a team must decide whether they should choose a path down which others have gone, or whether to forge their own way.
One way to reuse architecture is to use that same platform or framework that other teams have used. A good platform or framework allows each team to focus on their own unique “value added”. There is no value in building what others have already built, so teams who ignore platforms and frameworks are not focusing on the things that only they can do.
Platforms and frameworks are like paved roads that may help a team progress faster on their journey, with well-defined “exit ramps” or extension points where a team can extend the platform to meet their needs, but they come with side-effects that may make them undesirable.
Teams need to decide when, if ever, they need to leave the path others have paved and find their own way by developing extensions to the platform or framework, or by developing new platforms or frameworks.
The challenge teams face when they use platforms or frameworks as the basis for their software architectures is to choose the “paved road” (platform or framework) that gets them closest to their desired destination with minimal diversions or new construction. The problem created by MVPs is that that destination is not completely known at the beginning.
Platforms and Frameworks make many decisions for you, some of which you don’t need
Platforms and frameworks are usually opinionated, which can mean there are fewer architectural decisions to be made for an MVA. The question for a team is whether they can live with the decisions made by the developers of the platform. Ideally, a team would review the architectural decisions that they made, comparing them with the decisions that the team needs to make.
There are two BIG challenges with this:
- the team often is still discovering what decisions they need to make, based on empirical feedback provided by experiments, and
- the decisions made by the platform builders are not always conclusive, especially in cases where the platform has extension points where teams using it need to fill in their own code. These extension points are, using the “paved road” metaphor, the points at which a team can go off in their own direction.
Many platform decisions are innocuous and can be accepted and ignored when they don’t affect the QARs that the team needs to meet. The only way to know whether the decisions are harmful is through experiments that expose when the platform is failing to meet the goals of the system. Since the decisions made by the platform developers are often undocumented and/or unknowable, it’s imperative that teams be able to test their system (including the platforms on which they are built) to make sure that their architectural goals (i.e. QARs) are being met.
Extending a platform or framework can also be complex, even when it is technically possible. Other people using the platform or framework may not agree with proposed decisions and their related changes, or they may prefer alternatives that don’t meet the needs of some of the teams who desire the change. This is one of the reasons why there are so many platforms and frameworks that do similar things.
In addition, when a team decides to extend a platform or framework, they are making an implicit commitment to maintaining those extensions over time. They need to factor this cost and time/effort into their decision to extend the platform or framework. This includes the cost and effort of upgrading the application to use new versions of the platform or framework when they become available; failing to do so may cause the application to break, or fail to close security vulnerabilities, in addition to failing to take advantage of improvements in performance and scalability in newer versions.
Platforms and Frameworks save time, until they don’t
In our simplified view, a platform is the software (and supporting infrastructure) environment in which an application runs by utilizing the services of the platform. An example of a platform is Amazon Web Services. A framework is a partially completed superstructure of an application (or part of an application) that teams extend with their own application-specific behavior. An example of a framework is the Java Spring UI framework. A Large Language Model (LLM) can be thought of as a kind of platform that is extended by a team using prompts. Platforms and frameworks simplify application development by providing much of what a team needs to build their application.
Sometimes a team will need functionality that works differently than what the platform or framework provides. For example, when an LLM does not handle the kinds of inputs that the team needs to deal with, such as cases where they need to take audio of a phone conversation and respond to commands. The LLM may work fine when the conversation is recorded in a studio environment but may fail when the recording is in a noisy airport. The team may have to first build filters that clean up the audio before the LLM will work, but they may find that their filters are not sufficient. At that point they may need to build their own LLM that is trained with “noisy” conversation data.
Using the “paved road” metaphor, the LLM provides a proven path but it does not take the team where they need to go. When this happens, they have no choice but to either start extending the platform (if they can), finding a different platform, or building their own platform.
Their challenge is that it takes time to decide whether they are further ahead by building on top of what the platform does, or whether they need to build something unique to their situation. Their choices are constrained by the decisions that the platform builders made. If they can live with those decisions then building atop the platform may be their best choice, but if they can’t then building atop the platform is a waste of time, and time is their most precious asset.
Three questions that help frame your alternatives
MVP and MVA are bets about possible solutions. They may be right or wrong, and the only way to evaluate the “bets” is through experimentation. The three MVP questions (Is the product worth building? Can it scale and perform? Is it supportable?) help determine whether the platform meets your needs or not.
Figure 1: Three Questions that help frame architectural decisions
Teams need to consider these three questions in the context of a platform they are evaluating.
- Does the platform help or hinder them in developing an MVP? The platform may provide user-facing functionality that makes developing the MVP easier, but it may come with architectural decisions that the team can’t live with. The only way to know this, using the road metaphor, is to go a little ways down using architectural experimentation by experimenting to see if the decisions that platform has made match what the team needs for its MVA.
- Can the platform scale and perform under expected loads? The problem with this is that you typically won’t know your scalability requirements without experimentation. To use the paved road metaphor, you often won’t know if you need a lightly trafficked two-lane road or whether you need a superhighway.
- Is the architecture built upon the platform supportable over the long run? Platforms usually change at a slower rate than the system because changes require community consensus. Where the platform cannot be quickly modified, teams will need defined ways to extend the platform until the platform itself can be modified.
Rather than simply stimulating thought and discussion, these questions need to be evaluated empirically by running experiments. These experiments are, in practical terms, executable tests that can be run against the system while it is being built. Frequent testing of the system to evaluate whether the architecture is still fit for purpose helps to avoid subsequent uncontrolled rework.
While this list implies a linear progression through the questions, in reality the questions form a loop so that changes to deal with performance/scalability and modularity do not end up jeopardizing the solution, as shown in Figure 1.
Conclusion
A platform is like an existing road that can make the journey that a team needs to make in delivering an MVP easier, but only if the platform takes the team where it wants to go. The challenge a team faces in using a platform is that they don’t, at least at the start, know exactly where they want to go, so they don’t know if the paved road the platform provides will take them there.
An important way they can determine if the road is right for their MVP is to go a little ways down the road and see if it’s still taking them in the right direction which, for them, is defined by their QARs.
At some point, inevitably, teams will need to leave the “paved road” provided by the platform and make their own way. Experimentation helps them to decide when and where they need to do this by exposing where the platform needs to be extended to meet their needs, or where they need to develop completely new solutions that the platform does not provide, potentially even replacing the platform entirely.
