Designing Platform-Centric Organizations with Domain Thinking and Team Topologies

Blog

1 Jul

Now that we have a solid understanding of applying Team Topologies (TT) concepts to platform engineering and how this concept applies to stream-aligned teams within an organization, many of us have been considering the innovative potential of using these concepts across a wide range of domains. Suppose you are unfamiliar with the basic foundational concepts of Team Topologies. In that case, we recommend you check out the key concepts section of the Team Topologies site to familiarize yourself with it. The 9/6 model of Team Topologies remains as expansive and accurate as ever, regardless of the type of organization I have encountered.

In this blog, I will share my experience combining principles of Team Topologies and domain-driven platform engineering to create a more scalable, adaptive, and developer-centric platform organization by enabling clear team boundaries. This will create a more optimized cognitive load and dynamic evolution aligned with business domains. The term domain-driven platform engineering (DDPE) is likely new to the reader. Please check out some basic ideas and the need for DDPE in this article.

Why Structure Matters in Platform Engineering?

The rise of internal developer platforms with solid orchestrators (Humanitec, Mia-Platform, Kratix) has shifted the narrative from traditional infrastructure-centric approaches to productized services. Developers, having experienced the success of reduced cognitive load and the ability to be autonomous in building and delivering their products for Non-Functional Requirements (NFRs), are increasingly looking to map these learnings to the domain-centric aspects of their development. The past year has been increasingly "distracting" for an average developer, with the idea of agentic self-evolution attempting to trump the self-service. This has only exacerbated the problems for them as the decision-makers in the organizations are asking why the promised acceleration hasn't reached them fast enough.

In addition, most organizations fail to scale platform efforts due to ambiguous team boundaries, overburdened platform teams, and a disjointed developer experience. One of the FAANG companies I've interacted with still employs a federated platform engineering approach, where a specific domain team's ability to push the boundaries of its capabilities is severely curtailed by the need to collaborate with the mother ship. While adopting a platform model, a major Canadian insurance company found significant benefits for its greenfield operations but fell short in its brownfield initiatives. These challenges are often attributed to the 'I-told-you-so' crowd, who continue to claim that platform engineering is just the next fad that will die down. I attribute this to their lack of familiarity with the concepts of Team Topologies and the Platform-as-a-Product mindset, which form the backbone of this movement. In this context, aligning platform engineering structures with TT and DDD principles provides a sustainable and business-aligned approach to building and evolving platforms.

Before we proceed, a high-level view of how domain-driven platform engineering looks is prudent.

Figure 1: High-Level View of the Abstraction and Domain Dichotomy

Figure 1 illustrates a stacked service taxonomy across four major layers in your overall notional enterprise architecture, each defined by its degree of abstraction and domain centricity, which are the key attributes in domain-driven platform engineering. The vertical axis, ranging from bottom to top, represents an increase in domain specificity and a decrease in abstraction. At the same time, the horizontal axis also reflects this shift, creating a two-dimensional space to position platform capabilities and services appropriately. Let us refer to this shift in abstraction as the concept of “abstraction shift”.

To go further, the bottom layer consists of Foundational Services, which will exhibit High Abstraction and Low Domain Centrality, as these are standard services that can be used across various business domains. These are horizontal enablers common across all domains, forming the core of a platform team’s responsibilities. Some examples of the foundational services would be:

Core Platform Services (e.g., CI/CD, Service Mesh, Infra-as-Code)
Cross-Functional Services (e.g., Identity, Observability, Feature Flags)
Compliance, Experience (e.g., Authentication UX, Guardrails)

These services are intentionally domain-agnostic, focusing on reusability, scalability, and standardization, which enables Golden Paths across multiple domains.

Next up is what I call Common Enterprise Services, which are shared enterprise-wide services that are not domain-specific but serve business-wide workflows. Note that domain-centricity increases and abstraction reduces beyond the foundational services. Some examples of these are

Customer Relationship Management Systems (CRM)
Supply Chain Management Systems (SCM)
Quality Management Systems (QMS)
Warehouse Management Systems (WMS)
Inventory Management Systems (IMS)

I would also add domain-centric contextual analytics systems in this layer. Platform teams may offer platform plugins or adapters that make these services more composable and observable across environments. These form the integration substrate for cross-domain functionality.

Third from the top is the Domain Backbone Services, which are the services that anchor domain-specific workflows and are used repeatedly across multiple business lines within the same domain. You can see how the abstraction shifts across each layer in a nuanced manner, providing a better way to tie it to organizational constructs within the context of team topologies. Yet again, examples of these include manufacturing, asset performance management, payment processing, health information exchange, and similar systems, which can still be standardized across various industries and not be specific to an automobile, banking, or healthcare industry.

Manufacturing Execution Systems
Asset Performance Management
Payment Processing
Health Information Exchange

These services become candidates for domain-specific abstractions, offered as self-service capabilities or APIs within an Internal Developer Platform (IDP) for that domain, as we see in the catalogs provided by platforms like Mia-Platform. This is where platform engineering overlaps with domain architecture, necessitating a deep understanding, collaboration, and the development of customized interfaces.

