This message was deleted.

While it may overlap with a few other areas you called out, I'd say Test Environments (ephemeral, load, acceptance, etc) is often a focus area owned by platform engineering teams.

Yes, when I say infrastructure, they are responsible for creating the environments from test -> prod and all in between

Security is a big aspect as well. Mau not fall entirely under the PE purview, but in partnership with infosec. Also compliance measures must be baked in

Security and compliance. Especially if a company has to conform to ISO 27001 or FedRAMP.

Hi @Neil Millard, when you are referring to "focus areas" are you also envisioning individual teams for those, or a corresponding organisation respectively? Or in other words, how do you organize yourselves team-wise?

At my current project, each one of those is a team of 4-9 engineers. Together we support over 300 teams of developers

We have been thinking about those focus areas (domains) and their relationships as well lately, in particular to find a combined answer for: the product's valuable ingredients on the one hand and a potential team split on the other hand. So far we came up with 4 layers (could be 4 teams?!?). However, probably worthwhile to think about a dedicated Support Team. As mentioned by others, we also put a dedicated "control center" in place to manage incidents.

A dedicated support team, if possible, is a good idea. Otherwise your infrastructure engineers will spend way too much of their time doing support work and burn out in the process

We have a dedicated edge platform team for our public facing APIs. Specifically tuning/optimizing our GraphQL north-south traffic

Would you say that something like Gitlab or other SaaS is part of "Platform Admin"? @Neil Millard 🙂

Yes, enabling access to the tools, source control (Gitlab, Github), Kanban (Jira, Asana), CI/CD (Jenkins, CircleCI), email accounts, and such

What about some additional "governance" roles: e.g. Cost management, Identity management ... or could those be part of "Platform Admin" as well?!?

We do governance as well for the areas that we own - • anything that is deployed on the infrastructure we manage • anything that is using our pipelines for deployment • anything that is using DBs managed by us By governance we make sure • the company specific patterns are adopted • security related concerns • resource specific configurations (eg: cpu, autoscaling configs for apps running on ECS) • log setup • cost optimization • other myriad things

Adobe recently talked about their IDP Capabilities at ArgoCon and highlighted different components in following diagram:

Very good approach/abstraction from my perspective. What I like a lot is how the "user journey" of engineers becomes part of the "product" perspective. A very common and successful way to create relevant domains for teams and business metrics correspondingly, e.g. in e-commerce teams/platforms.