zigazou76, Machine de Gramme, http://www.flickr.com/photos/zigazou76/4481926257/

Sain puhua Tampereen maakuntakirjastokokouksessa 17.2.2012 keskitetyistä kirjastojärjestelmistä, palvelukeskeisestä arkkitehtuurista, rajapinnoista, standardeista. Kaikesta hauskasta siis. Taustalähteinäni oli muun muassa Tuula Haaviston, Marja-Rii Jokisen ja Mace Ojalan Kirjastojärjestelmät nyt! ja Marshall Breedingin Opening up Library Systems through Web Services and SOA: Hype or Reality? -teos vuodelta 2009 (Library Technology Reports, 45 (8)). Juha Hakala on kirjoittanut hyvän artikkelin kirjastoautomaatiohistoriasta (Kaksi vuosikymmentä kirjastoautomaatiota, Tietolinja 1/2007). Artikkeli käsittelee muun muassa kirjastojärjestelmiä. Kaikki mainitut teokset ehdottomasti lukemisen väärtejä.

Käytössä olevien kirjastojärjestelmien integroidut toteutustavat ovat herättäneet kritiikkiä osassa ammattikuntaa. Integroitu kirjastojärjestelmä eli keskitetty kirjastojärjestelmä (integrated library system, ILS) on yksi paketti, joka sisältää paljon toimintoja (luettelointi, hankinta, lainaus, palautus, tiedonhaku jne). Vanhan sukupolven integroituja kirjastojärjestelmiä on moitittu vuoroin monoliiteiksi, vuoroin dinosauruksiksi.

Nämä keskitetyt kirjastojärjestelmät voi mieltää ikään kuin elektroniputkeksi, eräänlaiseksi umpioksi. Alunperin on riittänyt, että data ja palvelut pyörivät suurimmaksi osaksi järjestelmän sisällä ja lisätyönä (yleensä järjestelmäntoimittajan tekemin) on saatu uusia toiminnallisuuksia ja laajennuksia ulkopuolelle.

jeua, Gang of Vacuum Tubes https://secure.flickr.com/photos/jeua/4811608960/

Järjestelmän umpiomaisuus ei ole vain integroitujen kirjastojärjestelmien helmasynti, vaan muiden alojenkin tietojärjestelmiä vaivannut ominaisuus. Kun kehitys kehittyi ja toimintaympäristö muuttui, alkoi myös kirjastoalalla olla paineita järjestelmille

• jotka ovat helpommin muokattavissa
• joiden toimintaperiaatteet ovat hyvin dokumentoituja
• joihin voi rakentaa ketterämmin erilaisia lisätoimintoja, joita järjestelmänvalmistaja ei välttämättä voi toimittaa.

Yksi vastaus tähän kaihoon on ollut palvelukeskeinen arkkitehtuuri (service-oriented architecture, SOA). Kyse on järjestelmäarkkitehtuuritason suunnittelutavasta, joka määrittelee miten tietojärjestelmiä pitäisi suunnitella ja rakentaa.

SOA-periaatteen mukaan eri tietojärjestelmien toiminnot ja prosessit on suunniteltu toimimaan itsenäisinä, avoimina ja joustavina palveluina. Lopputulos on modulaarinen kokonaisuus, jossa järjestelmä on paletti toisiinsa kytkettyjä palveluja.

Järjestelmän rakentaminen joukoksi keskenään kommunikoivia ja järjestelmän ulkopuolelle kommunikoivia palveluja muljauttaa esiin rajapinta-teeman. SOA-pohjaisessa järjestelmässä korostuu entisestään hyvin rakennettujen ja hyvin kuvailtujen ohjelmointirajapintojen (application programming interface, API) merkitys.

Ehkä yksi isoimpia perusteluja modulaarisuudelle, paremmille, avoimemmille rajapinnoille on tämä: Keskitetty kirjastojärjestelmä tarjoaa perusinfrastruktuurin kirjastopalvelujen automatisoinnille. Harva valmispaketti tyydyttää 100 %:sti kaikki kirjaston tarpeet, joten APIt mahdollistavat, että kirjastot ja muut asiantuntijat voivat luoda tarvittavia lisätoiminnallisuuksia.

