Nick Tune
1 min readOct 15, 2019

--

Hey Mark, I appreciate your comment.

I’d like to agree, and in the politest way possible disagree too and for 2 reasons.

  1. It will depend on the company and domain — I’ve seen this example work both ways. To find the answer for our domain the checklist is useful. In your example, point 4 (will consumers be slowed down by the dependency) would weigh heavily, directing you towards deciding a shared service was not a good idea.
  2. However, I still think that a shared service is possible. We should strive to make the shared service self-service so that consumers can leverage it without being blocked by the team that owns the service.

Regarding point 2, this relationship pattern is formally defined as the X-as-a-Service Team Interaction Pattern in the recently-launched Team Topologies book by Matthew Skelton and Manuel Pais. Highly recommended.

If an organisation has explored the possibility of X-as-a-Service and feels it’s not an effective solution, and the organisation expects there to be high-levels of co-change between consumers and the shared service, then I would agree that a shared service may not be appropriate in the given context.

Happy to continue discussing this more if you have any further comments.

--

--

Nick Tune
Nick Tune

Written by Nick Tune

Principal Consultant @ Empathy Software and author of Architecture Modernization (Manning)

No responses yet