The Platform Paradox

Now that our view of platforms has become less fuzzy, let’s dive deeper into the subtitle of this book: how platforms can break through age-old IT conflicts, specifically those between achieving standardization and boosting innovation. For that, we need to rethink the role that standards play and expect a few surprises.

Platforms play a unique role in overcoming perceived opposites. They are per definition harmonized—a platform’s strength lies in its broad usage. A platform can’t be customized for each user because the high onboarding friction would break one of the enabling factors for platforms (many in-house platforms fall victim to this trap). At the same time, platforms clearly boost innovation: they reduce friction and give their users many degrees of freedom, as we already saw with automotive platforms.

For cloud platforms, I occasionally remind customers of this counterintuitive quality in somewhat blunt terms:

Still, cloud platforms have been the biggest innovation drivers that IT has seen in the past decade-and-a-half. And, just as with automotive platforms, that’s because they harmonize. The platform’s constraints remove other constraints, like long lead times and heavy up-front investment in hardware.

At first, the paradox of platforms—unifying to boost innovation and diversity—might appear like magic, especially to IT leaders who have collected many battle scars trying to find a balance between these opposing objectives. But the effect of removing constraints by placing others has been known for more than a century. A vivid example is the Baltimore Standard for fire hydrants:¹

Information technology has seen similar effects—without burning anything down. HTTP is a standard: it is quite precise and universally adopted. By being a standardized protocol, it supported diversity between web browsers and web servers: any browser could visit any website, regardless of the respective technologies. It thus gave rise to the perhaps most innovative technology construct we have seen in the past decades, the internet.

Agreeing on interface standards is harmonization that becomes an innovation booster. Imagine a lack of harmonization, where one browser could work only with websites running on a server procured from the same vendor (the early browser wars almost drifted us into that direction). The internet surely would have never evolved the way it did.

HTTP is just one example of the power of interface standards. Common APIs achieve the same. By constraining—for example, by demanding common data formats and authentication mechanisms—diverse components can now interact and are no longer constrained in the choice of programming language or underlying run time.

Common interfaces also accelerate the creation of new solutions and boost innovation by making more functionality instantly available for reuse.

From far away, in-house platforms can resemble classic IT frameworks: all common elements that apply across business units/geographies/product lines are implemented in a base layer, on top of which resides a collection of more specific, but still reusable elements. The cherry on top is that each business unit or geography merely has to configure a few settings, and, voilà, your business application is ready to serve customers without an additional line of code written. Although large software applications like CRM or ERP systems do unify many common processes, this approach looks much better in PowerPoint than in reality. The approach is flawed for two reasons:

1. You’d have to anticipate all users’ needs. This is not only near-impossible, it’d also kill innovation.
2. Even if you could guess correctly, building the all-encompassing base layer requires a massive effort.

Such flawed visions routinely feature in IT strategy documents in the shape of a pyramid, notwithstanding the fact that people stopped building pyramids some 5,000 years ago, partly due to impracticality and partly due to horrible economics:²

So, how are platforms different? Platforms enable users to construct the needed functionality without having anticipated each and every possibility:

This characteristic allows platforms to be leaner and more flexible at the same time. Users build on top of a platform; they don’t just set configuration bits. Because it’s all too easy for platform builders to fall into the trap of wanting to anticipate users’ needs, I offer this simple test:

This observation might be the reason that Kim et al. cite serendipity as an essential element of a successful platform strategy: platforms leave room for users to innovate. So, the tip of a platform isn’t narrow like a pyramid but supports broad innovation, yielding a double pyramid whose shape resembles an hourglass:

The narrow part of the hourglass (the neck or waist, depending on your preferred anatomical analogy) depicts the harmonization that platforms rely on: a wide diversity of base technologies or choices is simplified behind a much narrower interface. That interface in turn supports broad innovation on top.

Technology platforms hide complexity, such as networking, security, data center facilities, hardware provisioning, workload placement, failovers, and much more behind a simple interface, which in turn enables a variety of use cases. Automotive platforms demonstrate this effect by boosting innovation inside the chassis layer (thanks to better economies of scale) and in the top layer (thanks to better economies of speed). The failed concept of badge engineering occurred exactly when things slipped back into a pyramid-shape.

Earlier chapters described both multi-sided marketplace platforms and technology platforms. Although they share common characteristics like low onboarding friction and democratization, they address different user groups and play at different levels of the organization. A multi-sided market is a business model that connects buyers and sellers (for e-commerce platforms), content creators and viewers (for social-media platforms), or drivers and riders (for ride-sharing platforms). Meanwhile, technology platforms harmonize and simplify a technology stack to boost developer productivity and application diversity. A technology platform can be an in-house developer platform, which shields development teams from the complexity of cloud run-time platforms. It can also be a mobile phone platform like Android or Apple’s iPhone ecosystem, which (mostly) shields application developers from the diversity of mobile devices and network communications.

Many successful digital businesses harvest the benefits of marketplace platforms and technology platforms.

For example, a ride-sharing company is a classic marketplace platform that connects riders with drivers. It’s built on a mobile technology platform that shields the application from different mobile providers and networks around the globe. Internally, it uses a developer platform that boosts productivity by reducing the cloud base platform’s cognitive load. Each of these platforms exhibits the hourglass shape that expresses diversity (the bulbs) enabled through harmonization (the neck).

No single aspect gives platforms these amazing properties; rather, it’s the interplay of multiple factors:

Componentization

Breaking something complex into standardized and recombinable components speeds up innovation through recomposition. To choose a historical example, standard-sized bricks have massively sped up construction without reducing creative possibilities.

Separating commodity from differentiators