The last set of services at the top are the true Unique Domain Services with the lowest level of abstraction and the highest domain centricity. Think of these as the custom application development organizations have to do a lot with an organization’s differentiators, driven by the inherent and historical ontologies.

These are bespoke capabilities that differentiated product teams develop with high ownership. These services typically remain outside the purview of the central platform team but are enabled or accelerated by reusable components provided by the foundational and backbone layers. While it is easier to conceptualize the types of services offered, the following examples help clarify this concept.

Trade & Settlement Workflow Orchestrator, which handles domain-specific flows for clearing, settlement, and confirmations in the financial services industry.
Genomic Data Inference API that provides access to domain-specific ML inference models for personalized medicine in the life sciences industry
Omnichannel Order Orchestrator that manages the order lifecycle across multiple touchpoints (web, app, store) in any kind of consumer industry
Usage Rating & Billing Microservice that calculates real-time usage charges based on telecom plans.

I will provide an expanded view of this illustration later in the article, along with additional team topologies and context.

Applying the DDPE Lens to the Four Fundamental Team Types in Platform Context

This section will examine the four fundamental topologies and how overlaying a domain-centric approach would enhance our discussion.

Stream-Aligned Teams

These teams are most closely aligned to a business domain or value stream. However, by definition, a domain spans multiple stream-aligned teams and a lesser number of complicated teams. These teams consume platform capabilities via self-service APIs, golden paths, and paved roads. Applying the DDPE lens, you will find that a stream-aligned team maps to a business subdomain and interacts with the platform via domain-specific capabilities.

Platform Teams

These teams provide reusable services and paved paths to streamline delivery for stream-aligned teams. They typically own the platform building blocks, such as CI/CD pipelines, observability, Identity and Access Management (IaM), Compliance, and often Infrastructure as Code (IaC) and Runtime platform capabilities. In the DDPE world, you need additional capabilities to be segmented and offered per domain context, not just monoliths. An approach like that leads to the extension of the TT model. You might ask why the platform teams or complicated subsystems would not provide these and why you need a separate construct to achieve this. The answer is pretty simple. In my experience, the skill sets required for the domain abstraction we discuss here do not lend themselves well to the above team constructs.

Enabling Teams

These teams within your organization help stream-aligned teams adopt new platform capabilities or improve their practices (some might know them as your neighborhood Centers of Excellence (COEs)). While they might often be short-lived and could take an advisory role, it does not necessarily have to be so. The enabling teams have a significantly interesting role when applying the DDPE lens. Instead of being the bridge between generic platform tooling and stream-aligned teams, their role expands to address domain-specific adoption pain points.

Complicated subsystem teams

While these teams handle areas requiring deep specialist knowledge that may be difficult to hire and retain in large quantities, in the DDPE world, they can build specialized subsystems used across multiple domains and platforms. My interpretation of the Complicated subsystem teams has always been that the capabilities these teams provide are specialized.

Cognitive Load as a Design Principle

As you can see in our example, the domain expertise required for implementing the abstracted-out capabilities neither falls within the platform team nor the complex subsystem teams. Today, it falls under custom development within the stream-aligned teams, which is gradually integrated into third-party platforms through platform APIs that connect with external products built by the SA teams. However, the accepted premise is that overloaded teams are typically a symptom of poorly defined platform responsibilities, abstractions, or both. So, if the cognitive load is a constraint, it becomes a design principle. Interpreting it as a design principle can lead to two simple decision points:

Don't make platforms too generic.
Design each capability around the domain needs and the maturity of the teams.

Applying this in the context of DDPE, you will find that a platform team supporting retail checkout and fraud detection requires different support models, as the skills required and domain complexities differ. Now, why should this be abstracted out? We need it abstracted because checkout or fraud detection shouldn't be duplicated for a product organization. For a services organization, where they can claim they don't care at some level, building accelerators around these platform capabilities is usually the difference between success through repeatability and the failure of creating umpteen different implementations of checkout features. But we don't do it. A standard platform, such as Shopify, typically provides a customizable checkout experience for online stores. It uses APIs to enable the product teams to personalize and integrate the process with their services. However, the cognitive load lies in the breadth of various platforms, such as Shopify, that one would use within the ecosystem.

Applying DDPE to the 9 Core Principles and 6 Team Patterns

As we apply the DDPE to the nine core principles of Team Topologies and the six team patterns, let's explore the overall shift in abstractions you need

Figure 2: Movement from highly abstract, generic platform services to domain-specific, business-aligned services

Figure 2 shows the expanded view of what was explained above. This layered model aligns with the Domain-Driven Platform Engineering (DDPE) approach by allowing platform teams to scale enablement without enforcing one-size-fits-all abstractions. It also encourages platform-as-product thinking, where domain context determines which layer of services the platform must invest in.

More specifically, in this context, this model supports Team Topologies-inspired collaboration, especially between platform, enabling teams, and stream-aligned teams. This is made easier by identifying where platform product boundaries should be drawn (e.g., foundational vs. domain-layer responsibilities).

This figure serves as a blueprint for platform capability mapping across domains, helping engineering leaders:

