This message was deleted.

Depends on if you want your developers making decisions that impact business and/or other teams 🙂 That's the main problem we run into when there aren't clear owners (or the owners aren't involved).

Hmm, interesting. We have a moving toward a YBYO culture so I guess that’s what we’re looking for 🫤 How did your team think about this when you broke up your monolith?

The problem we have with that is it's not the developer's job to care (or even know) about the metrics that other teams in the business care about. Things tend to run much smoother (for us) when the owners of services are the relevant teams that it would impact. They define the needs/requirements of the service, and are involved in the testing before release if QA feels they should have eyes on it.

Hi, lack of ownership (and accountability) can destroy soooo many plans, and cause sooooo many issues, and will ultimately lead to a really poor culture. Get it right from the start, set the expectation, explain the expected behaviour and then help nurture a positive culture :)

taking a DDD approach and understanding where your bounded contexts are can (but not always) help when trying to figure out where ownership for a particular service lies. As mentioned above, it's not just a PE issue, but one of process. once you have your service owners then you can work with them to figure out how to drive adoption of any new platform

Clear ownership is helpful, in two dimensions: 1. There should be a defined dev team that owns each monolith/app/microservice (or “cell” if you’re following cell-based architecture terminology). 2. And there should be a defined Product Owner for the business Capabilities that map to that cell. How those map will depend on how you drew your boundaries and where you are in your monolith-to-microservice journey.

@Ryan Alder Right, makes total sense - so was the main goal to ensure your developers don’t get overtaxed?

no the main goal was to make sure they didn't change/break things they didn't understand why things were done the way they were, and create headaches for business users ;-)

@Mo, excellent point here. So is the real value of establishing ownership quickly to maintain a great dev culture and ultimately keep your developers happy?

For us it’s still on a case-by-case basis. For services that clearly align to an existing product domain that already has a product owner, it’s a pretty easy call. The ones that are more generic, shared, cross-product, simple, etc. (e.g., address validation), we’ll either assign them to a dedicated “platform” PO (only for really core ones since this isn’t very scalable) or to whichever PO has an interest and capacity. So some POs own a major product and a handful of “minor capabilities”. Finally, ones that aren’t functional at all and are purely technical/infrastructure, we’ll either have a Technical PO if it’s complex (e.g., authentication) or just the dev team if not. I’m sure there are more methodical ways to do it. simple smile

That's about how we've handled the different cases as well

Yep, totally agree with @Jeff Madison re: DDD, bounded contexts, subdomains and a product owner! Also helps to view the platform as a marketplace of various services and capabilities (and get that team its own product owner as well). Lots of great tips in this thread, you’ll be fine :)

Also helps to view the platform as a marketplace of various services and capabilities

We’re using Backstage for that. Liking it so far. The Backstage yaml file in the service’s repo indicates the owning dev team and PO, amongst other things. For the business capabilities catalog, though, still just Confluence.

same, we're using backstage as a catalogue, and need to keep working on that. I'm hoping to extend the thinking and actually have products that are funded, endorsed, have a PM etc as part of the platform, making it a bit more official. Loving this exchange of thoughts, this is what communities are for! 🙂

@Jeff Madison @Mo - do you both have dedicated devs managing Backstage? We’ve heard it’s catalog capabilities are pretty robust but building it out and maintaining it long term might require more resources

Yes, it’s owned by a “platform” team, which also owns a bunch of other platform stuff (frameworks, libraries, shared services, templates). I wouldn’t say it’s been difficult to maintain so far. That said, managed offerings like roadie.io could make sense for companies with more budget than time.

yep it's owned by an ops team, tbh we should be using the metadata from it across all our systems (logging, monitoring, alerting) but still working on that