Platform engineering teams need to focus on building end-to-end workflows versus individual tools according to Naphat Sanguansin, CTO at Prodvana. A focus on workflows will help to abstract away the complexities of running services and allow for application engineers to focus on their product.
Sanguansin, who formerly worked at Dropbox, shared that Dropbox's attempt at introducing an SOA (Service Oriented Architecture) was not fully successful. The project focused on producing underlying infrastructure tooling to enable product teams to extract code out of their monolith and run it as services. While the individual infrastructure tooling was successful the product teams were spending more time dealing with the operational overhead of these new services. Sanguansin notes that:
As more teams and services were introduced into the critical path for customer traffic, we found it increasingly difficult to maintain a high reliability standard. This problem would only compound as we moved up the stack away from core functionalities and asked product teams to run services.
Lori Macvittie, distinguished engineer at F5, calls this the API tax: the time and technical debt that is paid by executing complex processes through individual building blocks such as API calls. Wrapping up these blocks into workflows helps to reduce both the investment time in the initial work and also future debt. As Macvittie explains, "that’s because using workflows instead of APIs means less complex code that’s easier to manage and easier to change. They are more agile and less fragile."
Sanguansin shares that Dropbox employed the Jobs to be Done framework to better understand their customer's needs in writing and shipping code. In this framework the customer is viewed to have a job that needs to be done. In order for a product to be desirable as a solution, that product must solve the job to be done both functionally and emotionally.
This approach aligns with how others see approaching the building of a platform. In an interview with InfoQ, Adam Hansrod, consultant at Equal Experts, stressed the importance of treating the platform as a product and not a project. In this approach, the platform is built incrementally based on feedback garnered from product teams. As Sanguansin notes, the Dropbox SOA initiative "did not take customers’ needs into account and so did not provide a workflow that tied all these building blocks together".
Sanguansin shares that Dropbox's Atlas initiative took the approach of providing product engineers with a complete workflow versus individual building blocks. For small, self-contained functionality, like the Dropbox homepage, Atlas provides a workflow where product developers only need to write the interfaces and implementation for their endpoints. The platform team managing Atlas takes care of the underlying production clusters, including provisioning, updating, and monitoring, and is responsible for pushing code out to production. Larger, more complex projects are able to coexist alongside Atlas, as the teams tend to be larger and more able to handle the operational overhead.
According to Sanguansin, this approach was an adoption success. The focus on an end-to-end workflow freed consumers of the tool to focus on what matters most to them: shipping features. As Sanguansin notes, "do the application engineers want to be known for writing the best, most correct Terraform configs?"
This emotional aspect aligns closely to the product thinking concept of delight. As Cristóbal García García, senior staff engineer at Amenitiz, and Chris Ford, head of technology at Thoughtworks, note:
You must never forget that you are building products designed to delight their customers - your product development teams. Anything that prevents developers from smoothly using your platform, whether a flaw in API usability or a gap in documentation, is a threat to the successful realisation of the business value of the platform.
This is echoed by Sanguansin's learnings from his time at Dropbox: "A platform that focuses on tooling instead of an end to end workflow ends up replacing a job with different jobs application engineers need to get done instead of solving the job completely".
By requiring product teams to stitch together infrastructure tools to ship their code they are unable to smoothly use the platform without added friction. Having the platform team focus on building an end-to-end workflow reduces friction by abstracting away complexities and allowing product teams to focus on what is most important to them.