Prioritize platform investments based on domain maturity.
Drive faster developer onboarding via domain-specific Golden Paths.
Enable value-stream aligned service delivery, reducing cognitive load while supporting differentiated innovation at the top layer.

Nine Principles

Focus on Flow, Not Structure It is recommended that organization should be around domain value streams (Retail, BFSI, HCLS) to reduce silos between platform layers and domain-aligned services. This way, optimizing flow from idea to running service in a specific domain becomes more of a reality.
High Trust Is Non-Negotiable: You must trust domain-aligned teams to choose tools and platform capabilities that fit their needs. Often, the challenge comes from over-governance in platform use. We used the example of Shopify above, but we provided the teams with the ideal.
Keep Teams Together: One challenge I have observed is that, in the organization’s desire to increase efficiency, the constant rotation of resources creates inherent instability. Stabilizing domain platform teams (e.g., the HCLS platform team) instead of constantly rotating engineers across backend, infrastructure, and DevEx creates more confusion than losing valuable historical knowledge to build capabilities more effectively.
Respect Cognitive Limits: Respect cognitive limits by modularizing domain capabilities as much as possible. Use DevEx metrics to measure effectiveness and make strong decisions to resist the urge to throw more domain capabilities to the stream-aligned team. Look for where the abstraction can be shifted and create additional domain-platform teams. Letting a single team own a whole domain is asking for trouble. Identify the ideal boundaries through effectiveness metrics and customer-visible issues to create more cohesive and self-contained teams.
Make Changes Small and Safe: Designing DDPE platforms with thin slices and versioned service interfaces will enable a safe rollout of new domain features and platform capabilities, where design and Razer-focused interface testing minimize the number of changes.
Connect Teams Directly to Customers: Stream-aligned domain teams (Retail, BFSI) must regularly engage business and end-users to shape platform accelerators and domain logic. There is nothing new here, but if the scope of these domain teams exceeds what you would want, customer interaction becomes a chore and does not achieve what you intended in the first place.
Embrace Complexity, Don’t Fight It: Build layered platform ecosystems, as shown in Figure 2, that absorb complexity in integration, compliance, and orchestration layers, rather than pretending to a one-size-fits-all approach. If you need to add more platform ecosystems, do so without fear that it might be challenging.
Foster Continuous Discovery: Enable discovery pipelines in domains (e.g., A/B experimentation in Retail, analytics sandboxes in HCLS) backed by platform self-service and DevEx tooling. Continuous delivery can happen for each sub-component (Boxes inside the boxes) of Figure 2. This is a surefire way to achieve faster convergence and integration, rather than creating a larger, monolithic buildout of your microservices.
Eliminate Team Dependencies: This can be the most challenging part of DDPE, but it does not have to be. Give stream-aligned domain teams autonomy over their tech stacks via a stable API/contract from DevEx and Core Services. Avoid blocking central approvals. Yet again, your contract testing becomes critical in this context.

Six Patterns

Let us examine whether any of the well-understood six patterns require fundamental rethinking as we introduce increased domain centricity.

4 Team Types: It is a matter of interpretation, but keep the four types the same as the original. However, there should be a clear understanding of where the domain backbone and standard enterprise services (refer to Figure 2) would be placed. Lack of clarity can be a significant problem for either the foundational services teams or the unique domain services, which would be affected by it. I recommend a pattern along the following lines to address this.

Stream-aligned teams are now anchored in specific domain value streams, supported by platform teams delivering foundational services via an X-as-a-Service model. A dedicated Enabling Team spans multiple domains, facilitating capability uplift across stream-aligned teams, especially when collaborating with Complicated Subsystem Teams to build complex domain logic. The model integrates continuous feedback loops between stream-aligned and platform teams, and promotes domain-backbone services as a bridge between foundational capabilities and specialized domain logic. Interaction modes—collaboration, facilitation, and service consumption—are explicitly mapped to streamline flow and reduce friction between team layers, ensuring platform and domain services evolve in lockstep with business needs, even with the introduction of the domain backbone and standard enterprise services.

Team Topologies Second Edition book launch - meet the authors and discover success stories. Reserve your place now!

Figure 3: Mapping Domain-Backbone services and Common-Enterprise services to the 4 Team Types

Collaboration modes will be relatively simple, as the X-as-a-Service mode will be reused for interactions between Domain-Backbone services and stream-aligned teams, and Common-enterprise services and the platform team. No appreciable adaptation is needed for managing the cognitive load, TVP, Flexible Team boundaries, and continuous adaptation, highlighting the power of the TeamTopologies model. Key principles to consider here are:

Do not overload domain teams with domain-backbone services
Do not overload platform teams with common-enterprise services
Start with the master TVP architecture and use the contract testing to ensure that the responsibilities remain autonomous
It is perfectly fine for the platform teams to shift responsibilities between Common-Enterprise services and stream-aligned teams, depending on the level of maturity achieved, with domain-backbone services.
Periodically review the feedback loops to evolve this structure.

Conclusion

In conclusion, the hypotheses we tested here, whether we can effectively apply them to organizations moving towards domain-driven platform engineering, are proven right. The following is a summary of the key points that emerged from the discussion.