Why collapsing platform silos and forcing them to earn adoption is the only way to achieve speed, efficiency, and customer focus.
Large, software heavy companies are under constant pressure: customers expect seamless digital experiences, new channels, and rapid innovation. To cope, many companies try to “go agile.” The playbook often includes setting up platform groups to reduce duplication and support product teams.
But here’s the trap: these groups are usually split into “technical platforms” (infrastructure, CI/CD) and “business platforms” (catalogs, payments, customer accounts). At first glance, this looks smart. In practice, it creates silos, dependencies, and frustration.
A better path is to consolidate all non-differentiating functionality into a single commodity platform group. Governed by Russell Ackoff’s Internal Market Economies (IME) principle, this model creates clarity, independence, and speed at scale.
Picture a global retailer with a booming e-commerce arm. Leadership decides to get serious about agility and sets up two flavors of platform groups: one to build CI/CD pipelines, run cloud hosting, and manage monitoring tools; another to handle shared services like product catalog, customer accounts, and order tracking. On paper, this should free up product teams to focus on customer-facing apps and websites. But reality is messier.
The technical platform group proudly rolls out a new CI/CD pipeline. Teams running the webshop and mobile app rush to adopt it, only to discover it doesn’t support their integration testing setup. They file requests for improvements. Weeks turn into months. Some teams grow impatient and script their own release workarounds, fragmenting the very consistency the platform was supposed to create.
Meanwhile, the business platform group is redesigning the “customer account” module. Product teams are told they must use it. But the rollout slips, and when it finally arrives, it enforces flows that don’t fit the mobile checkout process. Suddenly, teams can’t release new features without adapting to the platform changes. Worse, when the account module updates again, all consuming teams are forced into simultaneous updates, wasting cycles on unplanned rework.
At this point, the cracks are obvious. Two platform groups with separate roadmaps and governance structures create duplication and siloing. Reciprocal dependencies arise, where the platform groups need requirements from product teams while product teams need working services from the platforms, so neither can move without endless coordination. “Fake platforms” sneak in, like a catalog service that only works for the webshop but not for the mobile app or marketplace, burning budget without creating scale. And autonomy disappears: product teams are dragged into lockstep with every platform release instead of focusing on shoppers.
What was meant to accelerate delivery now slows it down. Engineers are frustrated, customers wait longer, and leadership wonders why agility never materializes. This isn’t rare: a survey of platform engineering leaders suggests ~67% of platform initiatives struggle to scale or deliver against expectations. In industries like IIoT and incumbent digital platforms, studies show many investments don’t yield the returns hoped for.
The antidote is straightforward: instead of fragmenting into technical and business platforms, create a single, larger commodity platform group responsible for all non-differentiating functionality.
For our retailer, this means CI/CD pipelines, hosting, observability, monitoring, and API gateways on the technical side, combined with authentication, authorization, notifications, customer profile stores, and generic payment rails on the business side.
The rule is simple: if multiple product teams need it and it doesn’t set you apart in the market, it belongs in the commodity platform. Everything else lives with the product groups. This model avoids duplication, clarifies ownership, and makes it obvious what belongs where.
The best way to picture this is through Apple’s iOS ecosystem. Apple continuously evolves iOS: new APIs, improved performance, additional features. But app developers are never forced to update in lockstep.
A fitness app can adopt the latest Health API in iOS 18, but if it doesn’t, the app still works fine on iOS 17. The platform evolves on its own schedule. Apps evolve on theirs. The contract between them is stable.
Meanwhile, iOS takes care of all the commodity services: push notifications, biometric authentication, secure storage, networking, camera APIs. No app developer wants to reinvent those. They just use them when it makes sense.
This is how a commodity platform should operate inside the retailer: the platform group evolves authentication, CI/CD, or customer profiles at its own pace. Product groups (e.g. the webshop, the mobile app, the marketplace) choose if and when to adopt new features. Stable contracts prevent lockstep dependencies. Everyone benefits from consistency and scale, without being chained together.
Russell Ackoff’s Internal Market Economies (IME) makes this model stronger. Under IME, the commodity platform group is not a monopolistic utility that dictates what everyone must use. It operates like an internal business in a market.
That means the platform group can only demand a market-conform subscription fee. If its price is out of line with external providers or in-house alternatives, product groups won’t buy. Just as important, product groups have freedom of choice: they can decide whether to consume a service from the commodity platform or source it elsewhere. Adoption isn’t forced; it has to be earned.
Take authentication as an example. The commodity platform might offer login and identity services at €0.01 per active user per month. Product teams compare this to an external identity provider charging €0.009. Because the external option is cheaper, yet the internal option is better integrated with existing data, the product teams choose it. But the choice matters, if the internal platform ever drifts into overpriced or clunky territory, teams can walk away. That freedom keeps the platform lean and user-focused.
This financial discipline means the platform group must stay healthy. It covers its costs through the subscription fees paid by its internal customers. If adoption drops, revenue drops and the platform faces pressure to improve, streamline, or even shut down.
For the wider organization, the effects are powerful. Commodity services are delivered at a fair price, benchmarked against the market, so bloated IT monopolies can’t hide. Budgets flow where they belong: if the webshop consumes half the platform’s services, half the bill lands there. That transparency creates discipline. Platform groups can’t inflate scope or build pet projects; they must deliver what multiple product groups truly need.
And because survival depends on adoption, the platform evolves constantly. Just as AWS cuts prices and adds features to stay attractive, the commodity platform group has to improve its developer experience, lower costs, and enrich its services. This keeps the whole system aligned with strategy: product groups invest their budgets in differentiating features (e.g. smoother checkouts, smarter recommendations, new channels) while the commodity platform focuses on rock-solid, shared foundations like authentication, notifications, and infrastructure.
The result is a self-regulating system. If the platform delivers value, adoption grows, economies of scale kick in, and unit costs fall. If not, product groups walk away and the platform must adapt or disappear. It creates a healthy balance: product groups obsess over customers, while the commodity platform group obsesses over enabling them.
Large software players don’t need a zoo of technical and business platforms. They need a single commodity platform group: self-service, non-differentiating, used across product groups.
When run under Internal Market Economies, this group earns adoption instead of mandating it, creates financial transparency, and evolves under real demand. Crucially, the platform must stay financially healthy, covering its costs through internal subscription fees. This ensures adoption is not just a vanity metric, but the lifeline that keeps the platform lean, user-focused, and accountable.
The logic is the same as iOS: a stable, evolving foundation; apps (product groups) adopting new features when it fits their goals; and a clean separation between commodity and differentiation.
Product Groups
Commodity Platform Group
Finance & Leadership
Customers
The payoff is real: financial clarity, economies of scale, autonomy and speed for product teams, and stronger focus on the end customer. Anything else is just another central IT empire with slicker branding.
Jurgen De Smet is a Certified LeSS Trainer and organizational simplification expert who writes about cutting through complexity to deliver real value. If this article challenged your thinking about platforms and organizational design, explore more of his insights on Your Simplification Officer where he regularly shares practical strategies for achieving speed, autonomy, and customer focus at scale.
RSS feed