Should We Create a Shared Service? A Decision-making Checklist
One of the key decisions we need to make in software architecture and in our organisations is when and where to create shared services and organise teams to build them.
Creating a shared dependency can boost the productivity of downstream teams. They can outsource some of their product’s responsibilities to another service owned by another team, and can instead focus more on innovating on their core capabilities.
Shared services aren’t all fun and games, however. Introducing a shared service creates a coupling and a dependency. Instead of a team being highly autonomous, now they may have to wait on shared service teams to deliver key improvements.
Deciding when to create a shared service can be highly subjective and quite often highly controversial. But there are a series of heuristics, or questions we can ask ourselves, to improve our chances of making the right sociotechnical design decision.
Take a look at the following checklist and the example patterns and I’m sure you’re more likely to architect better systems in the future.
The Shared Service Decision Making Checklist
If you just want to see the checklist, here it is. If you want to understand what each of these questions means and how they apply to specific scenarios, read the examples in the following sections.
- Will consumers lose any capabilities?
- Will consumers gain any new capabilities?
- Can consumers focus more on their strategic initiatives?
- Will consumers be slowed down by the new dependency?
- Will the shared service team be responsive?
- Will the number of consumers be problematic?
- Will the cost of migration be excessive?
- Can consumers refuse to migrate?
- Will the shared service improve business efficiency or eliminate waste?
Shared Service Patterns
To demonstrate the shared service checklist, take a look at the following two patterns. The patterns will be demonstrated in the context of a large travel company with hundreds of teams and many business units.
Bona Fide Generic Services
Some capabilities required to build our products and service are highly generic. They are undifferentiated and provide little opportunity for competitive advantage. They are Bona Fide Generic Services and the chances are good that they should become shared services.
In our large travel company, one of the architects has been doing some large scale analysis and has identified that many teams seem to be facing similar challenges and solving a similar problem: email. Some of the areas they are dealing with include:
- Building email templating services
- Managing email infrastructure or SaaS services
- Finding ways to avoid being put on spam filters
- Monitoring email
- Storing customer contact information
- Managing contact preferences
The architect decides that the company should form a new team to develop a centralised Customer Communication shared service. But is this a good decision? Is communicating customers really undifferentiated heavy lifting?
Let’s fill out the checklist:
- Will consumers lose any capabilities?
Consumers of the Customer Communication shared service are not losing any functionality. The new shared service allows them to do everything they could do before. - Will consumers gain any new capabilities?
Consumers of the shared service may not receive direct feature enhancements but they will be able to pass on the benefits of the new shared service to their customers: more ways to received communications, a centralised preferences centre, etc. - Can consumers focus more on their strategic initiatives?
Consumers now don’t have to worry about the intricacies of customer communication and can focus on their core areas. - Will consumers be slowed down by the new dependency?
Consumers rarely have unique needs for contacting customers and their core work doesn’t depend on it, so they are unlikely to be frequently slowed down by the dependency on the new shared service. - Will the shared service team be responsive?
The shared service team are committed to building cloud native systems and deploying to production every day. There is a high probability that when teams depend on them they will be able to respond quickly. - Will the number of consumers be problematic?
The high number of consumers is a concern but not problematic due to consumers all having similar needs. In this respect, the high number of consumers means higher efficiency. - Will the cost of migration be excessive?
One concern with the new shared service is the time and effort to get many teams across the organisation to migrate from their custom implementation to the new solution. In the long-term it will be worth it, but in the short term it will cost each team upto a month of productivity. - Can consumers refuse to migrate?
The Head of Architecture, the CTO, and the Chief Product Officer have all given their blessing to the new shared service so there is alignment on moving to the new service. Some teams may initially resist but it’s unlikely the shared service will be built and not used. - Will the shared service improve business efficiency or eliminate waste?
The shared service will ultimately remove an extremely high level of duplication and allow hundreds of engineers to spend more time on activities with a higher value.
What do you think? I think this was a great decision by the organisation to introduce a shared service which improved the user experience, the efficiency of teams, and the morale of many employees.
Deceptive Reuse Services
Not all shared services remove undifferentiated heavy lifting and improve efficiency. Sometimes, the appearance of reuse and salivating prospect of improving efficiency can be deceptively dangerous.
After conducting further enterprise analysis, another architect has also identified duplication and reuse potential. Multiple departments within the organisation have their own package builder services.
The package builder services are used to build holidays. In the Mass Market Holidays department, the internal team create standard holiday packages with few customisations. In the Luxury Experiences department, customers themselves can build their own unique holidays consisting of jungle tours, guided expeditions across Africa, mountain climbing, and so on.
The architect decides a shared Package Builder service is needed. It will remove duplication and allow the business to have all of the package building information in a single place. Is this a good or bad decision?
Let’s fill out the checklist:
- Will consumers lose any capabilities?
It is likely that the Luxury Experiences department will not be provided with all of the features in their current package builder service. The architect believes they are unneeded and should standardise with other department. This applies to new features the Luxury Experiences team were planning to build as well. - Will consumers gain any new capabilities?
The Luxury Experiences teams do not expect to gain any new features their customers will require. - Can consumers focus more on their strategic initiatives?
For the Luxury Experiences team, package building flexibility was a core strategic initiative so the shared service is still an area they need to focus on. - Will consumers be slowed down by the new dependency?
The Luxury Experiences team will now depend on the centralised Package Builder team for a lot of their work. High levels of coordination will be needed and the team are likely to be heavily compromised. - Will the shared service team be responsive?
The Package Builder team will be formed in another area of the business and geographically located in a different continent. Engineering standards are a little different over there. Typically they deploy software once a quarter and love to have code freezes. Responsiveness could be a big problem. - Will the number of consumers be problematic?
There will be around 5 consumers of the shared Package Builder service. Not a huge number, but 5 teams all competing for the time of 1 team could result in delays and politics. - Will the cost of migration be excessive?
Migrating to the new system will require only a few weeks of lost productivity. So the time to migrate will be reasonable. - Can consumers refuse to migrate?
There are likely to be some big political battles because teams do not want to depend on a shared service for areas in which they need the ability innovate quickly. - Will the shared service improve business efficiency or eliminate waste?
Theoretically duplication will be removed. In reality, the additional dependencies, frustrated employees, and degraded customer experience will be orders of magnitude more costly.
From my perspective, this is a huge mistake. The luxury customer experience has been negatively impacted which will directly impact revenue. Equally, the Luxury Experiences teams are now being slowed down when they want to innovate on their core opportunities.
Are these problems worth it? I don’t think so. The business goal of having all of the package builder data in a single place could very easily have been achieved using other approaches.
This is an example of a Deceptive Reuse Service. We tried to extract undifferentiated heavy lifting in a part of the system which was actually core to a part of the business.
