Let’s talk about the elephant in the room. Most transformations do not deliver upon their intended results. Many of these transformations use sound agile methodologies, yet they fail to deliver on the expected results. DevOps came along and refocused the effort, but still, we run into difficulty with transformations stalling or even failing.
Current thinking puts the development (aka. delivery) team front and center in the transformation to rapidly enable the delivery of value to customers. For a team, they need to be able to have all the right skills and capabilities at the disposal so they can own their delivery processes. In complex environments with multiple architectural principles at play, this can be difficult to achieve. To cope with this, we create another team, the platform team, to enable the delivery team.
The question is, do I need a platform team?
The Platform Team
Another common name for the platform team is the DevOps Team. However, we usually describe having a DevOps Team as being an anti-pattern as DevOps as a practice is not something a single team can own for your organization. So instead, we’ll talk about platform teams, but they may be called a DevOps Team in your organization.
An empowered delivery team should be allowed to select their tools and manage their delivery pipelines. Although true, it quickly becomes unmanageable at scale. The cost of allowing every team to do things their way is complexity. Every team now has to make a lot more decisions about how and where to deploy their code. The transfer of skills becomes harder, and teams will now spend time evaluating and operating infrastructure. They also need to be aware of and implement any required regulatory needs.
Balancing these concerns correctly can be like trying to land a paraglider on a small platform in the middle of a lake. Certainly possible with the right skills and some help, but be prepared to miss sometimes and end up in the water.
What is the platform this team creating? Our definition of a modern platform is from Evan Bottcher: “A digital platform is a foundation of self-service APIs, tools, services, knowledge, and support which are arranged as a compelling internal product. Autonomous delivery teams can make use of the platform to deliver product features at a higher pace, with reduced co-ordination.”
However, problems arise when the delivery team needs to make requests to the platform team to make changes. When this happens, we have failed at enabling autonomous delivery teams.
Platform as Product
Unfortunately, the scenario described above happens all too often. The platform team has the mandate to move people to their platform even though this may not be the best solution for the delivery team. Most delivery teams do not want to give up control of their delivery process, especially when the internal platform may slow them down or not have the feature they need.
To solve this, as we move delivery teams from project based to product-based thinking, why not do the same with the platform team?
If we treated our platform as a product, one that the delivery team can opt to buy into or not, we create a change in mindset on both sides of the debate. Done correctly, the internal platform should have all necessary security and regulatory controls built into it. If a delivery team wishes to use a different platform, they can. Providing they implement those same requirements. If the delivery team doesn’t wish to use the central platform (and if they are ahead of the platform team, they may have a good reason), this could be seen as encouragement for the platform team to up their game.
The platform team would then also have a Product Manager with P&L ownership for the product. Any non-trivial platform will likely consist of several teams, each looking after a component of the platform. The danger of not tying these together well is that the platform team can become seen as a collective of independent teams. If delivery teams now start to engage in different areas, this can slow both sides down. For example, imagine the platform has a CI tool component deployed and supported by a CI tool team. We want the delivery team to engage with the platform, not the CI tool team, as the platform is the product. The delivery team should be consuming the platform’s service and the platform team does not have to know what the delivery team is running on the platform.
Take the analogy of the Apple app store. You don’t ask Apple about your problem with Candy Crush, but you can rate the app and send questions to the developer through their platform. Apple is providing tools to enable publishing, setting standards, kicking people off when they don’t measure up, sharing usage data with developers, and promoting the best apps.
What next?
Hopefully, this has given you something to think about concerning your platform teams. Do you see these issues? Do you think taking a more product-based approach for your internal platform will help?
There are benefits to having a platform team. Done correctly, they can take on the complexity of integrating the variety of tools, which may be considerable in a large organization. Perhaps by treating the platform team as a product team, we can also avoid the platform team becoming a blocker to the delivery team.
