Some of the problems with museum information management strategies

The museum sector is, probably more than others, saddled by the lack of a proper information management strategy (you may call it digital strategy, or just strategy): the typical medium to large museum will manage its museum collections, its archive and its library with three different software solutions and publish each of them (when possible) on the web using either different platforms (vendor specific) or different integrations. If they have donors, these will be stored in separate systems and databases (often more than one), so there is no way to know that, for example, an artist in the collection is also a donor. And so on, spanning to another five or six silos of information, all of which are crucial to the museum's operations. In addition, because many of these systems, even when they are dedicated, are inadequate, lots of important information is on Word and Excel files, on people's computer, not backed up and not centrally accessible.

In addition, if and when integrations between different systems happen, they don't start from the ground up: integrations are more often than not added components on top of the existing (messy) landscape, so when any of the underlying components changes or it is upgraded, the integration crumbles. Would you build a house on unsafe foundations, that you already know are wrong?

All of this is doing software vendors a massive favour, as they can sell museums more of the same: more systems, more training, more integration services and more APIs (yes, I know of a company that charges extra for its API: madness). Why does this happen? In my experience it is because there is a widespread lack of understanding of what a software system is and what it should and ought to do. I taught many workshops on database design to museum database administrators, where I was a little shy asking if I should not cover basic concepts like one-to-many and many-to-many relationships, as they are the bread and butter. My audiences told me to start from an even lower level - as they didn't really know what a database was or how it worked. So they buy the equivalent of black boxes.

A database is a database. Full stop. A collections management database is a database that is configured with the tables and fields required for managing a museum collection (and it should have the flexibility to understand different types of collections and operations, but it often does not). An archive database is a similar database, with (different) tables and fields for managing archival (hierarchical) collections. There is no reason why the two could not coexist in the same software, provided that the interface to that software is flexible enough to manage the different workflows required. A digital asset management system is a database of assets... you can see where I am going with this. (Diversion: the primary difference between a DAMS and a CMS is that the former is asset-centric and the latter metadata-centric, so one cannot and will not replace the other, although whether your organisation needs both is debatable - I will write an article about this).

To the technologically-aware humanist in me, the fundamental key to information management for museums (and archives, and libraries) in the 21st century will be flexibility, configurability and access control: this is a philosophical-driven approach, not a technology-driven one - technology (and APIs) will follow. There is no point in asking for, or having, APIs between different platforms without first defining the overall institutional museum information landscape and the scope and role of its content and why you need to integrate, which will define what type of APIs you will need.

You need to design your house, before you start laying its foundation: otherwise you will always find yourself occupying the wrong space and will keep building provisional sheds for the stuff you didn't think about in the beginning.

#damandmuseum