Wednesday 22 July 2015

UKOLN Informatics

Sad to hear of the closure of UKOLN Informatics. This unit set in train and/or encouraged a wide range of digital and e-library (for those of us of a certain age) initiatives over the years, particularly in the late nineties and turn of the millennium. It's a relief to see that some of its progeny have found good homes but a shame that the doors are set to close. Many thanks and good wishes to all concerned.

Sunday 19 July 2015

Core specification or core specifications?

Thinking about the prospect of a revision of the UK Core Specification, I got to wondering whether or not it should be a single, monolithic beast.While it's useful to have something to act as a basis for a formal Statement Of User Requirements at the start of a procurement process perhaps its singularity could cause a problem as much as a solution.

When I did the lessons learned with my manager after Rochdale procured Spydus we both thought that we'd got the best of the available options but it would have been good to have been able to have some of the nice bits of functionality of some of the other systems on top of that. Of course, we were procuring a single library management and the idea of a best-of-breed pick'n'mix of bits of systems wasn't — and probably still isn't — a practical option for us. But it's an appealing idea and it would be a shame if a revised UKCS closed the door on it unnecessarily.

Needless to say, there are pitfalls as well as advantages…

In favour of a modular UKCS:

  • Possibility of building "best-of-breed" hybrid systems
  • Potential for increased diversity in the market place
    • Contracts could be awarded to more than one supplier
    • Newcomers to the market could concentrate on doing one thing well rather than having to make a big commitment investing in developing a universal solution
Problems with a modular UKCS:
  • Which modules? One of the problems with the existing UKCS is that it presupposes the shape of the solution — there'll be a an acquisitions module, a serials module, etc. etc.
    • One of the things we tried to so when we were putting together our requirements was to get people to think about functional outcomes and outputs rather than bolt-ons or "modernisations" of the machinery they knew. I'd like to imagine something similar for a revised UKCS but that's easier said than done.
  • How would/could you specify the interaction between modular components?
  • Procurement processes hate shades of grey. A complex procurement — a bit of this, a bit of that — would be bloody hard work (a simple procurement like ours was a hard slog).
  • It would be more work for the suppliers — instead of a simple first-past-the-post competition for each organisation's procurement they'd be entering into a series of Nash equilibria.
  • It would be hard work technically:
    • How would the interfaces between system components be set up and managed? And who by? We have fun enough with SIP2 and EDI, enriched content and interfaces with third-party services and systems!
    • If the main part of the system is provided as Software as a Service, how would the rest of the functionality work with it?
    • What would be the maintenance and support arrangements? Could Service Level Agreements be constructed in such a way as to encourage collaborative working between competing suppliers?

The problems may not be insurmountable. The benefits may not be realisable. Either way, I think it's important that the possibilities should be explored.

Wednesday 15 July 2015

Ideas and innovations in public libraries

The very excellent Ian Anstice has added a useful new page to Public Libraries News: a digest of reported "new ideas" in public libraries. Some are brand new and innovative; others are things that some libraries have been doing, unheralded, for yonks. Love them or loathe them, new ideas and innovation have been part of the business of public libraries for over a century and a half. Seeing so many of them stacked up in one place like this is breathtaking: you get some idea of the breadth of services delivered by the national public library service and some of the depth of thought put into developing, improving and supporting those services.

Have a look at the Ideas and innovations in public libraries page here.

Wednesday 8 July 2015

System permissions - stray thoughts

I'm doing some work at the moment on system permissions on a transport management system I'm responsible for, called Tranman. Partly because I looked at the way the security settings and permissions were set up and thought: "I don't understand any of this!" Partly because I'm concerned that so many people seem to have high-level permissions on this system. That last isn't a criticism of anybody: you make your suite of best guesses when you do your implementation and do a review later in the light of experience.

When a new system's being implemented many organisations work on the basis that a manager needs more permissions than the people they manage so managers' user accounts tend to accumulate more permissions the higher they are in the pecking order. In fiercely-hierarchical organisations like libraries this can be taken to the nth degree: when I came into the first library management I ever managed all the librarians had superuser access to the system!

In truth they don't need this: nearly all complex systems like an operational management system don't have a single hierarchy of permissions; they have a permissions matrix. The manager may need to have oversight of more parts of the system but they don't necessarily need to be able to get in and do the work. For example, the manager would need to be able to authorise orders and payments but they wouldn't necessarily be able to create orders and invoices; and for audit purposes there are good reasons why these should be either/or functions if at all operationally possible. (Where it's not operationally possible you should include the necessary warnings and safeguards in the standard operating procedures).

The general rule of thumb is that the user should only be able to access what they need to do their job and, ideally, should only be able to see what they can access: all those library superusers disappeared the first chance I got. This caused some consternation: "You can't give yourself more control of the system than your senior managers!" to which the answer was: "I just have." These days I work in IT and my line manager doesn't have access to any of the systems I manage: "What would I do with it if I had it?" And to be fair, the managers I work with these days tend to work on the basis that "working life's complicated enough so if you can declutter my space by removing those things I don't need to do myself, great." It improves system security, it streamlines the operation, they get a less stressful user interface and there's less opportunity for error, so why wouldn't you want to do it?

One of the things I've decided that I want to do with this particular system is to set up a permissions group for auditors that would allow quite a wide area of access but all of it view-only. The more I think about this the more I think this needs to be considered in the review of library specifications that Ken Chad's encouraging (more details about this in the LibTechRFP wiki).