Be Clear on What a Software Platform Is
Different people have suggested different definitions for the term software platform. Let me briefly share mine: I view such a platform as a collection of software assets that are used by several products, as the following picture illustrates.
In the picture above, product A, B, and C are built on the platform and use its assets. To put it differently, the platform serves three different products.
Let’s look at two examples of successful software platforms, syngo and Amazon Web Services (AWS). The former is a platform that standardises how medical images are read, stored, and shared across MRI and CT scanners as well as other Siemens Healthcare products; the latter offers cloud-based services on which other products can be built, for instance, Netflix’ video streaming. In both cases, a range of products take advantage of the services each platform offers.
Consider the Benefits and Drawbacks of a Software Platform
Platforms offer several benefits: They can help grow a product portfolio faster and cheaper and they can help increase revenue. Take a portfolio like Microsoft Office, for example. If the teams developing the different apps all created their own user-interface layers, there would be considerable code duplication, added development costs, and increased development time.
A software platform that standardises the user interaction and offers additional shared services, like saving and opening files, avoids these issues and allows the app development teams to focus on creating the app-specific functionality, rather than having to develop infrastructure code.
What’s more, opening up a platform to other companies, as, for instance, Amazon did with Amazon Marketplace, can create a new revenue source and help diversify the business. In Amazon’s case, the platform enables third-party sellers to sell products alongside Amazon’s offerings and Amazon collects a fee for each third-party sale.
But platforms come with potential drawbacks. I have seen software platforms that grew so big and powerful over time that they became a bottleneck and slowed down the rate at which the end-user facing products could offer new and enhanced features. I have also witnessed a brand-new platform being retired, as it was overly complicated to use and did not meet the needs of the development teams that should have used it.
As these examples show, it is worthwhile to carefully consider if a platform can benefit your business, thoughtfully building it, and carefully managing it.
Treat the Platform as a Product
While a software platform is a piece of technology, it is still beneficial in my experience to treat it as a product in its own right, albeit a technical one: It creates value for the product development teams by making it easier and faster to build their products and it generates value for the business by reducing cost, accelerating development, and increasing revenue. Consequently, a platform should have its own product strategy and roadmap, KPIs, product backlog, and well-designed software architecture that leverages the right technologies.
Make sure, though, that the platform decisions are guided by the needs of the products it serves. After all, a platform exists to help teams build better products faster and cheaper. In other words, the platform strategy and roadmap should be derived from the strategies and roadmaps of the products that are built on it, and its architecture should be designed to make it as easy as possible to use its services.
A software platform, therefore, is more than a set of APIs. It typically requires documentation that shows how the platform assets can be used. Additionally, it may require tools to allow teams to code against the platform APIs. At the time of writing, AWS comes with a cloud development kit that supports .NET and Java, integrates with different IDEs, and hence supports developers to develop AWS-based applications, for examples.
Assign a Platform Owner
If we regard the platform as a product in its own right, then there should be clear ownership and a platform owner, an individual who manages the platform and ensures that it creates the desired value, as the following picture illustrates.
As a software platform is a technical, supporting product, I recommend looking for a senior developer or software architect with a strong technical background who is able to talk to the members of the product development teams and understand their needs as well as empathise with the end users, depending on the nature of the software platform. (This is certainly true for platforms that offer end-user facing services.)
At the same time, the person should have the necessary product management skills to professionally manage the platform and ensure that it does a great job for the users—the product development teams who use its APIs—and the business. One of my clients, a games development company, successfully applied this approach to manage one of its key platform products.
Last but not least, a platform owner also has to work with the individuals who manage the products built on top of the platform—product owner A, B, and C in the picture above—to understand their strategies and roadmaps and discuss whose needs take priority in case of conflict.
Start Small
Creating a software platform is a new product development (NPD) effort and should be managed accordingly. This is also true if you take existing code and encapsulate it in the platform, as this typically requires changing or rewriting the software and finding an effective platform architecture.
I therefore recommend building a Minimum Viable Platform, ideally for a small number of products. This allows you to get a first version out comparatively quickly and adapt it to the feedback of the users—the product development teams. Like other NPD initiatives, you should, of course, validate the platform as you develop it, for example, by exposing early versions of new or changed APIs to the product development teams and asking them to code against them. But like other new products, you’re likely to find out how well the platform works only once it is being used in earnest and the products have started to employ its assets.
Once you have shown that the platform does a great job for a small number of products, you can start expanding its services and serve additional products. This avoids one of the potentials drawbacks mentioned earlier: launching an ambitious software platform that is too difficult to use, something I have sadly seen happening more than once.
Ensure that the Platform is User-Led, Not Technology-Driven
Technical products, like a software platform, have a dark side: As they are developed by specialised teams, they can end up being over-engineered and over-complicated. In the worst case, a platform works beautifully on its own, but coding against it is painful and the overall performance of product and platform is poor.
There are two techniques that can help you mitigate these risks:
- Start developing a new platform by staffing the platform development team with members from the product development teams.
- Use the solution validation techniques you would employ for an end-user facing product, for example, sprint review meetings in which members of the product development teams participate and early releases of new or enhanced platform services which the dev team members test.
I have successfully employed the two techniques to develop a new telco software platform, where we assembled the initial platform development team from the various product dev teams that were destined to use the platform. This ensured that the platform did a great job for the products it served, and it increased its acceptance amongst the product dev teams.
Don’t Let the Platform Become a Bottleneck
I once worked with an organisation that employed a software platform that became so successful that it grew bigger and bigger: It served more and more products over time and it offered more and more services. What initially looked like an amazing success story, developed into a difficult experience: The platform started to slow down the rate at which the revenue-generating products could release new and enhanced features, as an increasing number of products were competing for the platform resources. The platform had become a bottleneck.
I hence recommend that you carefully manage the growth of your platform. In some cases, it might be better to accept some code duplication if this helps a product development team get a new feature out faster and create the desired value for the users and business. Alternatively, consider breaking up the software platform and offering platform variants that each serve a set of clients, for example, a storage platform and a media services platform.
Like with other products, regularly review the performance of the platform and make the necessary changes to its strategy and roadmap.
Published on Java Code Geeks with permission by Roman Pichler, partner at our JCG program. See the original article here: Leveraging Software Platforms Opinions expressed by Java Code Geeks contributors are their own. |
