You platform is more than just using AWS or Azure, its your application and integration architecture realised.

A platform is key to enabling multiple engineering squads to focus/deliver the unique business value.

In order to scope correctly, we need to consider beyound the infrastrcuture, and include such topics as the patterns of Application and Integration Architecture.


A platform refers to your software solution and how you tackle the cross cutting concerns (to meet the Software Qualities).

Consider how you get consistency

  • SelfService - i.e. requesting a Repository (with guard rails)
  • Patterns, Templates and Standards
  • Central services - i.e. ApiGateway
  • Reusable code libraries - i.e. Telemetry
  • Consider Platform Engineering

Context - Software (distributed)

This post will need to assume a distributed architecture such as microservices.

The challenage

Your answer may differ (it depends on your context)

So lets give an exmaple context:

  • We have several squads
  • Our solution is made of dozens of (mircro/mini) services.
  • We need to expose API’s via an API Gateway
  • Cross cutting concerns is being delivered slightly differently per squad.
  • The majority of domain code is relatively the same in complexity (interacts with a EventBroker and database, while exposing API’s)
  • Our solution needs to comply several Software Qualities
  • we have one main programming language (C# for example), but we have no standards. (so code between teams differs)

this is complex, we need to tame this.

Our Goal is to:

  • maximise our speed of delivery (aka reduce the time it takes to make a change, Time To Market - TTM)
  • lower the complexity of the overall solution (aka reduce the how much it costs to engineer and operate, Total Cost of Ownership)


We will try and take a page from Google, Monzo, Sterlin Bank, Just Eat, ITV and many more

This allows for common things to be done the same way, allowing us to automate, share knowlegde and reuse.

How does this apply to our platform?

Platform and Platform services

The platform is the wholistic view of the architecture

Above is an exmaple view (its missing a lot of detail), and shows alot of platform services.

The Platform is made of:

  • Platform Services- services which multiple squads make use of, these are normally cross cutting or common (things we can make consistent), such as the Database cluster and assoicated code libraries, code patterns, templates, etc
  • Services (workloads) - these are the domain services which combine to make the product sold to customers

Consider that the Platform Services are to delivered by the Platform Engineering squad.

Cross cutting and common

The following is an overview with a possible set of areas. Each area has several services.

Area Description
Development Experience How we write code, test, build, deploy, and collaborate
API’s Exposting APIs (API Gateeway), Auth*, Service Catalogs for both internal and external use
Hosting & networking How we host (containers), servicemesh, secure and lockdown workloads
Stateful services From databases, to event brokers
Telemetry How the engineers can maintain and operate services
Self-service and Common code All services will have elements of these
Administration Tools to admin/operate services, and support processes
Recovery and Audit Handling desaster recovery and ensuring we can confirm who did what

These are high level areas, please click on the area to see what each section is made of.

Service included

The platform is also part of the service (this can be often missed)

If we look at the code we can write for Telemetry (logging, metrics, spans), its common and can be made consistant, there is no value writing 10 different variations.

Whats on top.

We have mentioned Platform servcies

Each of the services have to be designed with the following in mind.

  • Tenancy Model - i.e. how we setup the RBAC in databases.
  • Training and Tools - docs, courses, bootcamps, onboarding.
  • Templates, Standards, Patterns, Library Code - how we design for read heavy scenarios, how we epose the API internally.
  • Self Service (automate all the things) - how can we let Product Squads request a database, which has all the guaard rails applied.
  • Shared Responsibility Model - simple RACI, when someting breaks who gets alerted.
  • Processes - provisioning of a service, execution of a backup restore, all processes manual and automated (keep it light weight as possibe)

(Its people, process and technology.)

Inner source and community

Its mentioned in the Platform Engineering, but this is important to the sucess of this.

Treat your platform as open-source within the company.

Improved Consistancy

By implementing Platform Engineering along with a platform, we enable

  • consitant approaches to common code
  • product squads focus on business logic
  • self service allows independence, and automation
  • engineers can help one another, as they all work in the same way

This can improve TTM and TOC. (the return on investment is easier to see with larger squad numbers, where consistancy can make a massive difference)

© 2022 All rights reserved.