N100FN100F
Published on

A platform is an internal product

An internal platform fails when it is imposed and succeeds when it is chosen. Treating it as a product, with users, a recommended path and something to gain from using it, is what sets it apart from a list of prohibitions.

Service line Platform Engineering

The users are the teams

When an organisation decides to 'have a platform', the usual move is to start with the tools: an orchestrator, a deployment system, a portal. Six months later there is a lot of infrastructure and few teams using it, because using it costs more than going around it.

The change of perspective is easy to say and hard to practise: the platform is a product, and its users are the teams that build applications. Like any product, it has to solve a real problem for them and be more convenient than the alternative.

The recommended path

The recommended pathA recommended path with four stations against a do-it-yourself path that solves each stretch separately.PLATFORM · INTERNAL PRODUCTThe recommended pathRECOMMENDED PATH Templateborn with structure Registryplace and owner Build and deploysame for all ObservabilityincludedIdeaProductionDO-IT-YOURSELF PATH????Each stretch is solved alone: slower, different in every team, with no traceability.Goal: make doing things properly the easiest option.If the governed path is the fastest, nobody goes around it.N100F · n100f.com

The practical way to think about it is as a recommended path: a route from idea to production that is already solved, where every stretch works without the team having to invent it.

  • A template the application is born from, with its structure, its documentation and its deployment already prepared.
  • A registry where the application gets its place: addresses, ports, owners.
  • Automated build and deployment, the same for every application.
  • Observability included, with no manual configuration.

A team can leave the path if it genuinely needs to. But then it solves on its own what the platform was already giving it, and that is usually enough to stop it doing so without a reason.

What turns a platform into a product

  • Adoption is measured, not the number of tools: how many applications are born from the template, how long a new application takes to reach production.
  • It is documented for whoever uses it, not for whoever built it.
  • The teams are listened to. If they all go around the same stretch, that stretch is badly solved.
  • It is versioned and announced. Changes to the platform affect every application; they are communicated like changes to any product.

The goal

That doing things properly is the easiest option. If the governed path (with phases, registry and traceability) is also the fastest, governance stops feeling like a toll.

The first stretch of that path is the lifecycle: the phases every application goes through and the gates between them.

How we apply it: Platform Engineering.

If your cloud cost keeps growing and nobody knows why, or your architecture depends on whoever built it, let’s talk.

Let’s talk