Technical Platforms Are Not Enough: The Crucial Role of Business Domain-Centric Platforms
Platform Engineering continues to gain significant attention in the technology industry. The core promise remains attractive: optimize the developer experience (DevEx) and accelerate value delivery through self-service capabilities and automated infrastructure operations.
Current Internal Developer Platforms (IDPs) often concentrate on essential technical domains: provisioning of CI/CD pipelines, abstracting infrastructure like Kubernetes, providing developer portals, standardizing observability, and embedding security. These efforts offer well-known benefits such as improving deployment frequency and reducing technical tasks for development teams.
However, it's worth asking: Are technically driven platforms the full extent of platform value?
While optimizing technical delivery is important, are we potentially missing an opportunity to use platforms to directly enable the business itself?
My observations and analysis suggest that the next step in Platform Engineering involves moving beyond purely technical foundations. It means that we as a community should move our focus with regards to platforms towards business domain-centric platforms which offer business domain capabilities as self-service products.
Platforms Through the Lens of Team Topologies & Core Principles
To understand this evolution, it's helpful to refer to established principles, particularly those from Team Topologies by Matthew Skelton and Manuel Pais. Team Topologies offers a model for organizing teams to achieve a fast flow of value.
Within Team Topologies, the Platform Team is “a grouping of other team types that provide a compelling internal product to accelerate delivery by Stream-aligned teams” (Source: Team Topologies Website). Stream-aligned Teams focus on delivering value within a specific business domain. Platform Teams support the Stream-aligned Teams by providing internal services, tools, and APIs that other teams consume, reducing their cognitive load. The platform acts as a foundation, allowing stream-aligned teams to build, run, and iterate on their applications with more autonomy and speed.
The key is that the platform provides a curated experience, offering services that reduce the cognitive load for stream-aligned teams.
Regardless of scale, successful platforms share key attributes:
Self-Service: This is essential. Users (primarily developers in stream-aligned teams) must be able to discover, request, and consume platform capabilities autonomously, often automatically, with minimal friction or manual intervention.
Developer Experience (DevEx): A core objective is to improve the experience for developers. The platform should offer intuitive interfaces (GUIs, APIs, CLIs), clear documentation, helpful abstractions, and quick feedback loops.
Platform as a Product: Platforms should be managed as internal products with developers as customers. This requires dedicated product management, user research, a clear roadmap, and feedback loops for improvement. Evan Bottcher writes this: "a foundation of self-service APIs, tools, services, knowledge and support which are arranged as a compelling internal product".
The Status Quo: Platforms as Technical Accelerators
Observing the current landscape, the predominant focus of many IDPs revolves around accelerating the technical aspects of software delivery. Common offerings include:
CI/CD Pipelines & Tooling: Providing standardized, automated ways to build, test, and deploy applications.
Infrastructure Provisioning & Abstraction: Offering self-service access to compute, storage, and networking resources, often abstracting Kubernetes complexity or providing reusable Infrastructure as Code (IaC) modules.
Developer Portals: Centralized interfaces (often inspired by Backstage) for service discovery, documentation, template creation, and operational visibility.
Observability Stacks: Providing integrated solutions for monitoring, logging, and tracing to understand application and system behavior.
Security Tooling & Guardrails: Integrating security scanning, policy enforcement, and secrets management into the development lifecycle.
"Golden Paths": Pre-defined, supported technology stacks and workflows designed to streamline common development scenarios.
However, we must ask: Is optimizing the how (deployment, infrastructure) the most impactful use of the platform model? Does it sufficiently address the what – the core business logic and capabilities?
The current emphasis largely centers on reducing the cognitive load associated with technical complexity – understanding Kubernetes, managing CI/CD, or setting up monitoring. While necessary, this focus might overlook another source of cognitive load for stream-aligned teams: the complexity of the business domain itself. Developers often deal with complex business rules, legacy system integration, cross-functional dependencies, and complex processes. A platform solely focused on technical aspects leaves this burden largely unaddressed, potentially limiting the agility promised by Platform Engineering and Team Topologies. Reducing cognitive load is key, and this principle should be applied more broadly than just to technology.
Business Domain-Centric Platforms
This leads to the concept of Business Domain-Centric Platforms. These platforms aim to encapsulate, abstract, and offer business capabilities as well-defined, self-service products (typically APIs or services). Their goal is to accelerate the delivery of specific business outcomes by standardizing business logic or processes.
Instead of each stream-aligned team needing deep expertise in non-differentiating areas like pricing calculations or regulatory checks, the platform team builds and maintains this capability as a reliable service for multiple stream-aligned teams to consume.
Several architectural patterns support the creation of business domain-centric platforms:
Composable Architecture: Business domain-centric platforms are key to building composable enterprises. They provide well-defined, independently deployable, and reusable business components (e.g., Customer Profile, Payment Processing, Scoring, Real Estate Rating) that can be assembled into new applications or value streams with less effort, supporting decoupled, adaptable systems.
Business Process Automation (BPA): Complex business processes often span multiple teams. A business domain-centric platform can automate key steps (e.g., identity verification, tax calculation) or orchestrate entire reusable workflows, ensuring consistency and efficiency.
Cross-Domain Collaboration & Consistency: When business capabilities are exposed via a shared platform, it promotes consistency and facilitates collaboration across different business units or teams consuming these services.
This represents a shift in thinking. Technical platforms primarily function for the business – enabling it indirectly by making development teams more efficient. A business domain-centric platform is a codified, reusable part of the business logic. It moves the platform concept closer to the business side. This requires platform teams to have both technical skill and a deep understanding of the business domain. It aligns with Gregor Hohpe's concept of platforms enabling innovation through harmonization – standardizing core functions to free up capacity for differentiation.
Technical Platforms compared to Business Domain-Centric Platforms
Business Domain-Centric Platforms: Examples & Comparison
Consider these examples of potential business domain platforms:
Customer Identity & Permissions Platform: Extends basic authentication to provide APIs for managing customer profiles, registration, account recovery, consent, roles, and permissions consistently across applications.
Dynamic Pricing Engine Platform: Offers an API for calculating prices based on complex rules involving customer segments, inventory, promotions, competitor pricing, and location, abstracting this from e-commerce frontends or billing systems.
Product Configuration & Catalog Platform: Provides services to manage product information, variations, attributes, bundling rules, and compatibility, ensuring consistency across sales tools, online stores, and manufacturing.
Risk Assessment Platform: Exposes APIs for standardized risk calculations (e.g., credit scoring, fraud detection, compliance checks) consumable by various systems.
Content Management & Delivery Platform: Offers capabilities for managing and delivering structured content (articles, product descriptions) across websites, apps, and knowledge bases.
These examples show how business domain-centric platforms differ from purely technical ones. Their value is measured not just in technical but in business metrics: consistency of pricing, speed of launching product configurations, unified customer view, or reduced compliance risk.
The following table summarizes the distinctions:
| Feature | Technical Foundation Platform | Business Domain-Centric Platform |
|---|---|---|
| Primary Goal | Optimize Dev Workflow, Infra Efficiency | Accelerate Business Capability Delivery, Ensure Business Logic Consistency |
| Key Services Examples | CI/CD, K8s Abstraction, Observability Tools | Customer API, Pricing Engine, Risk Calculation Service |
| Primary User Benefit | Reduced Technical Toil, Faster Deployment | Reduced Business Logic Complexity, Faster Feature Launch, Consistent Rules |
| Typical Metrics | Lead Time for Changes, Deployment Frequency, MTTR | Business Feature Cycle Time, Logic Reuse Rate, Cross‐Team Consistency |
| Core Team Skills | Deep Infra Knowledge, Automation, Cloud Tech | Domain Expertise, API Design, Business Process Modeling + Strong Tech Skills |
Building business domain-centric platforms requires a different value proposition and skillset. While strong technical foundations are essential, deep domain expertise, API design, and business process modeling become critical. This may necessitate changes in mindset and team composition.
Why Business Domain-Centric Platforms Matter
Investing in business domain-centric platforms is a strategic decision with significant implications. The benefits include:
Enhanced Business Agility: Reusable business capabilities allow faster responses to market changes. New products can be composed quickly by leveraging existing logic, reducing time-to-market for business value.
Improved Value Stream Alignment: Platforms built around business capabilities naturally align with and streamline end-to-end value streams, reducing friction between teams.
Fostering Business Innovation: Handling common business logic (like identity management) frees up stream-aligned teams' cognitive capacity. This allows focus on customer-facing innovation – the "Platform Paradox" where standardization enables creativity.
Consistency and Compliance: Centralizing critical business rules, calculations, and data definitions reduces errors, inconsistencies, and compliance risks.
Breaking Down Silos: Shared platforms encourage collaboration and break down organizational silos by creating shared dependencies managed as products.
Shifting focus towards business domain-centric platforms elevates Platform Engineering from an IT efficiency driver to a core enabler of business strategy. It transforms the platform from a cost center into a strategic asset for value creation.
Identifying Candidates for Business Domain-Centric Platforms
Embarking on the journey of creating business domain platforms requires careful consideration and a strategic approach. The biggest challenge I see in this area is the danger of falling back into the undisciplined “bend everything towards reusability with force” frenzy of the dreaded Service Oriented Architecture (SOA) days. We want to establish business domain-centric platforms in order to reduce cognitive load and especially to improve the flow of all teams involved. In other words: we want business agility.
Agility requires a high degree of self-discipline by all parties involved.
Therefore a rigorous decision making process with a strict discipline in minding the overall strategic direction of the company and the product(s) involved with regards to business differentiation and value propositions is key.
The first step is to identify which business capabilities are suitable candidates for platformization. This involves understanding the strategic landscape of your business domains. Techniques like Domain-Driven Design (DDD) are invaluable here. DDD encourages classifying subdomains into categories:
Core Domains: These represent the unique, differentiating capabilities that provide a competitive advantage. These are often complex and require significant investment but are no candidates for a shared platform due to their strategic sensitivity and rapid evolution.
Supporting Domains: These are necessary for the business to function but don't provide a direct competitive edge. They often support core domains.
Generic Domains: These are capabilities that are not specific to the business and can often be solved with off-the-shelf solutions (e.g., travel expense claims at consulting companies).
A great way to classify your domains into core, supporting and generic are Core Domain Charts which were invented by Nick Tune and are now hosted under a Creative Commons License at the DDD-Crew on GitHub.
Core Domain Charts
Business domain-centric platforms are often suitable in supporting or generic domains where standardization across multiple stream-aligned teams can offer significant benefits. The goal is to abstract away complexity that multiple teams grapple with, freeing them to focus on core, differentiating work.
In the visualization below are some rough heuristics for strategies in terms of busines domain-centric platforms based on Core Domain Charts. The strategies are as follows:
SaaS Platform: Usage of a Software As A Service solution with no customizing except for integration. The platform in this case is mostly a wrapper for internal integration towards identity providers and other company internal standards.
CotS Platform: Usage of a Custom of the Shelf solution like SAP with moderate customization. In this case you use the CotS-Software as the backbone on which you provide modifications for your own business processes.
Self-implemented Platform: You implement the whole business domain-centric platform on your own.
Strategies for business domain-centric platforms based on Core Domain Charts
Strategic mapping tools like Wardley Maps invented by Simon Wardley can further refine this identification process by visualizing the value chain and the evolutionary stage of its components (Genesis -> Custom Built -> Product/Rental -> Commodity/Utility). When applying Wardley Mapping to identify business domain-centric platform candidates:
Look for components that are less visible to the end customer but essential for delivering value. These are often supporting or generic capabilities.
Consider the evolutionary stage:
Capabilities sitting on the boundary between Custom Built and Product are often excellent candidates for internally developed business domain platforms. They are becoming standardized within the organization but aren't yet fully commoditized externally. Building an internal platform here allows you to codify best practices and accelerate multiple teams.
Capabilities firmly in the Product/Rental stage might be suitable for an internal platform acting as a wrapper or abstraction layer around Commercial Off-The-Shelf (COTS) solutions (like SAP). The platform provides a consistent internal API and self-service experience, hiding the complexity of the underlying vendor product.
Capabilities that have reached the Commodity/Utility stage are typically best addressed by consuming external SaaS solutions directly, potentially via a thin integration layer provided by a technical platform, rather than building a dedicated business domain platform around them.
Platforming strategies for business domain-centric platforms based on Wardley Mapping
A great resource that perfectly connects the dots between Team Topologies, Domain Driven Design and Wardley Mapping is the work by Susanne Kaiser around Architecture For Flow.
Similarly, the Cynefin framework can help assess the complexity and nature of different domains (obvious, complicated, complex, chaotic) to determine where standardized platform approaches are most applicable (typically in the complicated domain, where expertise can be encapsulated and offered as a service).
Thinnest Viable Platform (TVP) and Strategic Discipline as Key Success Factors for Avoiding the next SOA-Fallacy
Once potential candidates are identified, resist the urge to build a comprehensive, all-encompassing platform from day one. Instead, adopt the Thinnest Viable Platform (TVP) approach, a concept highlighted in Team Topologies thinking.
The TVP is the smallest possible platform that can deliver meaningful value and accelerate the work of stream-aligned teams. Start by focusing on a single, high-impact business capability identified in the previous step. Build the minimum set of services, APIs, documentation, and support needed for a stream-aligned team to successfully consume that capability via self-service.
The key principles of TVP include:
Start Small: Focus on solving one specific, high-priority problem for developer teams first.
Prioritize Value: Ensure the initial platform offering delivers tangible benefits quickly.
Iterate Based on Feedback: Treat the platform as a product. Gather feedback from early adopters (the stream-aligned teams) and iterate, gradually expanding the platform's capabilities based on demonstrated needs and value.
Avoid Over-Engineering: Build only what is necessary to meet the immediate needs, preventing the platform from becoming bloated or overly complex before its value is proven.
By identifying strategic candidates through approaches like Wardley Mapping, Cynefin or DDD and starting with a TVP, organizations can begin building business domain-centric platforms in a focused and iterative manner, reducing risk and ensuring alignment with both developer needs and business goals.
Mind the sentence I highlighted in the previous subchapter above: Agility requires a high degree of self-discipline by all parties involved.
The biggest challenge in building and evolving a business domain-centric platform is to say no.
Back in the Service Oriented Architecture days I observed many teams and even organizations that said “yes” to everything that came up. We ended up in “highly reusable” services which only were reusable from a very superficial black box perspective. By looking deeper into those services we often identify a high degree of coupling and tangling because the “consumers of a service” metric was a predominant factor. How cohesive was their offering? How specific were certain features and datasets in that service? The answers are disappointing and the reason is: nobody ever dared to say no.
The team(s) involved in building the platform have to follow a clear and concise product strategy. They should not implement and provide each feature request thrown at them by other teams or stakeholders. Instead they have to weigh in on the strategic relevance of feature requests for their platform. These teams should and will say “no we won’t solve this on the platform” a lot of times. Downstream teams or management will often challenge these assertions, which is legitimate. Maybe the Platform Team was not aware of certain circumstances but there is a fine line here: Forcing features into the platform from the outside will ruin your platform mid- to longterm, frustrate the Platform Team and worse: drive down flow due to higher coupling on an organizational or even technical level. Management should empower the teams responsible for business domain-centric platforms to say no. This applies to teams responsible for internal developer platforms as well. But I think that the danger of driving down flow is substantially higher in the area of business domain-centric platforms.
Implementing business domain-centric platforms requires a deep and holistic understanding of governance and ownership dynamics. Domain-Driven Design Context Maps are very helpful here for visualizing the relationships between teams and systems. Specifically, focusing on patterns like Upstream/Downstream, Open Host Service, Partnership, and especially Customer/Supplier relationships can help to visualize and understand governance dynamics between teams. Team Topologies' interaction modes help aligning with these identified relationships. A 'X-as-a-Service' mode might be perfect for a clear Customer/Supplier dynamic, while a 'Partnership' mode might be necessary for more collaborative and evolving relationships. These visual tools and interaction models help define clear lines of responsibility, reduce ambiguity, and ensure that the platform evolves in alignment with the needs of its consumers. By explicitly visualizing these governance dynamics, organizations can proactively address potential conflicts, streamline decision-making, and create a more effective and sustainable platform ecosystem.
Future Vectors: AI, MCP, and Business Integration
Emerging trends further highlight the importance of business domain-centric platforms:
Role of AI/ML: AI/ML models often represent complex business logic (e.g., recommendations, fraud detection). Encapsulating these within a business domain-centric platform (e.g., a "Recommendation Service") makes them reusable and manageable. AI can also potentially optimize the platform itself or consume other business domain platforms.
Model Context Protocol (MCP): As AI agents become more prevalent, their ability to interact effectively with diverse systems and data sources is crucial. The Model Context Protocol (MCP) is an emerging open standard designed to facilitate this interaction. MCP provides a standardized way for AI applications (clients) to connect with and consume context (data, tools, APIs) from various sources (servers). Business domain-centric platforms, exposing their capabilities via well-defined APIs, could act as MCP servers. This would allow AI agents, using MCP, to seamlessly leverage core business logic (like checking customer permissions via a Customer API or calculating risk via a Risk Assessment API) in a standardized, secure, and scalable way. This integration makes business capabilities readily available for sophisticated AI-driven automation and decision-making, enhancing the value proposition of both the AI agent and the business domain platform.
AI and MCP enhance the value of business domain platforms by making complex logic reusable and accessible to intelligent agents.
The future points towards tighter integration between Platform Engineering and business strategy. To succeed, platform teams need to become more business driven, working closely with business stakeholders who recognise the strategic potential of the platform beyond infrastructure. This requires a "Sociotechnical" perspective, understanding the interplay between organization, teams, and technology.
Conclusion: Charting the Course for Platform Evolution
Platform Engineering has improved developer productivity and technical operations. However, the journey continues. Evolving from purely technical platforms towards those encapsulating business capabilities represents the next stage of value creation. By embracing business domain-centric platforms, organizations can achieve greater agility, foster innovation, and align technology investments with strategic outcomes.
This shift requires re-evaluating current platform strategies. Organizations should consider: Are our platforms addressing technical friction or inherent business domain complexity? Where does the most significant cognitive load lie for our stream-aligned teams?
The path forward involves treating platforms as strategic business products. It requires teams with both technical and domain expertise, guided by a vision of enabling business value.
I can help
I offer consulting services for organizations seeking guidance on:
assessing their platform strategy
exploring candidates for business domain-centric platforms
establishing business domain-centric platforms with a TVP approach
identifying blockers in the flow of their teams
Don’t hesitate to contact me or to schedule a call with me.
