Building an Effective Digital Platform: Adam Hansrod on the Benefits, Challenges, and Approach

Equal Experts have open sourced a playbook detailing their thinking on building Digital Platforms. The playbook outlines strategies to organize a successful digital platform and explores the challenges that can be faced by digital platform teams. InfoQ spoke with one of the authors of the playbook to discuss the ideas in more detail.

The playbook defines a Digital Platform as "a bespoke Platform as a Service (PaaS) product composed of people, processes, and tools that enables teams to rapidly develop, iterate, and operate Digital Services at scale." 

The authors of the playbook argue that an effective digital platform will improve an organization's time to market, increase revenue, reduce operational costs, and improve innovation. An effective platform is one that is differentiating, designed as a product, and is opinionated. 

The platform is differentiating in that it abstracts away organizational complexities and toil, allowing teams to focus on driving business value. As explained within the book Site Reliability Engineering, "Toil is the kind of work tied to running a production service that tends to be manual, repetitive, automatable, tactical, devoid of enduring value, and that scales linearly as a service grows"

They emphasize the importance of treating the platform as a product and not a project. This includes staffing an empowered Product Manager who can work to gather feedback from digital service teams that are using the platform as customers. Building the platform incrementally based on the feedback from the customer teams drives stronger adoption of the platform. 

This feedback gathering needs to be built on bi-directional feedback loops enabled by trusted relationships that are built between members of the platform teams and the digital service teams. The authors suggest leveraging a number of product management techniques such as conversations, surveys, capability analysis to help the team better understand the needs of the digital service teams. Assessing the effectiveness of the digital platform should be done by measuring delivery throughput, production reliability, and user satisfaction.

Advertising the platform is necessary to help build awareness and to push adoption. This must include examples of the opinionated user journeys that are currently supported and those that are planned to be supported. With future plans, it is also important that the digital service teams see their feedback shaping the roadmap direction. 

As noted by the authors, an opinionated platform "makes it easy for your teams to build, deploy, and operate Digital Services by providing a curated set of high quality building blocks." 

Similar to how companies like Spotify and Netflix approach this problem, they describe a digital platform as a set of paved roads that are fully automated and encompass the organizations learned best practices. These guardrails reinforce the opinionated nature of the platform and help push the digital service teams towards success. A chief focus is on removing complexity from the digital service teams' user journeys. This frees up the team to focus on the digital service business logic and customer needs. 

This approach aligns with ideas such as Team Topologies where the goal of platform teams is to build the Thinnest Viable Platform (TVP). As defined within the book Team Topologies by Manuel Pais and Matthew Skelton, 

A TVP is a careful balance between keeping the platform small and ensuring that the platform is helping to accelerate and simplify software delivery for teams building on the platform.

The playbook notes that platform direction and scope can be illuminated by "small, frequent experiments on platform capabilities, powered by their own hypotheses and user feedback from Digital Service teams". By building the platform incrementally and delivering it in small increments, adjustments can be made based on learnings and user feedback.

Although the focus on the platform is reducing pain points and toil for digital service teams, the playbook interestingly shares the idea of adding intentional friction as a type of guard rail. This technique, of making suboptimal practices more challenging, helps to reinforce the opinionated nature of the platform and help aid adoption of the new services. 

The playbook introduces a number of pitfalls that can derail a successful digital platform launch. One risk is treating the platform as a universal infrastructure solution. They highlight that a platform needs to focus on a subset of cloud services that support critical service workloads. 

They recommend that a digital platform be built with an initial digital service team as the first user. This prevents building a platform for the sake of having a platform as the needs of this service team can help direct the best platform components to target. A service team as customers is required to properly treat the platform as a product, as the digital service team's user journey is vital to defining the platform roadmap. 

InfoQ sat down with Adam Hansrod, Consultant at Equal Experts, to discuss the concepts and ideas within the playbook in more detail.

InfoQ: How can a Digital Platform team gain the necessary insights into a Digital Service team's user journey?

Adam Hansrod: Early on when building a Digital Platform product, the platform team should run through discovery & inception exercises with the delivery teams to establish context, identify dependencies, as well as map the expected user journeys.

