At the heart of platform architecture and strategy lies a very interesting duality – Platforms are about chaos and control at the same time. In this article, I will talk about how these seemingly competing forces are actually complementary and what this means for organizations building technology platforms.
I say that platforms personify organizational and even ecosystem-wide chaos because of the possibilities they unleash at their edge. By providing powerful capabilities and the ability to compose these abilities into new or existing business processes, platforms can unleash a tide of innovation which would have hitherto been impossible or locked up inside an organization. Organizations can exchange value across platform boundaries by building customized, higher-order interactions among themselves and with their customers. This is as true of business platforms aka marketplaces as it is of technical platforms. In a well designed platform this is done without explicitly involving the platform owner. This is the core definition of a platform anyway – that non-owners can use it create new experiences.
This enablement is what I refer to as Chaos, and it is the desired outcome of deciding to build a platform.
However, platforms are also defined by standards. And standards are limiting by definition. A well designed platforms explicitly calls out exactly what all of its components do, how they can be extended and composed, how new things can be added, how its users are identified, permissible limits of use, cost per unit for use and so on. The “Golden rule of platforms” is that there are no backdoor for anyone, so the defined standards are the only ways ANYONE get to use it. This is the controls aspect I had mentioned earlier, manifested in the real world via well defined standards and APIs.
It turns out that Control and Chaos are not conflicting it all. If we want to fully harness the power of the platform but avoid a complete meltdown, we can only do so by enforcing some rules. The rules could be technical (identity management, rate limiting, standard API protocols etc) or they can be business (policing of the platform against illegal activities etc). Once these rules and the tools to enforce them are in place, the users can be allowed to do what they will with some assurance of stability. This is equivalent to saying that a platform has to be designed and implemented “all up-front” in terms of these meta-capabilities. Authentication, authorization, rate limiting, billing, reporting all have to be made available from day-1 if we want platform adoption and stability.
Control in a platform system comes from standards and interfaces that everyone must adhere to. There is nothing else which says what can or cannot be done.
The situation is very different in product-centric organizations. The way the true customers of the technology interact with it is often fashioned by a layer of internal business teams like sales, relationship management, operations etc. These teams define a panoply of processes that control and regulate customer access to the technology. In this way, they preclude the need for the product to become a platform because there is never the need to let the customers do “whatever they want”. The internal teams decide what is being offered.
In case of products internal to an organization, we can still see this internal team(s) phenomenon buffering the technology from customers. We might have product managers and business leaders defining every aspect of technology development and use by defining specific goals and funding specific programs (roadmaps, OKRs etc are all processes). While this is not a bad thing in itself, it also means that technology only develops to meet the current goals, and is not well equipped to handle fast changing business environment or even the internal shifts in focus that often come with changes in leadership.
Development teams are not free of this process mentality either. Have you ever heard a developer say “Oh no one else will call that API I wrote. We will just manually hit whenever we receive a mail from XXXXX”. I have. This is process filling in for system.
This difference in how control is exercised has a profound implication on the responsibilities of people in companies that choose to pursue a platform technology strategy. As a product company becomes a platform company, internal teams become more peers and advisors to the customers rather than being the gatekeepers to the platform. The platform needs no gatekeepers beyond the publicly defined and systemically enforced controls already in place, and so the customers can start playing around with it on their own. They can do whatever they want without involving the internal business teams at all. The internal teams now have to compete with the other customers of the platform, or become advisors to them in the best use of the platform (depending on the context and role). For example, Amazon internally uses AWS to build Prime Video, Netflix also use AWS to build a rival, and may the best company win!
This means that any person or team that has relied on defining and enforcing processes in the use of technology now finds itself increasingly irrelevant. This is one of the biggest hurdles an organization has to overcome if wants to build true platforms. The nature of work can change so dramatically for so many people and teams (to the point of obliterating their roles) that there is intense resistance to adopting this new way of doing things. People want to continue exerting control using the time-tested (but suddenly ineffective) process driven methods.
The key objective we are chasing in this discussion is this – How can the platform owner continue to operate the platform reliably without having to review every customer use-case? The control structures emerging from platform systems are very different from what we would normally consider structured processes. This leads us to the realization that building a platform is not just a technology activity. It is a mindset (much like being agile) that has to permeate all aspects of the organization and be absorbed across all functions, often painfully.
