Wednesday, March 2, 2016

Many software companies have been infected by the platform bug. They market their software as a platform. They have built a platform. Their software comes with tiered architecture, an API, and perhaps even some developer tools. But do they really have a platform?

Well, to have a platform, someone has to “stand” on it. What that really means is there have to be others who have built applications on your platform. If the only applications available on your platform come from you, the world couldn’t care less about your platform. There have to be companies out there that decided to build their applications on your platform and not on someone else’s.

That last point is critical. The application developers are effectively asked to place a bet on your platform. That’s particularly important for commercial application vendors as their application will require your platform to run. That represents a huge commercial risk. The application vendors can usually afford to build their software only for one or two platforms. Supporting more than that becomes very cost prohibitive. So why would the application vendors select your platform over some other one?

This effectively becomes a business decision based on the market presence of the platform. The market presence is critical in determining the total addressable market for the application. It’s only one factor, because your application actually only targets a fraction of that potential target market - there are other factors involved based on the type of the problem the application solves. It is very rare, that customers would adopt a certain platform because of a particular application. They may adopt a platform because of a perceived abundance of applications but rarely because of one application.

Let’s take the mobile devices as an example. If you want to build a mobile application, you need to decide on which operating system platform your application will run. Considering the market presence, your decision is relatively easy - you need to support Android and iOS and then your application will support well over 95% of all mobile devices. Adding a third platform to support - perhaps Windows or Blackberry - makes commercially little sense. It’s a huge development cost for a marginal increase of potential customers.

While the market presence is key for an application vendor to support your platform, the features are not. No matter how rich your API is, how easy your development tools are to use, or how well you ensure security, scalability, reliability, etc., application vendors won’t support your platform if you don’t have a market presence that represents an attractive enough target market. Sure, all those features are important but, commercially, the market potential will always beat features.

There has been a long debate about Enterprise Content Management (ECM) as a platform. All the key vendors provide technically a platform. They have the right architecture, the API, and the developer tools. But let’s take a look at the market from the application software vendor point of view. The market is very fragmented with many players and none of them has more than 15% of market share. If you can only afford to support 1-2 platforms, which ones to you choose? IBM? OpenText? EMC? Box? SharePoint? Picking any one of those two will give you no more than 25% of the market as a potential target audience. Would you as an application vendor bet your business on any one of those platforms?

No. What you do is you build your application in a manner that is agnostic to all those ECM systems and you provide integrations to any one of those ECM repositories. That way, you only need to support one code base while potentially targeting a significant percentage of the ECM market. You have mitigated your commercial risk by not making your application stand on any one platform - there is no business dependency for the application. Your approach, however, makes all those ECM systems just information sources, not platforms.

“Wait a minute”, you might say, “how about the applications that are built by customers rather than commercial vendors?”. True, those applications do make your platform a true platform, even if most of the customer development falls more into the category of customizations rather than applications. But as that line is very blurry, let’s not split hairs. The question to ask is what makes customers who intend to build their own applications choose your platform? And the answer is, yet again, not so much about the features and technology and much more about the skillset availability, which is a function of market presence.

To be a platform, any system has to devise a business model that compels application developers to bet their applications on a platform’s success. How do you attract developers to build their applications on your platform? How do you make it commercially attractive for them? Without resolving this fundamental issue, all the features and APIs won’t make any difference.