As that Digital Platform starts to grow, a platform team needs to keep close to their first users and ‘be in the room’ when service team members are complaining (whether that's about the platform or something else entirely!). Service team members might not realise what they’re complaining about might be great feedback on platform features and capabilities that aren't meeting their requirements.

As the number of teams using the Digital Platform grows, a great source of feedback on the quality of self-service functionality and documentation can be the questions and requests for help from delivery teams, as it can show:

• missing functionality
• the documentation isn't as helpful as it could be
• where a conversation with the questioner could be required to help fill in gaps of knowledge around processes

Throughout the life of a Digital Platform, dedicating someone from the platform team each day to answering questions or helping delivery teams with using Digital Platform capabilities and functionality can help build up their knowledge of how they're being used. This approach can be complemented with quantitative approaches like surveys, or user-centred exercises such as user personas or user journey mapping to equip a platform team to better understand what their users are trying to achieve and what challenges they’re facing.

InfoQ: When should the platform team decide to push the user journey into a different direction?

Hansrod: A platform team should make decisions about altering the user’s desired journey when that user journey is working against (or will in the future work against) the principles the platform team wants to encourage.

A common example can be the branching strategy, if the platform team is trying to encourage principles around continuous delivery they might introduce friction in the user journey where teams are creating long-lived feature branches and reduce the effort required to work using a trunk-based development process.

InfoQ: Could you elaborate on what the Inception Phase is?

Hansrod: The inception phase is a set of pre-delivery activities run collaboratively to make sure there is enough information available to start delivery with the best possible chance of success. If inceptions have just one job to do, it’s to de-risk delivery.

This range of activities includes (but is not limited to) validating and aligning on expected outcomes; clarifying scope; identifying dependencies; defining ways of working; exploring technical feasibility; and planning the subsequent delivery.

Inception phases are similar to classic project kickoffs but focused on collaboration and testing the assumptions around the success of the initiative. The information gathered during an inception phase typically results in a decision on whether to continue, pivot or stop with an initiative.

InfoQ: In the playbook you state you should treat "your public cloud provider as Software as a Service (SaaS) not Infrastructure as a Service (IaaS)". How does this manifest in the decisions made by a Digital Platform team?

Hansrod: By treating the cloud provider as SaaS rather than IaaS, you're shifting your mindset to composing platform capabilities from cloud tooling and services that free time up in the future rather than commit more time in the future to maintenance. Building everything from scratch via the cloud providers IaaS offerings will only increase the amount of BAU work you'll need to do in the future.

InfoQ: What direction would you give an organization that is trapped within an end-to-end testing paradigm? What steps should the Digital Platform team tackle first to help with the transition?

Hansrod: I'd direct the organisation to:

1. Move their end-to-end tests down to integration or contract tests
2. Build stubs for each service so valid test data is available at compile/test time, rather than requiring a running service in an environment to test against.
3. Explore moving what is being tested even further down the testing pyramid to unit tests

The Digital Platform team should help support the above direction by making it easier for non-end-to-end testing to be done. Activities the team could perform include providing Pact servers to enable contract testing, or working examples of how to run tests in a pipeline against stubs rather than against whole environments.

InfoQ: One of the requirements to start a Digital Platform team is homogeneous workloads. How can an organization with heterogeneous workloads across multiple teams begin to implement a Digital Platform?

Hansrod: When an organisation has multiple teams with heterogeneous workloads (i.e. each team has different workload types or little in common), it can be difficult for a platform team to provide a high-quality experience for each team as they won't invest as much effort in providing smooth user journeys around each workload.

In this scenario, attempting to build a silver-bullet platform that supports multiple workloads will quickly slide into the lowest common denominator features required to support the workloads, rather than a targeted effort to provide a smooth user journey around each workload.

In my experience in this scenario, it’s better to invest directly into each team to ensure they’ve got the tools they need and recognise they won’t have as smooth a journey compared to teams that do share homogeneous workloads with others and can be supported by a platform team.

InfoQ: What methods have you found most successful in advertising and building buy-in for the Digital Platform vision?

Hansrod: It’s all about building trust and demonstrating value early with the accountable & responsible stakeholders and users. I’ve found weekly or fortnightly showcases are a good way to showcase platform capabilities and build buy-in with delivery teams and stakeholders.

Stakeholders will want to understand how the digital platform vision will help them achieve their aims to help the organisation and may need showcases where they can see how where the platform is right now is helping achieve their objectives. I’ve found that whilst every organisation has a different set of priorities common demonstrations of value that a digital platform can provide is to help save money by removing duplication of effort and increasing standardisation, generate revenue by increasing the speed at which services get to market and the quality of the services delivered, and reduce risk around the security of the services being produced by providing the tooling and processes to shift security left.