Skip to content

Doing platforms well

I have written about products and platforms on the blog before. This seem to be conversation that I am getting back to with both friends and colleagues. I have given arguments why it might not be a good idea to build a platform in my previous post Two arguments for avoiding platforms. In this post I am talking about why you should build platforms but also, more importantly, what you should think about when doing it.

Several big players in all kind of industries build platforms for various reasons (this in itself is not an argument to do it however). One of the strongest reason, I think, is economy of scale. That we can reuse the same platform for several products in an easy and manageable way. And taken one step further, that others can build products on top of our platform. This is a trend that we have seen in the car industry for a long time. It is also one of the reasons why the iPhone became such a success, the fact that it was so easy to build applications on their iOS.

I strongly believe in building platforms but I equally strongly believe we need to do it right. I was talking about this with one of my colleague a week or two ago now. He has been working as an architect for many years (read: decades) in the Telecom industry. As we were talking, there were a few things that stood out.

The customer decides

There are two sides to this coin. Firstly, there is so much functionality that is being developed that no-one is ever using. The so often quoted report from Standish Group is suggesting that 45% of all software features that are done are never used and another 19% are rarely used. All of these extra features will do nothing more than adding to the complexity and the maintenance burden of the platform. So unless there is a strong request from a customer for a feature, resist the temptation to develop the features just because someone might use it.

Secondly, we need to recognise that different users will use different features. Some features are important to one customer but not to another. It is therefor our job, as a platform vendor, to make sure that the platform can easily be customised for various needs. It must be easy to include or exclude features from the platform to fit the customer.

Modularise the platform

This can seem like sound architecture but it is surprisingly often overlooked. Too often, too fast, platforms are “optimised” in a ways that compromise the integrity of each module. This is certainly true in software platforms but I am sure it can be seen in other platforms as well. Requirements will inevitably change and a module does occasionally need to be re-written. If the boundaries between the modules has been compromised a job that seemed easy will grow into a much bigger job.

Never compromise on quality

One of the big benefits with a platform is, as I mentioned earlier, economy of scale. This means that a lot of customers are relying on the platform as a safe and sound foundation for continuous work. If we allow bugs and faults to enter the platform a large number of products will be affected. Not paying enough attention to issues in the platform will potentially have disastrous effects for your whole ecosystem.

Pay extra attention to your interface

Me and my colleague did not get in to this in our conversation but I think it is so important that it can not be excluded. The interface, whether it is the fittings of a car seat to the car or an API for a function in a operating system, is what the user of the platform will see. If it is done well it will be easy to build products on top of it but if not done well, it will reduce the time to market and possible ruin the business case.

These are the four things that I think is most important when building a platform. Is there anything that you think I have forgotten?