It just happens that I am thinking a lot in the SOA / Web Services / ILS / OPAC space and in the computer scientists (please don't call us "techies") talking to librarians space.
I guess one difference that I perceive is that CS people often don't, due to their training, start with a particular technology (Ajax, RSS feeds, whatever) when looking at solving a problem. Similarly, Enterprise Architecture is about first abstracting the basic desired function ("provide relevance ranking") rather than examining a specific technical solution ("stick Endeca on top of my ILS").
That's why you will find me writing a lot about "what", as in, what are the underlying things you want to do, rather than "how".
So that being said, I see a lot of activity around fixing the ILS, unsucking the OPAC and such.
And I realize I haven't done a very good job of constructing the chain from SOA theory to new improved disintegrated library system.
To some extent, it is the same "you can't get there from here" pig makeover story that has been extensively discussed elsewhere. You can't incrementally decorate your way out of the underlying problems with the ILS. Have you seen Extreme Makeover: Home Edition? They have a simple process for transforming people's houses:
- Demolish the current house
- Build a brand-new house (using the latest tools and technology, along with a lot of hard work)
What does that mean in practical terms? It means you need to be building a brand-new library system, using the latest tools and technology, along with a lot of hard work. Now if you've seen EM: HE, the other thing you will notice is that in the triangle of people versus time versus scope, they make the time very small, by making the number of people working on the house very large. So: it takes a village to raise a new library system. And the construction materials that we have at hand, the latest concrete, wood and utilities, are services (whether you call them Web Services, REST APIs, new standard interfaces, extended OpenURL - it's all services). Services are the new pieces you need to build the new LS.
But... you're probably ahead of me here. If you put these pieces together haphazardly, the house will fall down. If you don't want your new LS falling apart, you need... architecture. A sort of Service-Oriented Architecture, in fact. An SOA agreed upon by the community (the library technology village), defining a standard set of services so that we can all build our own unique Extreme Homes.
Without a common set of services, a shared basic architecture, it's as if you're building pyramids with giant chunks of limestone, and I'm building temples with bricks and concrete: we're both using great technologies, but we can't easily build on each other's work, because our fundamental building blocks are completely different.
That's all that SOA is, a way to come to a common agreement, so that we can all use the same pieces, the same technology components. If you agree that the way to get to a new library system is by using services, then SOA provides the framework to ensure that we all get to use the same pieces, so that no one organization has to build the entire thing themselves. You use my relevance ranking service, and I use your book cover service.
And all of this does NOT have to be slow, with everyone waiting for some giant SOA committee consensus. Let's agree on a few services, and combine them in different ways to make a bunch of version 1 library systems. And then a few more services, and a few more.
Replacing the monolithic ILS with a new silo will fail. Trying to define everything in advance in some Big Bang Waterfall will fail. But total anarchy of services will, I believe, also fail. We can't spend all our time pouring and re-pouring the foundation of the house, putting up a wood frame and then tearing it down and putting up a metal one. We need to build services on top of services, layer by layer, orchestration by orchestration.
So I apologize if I'm often on about apparently esoteric debates concerning SOA reusability and similar theoretics. What all the SOA jabber is about is making sure that we have the right methodology to sustain building more and more complex sets of services, or in other words, ever more complex yet maintainable new library systems.
If this explanation is still not doing it for you, please let me know.
Comments