SOA:n plussia ja miinuksia kootusti ovat muun muassa
+ yhteentoimivuus muiden palvelujen kanssa
+ palvelun uudelleenkäytettävyys järjestelmässä
+ avoimuuden mukanaan tuoma järjestelmätoimittajariippumattomuus (vendor lock-in)
+ järjestelmän kehittäminen nopeammin vastaamaan toimintaympäristön muutoksiin
– hallinnollinen haaste: kehittäminen voi olla villiä ja vapaata, mikä on haaste muun muassa muutoksenhallinnalle
– toimintatavan monimutkaistuminen: palvelujen keskinäisen vuorovaikutuksen ja viestien hallinnointi
– avoimuuden tuomat haasteet tietoturvallisuuteen.

Periaatteet käytäntöön: esimerkkejä

dview.us, Shades of Gray https://secure.flickr.com/photos/differentview/3963762281/

Harva asia tässä elämässä on mustavalkoinen. Sen sijaan useimmiten käytössä on koko skaala harmaan eri sävyjä. Tämä skaala löytyy siitä, miten SOA-periaatetta on toteutettu erilaisissa kirjastojärjestelmissä. Breeding (2009) esittelee teoksissaan esimerkiksi nämä järjestelmät eriasteisesti SOA-henkisinä:

• Evergreen: avoimen lähdekoodin kirjastojärjestelmä. Suunniteltu kokonaisuudeksi, joka sisältää keskenään yhteistyötä tekeviä palveluja
• Innovative Interfacesin Millenium: järjestelmässä on komponentteja, joiden toimintaperiaate on SOA-henkinen
• Talis-yrityksen Alto: Alto-kirjastojärjestelmä on vanha (1990-luvulta), ennen SOA-kautta luotu. SOA-rakennetta eli palvelukeskeisyyttä Talis on tuonut Altoon Keystone-alustalla ja talislms-jangle-konnektorilla.

Kuali-projekti

Suosikkiesimerkkini järjestelmäprojekteista on Kuali-säätiön monikansallinen projekti, jossa on mukana korkeakoulujen ja yritysten muodostama yhteisö. Yhteisö rakentaa avoimen lähdekoodin ohjelmistokokonaisuutta korkeakoulutuksen tarpeisiin. Ohjelmistot on julkaistu Educational Community License -lisenssillä, jonka Free Software Foundation määrittelee yhteensopivaksi GNU General Public License versio 3:n kanssa.

Kuali-projekti sisältää useita ohjelmisto-osioita eri tarpeisiin, muun muassa

1. Kuali Financial System (KFS), joka tarjoaa työkalut korkeakoulujen taloushallinnolle
2. Kuali Coeus (KC), joka on tutkimustyön hallinnointityökalu
3. Kuali Student (KS), jolla hoidetaan opiskeluun/opettamiseen liittyviä prosesseja
4. Kuali People Management for the Enterprise (KPME) eli henkilöstöhallintatyökalu
5. Kuali Mobility Enterprise, or Mobility, työkalusarja, jonka avulla mobiililaitteilla voidaan ottaa yhteyksiä organisaation erilaisiin järjestelmiin.

Kuali Open Library Environment (OLE) on projektin kirjastojärjestelmäosuus. Jokainen OLE-komponentti on modulaarinen ja käyttää standardeja rajapintoja. Instituutiot voivat ottaa käyttöönsä ja miksata OLE-komponentteja muiden olemassa olevien sekä avoimen lähdekoodin että kaupallisten järjestelmien kanssa.

Kysynkö “miten?” vai kysynkö “millaisia?”

Alkuperäinen otsikkoni oli “Miten rakennetaan kirjastojärjestelmä – integroiduista järjestelmistä modulaarisuuteen?” ja esitystä rakentaessani tulin siihen tulokseen, että kirjastolaisen roolista MITEN-kysymyksen sijaan on mielekkäämpää pohtia, MILLAISIA kirjastojärjestelmiä rakennetaan.

Matemaattinen kaava tämän leimauksen takana on tämä:

“Kirjastojärjestelmätoimittajia emme ole”
+
“Järjestelmien kehittämistyöhön emme voi konkreettisesti vaikuttaa”

^{[ja konkreettisella tarkoitan sitä, että emme mieti puolipisteen sijaintia lähdekoodissa]}

