Dieser Artikel ist auch auf Deutsch verfügbar
This article is part of a series
- Part 1: Common Approaches in the Field of Socio-Technical Architectures (this article)
- Part 2: Platforms, Teams, and APIs: How Do They Fit Together?
- Part 3: Socio-Technical Architecture as a Competitive Advantage
- Part 4: Don’t Forget the People
- Part 5: How Much Thinking Can a Team Handle?
- Part 6: Internal Development Platforms
- Part 7: Enabling Stakeholders as a Success Factor
- Part 8: Socio-Technical Architectures: Informality from Mining to Today[1]
Iterative Adaptation for Adaptive Organizations
Organizations are not static systems—they are adaptive networks that continuously evolve. Working within the realm of socio-technical architectures must therefore be an iterative and ongoing process. There is no such thing as “done”; instead, change requires regular adjustments and feedback loops. Two fundamental principles are essential in this context:
- Psychological Safety: Teams need an environment where they can freely experiment, learn, and make mistakes without fear of negative consequences. A culture of trust fosters innovation and continuous improvement.
- Fast Flow of Work: In a world driven by Economies of Speed, it is crucial to identify and eliminate bottlenecks in workflows. Reducing friction in processes allows organizations to adapt quickly and remain competitive.
Team Topologies: Structuring for Fast Flow
The Team Topologies approach, introduced by Matthew Skelton and Manuel Pais in their 2019 book of the same name, provides a clear framework for organizing teams around value streams and workflows. The goal of Team Topologies is to reduce cognitive load on teams while maintaining a strong focus on the flow of work.
This approach is particularly relevant for IT organizations that must navigate increasing complexity and speed. By structuring teams in a way that aligns with their responsibilities and capabilities, companies can improve efficiency, reduce friction, and create an environment where teams can deliver value more effectively.
Core Concepts of Team Topologies
Team Topologies defines four fundamental team types, each playing a distinct role in optimizing workflow and delivery:
- Stream-Aligned Teams: These teams contribute directly to value creation for customers. They own end-to-end delivery for a specific product, service, or business capability. All other team types exist to support Stream-Aligned Teams, enabling them to deliver as efficiently as possible.
- Enabling Teams: These teams help Stream-Aligned Teams develop new capabilities by providing guidance and expertise in specific technical or business domains. They focus on knowledge sharing and mentorship, rather than owning long-term delivery themselves.
- Complicated Subsystem Teams: These teams handle highly complex technical components that require specialized expertise—often in areas where hiring skilled professionals is particularly challenging. Their work involves deep technical problem-solving that cannot be easily distributed across other teams.
- Platform Teams: These teams create self-service platforms that enable other teams to build and deliver value more effectively. By providing reusable infrastructure, tools, and services, Platform Teams reduce cognitive load for Stream-Aligned Teams and help accelerate delivery.
Beyond the four team types, Team Topologies introduces three modes of team interaction: teams work collaboratively when needed (Collaboration), provide services with minimal coordination effort (X-as-a-Service), and offer temporary support to other teams (Facilitating).
However, reducing Team Topologies to just these four team types and three interaction modes would be misleading. At its core, the approach is about organizational strategies that establish fast flow within delivery organizations. To achieve this, organizations must regularly assess and refine their structures. Techniques like Value Stream Mapping and Flow Engineering can be valuable tools in this process.
Another essential aspect of Team Topologies is its emphasis on cognitive load. Only teams with a manageable cognitive burden can deliver quickly and efficiently. Overloaded teams struggle with complexity, which leads to slower delivery and inefficiencies.
Rather than being a rigid framework, Team Topologies is an iterative approach. Decision-makers can apply it collaboratively with their teams to adapt more quickly to market changes and optimize the flow of work within their organizations.
Domain-Driven Design: Purpose Through Clear Domain Boundaries
Domain-Driven Design (DDD) was introduced in 2003 by Eric Evans in his book of the same name. The approach focuses on business-driven modeling of complex system landscapes. Although its origins lie in software architecture and development, DDD has evolved significantly beyond that.
The core idea of DDD is to manage complexity in modern organizations by dividing them into well-defined domains based on business needs. These domains are then structured using Bounded Contexts, which ensure that each team operates within a clearly defined and coherent scope.
Team Topologies explicitly recommends aligning team boundaries with Bounded Contexts. This helps organizations reduce dependencies, improve clarity, and ensure that teams can work effectively within their respective domains.
Alignment on Purpose
A central aspect of Domain-Driven Design (DDD) is aligning teams with purpose within their Bounded Contexts. These contexts do more than just define technical boundaries—they also establish clear responsibilities and focus areas for teams.
This concept aligns closely with the principles from Daniel H. Pink’s book Drive, which identifies three key elements of motivation: Autonomy, Mastery, and Purpose. DDD provides a foundation that enables teams to achieve these elements in their work:
- Autonomy: Clearly defined boundaries foster team ownership and responsibility.
- Mastery: Within a Bounded Context, teams can specialize in a specific problem domain, deepening their expertise.
- Purpose: A strong domain focus allows teams to clearly understand how their work contributes to the organization’s overall strategy.
Strategic Staffing and Procurement: Core, Supporting, and Generic Domains
Domain-Driven Design (DDD) distinguishes between Core Domains, Supporting Domains, and Generic Domains, providing a structured approach to strategic staffing and procurement decisions:
- Core Domains: These are business-critical and provide the greatest competitive advantage. They should typically be developed and maintained in-house to ensure long-term expertise and innovation.
- Supporting Domains: These enable core processes but are less critical to competitive differentiation. In these areas, partnerships or external support may be a viable option.
- Generic Domains: These are standardized areas that do not provide a competitive advantage. They should be outsourced or purchased whenever possible to optimize efficiency.
This classification helps IT decision-makers make strategic make-or-buy decisions, ensuring that internal expertise is focused on key business areas while supporting and generic functions are efficiently outsourced.
Iteration and Customization: No Silver Bullet
All the approaches presented offer valuable tools, but none of them are one-size-fits-all solutions. Decision-makers must adapt each method to the specific needs of their organization. An iterative approach is essential, as organizations are dynamic and their structures must be continuously assessed and optimized.
The values of the Agile Manifesto serve as guiding principles in this process. Statements like “Responding to change over following a plan” and “Collaboration over contract negotiation” emphasize that people and teamwork must be at the heart of any transformation.