Creating Value Using Platforms

What is a Platform?

What is a platform? If the term seems nebulous to you, then you’re not alone. Throughout my career, I’ve had the chance to work with companies across many industries, building platforms. The term platform has meant different things to each of them, and they’ve had varying degrees of success in implementing them.

The word “platform” has been overused to the point of dilution, but according to Gartner, “a platform is a product that serves or enables other products or services.” Writing on martinfowler.com, Evan Bottcher says, “a digital platform is a foundation of self-service APIs (Application Programming Interface), 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 coordination.” We may also hear words that seem synonymous for platforms in organizations – capabilities, bounded contexts.

For this conversation, when we talk about platforms, we mean a set of services that are internal to a company or externally published that enable other products or services. This means a platform supplies some value for a company implementing that platform itself (if it’s an external product) or provides some value for solving the problem multiple times on a small scale.

A great example of a valuable platform is Twilio. Twilio lets developers quickly and reliably send SMS messages from their application by creating simple, easy-to-use APIs. The real value is that Twilio has built relationships with major carriers to allow programmatic SMS sending. A company choosing to build its own system would have to establish all those relationships, abstract the mechanics, and test them – incurring extensive development and maintenance costs. Twilio set its price point to make them an attractive alternative to that development.

What makes a platform valuable?

A platform is a product. In software, products have associated costs for maintenance and sales. Even internal platforms need to be evangelized so that they are discoverable by others, thus having costs associated with them.

Consumers of a platform are offloading a portion of their development effort, and therefore their control over their destiny; a calculus needs to occur to understand if this is a good choice. If the value exceeds the cost and risk, the platform is a good candidate for adoption. The platform owners need to understand the perceived costs, risks, and values to swing the equation to adoption. It’s this calculus where I’ve seen the most stumbling blocks – organizations write beautiful code without understanding the greater ecosystem and how they fit into the solution. Any friction in getting access to the platform or getting value out of the platform decreases the desirability.

In short, a platform must be accessible, dependable, and valuable.

Designing a Compelling Platform

If we’re making a compelling platform, and it needs to be easy, dependable, and valuable – what are some of the key considerations? Below is a layered architecture of a platform, beginning with the value chain through to building the right ecosystem.

A platform team is responsible for delivering value to a consumer – a consumer needs to be comfortable taking a dependency on the platform and should be able to extract value rapidly

This picture starts with value – understanding the customer, which problems are valuable to be solved, and how they can be engaged to help evolve the platform over time. Evolution needs to occur rapidly, so an agile team whose backlog is decoupled from other backlogs is strongly desired. That way, when a feature is requested, there shouldn’t be a dependency on three other teams completing their work first!

It also says that we, as platform owners, need to make sure our customers understand how the platform is supported. What can they expect in terms of Service Level Objectives? How will they design their systems to improve reliability in the unlikely event that the platform fails? How do we architect for resiliency and handle failures from the technical side?

Lastly, we want to reduce the friction for someone to adopt and use the platform. We want to give them clear documentation for the most common scenarios so they don’t need to guess how to use the platform. We want to make onboarding as simple and well-documented as possible to reduce frustration. Any associated costs to use the platform need to be clearly defined. In short, we’re giving our consumers everything we would want as developers using someone else’s systems.

Organizational Alignment

One of the biggest keys to a platform’s success is appropriately aligning the organization to support the platform. We first need to make sure the product owner understands the customer’s need, can work with the customers to refine the need, and is empowered to make decisions to develop and support the platform.

We need to understand our platform’s development, operational, security, and support needs and develop a team structure to staff for those needs appropriately. Failure to plan properly can lead to projects being understaffed, leading to customers being dissatisfied.

A platform requires executive support to ensure it is adequately staffed and funded, it has clearly defined metrics for success, and that there is a plan for monitoring those metrics. For example, success metrics may include adoption, numbers and timelines for determining if the platform needs to be adjusted or terminated. It should also include metrics around cost. If there is a way to measure the impact, defining those metrics will help demonstrate to others how the platform provides value.

Lastly, funding sources need to be determined – if a platform is internally used, how much of that platform should the consumers pay for? Usually, there’s some cost-sharing between the various teams.

Technical Considerations

A platform necessitates iterative development and agile considerations. Our technical choices need to reflect those needs.

CI/CD

Automating deployment makes iterative development possible. It removes the manual steps and adds automated quality gates to keep the confidence high. The true value proposition with this automation level is that we can do minor, iterative releases without adopting much test overhead since we can focus only on the newest code.

Cloud Delivery

In the current state of the ecosystem, saying a platform will be deployed in cloud infrastructure is rarely controversial, but it’s key to understand why cloud infrastructure is essential.

1. It’s ephemeral, meaning it’s easier to test something in isolation making deployments more reliable.
2. The cost of experimentation is low since we only pay for what we use and can quickly and cheaply decommission our experiments.
3. Capacity planning is simplified since we can rely on burst cloud capacity.

Architecture

Creating system boundaries for a platform domain allows it to be decoupled from other systems and enables planning for failures of those systems. A domain-driven, microservice architecture helps create those boundaries and can boost evolutionary architecture patterns that help support the platform over time.

Designing the system for observability also means that issue remediation is faster, and metrics are captured to help drive decisions.

Documentation

Clearly documenting the system and expectations is an investment. This upfront investment reduces the friction for adoption by getting consumers up and running faster and more easily, as well as reducing the burden on the operational team by improving supportability and reducing troubleshooting assistance. Documentation is usually an afterthought for developers, but a culture of sharing information with others and making systems easy to use should be considered from inception. A simple wiki describing the intake process for contacting and collaborating with the platform team members and product owners can go a long way in reducing frustration. Step-by-step onboarding instructions and examples will lower frustrations and reduce ad hoc issues that need to be managed by the team. If I’ve witnessed one area of under-investment repeatedly, it’s in creating meaningful, searchable documentation.

Next Steps

There are a lot of opportunities to use platforms to drive value both internally for your company and externally for your customers. If you’re considering a platform approach or a platform product, make sure you plan it appropriately to ensure that it is set up for success. You can be scrappy and create platforms with smaller teams if there’s a clear understanding of the value chain. Understanding the support structure and how you’ll manage to evolve the product is vital. If I had the chance to go back and advise people differently, it would be to focus on the ecosystem; if a platform has compelling value, then it’s the ecosystem that will ensure it thrives or fails.

AIM has experience across the various dimensions needed to deliver a strategic platform. We excel at product development practice, agile leadership, cloud and microservices architectures, DevOps, and quality engineering. We’ve built platforms for many Fortune 500 companies and have the experience to help get you started.

---