Today’s leaders have received the message: in order to compete, your enterprise needs a digital platform. Your success depends on platform thinking – because if you don’t have the right foundation, you’ll never fully realize the transformative potential of your digital strategy. 

At Nuvalence, we’re all-in on platform thinking; with decades of experience building successful digital platforms at global enterprises, leading technology firms, and venture-backed startups, it’s in our DNA. That’s why our clients often engage us to evaluate their application and service portfolio with the goal of creating a roadmap to a true, commercial-grade digital platform.

During these assessments, we apply a very specific definition of what it means to be a platform. But it all boils down to this: Developers flock to easy-to-use, cost-efficient platforms that help them rapidly deliver new capabilities to their users. Anything that stands in the way of this north star also stands in the way of your success.

We see a lot of warning signs that a portfolio isn’t a true digital platform. Read on to learn about five of the most common ones.

1. Lack of Developer Self-Service

One of the most powerful draws to a platform is a low barrier to entry. A well-built platform offers a glide path to developers who want to unlock immediate value from your services. This means low-touch, high-value onboarding without the bureaucracy of meetings or personalized training. They also expect true self-service, with high degrees of automation, rules-based authentication/authorization, excellent documentation, and frictionless support. 

Furthermore, a platform needs to be running a service or set of services. Libraries, SDKs, and toolkits might all support platforms, but they’re not platforms themselves.

So if developers depend on you to get started, or if you’re asking them to “create their own instance” of a platform – then what you’ve built is not a true platform.

2. Centralized Extensibility

By definition, a platform is the central pillar to an ecosystem. Any member of that ecosystem must be able to extend the platform’s value AND have the option to contribute that extension to the rest of the ecosystem. When done right, this extensibility empowers developers and third parties to fill feature gaps that are necessary for their specific use cases, with minimal friction or dependence on the core platform engineering team.

In practice, platform extensibility must be designed so that third parties outside of the core platform engineering team can safely extend its functionality. Clear boundaries between what is and is not extensible by third parties need to be drawn. Platform extensions should never be able to destabilize core platform capabilities or other platform extensions. This means that automated testing (available to third parties), versioning, cross-extension dependencies, scoped enablement, isolated execution, and activation triggers must be carefully considered. Just because your platform “has an API” doesn’t mean it’s centrally or safely extensible.

If third-parties can’t safely extend your platform’s functionality, your platform team has become a bottleneck, or you consider your API to be synonymous with your platform – then what you’ve built is not a true platform.

3. Poorly Considered Abstractions

Platforms try to create simplified abstractions over more complicated services. It’s generally understood that “abstractions are leaky”, meaning that while the abstraction is meant to shield developers from complexity, they often need exposure to the complexity in order to get their jobs done. We often see situations where developers building on top of a platform need to get exposed to the inner workings of the platform in order to debug, improve performance, or simply get their platform-based applications up and running. A good litmus test is whether or not a developer can fully troubleshoot and debug their application without support from the platform engineering team. 

If developers are unsure if a problem they are seeing is a “platform issue” or an “application issue,” it’s usually a good sign that the abstractions have not properly been designed and implemented – and a sign that what you’ve built is not a true platform.

4. Unclear Units of Scale

Before developers use a platform, they need to understand the units of scale across the services provided by the platform. The units of scale don’t have to be consistent across services; they just need to make sense in the context of each service. Units might include compute allocation, memory allocation, requests, streams, responses, or storage. Definitions for the min/max, parallel vs. sequential allocation, cost per unit, and self-service limits must be documented and enforced. 

If units of scale aren’t defined at all, or if they’re handled collaboratively between the platform engineering team and application developers – then what you’ve built is not a true platform.

5. Poor Operational Maturity

Every platform must have SLAs/SLOs that are clearly understood by all parties, and require minimal coordination between platform engineering teams and the rest of the ecosystem. This operational maturity also includes support for constructs like:

  • Canary deployments
  • Rules-based traffic routing (i.e., by the tenant, service version, geography, etc.)
  • Localized versioning and updates at individual service and tenant scope
  • Tenant-aware observability and tracing through all layers of the platform and infrastructure

If your platform operators need to closely collaborate with application developers to ensure the platform remains stable (and doesn’t break when changes are made and new capabilities are introduced) – then what you’ve built is not a true platform.