Creating Value Using Platforms

laptop with code and hands

When we talk about platforms, we mean a set of services 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.

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.”

On martinfowler.com, Evan Bottcher refers to digital platforms as a foundation of self-service APIs (Application Programming Interface), tools, services, knowledge, and support arranged as a compelling internal product. And is often synonymous with platforms in organizations with capabilities and bounded contexts.

What is an example of a platform?

A great example of a valuable platform is Twilio.

Twilio lets developers quickly and reliably send SMS messages from their applications 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?

Simply put, 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.

Platform consumers offload a portion of their development effort and, therefore, control over their destiny; a calculus needs to occur to understand if this is a good choice.

The platform is a good candidate for adoption if the value exceeds the cost and risk.

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 accessing or getting value from the platform decreases the desirability.

Graphic demonstrating platform desirability impacts. On the left side, expensive, hard to get started, difficult to use, unreliable, slow to evolve. On the right side, addresses a need, reduces effort, reduces duplication, easier to manage, more secure

A platform must be accessible, dependable, and valuable.

Considerations when Designing a Compelling Platform

What are some key considerations if we’re making a compelling platform that needs to be easy, dependable, and valuable?

Below is a layered platform architecture, beginning with the value chain to building the right ecosystem.

llyered 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 must 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!

Be sure to answer these key questions about how the customer will use the platform:

  • 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. Providing clear documentation for the most common scenarios removes the guessing game from the platform’s usability. Plus, simple onboarding tied in with well-documented information leads to reduced frustration. And all associated costs for the platform need to be clearly defined.

In short, the goal is to give our consumers everything we would want as developers ourselves.

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 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 understanding 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.


Get In Touch

Whether you need help with technology strategy and implementation or have an in-flight project in need of additional resources, AIM is here to help.

Fill out the form below and one of our experts will be in touch.