Platforms bake widely used functions into a common layer and make them easily consumable and composable into new solutions. Borrowed from the pyramid approach, finding this dividing line, especially as it keeps shifting, is no easy task. Successful platforms get this right.

Building Economies of Speed on Economies of Scale

Building platforms is a scale business—they thrive on growth and require massive investments. However, platforms hide these scale effects from their customers by allowing frictionless incremental usage. They thus democratize access to resources, which boosts innovation.³

Centralizing decentralization

Platforms are central elements that foster autonomy and independent decision making. They support decentralized organizations while providing a common safety net and necessary guardrails.

Let’s look at how each of these effects contributes to platform magic:

Simon Wardley highlights the linkage between commoditization (something becoming commonly available and undifferentiated) and componentization (the ability to assemble something new from pre-made parts). Platforms achieve their potential by not being monoliths, instead exposing many recombinable elements that can then be commoditized.

Componentization is more than splitting something into parts. Chopping wood isn’t componentization. Instead, the pieces need to have a clear relationship to one another, an aspect that we’ll dive into a bit later.

Componentization generally requires an overarching architecture that defines boundaries and connecting elements. The automotive industry was successful with its platform strategy because cars have a well-understood architecture of individual components. Increasing componentization was the primary mechanism that allowed companies like Volkswagen to progress from the basic hat-platform model to a modular “toolbox” approach.

Product platforms, much like frameworks, look to draw the line between commonly needed components and those that differentiate: whatever can be widely used goes inside the base layer and the rest is built bespoke on top of it. Even though that sounds intuitive enough in principle, in reality, it’s a delicate balancing act. Several factors make drawing that line difficult:

• Needs vary by user group: Some users might welcome items included in the platform, whereas others consider them restrictive. A “soft” platform edge can allow user contributions, but that doesn’t make the problem go away entirely.
• The boundary shifts: IT evolves and so do the needs of platform users. Cloud platforms started out provisioning just virtual machines and storage but today provide higher-level services from serverless compute to data analytics and machine learning.
• Cohesion over precision: Identifying the exact dividing line between commodity and differentiator for each element doesn’t necessarily yield a good platform. Users expect a uniform level of abstraction across platform services.
• Interaction matters: How users access the platform is as important as what’s inside it. Valuable functionality that’s difficult to access won’t make a great platform. Vice versa, oversimplification will restrict usage, falling back into the pyramid model.

Drawing the line between what goes inside the platform and what is left to the application requires constant fine-tuning based on feedback cycles. Perhaps that’s one reason that successful cloud platform providers are relentlessly customer centric.

Platforms thrive on scale. The most successful technology platforms, cloud services platforms, depend on enormous up-front investments, such as large-scale data centers and global fiber networks. The magnitude of these investments limits the market to just a handful of so-called hyperscalers.⁴

Perhaps the biggest innovation of cloud platforms has been to free users from these scale effects: they have instant access to resources and only pay for what they use. Those are the perfect properties to operate in economies of speed because they encourage experimentation and innovation.⁵ By hiding the economies of scale, the cloud has democratized IT: whereas in the past, only large enterprises had access to fancy data centers and mainframes, today any start-up business, no matter how small, can use the same powerful technologies. The real magic trick of cloud platforms is as follows:

IT is frequently depicted as a “stack” of layers, ranging from an application to the middleware (like application servers or databases), operating systems, processor architectures, networks, and ultimately down to power supplies and physical server racks. Because items on top depend on the items lower down, lower layers generally have slower rates of change.

The prevalent processor architectures in use today (Intel x86 and ARM) date from 1978 and 1985, respectively, making it all but certain that they’ll reach a popular lifetime of more than half a century. The Windows operating system is leading a happy adult life at 35 years and Linux is turning 30 this year. And it turns out that the 19-inch rack, the standard size for mounting computer hardware in data centers, dates back to 1922 (look it up on Wikipedia). Higher up, things move faster: developers now code mobile apps in Kotlin, whose 1.0 release dates back a mere five years, and deploy those apps on the latest Kubernetes release from a few months ago.

Platforms are critical layers in this stack: they evolve comparatively slowly but enable high rates of change “above”. They are like a transmission for the rate of change. Operating systems are a great example, and that’s why they deserve the “platform” label.

ThoughtWorks’ Peter Gillard-Moss defines platforms as follows:

Peter’s wording aptly describes the platform paradox: we relinquish some control but do so in a centralized manner. This important nuance also explains why many so-called platform initiatives started by traditional infrastructure teams fail: they aren’t looking to relinquish control but aim to strengthen it:

Traditional IT organizations link operational control with end-user control. A database administrator who assures the operational aspects of a database also exerts control over its use: developers need to file a ticket to change the schema. Although it’s understandable that a person accountable for service uptime wants to restrict changes, the result is excessive friction. The typical alternative has each team managing its own database, ignoring central expertise and governance. Teams were forced to select either economies of speed or economies of scale.

Platforms provide the best of both worlds: they provide central control and governance while decentralizing usage and innovation to the platform users. Again, we converted an issue into two independent dimensions.

Platform characteristics such as high levels of automation and a shared responsibility model make this apparent oxymoron work.

Relinquishing control is often perceived as a compliance risk. Experience shows, though, that carefully relinquishing control actually increases compliance. Rigid and cumbersome IT infrastructure tempts teams to go rogue to make progress. An low-friction platform invites compliance, and openness allows users to use parts of the common layer even if it can’t meet all their needs. They have gentle slopes.

Allow me to conclude a metaphor from The Software Architect Elevator. A4 paper is one of the most widely used standards in the world, but hardly anyone could claim that it stifles their creativity.