Understanding Platform Governance: A Q&A with ESSEC Business School’s Thomas Kude and Thomas Huber
The Early Adopter Research Podcast covers a wide array of topics from cybersecurity to big data governance. In a recent episode, Early Adopter’s Dan Woods focused on designing enterprise platforms with two professors from the ESSEC Business School, Thomas Huber and Thomas Kude. The conversation focused on the way that platform governance can influence and inform the design of product based platforms. Huber is an associate professor of information systems at ESSEC Business School in Paris who is conducting research on platforms and the management of platform ecosystems. Kude is also an associate professor at ESSEC Business School who studies platform governance, agile software development, and IT governance in the digital age.
This is an edited version of the full conversation from the podcast.
Woods: I recently wrote an article explaining my interest in supporting people who design enterprise platforms. There a variety of different roles in creating a platform, including matchmaking and code creation. And you have created a language for how these are governed. How would you both describe platform in the modern enterprise IT context?
Kude: Platform very broadly, at a higher level, can be seen as a stable core that enables other elements, which could be individuals or artifacts, to interact. But in our research, we look at digital platforms, such as enterprise platforms. The interesting thing is that these digital platforms combine elements of what we call product platforms on the one hand and matchmaking on the other hand. It’s striking to see that both of these ideas are actually not really new. Take product platforms in the automotive industry or take an ancient bazaar that brought together merchants and customers. So these are examples of product platforms and matchmaking. So why all this fuss today? Digitization has really dramatically changed the relevance and reach of platforms for a number of reasons. And I think this is why, nowadays, digital platforms are everywhere.
What are the different kinds of ways that platforms are put to use?
Kude: There are some platforms that lean more towards matchmaking, such as Uber and Airbnb. But there is also more of what we call hybrid platforms, which also have this notion of a foundational system, which very much resembles the product platform idea. And so take SAP or Salesforce as examples, but take also Google Android or Apple’s IOS as examples.
What happens in a product platform that’s different from matchmaking?
Kude: What happens in a product platform is that there’s actually a foundational system, which is a piece of technology that we call “complementers” and which third-party vendors can build their own solutions on. This is something that is very different from the case of Uber, which is really where the technological part is about bringing different user groups together. And here in the product platform or in the hybrid example, we have this foundational system and it has a lot of implications for questions of platform governance.
Huber: What is really important is that what we refer to as the non-matchmaking platforms, the product platforms, provide often the core functionality that is being reused by external companies or external individuals, depending on the specific market that the platform is in. But the idea of a core functionality that is shared, I think, is very important.
So if we have the Apple or Android ecosystems, you have a core set of APIs that allow people to create applications. That’s the product platform. But then, it also allows people to sell those applications, that’s the matchmaking part of the platform. So that’s the way it’s hybrid. In enterprise software, how would you define how a platform creates value with respect to those two capabilities, matchmaking and co-creation?
Huber: In the enterprise context, traditionally, even the large scale systems that you mentioned earlier, like the SAP ERP system, have always had aspects of a product platform. They were working with partners for, well, many years now, not just in the last five or ten years or so. But even 20 or 25, 30 years ago, they were already working with partners. Of course, the reliance on external partners has increased over time as they added APIs that were accessible to external complementers or external software companies. I think a more recent phenomenon in the enterprise software market is that there are also app stores. Traditionally, many of the large companies in the enterprise software market did not have direct access to customers. They were approached by consulting companies, maybe even by smaller software companies. And now they are also adding the functionality to sell products via, basically, a matchmaking module of the platform.
Probably the one that’s furthest ahead in this is the Salesforce app marketplace, where you can build apps that extend Salesforce without a lot of prior restraint. In your research about platform governance, you distinguish between the two types of governance that have important impacts on making a platform successful. You talk about systemwide governance, which generally has to be about rules and values and allows a lot of people to participate without a lot of interaction. And that helps scale a platform. But, on the other hand, there are certain times when a partner comes that is going to need a lot more attention, a lot more access to the internals of the platform. And that partner engages in a different type of governance that you call “dyadic governance.” Could you talk about these two types of governance and their role in making platforms successful?
Huber: Those types of governance first differ in terms of the activities that you enact when you engage in them. So the arm’s length governance, that’s very much like following the standard, maybe not even personal interaction, maybe you will be serviced through an online portal or through some other system, maybe you will call a call center.
A perfect example of this that I just went through is this podcast getting signed up to the Apple podcast distribution system. I had to go through an interface, I had to submit my podcast. I then got a response back from a service person that said, “You need to fix these three things for it to be okay with us.” And then I fixed those three things, and then it was approved. It was very arm’s length and standardized, and that’s an example of the kind of ecosystem-wide sort of governance that you’re talking about.
Kude: I think that is really an excellent example. It shows us that the goal of Apple here is geared towards scalability. They try to standardize governance as much as possible. Even though your podcast is great and it is a special one, they want to do this for many other app developers. Of course, they want to co-create value, but they want to do so while scaling their ecosystem as much as possible. And this is exactly what may be different, what we refer to in our research in the enterprise software context, and this is where dyadic governance comes in to play.
Now let’s now move to the idea of dyadic governance. It seems that this covers a lot of territory and it’s going to be complicated for me to understand it. Here’s what I’m thinking is, at one level, you’ve got somebody like SAP or Oracle who’s combining and creating an enterprise software system. And so they are looking at making and expanding the footprint of that system, and sometimes they have a big extension they want to make. And so instead of developing it themselves, maybe they integrate with a third party to provide that extension. Or maybe they buy the company. Both of those, it seems in your model, would be dyadic governance because they’re complicated relationships that are core to the fundamental platform. But then, you go down further and you have a bunch of smaller companies that want to work with every CRM or they want to work with every sort of analytic system. Explain the dimensions of this dyadic relationship and why you have to have it at all.
Huber: First of all, why you have to have it at all is because often times, it’s difficult to cater to very specific needs by just doing the standard stuff. So when we continue your podcast example, all you can do via arm’s length governance is what someone has anticipated in the standard, so, for example, in the form fields that this online portal provided to you. But what happens if you have a very distinct business opportunity? Let’s say, a project that you may be able to sell to a major customer that you haven’t served before, but only if you engage in very close interaction with some complementer company who offers a solution based on your platform. This would be a situation where you’d need dyadic governance.
Would you explain the word “complementer”?
Kude: A complementer is basically our term for a third party provider that adds some functionality to a platform and—this is the important part we want to stress—is that it is complementary. It may be a niche solution that the platform owner is unwilling to provide because the market use is too small. This is where the complementers come in. And we call them “complementers” because together, they co-create value for the respective client. It may be a client that uses some of SAP’s or Oracle’s or Microsoft’s basic functionality, but then needs additional functionality from one or more of the complementers.
And by definition, the complementer is not just a user. So, like, when I take an Uber ride, I’m not a complementer. But if I provided an enhanced way of ordering an Uber by using American Sign Language from a video interface, maybe then I would be a complementer because I’m adding functionality.
Kude: Right. And this goes back to the distinction we make between pure matchmakers and hybrid platforms that combine some elements of product platforms.
Now there’s a range of the complexity and intensity and impact of these dyadic relationships. Talk about the difference and the effect that a dyadic relationship has on a platform’s ability to be successful and also to scale.
Huber: First of all, it’s important to note that this is a tradeoff. You can’t have everything at the same time. And this is why we found that dyadic governance is something that’s often conducted situationally. It’s nothing that a platform owner does with every complementer all the time, but only with a few complementers. And with those few complementers, only when it’s absolutely necessary because the standards are not enough to leverage the business opportunity.
And now with the theme of early adopters, what are they trying to do? They’re trying to take a variety of enterprise software products and they’re trying to knit them together into a platform that serves their interests and makes something possible. An example would be a company that supplies tech employees to large retailers because the large retailers need trained people, but they’re not very good at finding and training people who know about computers or cell phones or audiovisual equipment. And so this other company provides those employees to these large retailers. They’re good at training and finding those people, but what they realized is they had to manage this large workforce, but then they had to also allow this large workforce to collaborate. And so they combined a workforce management solution with an internal social network solution so that they would enable all of the employees to communicate with each other, to capture knowledge, and to have this governance system where each them is not a complementer, but a user that then is sort of a low level complementer in that they provide knowledge to the system. So they’re explicitly trying to make the system better, but they’re also playing by very generic standardized rules. It seems to me that this is the goal of enterprise software in general, but enterprise platforms, product-based platforms as well. What examples have you seen of how this works in a context inside companies where you have enterprise platforms being built according to the design that I mentioned, but also then being governed by the principles?
Huber: This is a very fascinating idea and a very exciting question that we have been thinking about quite a bit as well. You have a really good point that those companies that succeed in our digital age are often those that are able to benefit from and integrate some of these platform ideas that we have been talking about within their organization. So in our research, we have seen that for questions of IT governance and digital transformation, it is often this platform and thinking that would characterize the successful companies. And why is that the case? What we believe is that today, in the digital age, it’s not enough to be good at one thing, but often, we have to fulfill contradictory demands, achieve many things at the same time. And this is exactly where the notion of platforms comes in because platforms, if they are managed and governed in the right way, provide firms with the ability to ensure, on the one hand, control and stability, and, on the other hand, flexibility and innovativeness. And this is exactly what the winners in the digital age are doing. This is why I think that you are absolutely right that you can learn a lot from these platform governance ideas and platforms in general for IT governance, the ways IT needs to be managed within organizations.
It seems like one of the implications of what you’re saying is that the way platforms grow internally—because almost all internal product-based platforms are on an evolutionary path—they’re very rarely just stable. It seems like the advice we can give early adopters who are designing these platforms is first, understand the core reliability and functionality of that platform and then establish a surface area, a user interface that is an ecosystem governance model, where everything is standardized and you can get value out of that. And underneath that, there’s a bunch of integration of various products happening that gives you a new level of value. And that is the way that you scale usage and value of that first stage of an enterprise product-based platform.
Kude: I agree with that because in platforms we often talk about the notion of what we call “generativity.” It’s this idea of providing a platform and then enabling unforeseen innovation at a large scale. I fully agree with you that we want to have ecosystem governance on the one hand, but I think what we can really learn from our research is that scalability shouldn’t be our only focus. There are circumstances—especially when it’s about very innovative topics—when it is important to engage in some more dyadic governance to make specific things happen. And this is where the values come into play that we have seen as so important in the enterprise platform context. Because it is the values that often guide innovation. Often, it makes sense to not go for scalability and standards in any case, but to allow teams to work together. But then guide it by some higher level values. If firms can make this happen, they’re on the right track.
That’s a fascinating concept: that innovation and evolution would be guided by values. For example, I observed the evolution of the Etsy platform, which had a variety of different rules in it about the kind of people they would include at the beginning, which was only artisanal suppliers. And then they had certain restrictions and various policies that governed that. But then as the platform grew, they allowed people who would not only make their own stuff but would use manufacturers. Now they’ve even expanded that further so that there’s a lot more people coming. And they’ve been trying to preserve their values of providing special products while at the same time expanding their product line and expanding the number of entrepreneurs that can participate. So that’s an example where I’m not sure if you’d argue that the evolution was consistent by the values, but maybe a change in values enabled a different evolution of the platform.
Kude: I think it’s an excellent example because what the values did in this case is that, first, they made sure that there’s a certain level of trust and community in the platform. And then complementers invest into the platform. So that all kinds of user groups that are active on this platform are willing to invest because it is a large commitment in many cases, especially when we talk about enterprise software. And by ensuring that there’s these higher values and higher principles that guide innovation in the ecosystem, we can make sure that all the participants are willing to invest efforts and, to a certain extent, lock themselves into the ecosystem.
Huber: When we look at values, what we are really interested in is how these values help complementers start to trust the platform owner. Because the idea is that every complementer puts itself in a situation of risk when joining an ecosystem. For example, when you join the SAP ecosystem, you have to take major investments, like do some certifications and things like that. You also have to build up all this technological knowledge. Even if you don’t certify your employees, it’s still an investment. So you could spend this money in another way as well. So you sort of become dependent on this platform owner—in this case, SAP. And when we look at the values, it’s basically values about how SAP promises to behave in the ecosystem. And these promises have effects on complementers because on the one hand, they feel, “Okay; this platform owner is a trustworthy counterpart.” But of course it also raises expectations, so what is really important for the platform owner once the platform owner has made this promise is to basically keep it. So even though those values, they often sound like, “Oh yes, that’s a nice thing to say,” but they make a real difference in the investment behaviors of complementer companies. For them, this is not just empty promises. For them, this gives assurance, which makes them invest more in the platform. And these investments then, of course, pay off by creating value for the platform.
So when you’re creating a product-based platform inside a company, you want to make sure that you understand first, the ecosystem wide governance levels and the users’ benefit and how you’re going to systematically deal with them. Secondly, you want to understand where you are going to want to extend that platform and what kind of dyadic governance are you going to need. It seems like there are two cases. One case is the complementers, who are people internal to the system who are going to have a special relationship with that system and be able to do things and create content that then become part of the system. Then, in addition, there’s the larger, major extensions which are saying, “We’re going to integrate a whole new system. Instead of just having our workforce management and our collaboration system, now we’re going to also integrate a chatbot interface that will be used by consumers in the stores or on their app and also used by us to answer questions. It seems your advice is, “Know what you’re doing. When is it the right time to add complementers? And how are you going to control them? When is it the right time to extend the platform?” These are key decisions that either make for success or failure.
Huber: Early adopters are facing the special problem that they don’t have a giant customer base or a giant base of complementers that they can learn from whereas a platform owner like Apple doesn’t have to open any API to everyone immediately. I’m sure that before they opened up the Siri API, they experimented with it inside. And some of the special Siri features that we always were using on our iPhone, they have basically now become standardized and made available to everyone. For early adopters without a giant workforce, a giant customer base, a giant base of complementers, they probably have to open up to external companies as well. And this is what dyadic governance can do. So if you think, “Oh, there’s a complementer who has a really good idea. And I think this complementer could help me come up with an innovative solution for a problem that I would see to become a platform feature.” Then dyadic governance would be the right thing to do. Then the standards won’t help you.
Kude: It’s also about being smart and knowing what you’re doing in terms of expanding the platform. There’s many things that we can learn from our research on inter organizational platforms. We did a study on Google and Google Photos. We were interested in the question, what happens when Google competes with their own complementers, in a way, because they added an app when the complementers were already providing similar functionality. This can have implications for internal platforms as well because we can learn that on the one hand, we should be careful not to integrate too much into the platform, to leave enough space for innovation, leave enough space for niches that could be used by complementers. But at the same time, we can also gear innovation toward a specific area.
What did Google provide that was competing with the existing complementers?
Kude: There were a host of complementers that were active in this photo management space. But then Google introduced this app that kind of integrated this functionality and that was competing with many of the complementers active in this space. So one could have thought that it would kill innovation in that area. But no, what it did is it provided what we call the digital real estate for others to build on.
Do you have any governance train wrecks that you can talk about? For example, recently, we’ve seen in the open source community some massive governance train wrecks with respect to the Redis community, where Redis Labs had made a bunch of intellectual property less accessible through licensing than it had been in the past. And the open source community, which builds the foundational product, found this to be very upsetting.
Huber: Yes. One example might be Microsoft a couple of years ago when they decided to discontinue Silverlight. Because before they decided to discontinue Silverlight, they tried to gain traction among their complementers. They actually engaged in quite some dyadic governance, as we would call it. They tried to give complementers specific incentives to support Silverlight and things like that. And then after a very short time span—at least for the platform market—they discontinued it. And this led to a lot of disgruntled complementers and I think this would be another example of such a train wreck.