What are the railroad tracks of your SAFe agile release trains? How are they built, and why do they matter so much? In this talk at the SAFe Leadership Forum, I explore how platform engineering creates the foundation that enables agile teams to continuously deliver value for fast flow.
The challenge: cognitive load in SAFe#
When we look at the continuous delivery pipeline inside the SAFe framework, we see that it holds all the workflows, activities, and automation that agile teams need. That is already a lot. But it gets worse. In SAFe, teams practice “you build it, you run it,” which means every agile release train needs infrastructure (cloud or on-prem), runtime environments like Docker or Kubernetes, CI/CD tools like GitLab or CircleCI, monitoring with Prometheus or Dynatrace, security scanning with Snyk or SonarQube, and collaboration tools like Jira or Confluence.
In large organisations with multiple ARTs, each one maintains its own continuous delivery pipeline. This leads to inconsistencies, an exploding tool landscape, and a cognitive load that is simply too high for the teams. Their focus shifts from building solutions to managing infrastructure.
Team topologies meet SAFe#
In 2019, Matthew Skelton and Manuel Pais published “Team Topologies,” which had a huge influence on how we think about organising teams. They identified four fundamental topologies: stream-aligned teams that work on a product domain, enabling teams that help others overcome obstacles, complicated subsystem teams, and platform teams that provide capabilities to all other teams.
When we combine these topologies with SAFe, the picture becomes clear. Inside an agile release train, you have agile teams (stream-aligned), a system team (enabling), and a platform team. For larger organisations with multiple ARTs, it can even make sense to have a dedicated platform ART with 50 to 120 people.
Building the platform: an internal product#
The platform team builds an internal product. The customers of this product are the agile teams and ARTs. The platform provides all the tools and capabilities these teams need to build their solutions: observability, security, CI/CD, infrastructure provisioning, and more.
A critical distinction: the platform team does not do the monitoring for the teams. They provide the capability of monitoring. The teams themselves use these tools to observe their solutions because they practice DevOps. They build it, they run it. The platform team generates value for the agile teams, and the agile teams generate value for their customers.
“The platform team only gives the capability to the teams. The doing is within the teams because they are doing DevOps.”
Architecture principles: the floating platform#
When architecting such a platform, two concepts are essential. First, use adapters for every tool you integrate. In my 22 years of career, I have seen tools come and go constantly. You never know how long GitLab, GitHub, or any other tool will be around. With adapters, you can easily swap tools without disrupting the teams.
Second, follow the “floating platform” concept from Gregor Hohpe’s books on platform strategy and cloud strategy. The idea: build a platform with an excellent developer experience, integrate all the tools and cloud providers, but never abstract them away. Do not duplicate features. If you do, your platform gets dragged into complexity and starts to sink. A floating platform floats on top of the tools, making them accessible in a governed, streamlined way.
Live demo: the platform in action#
During the talk, I demonstrated a platform we built together with LGT, a private bank from Liechtenstein. This platform, which we call the Zühlke Platform Plane, showcases what a modern internal developer platform looks like:
- Self-service portal: Teams can create repositories, provision databases, and deploy applications without tickets or waiting.
- Single sign-on: One login gives access to all tools. No more juggling multiple accounts and passwords.
- Spaces: Each project or product gets its own space backed by a Kubernetes cluster. Owners can onboard and offboard team members in seconds.
- Partner concept: External partners bring their own identity, get integrated via Microsoft Entra, and can self-manage their teams.
- AI-powered features: An AI assistant answers documentation questions, analyzes Docker images, and helps with log analysis. When you have everything in one platform, creating these AI use cases becomes straightforward.
- FinOps: Cost tracking is built in so teams can see what their applications cost and optimise accordingly.
- Security scanning: All repositories and container images are continuously scanned for vulnerabilities with full provenance tracking.
“When a developer deploys an application, they automatically get monitoring, logging, dashboards, everything. They don’t need to care about any of that. This is the power of such a platform.”
Why platform engineering matters for SAFe#
Gartner identifies platform engineering as one of the top technology trends, and McKinsey and BCG agree. They predict that 75% of organisations will have such a platform in the future. In the context of SAFe, this platform is nothing less than your continuous delivery pipeline, the railroad tracks for your agile release trains.
The platform engineering team creates the platform as an internal product. It is a self-service portal with all the capabilities and tools agile teams need to build their solutions. With that, the platform becomes the foundation of your entire SAFe transformation.
Key takeaways#
- Cognitive load is the bottleneck: When every ART manages its own tools and infrastructure, the complexity becomes unmanageable. Platform engineering solves this.
- Team topologies and SAFe fit together: Platform teams in SAFe provide the foundation that stream-aligned teams need to focus on delivering value.
- The platform is an internal product: Treat it like a product with internal customers. The platform team builds it, and the agile teams use it.
- Use adapters and build a floating platform: Integrate tools without abstracting them away. Stay flexible for the future.
- Self-service is essential: No ticket ops. Teams must be able to onboard people, create environments, and deploy applications on their own.
- AI becomes easy on a platform: When all tools, data, and capabilities are in one place, building AI use cases is like playing Lego.
- We are entering the age of industrialisation of software development: Platform engineering is the foundation that makes this possible.