It almost seems like a rite of passage: Every company sooner or later discovers they need to build a “platform”. The idea is simple: If you find the common denominator behind the company’s development activities, you can build the tooling that allows future projects to be more cost-effective provided they make use of the same functionality. In theory, the math checks out: If for every customer you save time, an initial investment should break even and return a profit eventually. At least as long as you keep churning out profitable projects and products.
I want to argue that an integrated platform is nevertheless often not the right approach. Depending on the circumstances, platform projects can be an excuse to avoid a difficult product discovery exercise and a sign of lacking strategic focus. They also tend to demonstrate a certain naïveté when it comes to scoping future needs.
Nevertheless, making development work more efficient is a valid goal. Understanding the problems of the integrated platform directly leads to an alternative strategy.
Before going any further, I have to be a bit more precise about the word “platform” which is one of these terms that is used to describe many different concepts and that means different things to different people.
The way I use this term here is as follows: A platform, in the sense of this article, is a tightly integrated system developed for internal use in which you can embed custom logic, data, and configuration to develop future instances of your company’s principal value delivery more efficiently.
Specifically, in this article, I am not considering platform products that you sell directly to your customers. AWS would be an example of such a platform product: A system that enables your customers to build their solution on top. These are very different matters with challenges and opportunities of their own and I won’t consider them here.
To provide an example of the kind of platform I have in mind, imagine a company that makes specialized software tools. Their customers are in the energy sector and use the company’s tools to analyze sensor readings of wind turbines and to make preventive maintenance decisions. As the company has had several customers with similar requirements, they would be tempted to build a system that includes all of this recurring functionality. The solution for the next customer then could be not more than a thin layer of configuration and custom logic on top of the shared infrastructure. This shared system is the platform.
The wording tightly integrated is key in this definition: The motivation behind an internal platform is to reduce the additional work required to produce instance n+1 of a company’s value delivery to a minimum. An initiative that extracts the anomaly detection code into a shared library would not normally be considered a platform.
Here comes the problem: By requiring that every future instance of your value delivery is built on top of this platform, it is easy to fall into a situation where your platform is either too narrow, too wide, or both.
Your Platform Is Too Wide: A Sign of a Lack of Focus?
I would like to refer back to my earlier post on problem spaces and solution spaces which explains how we can look at the set of all possible problems and the set of all possible solutions that we can build as two different spaces to explore. The article argues that the goal of a software project is to find a high-value match between the two spaces.
If you think about your platform, we can say that that there is a set of points in the problem space that can be solved with solutions built on top of this platform. Let us call this set of points Q the set of problems supported by a platform.
Now, as discussed in Problem Spaces and Solution Spaces, navigating problem space to find the most valuable problems to solve is a difficult exercise. This can create the temptation to cast the net very wide and to require Q to be very large.
In the example, you may want to make sure that future needs are covered and to build a platform that supports any predictive maintenance problem, not just wind turbines.
You can surely appreciate how this quickly devolves into an ivory tower exercise as the platform team now has to consider problems in parts of the problem space for which you don’t have and likely never will have a single customer. As problem-solution mappings are not continuous, this significantly increases the required investment.
Worse, it also has an impact on technical design choices. Knowing the subset of the problem space which you want to address can help to make simplifying assumptions. When the target space is very large you need to settle for the smallest common denominator which may not be the most appropriate choice for any of the solutions you will build in practice.
You cannot rule out that a user will access the solution with IE5? Your platform needs to account for that. Do you need to support all cloud providers? Your platform needs to accommodate that as well. You cannot rule out that you will receive real-time data from hundreds of thousands of turbines every second? Your platform needs to support that use case.
Every simplifying assumption that you do not make will cause the platform team to spend time on things that will never deliver value.
Your Platform Is Too Narrow: An Obstacle Rather Than a Support.
The opposite phenomenon also exists: The problem space Q supported by your platform can turn out to be too narrow. This happens because you build the platform as an extrapolation of real problem-solution matches that you identified before. In this extrapolation you automatically make assumptions: Every single customer that your predictive maintenance software was ever delivered to, could send their sensor readings over the network, for example.
Often, these assumptions are accepted implicitly and never discussed. They seem obvious because things have always worked this way.
This is when the sales department calls: They have just landed an amazing new deal! The only catch? The customer’s turbines have limited network connectivity and a part of the analysis needs to happen in an embedded system in the turbine while the backend only receives aggregates.
All of a sudden, the platform is more in the way than it is helping as you can’t easily extract the part that needs to run in the turbines. Worse, the backend does not yet support receiving pre-aggregated results, the architecture is built to do aggregations on demand. It is scrambling time. Trying to shoehorn a solution into a system that was not designed for this use case leads to hacks that try to work around the limitation by relying on the internals of the platform. The result is a mess.
Likely, Your Platform Is Both: Too Narrow and Too Wide
Now comes the worst part: The dynamics that lead to platforms that are too wide or too narrow are by no means mutually exclusive. Chances are that your platform is both too narrow and too wide.
In the example cited above, you have spent countless engineering hours on building something that supports arbitrary predictive maintenance problems and display the results in IE5. But what you really needed was a way to get the code to run on an embedded system.
Can this risk be avoided? It boils down to how well you know your problem space. If you can draw a very precise line around a part of the problem space so that all of your future needs fall inside this subset without preparing for too many hypothetical situations: Great, an integrated platform may be for you.
However, I would argue that most of the time we don’t have this level of foresight.
Is There an Alternative?
As stated initially, the objective of a platform project is to enable other teams and to make future value creation more efficient. This is a valid goal. Continuously improving efficiency is one way of achieving growth. Furthermore, being quicker to market because of your internal intellectual property can improve your lead on the competition. All big technology companies are investing heavily not only into their products but also in building the enabling structures that make value creation more efficient.
I would like to suggest that all of this can be achieved whilst avoiding some of the problems cited above.
You might have noticed already that I stressed the word integrated earlier. The problems described above really only exist as long as the platform prescribes the set of problems you can solve, as long as it is a limiting framework.
However, this is not a prerequisite if the goal is to enable your teams. Instead, I would suggest that initiatives designed to enable internal teams should produce isolated, specialized tools rather than an integrated solution.
Tools instead of a platform, what is the difference?
I think that the spirit is fundamentally different: Instead of trying to predict the problem space, tools focus on the solution space. The goal is to find recurring needs that pop up across projects in your organization and to abstract these out as components that can be reused the next time around.
This can happen in the form of services, libraries, scripts, or even simply recipes to copy and paste from, depending on the need.
The imaginary company described in this article might extract the prediction algorithm out as a shared library. Furthermore, they might develop a library with UI components for modern browsers. They could create a series of APIs that implementations can use to send out notifications when a problem has been detected.
The idea is to make the development of solutions in the shaded areas of the solution space easier. This approach reverses the responsibility. The project team can use a tool if it turns out to be useful but they can also drop it if it gets in the way. The glue that holds everything together is the code that the project team writes, not a platform.
It will happen that you aim incorrectly and that some of these tools turn out to be not very useful. However, as the approach is modular, low-value tools can be dropped with little repercussion.
A challenge this opens up is the question of interoperability. In an integrated platform, all components are designed to work together. With isolated tools, there is going to be a need for glue code to make things interoperate. I don’t think that this is necessarily a problem, though. It might just be an additional motivation to use open formats and standards for the exchange of information which in turn makes it easier to integrate with external systems.
Conclusion
You may say “We are doing exactly what you propose and we call that a platform”. If so, great! As I said, the word ‘platform’ is incredibly fluffy and it is entirely possible that what is practiced in your company does not at all resemble the construct that I am questioning here.
My main point is the following: If the goal is to enable your internal teams to more efficiently deliver value, then focus on removing friction in relevant parts of the solution space and let the teams building the solution do the discovery work in problem space instead of trying to draw arbitrary lines around a subset of problems you think might be future proof because you will likely waste time building something that is not.
The Solution Space 