Endless diagrams

December’s Aus GLAM Blog Club topic is “End”. I’ve been working on system relationship diagrams and training documents this month, so the word “end” makes me cringe. I’ll try and explain with my relaxed, holiday brain… I think I switched off the moment that I left work for the year.

The “end” of a library system is theoretically the outside edges of all the little systems that we use. If you imagine your catalogue database as a flowchart with shapes representing each system, there will be systems with fewer connections to other systems towards the edges… and some sides of the shapes that don’t have any connections going outwards.

A diagram showing a library catalogue, public website, circulations system, and staff email connected

(I apologise for my messy sketches. The colours mean nothing, I just like my coloured pens. Also, this isn’t my current library, it’s an imaginary library, hopefully generic enough to be similar to yours.)

To say that we’ve found our edge there is being a bit dishonest, because most libraries have relationships between their systems – or staff – and external systems. Libraries Australia, WorldCat, or library vendors and journal publishers send in metadata to be incorporated into our libraries’ systems… those are the obvious ones. Think deeper. SurveyMonkey or other sites that somebody in one team at your library has done some user engagement through. Google Docs or DropBox being used by your staff even if it’s against your content storage policy.

a diagram of basic internal library systems and how they relate to external systems and services like Trove, software vendors, library vendors, and other libraries

Now, think of the “ends” of those systems, especially cloud ones. The end is an ever-shifting gradient rather than a nice, clean line. The more you understand the different risks and dependencies of all these systems and how your library uses them, formally and informally, in their workflows, the more impossible it becomes to explain. It’s often easier to pretend that the systems we don’t own (or pay licensing fees for) fall outside of our overall library “system”. It is also easier to pretend that the on-site hosted software in our server rooms marks the end of our ability to control our data – and thus our responsibility.

It’s awful when I’m working as a test analyst in my library, because it means that “End to End” testing can never realistically reach all potential end points. There’s too many other libraries who are part of this huge and glorious mess.

I say mess as a test analyst, but as a librarian I love it. We are one of the few professions where we both act as, and serve, users of a wide range of systems. From analogue microfilm readers through to e-resources, we work hard collaborating silently and invisibly with librarians all over the world… at least, those who speak, write, and read English… but that’s a topic for another blog.

Every time I talk to people at my library about system relationships, and frame the systems in relation to that person’s daily work, they look at me with awe and horror… but I built my knowledge by drawing shapes in a graphics tool – you could just as easily use PowerPoint or Paint or coloured pens like I did today – and draw lines to represent all the connections.

I think every librarian should have a mental or digital mud-map of their systems and how they relate to external systems. You don’t need to be perfect, it will always be incomplete, because it will always be changing and because sometimes you won’t be able to know what everyone in your library is using. But the more you understand all the connections that are outside of your library’s control, the better placed you are to advocate for your readers needs and to demonstrate the value your services add to the world.

Personally I have found that the better informed my coworkers are about the ways the systems that they work with relate to other ones, the easier they find it to use them. A lot of people get anxious when they don’t know why something is broken, or how often to re-try exporting data to a different system, or who to ask for help when two systems that should be connecting just… aren’t. Knowing those points of connections and how everything fits into a grander scheme of library work and metadata can be really reassuring.

Though to be honest, I think that it can also just be fun to play around and do this, so I use every chance I get to do it!

On reflection, the “end” to your library system is probably the relationships between all the systems that your readers might need to help them use your collection, whether you own them or rent them or simply link to them. And sometimes you can’t imagine how deep that might go until you begin exploring and mapping them out.