Should We Create a Shared Service? A Decision-making Checklist

Nick Tune
Nick Tune
Jun 4, 2019 · 7 min read
Image for post
Image for post

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.

  1. Will consumers lose any capabilities?

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

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?

Image for post
Image for post

Let’s fill out the checklist:

  1. 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.

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.

Image for post
Image for post

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.

Image for post
Image for post

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:

  1. 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.
Image for post
Image for post

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.

Image for post
Image for post

Technology Strategy Ideas and Insights

Domain-Driven Design, Organisation Design, Continuous…

Medium is an open platform where 170 million readers come to find insightful and dynamic thinking. Here, expert and undiscovered voices alike dive into the heart of any topic and bring new ideas to the surface. Learn more

Follow the writers, publications, and topics that matter to you, and you’ll see them on your homepage and in your inbox. Explore

If you have a story to tell, knowledge to share, or a perspective to offer — welcome home. It’s easy and free to post your thinking on any topic. Write on Medium

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store