What makes it a service?

A question which I have been putting a lot of thought into recently is “What makes a service?” Adam Field leaving team has really solidified some of my thinking on the subject. I present the case study example of micro data repositories which are repositories we provide to researchers for storing bespoke datasets. Adam had been running this “service” for around about 9 months and it is starting to prove quite popular. It was only when he came to pass management of it on to me that we realised there were quite a few things missing. Adam was a smart member of the team who had been competently doing his job and meeting customer expectations but for this to truly be a “service” someone other than him had to be able to do that work.

Because Adam is competent he was already doing some good practice which makes life a lot easier for him and other maintainers to follow. He was using a standard software platform, in this case EPrints, and he was keeping his EPrints configuration and customisations very distinctly separate from the main EPrints configuration. This meant it was easy to see what code required maintenance and of course all the bespoke code was version controlled using git. However this didn’t leave me with much clue of what the various repositories on the service did or how I would know to issue a new one.

The first thing he did is put together some documentation for me. This explained what the platform was for, how it worked and what instances were running to date. This meant that I knew what I would soon be managing. However when I reviewed the documentation I realised it had a large section dedicated to “How to be a competent person like me doing my job” which undoubtedly would suffice, assuming I am competent.

What I noticed was that certain parts of the process were roughly the same each time. For his own sanity Adam had created a set of conventions in how configuration was managed and version controlled. I suggested to Adam that he created a script to automate the repeatable parts of the process. He did this and as he did he tidied and formalised some of the parts of the process to make it more rigidly defined. Each micro data repository still has bespoke configuration (that’s what keeps us in work) but now handle cranking parts of the process can be done with couple of simple commands.

The result of Adam’s work is that I could pick up maintenance and expansion of the service without too much conferring with Adam. Part of my role maintaining the system is to keep the documentation up to date and add scripts to automate the process as I feel it is appropriate. So in conclusion the differences between a “competent person doing their job well” and a “service” are:

• A service has its custom configuration clearly separated from its code
• A service has clear and concise documentation, including a definition of how it delivers value to the user (nod to ITIL)
• A service has scripts or other tools so that it requires as little effort as possible to maintain

The result of all this extra work is that other people can easily pick up and maintain a service without it being their full time job. There is no guessing about how its supposed to work or when it is the right tool for the job. A service runs itself like clock work.