Many people struggle with what to do with services that do not cleanly align to existing team or organisational boundaries. For example you might have a delivery team which looks after all back-end finance related functionality, and another who focuses primarily on external customer-focused systems, but what happens to a service that might be used by both parties, for example an Email Service?

Some organisations may make use of a dedicated Shared Services Team. Others may adopt a pattern of Temporary Service Ownership , or perhaps use a Roving Custodian . Another option is to not restrict who can make changes to the code base and allow both teams to make changes whenever they wish, and adopt an Open Service Ownership approach.

In this model, anyone who wants to make a change to the code base for a can. Source control is opened up to a wide group of people in different teams.

To allow a wide group of people to make changes, you'll also need to work out how they get these changes released. If you have a mature Self-Service Delivery mechanism in place, this might not be too challenging, especially if you can release changes with confidence knowing that problems will be caught and that you don't need to orchestrate releases with other teams. If the service in question is tightly bound to other services however, or a separate team handles production deployment, a level of coordination will be needed which could constitute much more overhead given the sometimes chaotic nature of who makes changes and when they are made.

It is also a model which is unlikely to work for a service undergoing a large amount of changes by a single team, as he prospect for multiple developers to get in each other's way is increased. In such a situation, adopting a pattern of Temporary Service Ownership may make more sense.

Opening up the service to anyone to contribute also requires that how changes can be made is well understood. This may require more polish than you generally require for your code bases. Documentation will need to be clear with good examples, and the build, test and deployment process needs to be slick. Simply throwing open the doors to an existing code base and saying 'now everyone make changes!' is likely to lead to chaos.

The challenge here is the lack of a clear custodian (or group of custodians) who can set direction. What sort of changes are acceptable? How do you ensure that a consistent set of idioms are being used when changes are made, to avoid for example an unholy mess of procedural, OO and FP styles all being used in the same code base?

The Roving Custodian can be considered a variation of this approach in that it makes use of gatekeepers who are not in a dedicated team, but who nonetheless decide what changes are and are not acceptable.

See more patterns.