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.