joten oma mielipide on se, että painavimpia välineitämme vaikuttaa kirjastojärjestelmäkehitystyöhön ovat hyvin ja riittävän yksityiskohtaisesti tehdyt vaatimusmäärittelyt ja kilpailutukset.

Vaatimusmäärityksen yksityiskohtaisuus on kinkkinen kohta. Muun muassa rajapintojen avoimuus vaatii tarkentamista: millä lailla avoin? Kuinka avoin? Ketkä rajapintaa saavat hyödyntää ja miten? Rajapintojen luovuttaminen kolmannen osapuolen käytettäväksi vaatii sekä kirjaston että järjestelmävalmistajan sopimuksen asiasta.

Tuetut standardit on toinen esimerkki: jos vaatimuksena on esimerkiksi “SIP2-tuki”, se jättää runsaasti tulkinnanvaraa kaikille. Väärinkäsityksen välttämiseksi kirjastojen olisi määriteltävä, kuinka täydellisesti se haluaa järjestelmien tukevan SIP2-protokollaa. Järjestelmänvalmistajien puolestaan olisi hyvä kertoa jo etukäteen, kuinka kattavasti järjestelmä tukee protokollaa.

Tämän kuuli myös päivän esityksissä. Homma tuntuu toimivan muualla maailmassa kilpailutusten kautta ja jotta järjestelmänvalmistaja pärjäisi kilpailutuksissa, on tuotteita rakennettava vastaamaan noita vaatimuksia. Valmistajat joutuvat tekemään strategisia uudelleenlinjauksia kehittämistyöhön sen mukaan, miten markkinat elävät. Uudelleenlinjaukset vaikuttavat suoraan siihen, millaista järjestelmää rakennetaan, millaisten ominaisuuksien kehittäminen nostetaan ykkösprioriteetiksi. Kilpailutukset pitäisikin nähdä välineenä vaikuttaa kehitykseen.

Suomessa ollaan toistaiseksi edetty päivityslinjalla. Siinä on omat hyvät ja huonot puolensa. Logiikka päivitysajattelun takana on jossain mielessä ihan ymmärrettävä: vältetään järjestelmähankinnan työläys. Mutta samalla menetämme yhden välineen määritellä yksiselitteisesti ja etukäteen, millaista tuotetta me olemme vailla. Omia tarpeitaan voi toki esittää muullakin tavoin, esimerkiksi kehitystoivein ja palauttein. Itselleni asia hahmottuu puhetapojen muutoksina: vaatimusmäärittelyt + kilpailutus ovat vaatimista, kehitystoiveet ovat toiveita. Niiden velvoittavuudet ovat erilaiset.

Päivityslogiikkaan on helppo päätyä, koska sekä vaatimusmäärittelyt että kilpailutukset ovat isoja hankkeita yksittäisille kirjastoille. Tätä kuormaa voi keventää tiiviimmällä yhteistyöllä kirjastojen kesken.

Tehdyt ja työn alla olevat kotityöt

Määrittelytyössä ei onneksi tarvitse lähteä tyhjältä pöydältä: Joensuu ja Rovaniemi tekevät arvokasta työtä järjestelmäselvitysprojekteissaan. Uusi kirjastojärjestelmä (UKJ) on kolmas järjestelmien problematiikkaa luotaava projekti, jossa selvitetään millainen järjestelmäkokonaisuus soveltuisi kaikille kirjastosektoreillemme. Hommaa viedään eteenpäin isolla koneistolla: eri osa-alueisiin keskittyvät työryhmät pohjustavat ja miettivät työprosesseja ja kriittisiä toimintoja. Tämän pohjalta päätetään projektin jatkosta. Yleisten kirjastojen osallistuminen on suotavaa. Järjestelmäasioista ja UKJ:stä kiinnostuneille suosittelen tutustumista UKJ-wikiin.

Tärkeää työtä on tehty KDK:ssakin muun muassa standardisalkun kokoamiseksi, joka antaa pohjaa standardikeskustelulle.

Hieman eri kulmasta järjestelmäasiaa lähestyy Vaasan kaupunginkirjaston Alueellinen verkkopalvelukonsepti. Konsepti pyrkii linjaamaan käytännön toimia, joilla YKN:n strategia jalkautetaan verkkopalvelujen osalta käytäntöön. Hyvää lukemista on aikoinaan reilusti aikaansa edellä ollut YKN:n verkkostrategia vuodelta 2007.