This is a question that comes up a lot; is a self-service solution better than a guided form-based tool or interface? There has been endless hype over the last dozen years or so about so-called self-service-solutions that will transform the way scientists interact with their data, giving ‘them the power to make decisions’ (whether they want to interact with their data in such a way or not). Do such tools really stack up when compared to carefully designed solutions specifically created to serve well-defined purposes? That’s what I hope to explore in this brief article.
Picture the scene; we are in a pharmaceutical company, you are a frustrated senior chemist or biologist (aren’t we always) having a lengthy meeting with your IT team to try and tackle the issue of data access. You want more access to help you do your valuable work. IT want to provide that data as best they can whilst not overwhelming themselves with support requests. Your opening gambit: ‘what I would really like is a tool that allows me to easily get to any data relevant to me, to allow me to explore that data as I want to.’ Light bulbs flash in the IT team’s minds (or are they blinding strobes?). ‘Perfect,’ they say, ‘that’s just what we were hoping you would say, we’ve been wanting to re-write tool X for years and think we can build you something that will let you get to any data you want. Can you approve the project?’
You agree, but why wouldn’t you? It sounds like IT have fully understood your needs and finally you can look forward to accessing your data the way you want to. Two years later, you meet up again in a high-level meeting and IT have come to show you the new tool they are very proud of. They talk excitedly for a while about SOAP and web services (you try not to dose off) and then it finally comes to the demo. They type in a URL with strange characters and explain as they do it that they are showing you how you can write a substructure search in just one line – ‘how neat is this?!’ The page whirs away for a while and then… a static HTML page with some compound IDs and, if you are really lucky, some structures… Right, Okay… ‘Wait,’ they say, ‘now we have this self-service architecture we can take that list of IDs and type in another URL to get some data.’ They show variations on the previous effort and proudly sit back with the belief they have delivered exactly what you asked for. They see the bemusement and slight shock in your face and chip in with things like ‘and now because we have Y we can build this little widget and that little widget.’ I think you know the rest of the story.
I confess, self-service solutions sometimes offer a little more than this, but not much more. A very common and popular variation on this theme is the workflow/pipelining tools. They offer you, the user, the opportunity to build your own system interactively – why wait for IT when you can be your own programmer? Fantastic! Essentially these tools remove the need for a programmer to develop the web-services described above and allow you to build your own. To augment the interaction they often offer a web-based form to fire off these workflows so you no longer have to type in the cryptic URL. Perfect!
Self-service solutions do have a place and a very important one. Given a well-structured database they allow you to retrieve data from systems not designed for interactive querying, where you want to dump some data for use, in say, a visualisation tool. But the problem is that the vision of self-service has been taken too far.
What I have always believed a chemist or biologist really meant when they asked for better data access, was not a tool where they had to figure it all out, but simply a better tool. They really wanted a more ‘flexible’ interface to their existing databases (if that tool also had the ability for self-service, even better). With the considerable advances in web-technology and hardware over the past 10 years we have all become more sophisticated when interacting with back-end systems, but I don’t believe we have really got to the point (or ever will) where we no longer want guidance on what we are searching and viewing.
Researchers do want to explore the data and visualise and mine it, but their main goal is far more obvious and practical; they want to spend as little time as possible getting to the pertinent information to help guide their research and day-to-day activities in the lab. If they have to wait for an administrator to add a single box onto a form then they are likely to get a little cross. The answer is to allow them to easily do that themselves, not force them to work in an entirely different way. Informatics is incredibly important in helping to drive research; without it we are completely in the dark and reduced to using guess-work to find new drugs. But IT departments should never make the mistake of thinking that because of that they should simply open up the database to all and throw the data access problem at the researcher and hope it sticks. Let’s get all the data in a single place that can be quickly and easily digested and made use of, and let the scientists get back in the lab where time really matters!
www.dotmatics.com
