Abstract
Summary
This article explores platform governance in established companies that face unique challenges when adopting platform strategies because of their complex organizational structures, diverse product ranges, legacy systems, and existing networks of partners. It analyzes four established companies’ governance strategies and proposes a multi-layered governance model that addresses the varying needs of internal business units, core partners, and third-party developers. This model highlights the importance of custom governance strategies tailored to specific ecosystem actors and their relationships. The findings contribute to a deeper understanding of platform governance in established companies and present practical recommendations for managers embarking on digital transformation.
Established companies are increasingly adopting platform strategies. 1 This trend is visible across various industries, from car manufacturing, such as BMW with its “BMW Connected” platform, 2 to equipment production, such as Trumpf with “Axoom,” 3 to banking, as seen with Singapore’s OCBC Bank and its Connect2OCBC platform. 4 The primary objective of these companies is to leverage the generativity of an ecosystem of external actors, i.e., to tap into the innovative potential of third-party developers. 5 Digital platforms are IT artifacts that provide interfaces through which third-party developers can connect applications to the platform’s core. 6 This setup effectively unlocks the potential of a broader digital platform ecosystem, involving third-party developers to create value collaboratively. 7 Yet, most of what we know about platform governance comes from newer digital companies, leaving out the unique challenges of established firms.
When building digital platforms, established companies face unique challenges but also have advantages compared to platform-native startups. 8 Accustomed to a traditional product-focused approach, established companies need to adapt to a digital service mindset and develop new dynamic capabilities for managing platform ecosystems. They must deal with legacy organizational structures, which are often complex and comprise multiple business units, which may not be suitable for the dynamic and collaborative nature of platforms. 9 Further complicating matters is the need to transform existing products into platform-compatible components, which demands significant technical adjustments. 10 Established companies also frequently collaborate with external partners who are essential for product development and market reach, adding another layer of complexity to an already intricate process.
In contrast, established companies can draw on an existing network of partners and an existing customer base to launch a digital platform and populate the platform’s ecosystem. Based on network effects, these initial actors can attract further actors, such as third-party developers, to the ecosystem. Overall, successfully navigating the challenges of organizational change, product adaptation, and ecosystem governance while leveraging existing relationships is crucial for established companies building digital platforms.
The literature on platform governance has largely overlooked the unique situation of established companies, as researchers have primarily examined digital platform ecosystems built on green fields, such as Google’s Android platform 11 or Facebook’s platform for games. 12 While some studies offer insights into how established companies should adapt platform governance, they typically focus on dynamic capabilities, 13 phase transitions in digital platform ecosystems, 14 and the complementarity between product- and ecosystem-related activities 15 rather than systematically deriving governance practices.
Consequently, our theoretical understanding of platform governance mainly revolves around a core-periphery model describing the relationship between the platform owner and third-party developers. 16 How established companies’ additional complexity impacts the core-periphery model and platform governance during the digital platform design and implementation phases remains unclear. To contribute to this gap, we pose the research question: How do established companies govern the core and periphery of digital platform ecosystems? To address this question, we conducted an exploratory multiple case study on four established companies from different industries that introduced digital platform ecosystems.
Our results show that established companies apply multi-layer governance approaches to govern: internal business units, core partners, third-party developers, and the relationships between these actors. Governing the core of a platform (i.e., internal business units and core partners) is crucial for the success of established companies’ digital platform ecosystems. Our study can help established companies avoid common mistakes in creating digital platform ecosystems and guide them in applying platform governance instead of relying on trial-and-error strategies.
Digital Platforms and Digital Platform Ecosystems
Digital platforms are changing the way companies operate and compete. We define digital platforms as “the extensible codebase of a software-based system that provides core functionality shared by the applications that interoperate with it and the interfaces through which they interoperate.” 17 The extensible nature of digital platforms allows the platform owner to draw on the generative potential of third-party developers for value co-creation. 18 Thereby, digital platforms facilitate a multi-sided business model that brings together third-party developers on the one side and customers on the other side. Multi-sidedness creates network effects; the more third-party developers provide apps and services on a platform, the more attractive the platform becomes for customers, and vice versa. 19
We refer to the digital platform, its interfaces and complementary applications, and its stakeholders as a digital platform ecosystem. 20 For example, Apple’s iOS platform provides developers with a standard way to create apps that run on Apple’s devices. These apps are then offered in the App Store, making Apple’s products more valuable to customers. This effect creates a thriving ecosystem that helps Apple, third-party developers, and users.
In sum, digital platforms offer a place for collaboration and value co-creation. They fuel digital platform ecosystems where users, third-party developers, and other vital players connect, interact, and contribute to the platform. This close relationship between the platform and its ecosystem drives value co-creation and innovation. 21
Governing Digital Platforms and Their Ecosystems
Organizational governance and IT are deeply intertwined: IT enables new ways of conducting organizational governance, and IT development and usage in organizations must be governed. 22 The latter is often called IT governance and involves innovation networks, digital platform ecosystems, or open-source communities. Thereby, IT governance describes what is governed, who is governed, and how it is governed. 23
Platform governance can be interpreted as a specific type of IT governance. Building on the dimensions of IT governance by Tiwana et al., 24 we refer to the digital platform and third-party applications as what is governed. For example, by implementing standards in the design of application programming interfaces (APIs), platform owners can govern how third-party developers interact with the platform.
Decision rights, control, and platform architecture are aspects of how the platform is governed. A higher degree of openness to attract third-party developers entails that platform owners relinquish some of their decision rights. 25 Formal and informal control mechanisms can effectively govern the quality of third-party applications on platforms, and the design of boundary resources has been identified as key to supporting third-party developers in creating applications. 26
The question of who is governed in the case of platform governance is straightforwardly answered in literature: the platform owner governs the third-party developers. 27 For example, Apple, as the iOS platform owner, provides boundary resources, applies control mechanisms, and decides on the degree of autonomy of third-party developers. The platform owners thereby stay in exclusive control of the platform’s core while opening the periphery of the platform to external actors. Governing the core and periphery of a digital platform ecosystem entails questions such as where to draw the line between the core and periphery; and to what degree to standardize the interface between them. Figure 1 summarizes our view of platform governance.
Theoretical pre-understanding of platform governance.
This theoretical pre-understanding shows that platform governance has, up to now, focused on the relationship between the platform owner and third-party developers, thus the interaction between the core and the periphery. Actors within the core, such as business units within the platform owner organization, are not considered.
Challenges of Established Companies in Governing Digital Platforms Ecosystems
Established companies face numerous governance challenges when developing digital platforms, often stemming from their entrenched organizational structures, diverse product portfolios, legacy systems, and existing partner networks. 28 Over the years, established companies have developed a complex internal structure along with mechanisms to govern that structure. 29 For example, companies often have created strategic business units that address specific markets and are granted some autonomy from the corporate center. 30
The rigid structures and hierarchical decision-making processes within established companies can impede the agility required for successful platform governance. 31 Decisions often require multiple layers of approval, resulting in slower response times and hindering innovation. For instance, Nokia’s decline in the smartphone market is partly attributed to its bureaucratic structure, which struggled to keep pace with the rapid changes the iPhone and its ecosystem ushered in. 32
Established companies often have longstanding relationships with partners that necessitate careful management and integration into the digital platform ecosystem, adding complexity to platform governance. 33 Balancing the interests of these existing partners with the need to foster innovation and attract new third-party developers can be a significant challenge.
Platform owners also face a critical challenge in simultaneously enabling value co-creation among participants (i.e., generativity) while maintaining control over the value co-creation processes. 34 This generativity-control tension is crucial for platform survival, as demonstrated by Google’s experience with its Android developer ecosystem. While Android’s open architecture attracted app developers, it also created vulnerabilities to exploitation, such as Amazon cloning the entire platform. 35 To counter this, Google adjusted its open-source license to restrict the access of third-party developers to specific core areas.
Established companies transitioning from a product-based to a platform-based strategy encounter significant challenges in adapting their business models and organizational structures. 36 This shift requires attracting third-party developers and fostering an ecosystem around the platform, which often necessitates changes in organizational culture and governance approaches. 37
Transforming an established product platform ecosystem into an innovation platform ecosystem presents significant institutionalization challenges. 38 These challenges involve rebalancing top-down control and bottom-up emergence, re-professionalizing ecosystem actors, and redefining the ecosystem’s organizing vision. Companies must navigate these challenges by implementing field-level governance mechanisms that foster adaptation and legitimacy among ecosystem actors.
Established companies venturing into digital platforms may face value impedance, a manifestation of friction or barriers hindering value flow within organizations. 39 Often arising from digital transformation gaps related to mindset, business model, organizational reconfiguration, and continuous renewal, these barriers can impede the growth and success of incumbent-born digital platforms. Developing dynamic capabilities—such as sensing the internal environment, value-capturing through connectedness, orchestrating silos, and transforming organizational boundaries—can help mitigate value impedance and foster successful digital platform development.
Another significant challenge for established companies is silo thinking and lack of coordination across multiple business units and product lines. 40 This silo mentality can hinder the cross-functional collaboration necessary for effective platform governance. Tiwana and Kim (2015) emphasize the importance of “peripheral knowledge,” where departments need to understand aspects of each other’s work to facilitate smoother communication and collaboration. They argue that without such cross-functional understanding, the decision-making process can be significantly delayed, impacting the strategic agility of IT initiatives. 41
The challenges established companies face require revisiting the “classic” core-periphery model. Thus, it is critical to understand better how established companies can manage the additional complexity and implement suitable platform governance during the design and implementation phases.
Method
To close the theory gap related to the governance of digital platform ecosystems initiated by established companies, we conducted an exploratory multiple-case study with four companies that have shifted to a platform strategy or are in the process of doing so. 42 An exploratory approach is appropriate because established companies implementing a platform strategy represent a highly dynamic phenomenon. An exploratory approach enables us to consider the phenomenon’s context and engage in data collection, data analysis, and literature on platform governance iteratively.
Our multiple case study comprises IS-Corp, an enterprise software vendor; APIbank, a financial services company; CarGroup, an automotive manufacturer; and ToolGroup, a producer of tools and equipment for construction (all company names have been anonymized). According to the exploratory approach, we did not sample the cases upfront based on fixed sampling criteria. Instead, we started with one case (IS-Corp) and sampled further cases with characteristics that contributed to the theoretical saturation of our results. 43 We applied two sampling criteria: the companies had to be established and successful in their industries before the dot-com bubble, and they had to be in the process of implementing a digital platform strategy with indications that the platform strategy was successful, i.e., that third-party developers were active on the platform (see Figure A1 in the Appendix for examples of third-party developers for each platform).
To analyze the cases, we iteratively collected primary and secondary data from the four companies and applied coding procedures of the grounded theory methodology to examine them. 44 For primary data, we conducted 62 semi-structured interviews with employees of established companies involved in implementing the digital platform ecosystem strategy. The interviews were recorded and transcribed. Memos written directly after the interviews were a basis for the subsequent coding process. In addition, we evaluated various types of documents as secondary data (e.g., company announcements, investor relations documents, internal meeting minutes, and presentations). We used the secondary data to better understand the structure of the digital platform ecosystems, to get examples of core partners and third-party developers, and to triangulate our findings on platform governance from the interview data.
To analyze the interview data, we first applied open coding, focusing on all governance activities of the four platform owners and their implications for other actors in the digital platform ecosystem. In the next step, we used axial coding to aggregate open codes into sub-categories related to the governance of different ecosystem actors (Table 1). 45 For example, we identified several open codes related to the platform owners’ own products and how they had to be migrated onto the new platform by the respective business units. Thus, we aggregated these codes in the sub-category “Migration of internal products onto platform.” Subsequently, we clustered these sub-categories into categories based on the group of ecosystem actors targeted by the governance. Notably, we identified internal business units, core partners, and third-party developers as categories.
Illustration of the Coding Scheme.
Kimmo Karhu, Robin Gustafsson, and Kalle Lyytinen, “Exploiting and Defending Open Digital Platforms with Boundary Resources: Android’s Five Platform Forks,” Information Systems Research 29/2 (2018): 479-497.
Joachim Stonig, Torsten Schmid, and Günter Müller-Stewens, “From Product System To Ecosystem: How Firms Adapt To Provide an Integrated Value Proposition,” Strategic Management Journal, 43/9 (2022): 1927-1957.
Johan Sandberg, Jonny Holmström, and Kalle Lyytinen, “Digitization and Phase Transitions in Platform Organizing Logics: Evidence from the Process Automation Industry,” MIS Quarterly, 44/1 (2020): 129-153.
Maximilian Schreieck, Manuel Wiesche, and Helmut Krcmar, “From Product Platform Ecosystem to Innovation Platform Ecosystem: An Institutional Perspective on the Governance of Ecosystem Transformations,” Journal of the Association for Information Systems, 23/6 (2022): 1354-1385.
Lastly, we used selective coding to link the categories to our theoretical pre-understanding of platform governance. For example, the governance of internal business units was most closely aligned with hierarchical forms of governance, the governance of core partners was related to closed forms of governance, and the governance of third-party developers corresponded to open forms of governance. For the governance of relationships between ecosystem actors, we did not identify a form of governance from previous literature and instead used the emergent concept of conciliatory governance.
In the process of selective coding, we relied on constant comparison by iteratively linking relationships that emerged between the emergent categories and theoretical concepts on governance to instances in the data. 46 The process of constant comparison was supported by memos that captured our ideas on emerging categories and their connections throughout the data analysis.
Findings
Case Descriptions
We chose four established companies to discuss how they apply governance across different layers of their digital platform ecosystem to orchestrate internal strategic business units, core partners, third-party developers, and the relationships between these actors. Figure A1 in the Appendix details the case companies and their digital platform ecosystems.
IS-Corp is a leading software company specializing in enterprise software, particularly enterprise resource planning (ERP) systems. With customers worldwide and offices in over 100 countries, IS-Corp’s ERP system is used across various industries and companies of different sizes. Several years ago, IS-Corp entered the world of cloud-based platforms. Thereby, IS-Corp encountered significant external challenges, mainly because they worked with a wide range of partners and navigated diverse global markets. As a result, they had to include more external developers for their newer systems to stay ahead and bring fresh ideas from outside their immediate network. Internally, though, things were a bit simpler. IS-Corp had already restructured its main enterprise software, making it easier to work with partners who built additional features onto it. One of IS-Corp’s partner program managers summarized the motivation behind the platform strategy as follows: The fundamental motivation [for partnering] is always that our portfolio does not cover end-to-end; thus, extending our services with these partners is important. The customers want an end-to-end process. Therefore, it is necessary to integrate third parties into the process . . . . This has, on the one hand, technological reasons if we consider, for example, highly technological solutions: build-time applications that run directly on machines, that is, know-how that [IS-Corp] does not possess . . . .On the other hand, in the end, it is the business case. If there is a relatively small market, [IS-Corp] usually would not want to implement the specific solutions on its own.
APIbank is a global banking and financial services company with offices in over 70 countries.
47
The company was undergoing digital transformation to provide a digital customer experience via multiple channels, primarily for retail banking. An essential step in APIbank’s digital transformation was the creation of a digital platform ecosystem, which partly exposed the bank’s data and functionalities to third-party developers. This proactive approach was also the company’s response to FinTech companies—tech startups challenging the core business of traditional banking companies. A project leader at APIbank described the main reason behind the platform strategy: You cannot do everything yourself. As a big company, we are simply not fast enough to come up with new innovative ideas, and then, in addition to that, you find . . . startups that focus on one piece of the value chain, and they do really well. And I think that’s also related to what customers perceive . . . . The purpose of the banking API is to attract people and businesses to use the API to enhance some offerings that aren’t obviously connected to banking but somehow profit from banking. So, this is the objective.
ToolGroup is a multinational company that manufactures construction and building maintenance tools and equipment. Recently, the group has begun offering digital solutions that enhance their products. They began integrating technology directly into their tools, adding functionalities further enhanced by online connectivity. The platform’s program director highlighted that synchronizing internal activities is required in the first step to establish the platform successfully: We want to define how isolated software solutions can play together so we can harvest and utilize different synergies from the generated data as well as maintained data. From the other side, we want to create the technical building blocks starting from hardware, i.e., we want to establish common standard hardware modules that can be reused for different tools and embedded software parts; we want to establish libraries so that they are part of this platform and linked to these technical building blocks.
CarGroup is a German automotive manufacturer with a global production and sales network. Several years ago, CarGroup shifted from a pure automotive manufacturer to a provider of individual mobility. This shift has been marked by the transformation of their in-car software into a platform for various applications. A team member of the platform project at CarGroup highlights that to fulfill the customers’ increasing expectations of additional services, leveraging the creativity of third parties is essential: Eventually, the target picture . . . is a valuable offer, which reveals a premium integration into the car. In this interpretation, premium refers to the perfect fit to the context as well as perfect integration in the driver’s environment . . . . However, when I actually enter scale with external developers, I find a massively larger pool of ideas I can build on and much more expertise, which I can leverage from external sources. Thus, I create a much broader access to the customer. I consider this as large added value.
Governing Internal Business Units
The four companies we examined recognized the potential of using digital platforms. These platforms allowed them to work with a broader group of external partners to create more value. However, moving to this new way of working was difficult. In the past, each part of the company was responsible for specific products or services. For example, at ToolGroup, different teams developed and marketed various types of tools. A single digital platform offering enhanced features becomes valuable only if it includes all tools. The product owner of ToolGroup’s digital platform summarized this challenge: [Establishing a platform] requires multiple silos to suddenly work together . . . one tool that is connected is a nice thing, but most of the use cases which differentiate your offering requires a population [of tools] that is connected. And getting that population equipped, considering hardware development cycles, product life cycles, adoption rate at customers, willingness to pay for it, hardware cost for connectivity, technology readiness, communication technology, a combination of costs for these communication technologies—that are quite complex things to handle to actually define the right sequence of use cases for implementation so that you can define a good path through that jungle.
To make the platform strategy work, all products should be able to connect to the system in the same standard way. Instead of letting each team decide how their product connects, one central team should control this process. This team needs to have the power to make decisions and ensure everyone follows them. At ToolGroup, this team decided on a common way for all their tools to communicate with the platform. The head of connected tools at ToolGroup described the interoperability requirement for a digital platform: The benefit lies in connecting a lot of devices that customers might have with each other, even across brands and manufacturers. So, there are connected tools, connected assets, connected buildings, connected cities, so this is all a full potential of the benefits that come into play when a lot of things are connected. Now, that obviously requires that you have the opportunity for these devices to communicate with each other and exchange information, and that requires a certain level of standardization and interoperability standards, which is why this is clearly a platform game.
CarGroup’s experience was different. Since cars have more features in common than tools do, making them all connect to a platform was simpler. CarGroup also realized they needed to keep their digital platform’s development separate from the cars’ development and production. This separation was required because information technology changes quickly, whereas making cars takes a longer time. Furthermore, they needed to ensure the digital platform could work with other software being developed within the company. At first, CarGroup struggled to establish a development process for the platform that conformed to the requirements of other internal business units: In the beginning, there were massive problems in the older generation [of the platform]. There was a release of an arbitrary new version, and randomly, things were not working, and tools frequently crashed. And we still experience similar things in the current generation since tools and the platform are again concurrently developed. (Project manager, CarGroup)
The case of CarGroup shows the importance of the digital platform being accessible internally to all business units that work on the cars’ user interfaces. By creating dedicated project spaces where members of different business units could experiment with the digital platform already in its early stages, CarGroup created awareness for the platform project. This approach sparked ideas for use cases on the platform across different internal business units.
I would say the platform itself has to be as open as possible for an internal utilization. This brings us forward since we have multiple business units that intend to deploy their products and services into the vehicle and, up to now, they rely on the development and safeguarding processes of multiple departments. (Project manager, CarGroup)
IS-Corp and APIbank faced different challenges because they offer services, not physical products. Their main task was to decide which services were essential to their digital platform and which were peripheral. After deciding, they set up a standard way for the platform and peripheral services to communicate.
Governing Core Partners
The four companies had longstanding relationships with their core partners. These partners helped them develop essential features and added their expertise, especially when entering new markets. For instance, IS-Corp first encountered some difficulties when they wanted to work with the insurance sector. The reason for these difficulties was that IS-Corp did not have the detailed knowledge required for that industry. By teaming up with a partner specializing in IT for insurance, IS-Corp gained relevant expertise and became more credible for insurance companies.
[The insurance companies] laughed at us: ‘You don’t have a clue about the [insurance] industry!’ And they were right: [IS-Corp] did not know much about the insurance industry. This is why we have a partner experienced with IT solutions for insurance. And the insurance companies said they would consider our solutions if we teamed up. That is how this longstanding successful partnership took off. (IS-Corp chief partner expert)
The four companies set up specific rules and methods to work effectively with their core partners. These helped them choose the right partners, motivate them, and work together in the best way possible. At the same time, they established standards that partners had to meet. IS-Corp, for example, had a special team just to onboard and work with partners. This team checked potential solutions from partners, got to know their market, and built strong relationships with them. IS-Corp’s global licensing manager described: We have a dedicated team called Business Development for Partner Solutions . . . .They analyze the [potential] partner solution, they know the market, and they actively get in touch with these partners. Of course, a business case is developed beforehand [to estimate] what revenue can be expected with that partner. Then, the partner is contacted, and a deeper ‘due diligence’ is conducted. The case is presented to a larger board at [IS-Corp]; they scrutinize the revenue, the potential, how the solution is framed, . . . and whether it overlaps with other products. Do we create competition with our own products or partner products? What does the technology look like? How is the partner’s shape, particularly regarding financial stability? How large is the partner? Can the partner provide 24/7 support? If we market the product, we market it worldwide; thus, support has to be ensured . . . . if [the board] says, that sounds nice, that is beneficial for [IS-Corp], we will start contract negotiations.
As these companies started to use platform strategies more, their core partners remained important. They helped build the platform core or essential apps that go with it. The company that owned the platform closely monitored what these partners did and how good their contributions were. This careful checking was necessary because the solutions they provided were critical. For example, a car system could be dangerous for the driver if something goes wrong. And if there is a problem with a bank’s services, it could severely harm the company’s reputation. A project manager for the platform project at APIbank summarized: The main thing is that before we go live with any new [partner] functionality, we have to go through legal obligations and all those business functions which verify if it’s okay to go live, and then still our business counterpart has to verify if this functionality or the data behind it fits into what people might do with it and therefore if it’s okay for the business to provide the data to other people out there or not.
When these companies started focusing more on platforms, they did not want to replace their core partners with third-party developers. Many core partners stayed involved in the work and decisions on the platform core. For example, ToolGroup worked with an IT provider to get their technology ready to connect with third-party developers. Drawing from its experience with other platform projects, this IT provider also advised ToolGroup on best practices for platform governance.
Governing Third-Party Developers
When the companies started using platform strategies, they wanted to benefit from the ideas of third-party developers. Although inexperienced with launching platforms, their large existing customer base helped them to attract these developers. They could promise a chance for the developers to reach all these customers. For example, for APIbank, integrating developers into their platform effectively provided a gateway to their millions of customers, increasing the likelihood of widespread usage of the developers’ products. A project manager at APIbank stated: We have critical mass already . . . . compared to startups, something like the Solaris Bank, which was also offering banking-as-a-service to startups. Their problem is that they can only offer a backend, but they cannot offer customers. On our platform, we have several million customers. The thing is that on our platform, the external developers will be able to access . . . all our customers . . . . So, from a development perspective, there is a pool of a million or so potential customers.
As they worked more with these developers, the companies realized they needed new rules and ways to manage them. Instead of having special rules for just a few core partners, they needed a system that worked for many developers simultaneously. APIbank saw this difference very clearly. The old way was to set up a unique contract with each partner. The new way is to set up generic rules without special conditions for third-party developers connecting to the platform. A project manager of APIbank illustrated the difference between the two governance approaches as follows: I think the biggest difference between a partner approach and an open [approach] is that in the partner approach, you are entering a specific and individual business agreement with a specific partner where there is a lot more responsibility on the bank’s side, which is more the classical model where you have to do vendor risk management and other things, which is all very expensive and very time-consuming. Whereas in the open case, most of the responsibility isn’t with the bank. It is a very, very clearly defined interface with generic conditions and no special terms regarding the API consumer.
It was essential for the four companies to have straightforward ways for these third-party developers to connect to the platform. But just having a way to connect was not enough. Developers needed extra tools and information to connect to the digital platform properly. They needed clear instructions and examples to understand how to use the connection points. All four companies were either providing these tools or getting them ready.
IS-Corp, which had the most mature platform, offered the most help to third-party developers. They had many resources, such as online guides, blogs, how-to videos, FAQs, and a YouTube channel. These tools helped developers understand how to work with the platform. If they faced a problem, they could contact IS-Corp’s team for help. IS-Corp, with the most advanced digital platform ecosystem from our sample, had the broadest range of resources available for third-party developers, as one external developer in the IS-Corp ecosystem described: There are wikis, social media websites, or blogs where people inform other people on what they did; you find tutorials, Q&As, FAQs. Then there is [IS-Corp’s] academy, a YouTube channel, which is also a key part in getting the knowledge out there on how to develop on [the IS-Corp platform] and how to get started and—even more complex—what functionalities one can use . . . . [these sources] are giving a good starting point for everyone just to get started, and if they get stuck in a problem that is deeper and it is not answered, . . . they can still contact the development or the representative who sold them the [IS-Corp platform] instance.
Third-party developers were free to develop new ideas without following strict rules. This autonomy helped them be more creative. Moreover, developers could talk and share ideas with other developers in online groups or at events. This exchange helped them learn from each other and find solutions to problems. To ensure that the innovations created by third-party developers were of good quality, there was a checking process before their products went live on the platform. And other developers often helped keep quality high by giving feedback and advice in their groups.
Governing Relationships Between Ecosystem Actors
In addition to governing internal business units, core partners, and third-party developers, the four platform owners governed the relationships between their business units and external partners.
First, concerning the relationship between internal business units and peripheral actors, platform owners moderated tensions resulting from potential competition between the two groups. At API bank, the opening of the API to third-party developers without prior connection to the company was initially met with skepticism within some of the business units. The head of digital transformation and innovation at APIbank illustrated: But I think again it relates to the fear of people that something is changing, for instance, that someone from the outside has developed something that has been developed inside, that they will be made redundant.
This approach also ensured that a few high-quality applications were available on the platforms right at the time of the platform launch.
Second, the platform owners realized there was a lot of potential in collaborations between internal business units, core partners, and third-party developers. Rather than governing each group individually, the platform owners also aimed governance at their relationships. By fostering collaboration in innovation clusters, platform owners could purposefully match core partners and third-party developers with business units based on their expertise. To do so, platform owners organized both one-off formats, such as partner workshops, and more continuous formats, such as co-innovation spaces. A core partner of CarGroup described their experience with such a format: So, we are currently here [in CarGroup’s co-innovation space] at least once a week. The main advantage is the direct communication with [CarGroup’s business units] because it is simply easier to ask something directly than to write emails or call. Another advantage is that the test setup that you find here tends to work better than in our company. I tend to think the idea is very good. That you say you put all the people involved together, and they can exchange ideas.
IS-Corp used different workshop formats for partners to create innovation clusters. Such workshops typically focused on a specific technological topic (e.g., the Industrial Internet of Things) or a specific industry (e.g., logistics) and included presentations of existing apps and use cases by selected partners. Third-party developers would benefit from the exchange with IS-Corp business units and core partners by learning more about developing applications for the IS-Corp platform and building a network of contacts they could draw on for questions about their development projects.
A Multi-Layer Model of Platform Governance
In essence, platform governance suggests that the platform owner controls the platform core and governs a periphery of third-party developers. 48 While this understanding applies to platform-born companies who develop digital platform ecosystems from the ground up, the four cases in this study displayed a more complex situation for established companies transitioning toward a platform strategy. They needed to consider multiple layers of ecosystem actors in their platform governance approaches. Thus, Figure 2 presents an enhancement of the initial theoretical understanding by shedding light on the governance of ecosystem actors in the core and the periphery and their relationships.
A multi-layer approach to platform governance for established companies (a: BU = business unit).
Established companies aim to combine various products and services on a digital platform. Our case studies showed that these products and services are provided not only by third-party developers, but also by internal business units and core partners. Thus, the platform owner needs a unified approach to platform governance that addresses the different actors.
Hierarchical governance of internal business units. Hierarchical governance aims to align the internal business units’ activities on the digital platform. 49 To do so, the corporate center or the dedicated unit responsible for the platform project assumes centralized decision rights. It defines internal standards that the business units must adhere to, for example, to synchronize the development cycles of the platform core and the business units’ products and services. Process control mechanisms ensure adherence to internal standards. From an architectural viewpoint, standards, modularity, and interoperability of the internal products and services are crucial to governing business units in the platform core. For example, IS-Corp’s cloud platform served as a development environment for applications implemented by the business units within the company. Comparing the four cases of this multiple case study showed that the governance of internal business units was particularly crucial for digital platforms built on hardware products. As illustrated by CarGroup and ToolGroup, development cycles for hardware and software had to be aligned to enable the launch of a digital platform. Once the platform had been launched, platform owners could grant their internal business units more freedom to come up with new applications on the platform.
Close governance of core partners. This part of the multi-layered approach to platform governance is coined by the closeness of the relationship between the platform owner and the core partners. Longstanding partners can be of crucial importance to the continuous development of the platform core. Therefore, the platform owner often makes decisions regarding the platform core jointly with them, sharing its decision rights. Similarly to internal business units, process control is applied to ensure that core partners are aligned with the digital platform ecosystem goals. However, instead of hierarchical governance, the platform owner can use contractual governance to implement control mechanisms with penalties in case of violations and relational governance to work closely with core partners on changes to the core. 50 For example, IS-Corp collaborated with core partners that provided micro-services and tools on the platform, which were crucial resources for third-party developers who joined the ecosystem. The core partners had to fulfill the same quality requirements as IS-Corp’s internal solutions, which were determined in the partner contracts. While core partners traditionally were supported with individualized boundary resources and relationship-specific customized IT, platform owners tried to standardize IT-based transactions with core partners iteratively. Governing core partners was particularly crucial for digital platforms within a business-to-business context (such as IS-Corp’s and ToolGroup’s digital platform) because a large number of partners traditionally had been involved in selling and distributing the platform owner’s products and services. Providing these partners with opportunities on the new platform was, therefore, a crucial lever to scale the digital platforms.
Open governance of third-party developers. The governance targeting third-party developers is more open than that of core partners to maximize generativity in the broader digital platform ecosystem. 51 Third-party developers are granted autonomy to choose technologies and frameworks, work along their own development cycles, and interact with customers. However, they do not have decision rights regarding the platform core. 52 As the developers are granted autonomy, platform owners rely on outcome-based control mechanisms to ensure quality standards. Additionally, informal control through developer communities emerges as soon as vibrant communities of third-party developers have been established. 53 From an architectural point of view, the platform owner aims to standardize the interfaces between the platform core and complementary applications and provide standardized boundary resources to ensure the greatest possible accessibility and ease of use. For example, APIbank invested much time and effort in creating APIs supported by a developer portal with comprehensive material for potential third-party developers. Thereby, the number of third-party developers potentially would be larger in digital platform ecosystems in business-to-consumer contexts such as the digital platforms provided by CarGroup and APIbank. The large number of existing customers would create network effects, attracting third-party developers to the platforms.
Conciliatory governance of relationships between ecosystem actors. The governance of relationships between internal business units, core partners, and third-party developers was conciliatory, i.e., it focused on harmonizing the activities of the different ecosystem actors. On the one hand, platform owners had to manage tensions between internal business units and third-party developers as the companies became more open and allowed competition between internal and external solutions on the digital platforms. On the other hand, platform owners fostered collaboration between business units, core partners, and third-party developers on their platforms. They would co-create solutions in innovation clusters, often with a specific focus on a technology or industry. As illustrated by our case studies, the platform owners’ business units typically collaborated with core partners with industry experience to create a foundation for additional third-party applications.
The multi-layer model significantly advances our understanding of digital platform governance. While prior research focused primarily on governing third-party developers in the ecosystem’s periphery, 54 our findings reveal a more nuanced picture. The traditional core-periphery model overlooks the critical governance needs of internal business units and existing core partners within established companies. As a result, we expand the body of knowledge on platform governance by broadening the concept of “who is governed” 55 beyond third-party developers. Our research demonstrates that established companies transitioning into platform owners must effectively govern a diverse array of both internal and external ecosystem actors, including business units and strategic partners.
Our findings also contribute to existing work on hybrid governance approaches, which has typically focused on combining tight and loose governance in interfirm networks to manage IT projects efficiently, 56 rather than fostering generativity within ecosystems. Our research reveals that platform owners strategically employ hierarchical governance for actors contributing directly to the core platform, while utilizing open governance for those involved in the periphery. This combined approach—hierarchical, open, and close governance—enables established companies to successfully orchestrate complex digital platform ecosystems. 57
The more detailed view of the different groups governed in digital platform ecosystems also allows us to reflect on the governance of the tradeoff between openness and control in digital platform ecosystems for the case of established companies. 58 The tradeoff is characterized by higher openness fueling the generativity in digital platform ecosystems while making quality control more difficult. Conversely, higher levels of control can increase the quality of contributions to a digital platform ecosystem but negatively impact the generativity. Established companies hesitate to open their technology to third-party developers as they assume that their technology includes some of their competitive advantages. In particular, companies that offer critical services, such as APIbank with banking services, want to stay in control of their platform. Differentiating core partners and third-party developers helps to implement mixed governance approaches in which the core is relatively closed and governed with tight control, while the periphery is open and governed with loose control. Thus, we provided a balanced approach for platform governance that addresses the openness vs. control tradeoff when attracting third-party developers and the question of how to work with different groups of ecosystem actors on a platform that fuels generativity but has a core with critical services.
Recommendations for Practitioners
Our study yields several actionable recommendations for managers and practitioners embarking on or currently navigating digital transformations. These recommendations are directly derived from the findings and case studies discussed to provide guiding principles for implementing effective platform governance of the core and the periphery. These recommendations are not recipes for success, but suggestions or considerations for managers developing platform governance strategies:
Embrace a multi-layer governance approach. A multi-layered approach involves recognizing the differences between internal business units, core partners, and third-party developers and implementing appropriate governance approaches for each. For example, internal business units might require more hierarchical approaches, while third-party developers might benefit from a more open approach. This approach ensures the platform owner maintains control of their core services while allowing more flexibility and generativity at the periphery. As an illustration, IS-Corp kept control over core activities while enabling open collaboration for external innovation. IS-Corp used hierarchical governance to maintain control over its internal business units, set internal standards, and used process control mechanisms to synchronize the development cycles of the platform core and the products and services offered by the business units. In contrast, to encourage innovation from third-party developers, IS-Corp adopted an open governance model, granting them autonomy while using outcome-based control mechanisms and fostering informal control through developer communities to maintain quality standards.
Leverage existing assets and relationships. Established companies could leverage existing internal capabilities, partner relationships, and customer bases to gain a competitive advantage. These existing assets and relationships can establish a foundation for the platform, attract third-party developers, and offer access to an existing customer base. For instance, ToolGroup leveraged its existing relationships, particularly with an IT provider experienced in platform projects, to facilitate the implementation of its platform strategy. This IT provider not only helped ToolGroup achieve the technological readiness needed to connect with third-party developers, but also offered valuable advice on best practices for platform governance, drawing from their experience with other platforms. However, established companies should be aware of the potential for conflict when existing partners are asked to participate in the platform on equal footing with new partners and should implement solutions to mitigate those concerns. Relatedly, leveraging existing customer bases can help established companies unlock network effects and overcome the chicken-egg problem inherent to platforms. 59 In business-to-consumer markets, where the chicken-egg problem is particularly pronounced, platform owners must reach critical mass fast before customers lose interest. Thus, the customer base of established companies can be a major asset to attract third-party developers. Still, the digital platform needs to offer sufficient value for consumers to remain on the platform. For example, APIbank and CarGroup could draw on their existing customer bases in the banking and automotive industries to attract third-party developers to their digital platform ecosystem.
Standardize and simplify integration for third-party developers. Established companies could simplify integration for third-party developers. Such an integration can be achieved by standardizing interfaces and providing support to make it easier for third-party developers to create applications for the platform. Developers need comprehensive tools and information, such as clear instructions and examples, to effectively utilize the connection points. All four companies in the study either provided these resources or actively developed them. APIbank, for instance, dedicated significant time and effort to creating APIs supported by a comprehensive developer portal containing a wealth of material for potential third-party developers. Similarly, IS-Corp, recognizing the need to support third-party developers, developed a range of helpful resources, including online guides, blogs, how-to videos, FAQs, and a YouTube channel. These tools are designed to help developers understand how to interact with the IS-Corp platform and provide them with support channels should they encounter problems.
Institute clear guidelines and support for core partners and third-party developers. Established companies could establish guidelines aligning all participants with the platform’s strategic goals. Companies could offer core partners tailored support mechanisms that reflect their strategic importance. IS-Corp established a dedicated team to manage relationships with core partners, conduct due diligence, analyze market potential, and ensure alignment with IS-Corp’s product portfolio. ToolGroup leveraged existing resources, including internal capabilities and longstanding partner relationships, as competitive advantages. They acknowledged the challenge of aligning multiple internal business units to collaborate on a single digital platform, recognizing the need for a unified approach to platform governance. ToolGroup also collaborated with core partners with industry experience to establish a foundation for third-party applications.
Establish a common goal for all ecosystem actors. To support conciliatory governance efforts, platform owners could aim to establish a goal shared by all ecosystem actors. Even though all actors focused on maximizing their benefits from participating in the ecosystem, platform owners can make the case that all actors would benefit more if the ecosystem were more successful. A common goal would also help navigate tensions between internal business units and external actors and guide the collaboration of actors in innovation clusters. For example, IS-Corp established the common goal of making the customers of the digital platform more successful, regardless of whether they would use only IS-Corp solutions or a combination of IS-Corp, partner, and third-party developer solutions. Over time, more successful customers would then spend more within the ecosystem. However, to make a common goal meaningful, platform owners should allow both core partners and third-party developers to capture a fair share of the value being created in the ecosystem.
Armed with these recommendations, practitioners in established companies are well-positioned to navigate platform governance strategies. They should continuously monitor the effectiveness of their governance mechanisms and adapt them as the platform changes. This includes responding to market demands, ensuring the platform remains competitive, and staying informed of emerging trends in the market.
Conclusion
Established companies are increasingly adopting digital platforms and ecosystems to stay competitive. This study found that established companies, unlike digital-native companies, need a multi-layered approach to platform governance to address the complexities of managing internal business units, core partners, and third-party developers. Established companies can leverage their existing business units and partners as a competitive advantage in the digital platform ecosystem. They can use these existing structures to access customers and encourage third-party developers to join the platform. However, established companies should not treat existing partners like new third-party providers. Instead, they need custom solutions to integrate these partners into the platform while still recognizing their unique relationship with the company.
This study contributes to understanding digital platform governance by examining its application in established companies. It moves beyond the traditional focus on third-party developers and explores the governance of a broader range of ecosystem actors, including internal business units and core partners. This multi-layered approach helps established companies balance control with ecosystem openness to foster innovation and value co-creation within their digital platforms.
Footnotes
Appendix
Funding
The author(s) disclosed receipt of the following financial support for the research, authorship, and/or publication of this article: This work was supported, in part, by the Deutsche Forschungsgemeinschaft (DFG, German Research Foundation) – project no. 521353095 and by the Austrian Science Fund (FWF) – project no. 10.55776/I6567.
Notes
Author Biographies
Maximilian Schreieck is an Assistant Professor of Information Systems, specializing in Digital Services and Platforms at the Department of Information Systems, Production, and Logistics Management at the University of Innsbruck. His research focuses on digital platform ecosystems, platform governance, the digital transformation of established companies, and digital platforms for social causes. (email:
Jan Ondrus is a full professor and Chair of Digital Disruption at ESSEC Business School in Singapore. His research centers on the development of digital platform ecosystems and the disruptive/transformative aspects of technology for business model innovation and social impact. (email:
Manuel Wiesche is a full professor and Chair of Digital Transformation at TU Dortmund University, where he studies platform ecosystems, digital work and AI, and new technologies as a source of organizational innovation. (email:
Helmut Krcmar is a Professor Emeritus of Information Systems and “TUM Emeritus of Excellence” at the Technical University of Munich (TUM), Germany. His research interests include digital transformation, platform-based ecosystems, information and knowledge management, service management, and information systems for healthcare and government. (email: