Blog

Thinking about platform development? – Here is what to consider

19 Apr, 2022
Xebia Background Header Wave

There you are. Having read all those exceptional stories about internal platforms being the accelerator of success for start-ups, you are in for one of your own. Developers in your team share wonderful and inspiring stories about how platforms have enabled others. So, this must be the best thing for your organization, right? Well, before blindly diving into this new adventure, here are some considerations before constructing and developing your own platform. We start by discussing the definition of a platform and how you can form your own definition of a platform. Regarding any definition, the inception and adoption of a platform will impact your operating model. Platforms can be a tremendous enabler for the value delivery of an organization, but it does require limitations on what the platform offers. Without focus, it simply will not offer the benefits of scale and speed. Considering these topics will help you to lay out and define a vision for your platform.  

What is the definition of a platform in your organization? 

Many broad definitions exist for the word platform. Not only does the language hold different definitions, but context matters as well. A developer might see a platform as a construct that offers infrastructure and CI/CD capabilities. A Product Owner or a Business Manager might see a platform as a construct that offers specific business capabilities: for example, a search & navigate platform for a product catalogue that is being used for various customer journeys. According to Gartner, creating new business capabilities using composable platforms is the future. 

So, language and context both allow for different perspectives and interpretations on the single word: platform. However, definitions on platforms have been made. Gartner, for example, defines a platform as “a product that serves or enables other products or services.” Interestingly, they reckon that platforms exist at various levels: “Platforms (in the context of digital business) exist at many levels. They range from high-level platforms that enable a platform business model to low-level platforms that provide a collection of business and/or technology capabilities that other products or services consume to deliver their own business capabilities.” This definition addresses the contextual aspect we mentioned earlier. A platform can be focused on providing IT capabilities or be more business oriented. Without a clear definition, it becomes difficult to provide focus and stability in the offerings of the platform. There are simply too many products and services to maintain. 

An interesting consideration for your own platform journey then becomes what your definition of a platform is. Or, to put it more in product terms, what problem are you solving? Who are your customers? To collect and define the answers to these questions, a value proposition canvas can be used. This canvas helps to form a profile on the customers of the platform and the value that will be delivered. It not only provides clarity about what the platform offers to its potential customers, but also the social contracts involved. As a user of this platform to be, I expect X, Y & Z to be offered. A service offering that impacts your way of working. 

The impact of a platform on your operating model 

Any platform, whether it is an IT or business platform, has an impact on the operating model of an organization. The operating model consists of those elements that are important for delivering the organization’s value proposition. Elements typically defined and determined by an operating model has to do with the value chain, how things are organized, what information systems are required and how the whole is managed. The introduction of a platform leads to (drastic) changes to this operation model. For example, the shift on responsibilities and expectations. It is not only the responsibility of a set of functional capabilities that will change. Imagine a team that now becomes responsible for a search platform that is being used by other teams to enable their customer journey. This team is now not only responsible for those functionalities, but additional expectations come to surface. That search platform must be available for a certain period, if it breaks down service must be restored. It is not simply about providing the capabilities, but also ensuring all the things that are part of it.  

One can imagine that every part in the chain now is responsible for their own service level management or change & release management. A thing to be cautious about is the level of generalized support, or the level every team needs to figure out these processes on their own. If many responsibilities are shared, it might be worthwhile to ensure broad support is available or automated. Adopting a platform requires support for all these changed expectations. Not merely architecture, but also the process & expectation side of running a product. This has consequences on the required skills and capabilities to staff your platform organization. 

Especially for platforms that provide business capabilities, it is important to find the right boundaries. Where in the process does the responsibility of the platform start or end? Big Picture EventStorming is a tremendous way to discover the process and determine the right boundaries between platform and consumers. For provisioning of technical capabilities, value stream mapping is a terrific way to identify the process and the resulting requirements towards the platform.  

More importantly, what is being learned from the discovery does not only provide information on the process. It gives indicators regarding cognitive load as well. The authors of Team Topologies describe cognitive load as: “the total amount of mental effort being used in the working memory.”  If substantial amounts of responsibilities and capabilities are moved towards a platform, that raises the cognitive load for the team or teams maintaining that platform. Having a high level of cognitive load for a small group of people will fail the platform initiative. A balance must be found. Which can be achieved in diverse ways. Of course, we can always add resources, “throw more people at it, but that’s a very limited solution. Another solution might be to buy managed capabilities, for example a managed CI/CD platform, and reduce cognitive load in that way. 

Is your organization ready for standardization? 

Platforms can be a wonderful way to generalize and productize foundational or enabling capabilities. A technical platform can be a fantastic way to speed up the development done by other teams. A platform can be the foundational building blocks for new business journeys to be developed. However, these benefits do not come for free. The first thought around this topic has to do with investments of time and money, but more importantly, a platform is about limitations. These limitations become tangible by the products or services you choose to offer. A platform allows the organization to enable and develop a couple of product offerings very well. It standardizes the offerings to the users and as such limits the number of variations you can and should offer. Without limitations on the offerings, you are not building a platform, but just creating an isolated machine of work. For technical capabilities, that means you are creating a gap between dev and ops again. 

The important thing about imposing these limitations is that it becomes easy to ensure the offerings are compliant with standards. Life cycle management and patch management is centralized into the platform. Although the platform team is responsible for these processes, it does not free consumers from their responsibilities. As a consumer of the platform, I need to adhere to the requests, for example, ensuring an upgrade can be executed.  

Platforms can be a great means to automate compliance and governance and as such remove burdens on the team. In our experience, the adoption of a platform as such should be used to automate governance policies, increasing the adoption and willingness to use these platforms. 

Ready to start your platform journey? 

Reflecting on these considerations hopefully helps you to form the vision, purpose, and definition of a platform in your organizations. Perhaps you discovered that a platform is not required, but you simply must be good at certain IT capabilities. There are numerous examples of organizations that thrive by being particularly good at observability and CI/CD. If you are about to incept a platform, we have a couple of suggestions to manage your platform-to-be as a product. 

 

Photo by Riccardo Annandale on Unsplash

Questions?

Get in touch with us to learn more about the subject and related solutions

Explore related posts