This message was deleted.

First, what do you mean DevOps? Is that a different team? A role? Something else? I think I have a different understand of DevOps. DevOps just says that the team that builds the thing owns and operates the thing, whatever it is. Internal (Platform) or external (Product). Given that, the answers would be • Q1 Every team (product and platform as product) does DevOps as a way of working. There's nothing to move. • Q2 See above, but every team does devops, and it's not a role, it's a process. • Q3. There is no

Dev

in a DevOps world. The same team does development and operations. Different people on the team have different strengths, but it's the same team.

DevOps for me a promise of automating the software delivery and kind of moving away from debate saying it's sometimes a culture shift you can't automate if you don't know how to handle manually, let's say we want to evolve the platform that you are building for your customer so it has delivery cycle someone pushing changes from dev, test to prod, so if we agree platform evolve similar to software build, then I believe those Q's become similar who owns the delivery and how owns the automation, b/c you need automation of delivery in both in the application and platform development.

To me, DevOps is way more than an automated delivery/deployment pipeline. DevOps is you build it, you deploy it, you run it, you get paged at 2:00 AM local time when something happens. To actually do that you need lots of tools and systems. You need a build system and deployment system that works reliably, Those are products that your "platform" teams own and deliver to your internal devs. They also use those same tools to produce those products. The product teams use those tools, just like they use compilers, to develop, deploy, and operate the products. To be a little more concrete, the platform team, for example, owns the delivery tool product. The product team owns the web-app and uses the delivery tool product to get it to external customers.

Greatly described, but I'm trying to understand we need process automation in platform delivery and app delivery (that many of us are already doing every day), platform is a new thing, I_f you say treat your platform as a product (evolve like any other product), I*dea -> Implement -> Test -> Build -> Deploy -> Observe*, similar to App delivery, I kind of interesting in understanding shared responsibility of team owning the delivery of platform features, is it we need to shift a role little bit within the org's or is it about crafting the skills of already existed roles within the org's it can take long, but having initial consideration is so vital right now._

interesting in understanding shared responsibility of team owning the delivery of platform features

The platform team itself will be responsible for delivering the features of the platform. But what exactly do you mean by delivery, @Saim Safdar? The platform team should not have any problems testing, building, deploying and observing the platform features, since that’s what they help other teams do, right? So, I assume you are interested most in the Idea -> Implement part, right?

What I'm trying to get from delivery is when you building the platform, this requires maintaining different stages (dev, test, prod) similar to in-app delivery, or better to say process automation as a feature moves up in the platform stack, one might say, and from practicality, it looks, one platform team responsible for setting tooling standards org's wide, setting up delivery for app and platform, s_etting up compliance and security pipelines_, circulating feedbacks from Internal customers, configuring clusters and much more, look to be a lot of responsibilities, Next's obvious set of Qs comes to my mind is, How much size is required for the platform team and in itself has different roles, so if calling everyone within the team as a platform engineer is tough to draw boundaries and responsibilities internally? Platform adaption we need to align the org's structure upfront.

Are you familiar with the Teams Topologies? It describes different possible models of teams structuring and collaboration. here’s a short summary: https://martinfowler.com/bliki/TeamTopologies.html