Hello everyone, I am currently a Product Manager in an organization where we have been trying for several years to get teams to do Continuous Delivery. To do this, we have undertaken a DevOps transformation, deployed a Kubernetes Platform, created user clubs to encourage exchanges, built guides, created services for developers to simplify their lives, etc. But the scaling of our initiative (with > 150 teams) leads us to restructure our operating mode for 2025. To do this, we have divided the Engineering Platform by theme (and therefore scope/team) as follows: * Alignment & Autonomy --> make understood + promote/support to ensure that each scope adopts a product culture, interacts as-a-service. * Internal Developer Portal * Observability (Opentelemetry, Grafana, etc.) * CI/CD (Git, Repository, Sonar, etc. * Dev Services * BDD (sql and non-sql) -> BDD (Redis, Mysql, ...), Messaging (Kafka, rabbitMQ...), Indexing (Solr, ...) * Containerization (K8S) * Infrastructure To divide, we relied on our existing by working as follows: 1. Divide into the most autonomous perimeter possible 2. Define the least expensive interaction modes (-> As a service) 3. Define how to align well In this division, "Security" may seem to be missing. We see Security as a subject distributed in each brick, to try to get out of the anti-pattern: "Security on the side, as a limiting source in productivity". Overall, I am looking for feedback of experiences on how to segment, cut out the possible perimeters of an Engineering Platform. What bothers me a little in the tooling landscape available on the site is that it is only a grouping of tools, not necessarily a good way to cut out. What do you think please? Thanking you in advance. Fred

Hey @Fred M, is this the structure that you currently have in place, or this is the goal structure going forward? I’d also interested to know more about how you’re thinking about security? i can tell you that there is no faster way to kill a platform than to lose momentum, and the biggest momentum killer will always be issues with security. Security needs to be core to all of this, and security teams need to be onboard from the beginning. Otherwise, you’re going to get to 6 months from now and find yourself stuck in an endless loop of conversations with security teams.

Lots to discuss here! Would be curious to hear your thoughts @Jordan Chernev. Since a lot of this seems very focused on department structure.

taking a look

Can you share that Alex ewerloeff piece?

@Luca Galante This is the operating mode that we are targeting for next year. We started in 2018 and today, our Kubernetes Platform (and all its ecosystem) is already widely used (several thousand pods). Basically, we are 2 teams: * A team implementing and operating the Kubernetes Platform * A team providing abstraction/simplification services for the product teams But all this is also enhanced with many teams from the existing organization offering services but often orthogonal to the spirit and practices that we are pushing. Their interventions are not very structured, this can lead to Platform instabilities. * We are at a point where we have a lot of products arriving, with many different uses. With the formalization of a clear scope, with clear contributing teams, this seems to us to be a good first step to absorb our scaling towards: * (Alignment) Better alignment to offer a coherent/unified vision within a Platform (all this to improve the developer experience). * (Autonomy + Expanding the circle of transformation by bringing existing teams into our IT department) Providing support capabilities for teams contributing to the Engineering Platform. On the specific subject of security, the subject is well addressed but we have not identified it as a team, a specific scope, to avoid the anti-pattern of the external person slowing down the work. I imagine that for this to go as well as possible, we will have to describe very precisely the expectations for each scope, with support/guidance for each one. I think that this corresponds to skills needed within the Autonomy/Alignment team. Moreover, the Autonomy/Alignment team does not appear in any article for the organization of the implementation of a Platform Engineering. And yet it seems crucial to me to spend time sharing, re-sharing the north star, describing the issues, supporting, guiding towards the right target, right trajectory, right priorities. I wonder how this can be done without it? In the different scopes mentioned (all in the form of Platform Teams), it is quite clear that the interactions will be described, as much as possible in as-a-service. @Jordan Chernev Thank you for the article Keb vs Cake organization! I was able to perceive the difficulty and the gap with our model. I will already try to identify who the suppliers/customers of each brick are.

Can someone explain the kebab vs cake? I do not understand how it relates to @Fred M

it's relevant because it highlights how organizations can be structured

thank you. interesting.