Starter services

Every new joiner to the team should be given a service to own and look after. Ownership of (or “catching”) this service will introduce them to the patterns and libraries used by the team, as well as giving everyone a sense of responsibility and feeling that they are adding value.

Caring for your Pokéservice

While everyone will work and interact with lots of Pokéservices, the purpose of an owner (or trainer) is to ensure that a service is well maintained (updating dependencies, failing builds etc), well understood (documentation/tests), correctly lifecycled (retired if no longer needed).

Pokéservice trainers do not have to be developers — they can be Product Owners, BAs, QAs, even stakeholders could catch them.

Pokéservice Cards

Every Pokéservice will have the following:

Name: a cool name, ideally a pun.

a cool name, ideally a pun. Type: this can be either a team, department and/or category of service (front end component, API, user facing application etc).

this can be either a team, department and/or category of service (front end component, API, user facing application etc). Description: a clear statement of what the service does and why it exists

a clear statement of what the service does and why it exists Stage: where this service lies in the product lifecycle (is it experimental or more evolved?). A service can only evolve if it’s stats meet a certain threshold, or some criteria of supportability are made.

where this service lies in the product lifecycle (is it experimental or more evolved?). A service can only evolve if it’s stats meet a certain threshold, or some criteria of supportability are made. Special moves: any technologies used, APIs provided or otherwise that are unique to this service (e.g. it’s the only app in your team that uses that latest hipster JS framework), as well as how to use them.

any technologies used, APIs provided or otherwise that are unique to this service (e.g. it’s the only app in your team that uses that latest hipster JS framework), as well as how to use them. Stats: indications of it’s value to the business, cost and ease of maintenance. Ease of maintenance could incorporate things like test coverage, number of different committers to the repo, technologies unique to this service.

indications of it’s value to the business, cost and ease of maintenance. Ease of maintenance could incorporate things like test coverage, number of different committers to the repo, technologies unique to this service. Shinyness: SLAs are super simple. If it’s a shiny, you can call me up after hours.

SLAs are super simple. If it’s a shiny, you can call me up after hours. HP: Pokéservices will use Hit Points to determine how healthy they are. This could consist of error rates, health of underlying services — whatever you use to monitor your services now.

Pokédex

This will be your central database of all the Pokéservices, and will include information of who currently owns the service, and who has “seen” it (which can be anybody who has worked on or committed to the service).

They are also the key to gamifying the system. The Pokédex will also rank trainers as they progress through the organisation. Everyone’s bonuses will be linked to the ownership, training of and retiring of Pokéservices, as well as annual “The Very Best” awards.

Gyms

Each of the types of Pokéservice defined by your organisation should have a Gym leader. This is someone who’s expertise is in that type (so a Tech lead for a department, or Front End overlord etc.), and can be used to “battle test” a service and ensure it is worthy of the type. A gym leader can then give github badges to cosign or verify the legit-ness of a service.

Trading

In a large organisation, it’s inevitable that people move around within teams and departments. The concept of trading allows me to move on without being straddled with services I no longer need to know about.

It also provides incentive to look after and maintain the services I own. If I try to get rid of a weird API that is undocumented, untested and falls over every other weekend, nobody is going to want to give me their Charizard for that.

Battling

Occasionally, there’ll be times where you have multiple services doing the same thing. This could be on purpose — one of the perks of a microservice is that it is easy to replace a small part of your system with another that performs better. It could be a result of silos in your organisation that inadvertently created the same thing without talking to each other. Or perhaps someone somewhere higher up got a fancy sales pitch for a new Recommendations API that will boost your conversion rate by 300%.