I’m curious how organizations with large business processes interact with Camunda? Such as a business process that cuts across the domains of several development teams. Is there generally a single team that manages the implementation of a process similar to how DBAs might manage databases? Or do all of the teams interact with the platform and contribute on their own? and if the multi-team approach is common, how are changes coordinated across the teams? How are data contracts for processes between those teams established and maintained? How is the division of domain responsibility coordinated? Who usually comprises these teams (devs, process engineers, product managers, etc)
Speaking specifically about large companies who are interested in implementing long-running end to end processes. the various stages and components of implementation can be very easily separated.
It would often start with a process owner (someone with a high-level overview of the end-to-end process) building a BPMN model, intended for documentation that will contain all the key milestones and decision made in the process.
This model can then be used to break up the process into easy to manage sub processes. In some cases you can have a very high level parent process that simply calls other sub-processes made and maintained independently by the most suitable teams or departments (going by a Domain Driven Design here can also be really helpful for determining strict bounded contexts between processes)
Getting a little more granular now, services orchestrated by Camunda can be built, deployed and maintained completely independently from the process that intend to use them, This means in very large companies we see specific departments who build the services needed by a process but might not even need to see the process that their service is actually be executed in. It also helps when it comes to decoupled release cycles as everything is versioned.
In the end you should have a scenario in which processes are maintained by analysts or process owner (with some tech knowledge required in most cases) while the services can be distributed across teams depending on their context.
Hope that helps.