Platforms, Ecosystems, and Vendor Management

A network effect is the phenomenon whereby a product or service becomes more valuable as more people use it. Each additional participant increases the value of the platform for all existing participants. Network effects are the primary source of competitive advantage in platform businesses, and understanding which type of network effect a platform relies on determines how hard it is to compete with or displace.

Direct network effects (also called same-side effects) occur when value increases as more members of the same group join. WhatsApp becomes more valuable as more of your contacts use it. LinkedIn becomes more valuable as more professionals join. Direct network effects are common in communication and social platforms. They are powerful because they are self-reinforcing, but they are also the most obvious to regulators scrutinising market concentration.

Indirect network effects (cross-side effects) occur when value for one group increases as the other group grows. More Uber drivers make Uber more valuable for riders, because wait times fall. More Uber riders make Uber more valuable for drivers, because earnings per hour increase. Most marketplace platforms rely on indirect network effects. The strategic implication is that growing one side of the market accelerates the other, creating a compounding advantage once critical mass is achieved.

Data network effects occur when a platform learns more from each additional user interaction, making its service more valuable for all users. Spotify's recommendation engine improves for all listeners as more listening data is ingested. Waze's routing improves for all drivers as more drivers share location data. Data network effects are harder to build (they require machine learning investment and large datasets) but harder to replicate (data assets are unique and accumulate over time).

Marco Iansiti and Roy Levien's 2004 framework, published in The Keystone Advantage (Harvard Business Press), classifies organisations within digital ecosystems by their strategy and role. The framework distinguishes three positions, each with different implications for long-term competitive advantage and ecosystem health.

A keystone player creates and shares value with ecosystem participants, improving ecosystem health and productivity. The keystone's primary concern is maintaining a healthy ecosystem. It extracts modest value relative to the value it creates. Google Maps acting as location infrastructure for thousands of applications is a keystone. Salesforce providing CRM (Customer Relationship Management) infrastructure for its AppExchange ecosystem is a keystone. The strategic advantage of the keystone position is sustainability: a healthy ecosystem produces compounding returns as niche participants innovate within it.

A niche player specialises in a specific domain within an ecosystem, creating differentiated value that the keystone does not provide. Niche players are the majority of ecosystem participants. Their specialisation makes the ecosystem collectively more capable. A tax software provider that integrates with Salesforce is a niche player. A fraud detection API that plugs into Open Banking infrastructure is a niche player.

A dominator extracts maximum value from an ecosystem, restricting what others can do. Dominators may achieve short-term advantage but tend to degrade ecosystem health, reducing the collective innovation capacity they depend on. Apple's App Store behaviour, with 30% commission, content moderation used to exclude competitors, and tying arrangements, is what led the EU to designate Apple as a "gatekeeper" under the Digital Markets Act: regulatory recognition that Apple's platform governance had crossed into dominator territory.

Vendor lock-in is a situation in which an organisation becomes dependent on a single vendor's products or services because switching to an alternative would be prohibitively expensive, technically difficult, or disruptive. Lock-in is structural rather than purely contractual: even if the contract permits switching, the switching cost may exceed the switching benefit.

Digital transformation programmes frequently create vendor lock-in through architectural choices made under time pressure. A structured lock-in risk assessment considers four dimensions:

1. Data portability: can the organisation extract its data in an open, standard format if it needs to switch? Proprietary formats with no export API create high lock-in even if the contract allows switching.
2. Integration depth: how deeply is the vendor's product embedded in other systems? A platform integrated with 40 other systems via vendor-specific connectors is structurally very difficult to replace.
3. Skills concentration: does the organisation's operational capability depend on skills specific to this vendor's product? Vendor-specific toolchains create capability risk if the relationship ends.
4. Market concentration: is there one dominant vendor or a competitive market with multiple comparable alternatives? One credible vendor at scale means less negotiating leverage and higher switching risk.

The UK Government's Cloud Strategy (updated 2017, reviewed 2022) explicitly addresses vendor lock-in risk. The "cloud first" policy requires departments to consider cloud solutions before on-premise, but the accompanying guidance requires assessment of portability, open standards compliance, and exit strategy before committing to a provider. Several high-profile UK government contracts with single cloud providers have been subject to Parliamentary scrutiny on lock-in grounds.

Organisations that build platform businesses must decide how to generate revenue from their APIs. The primary models are freemium (basic access is free, advanced features or higher volumes require payment), pay-per-use or metered pricing (charges based on call volume, data transferred, or compute consumed), tiered subscription (fixed monthly fees for defined usage bands), revenue share (the platform takes a percentage of transactions processed through its API), and data access fees (organisations pay for access to anonymised, aggregated platform data).

Twilio and Stripe use freemium for developer acquisition, moving users to paid tiers as usage grows. AWS (Amazon Web Services) uses metered pricing throughout. Stripe also uses revenue share at 0.35-1.5% per transaction, creating a direct alignment between platform and customer commercial performance.

Data access fees raise significant data ethics questions. A platform that monetises user behaviour data as an aggregate product may face regulatory scrutiny under the EU Digital Markets Act's provisions restricting how gatekeeper platforms use data collected from their business users' customers.

The EU Digital Markets Act (DMA), EU Regulation 2022/1925, came into force in May 2023 with obligations applying from March 2024. The DMA designates large online platforms as "gatekeepers" if they meet size and usage thresholds, and imposes obligations regarding interoperability, data portability, and fair dealing with business users.

The DMA's gatekeeper obligations include interoperability requirements (messaging gatekeepers such as Meta's WhatsApp and Messenger must open their APIs to allow third-party messaging services to interoperate), data portability (gatekeepers must allow users to move their data to competing services in a standard format), fair access (app store gatekeepers must allow alternative app stores and direct distribution), a self-preferencing prohibition (gatekeepers cannot favour their own products in search results or app rankings), and data use restrictions (gatekeepers cannot use personal data collected from their business users' customers to compete with those business users).

Six companies were designated gatekeepers in September 2023: Alphabet (Google), Amazon, Apple, ByteDance (TikTok), Meta, and Microsoft. The UK is developing a parallel framework through the Digital Markets, Competition and Consumers Act 2024 and the CMA's (Competition and Markets Authority's) strategic market status regime.

Every organisation building digital capability faces the fundamental make-or-buy question at every capability level. The framework for this decision should consider four factors.

Strategic differentiation: capabilities that differentiate the organisation competitively should be built or built on open-source foundations. Capabilities that are commodities in the market should be bought.

Total cost of ownership: build costs include development, maintenance, support, and the opportunity cost of engineering capacity. Buy costs include licence fees, integration effort, and lock-in risk. Both must be calculated over the same time horizon for a meaningful comparison.

Speed: buying accelerates deployment. Building takes longer but produces something tailored to specific needs. The speed advantage of buying is real but front-loaded. Maintenance and evolution costs accumulate over time.

Data and privacy: where data processed by a capability is sensitive or strategically important, building or using open-source tooling may be preferable to sharing it with a third-party vendor. SaaS platforms that process sensitive data create the international transfer considerations covered in Module 13.

The build-vs-buy decision is frequently made at the technology selection stage without considering the long-term maintenance burden of building. A custom-built payment system that solves a specific need may be a liability within three years if the team that built it has moved on and the codebase has not been maintained. The question is not "can we build this?" but "can we maintain what we build for the next five to ten years?"