Viime viikkojen kuuma puheenaihe on ollut Helsingin Seudun Liikenteen jättiläismäinen 90 miljoonan euron palvelukeskeiseen arkkitehtuuriin (SOA) perustuva it-hankinta. Keskustelua ovat herättäneet erityisesti tarjousten erittäin suuret hintaerot sekä viiden toimittajan hylkäykset seitsemästä tarjoajasta. Hylkäyksien syitä ei ole annettu tarkemmin julkisuuteen, mutta jotain voi kuitenkin päätellä hylättyjen joukossa olleen Initin valituksesta markkinaoikeudelle.
Hylkäysperusteena HSL:llä oli näkemysero Initin toteuttamien referenssitoteutusten palvelukeskeisyydestä. HSL viittasi vastineessaan markkinaoikeudelle myös KuntaIT:n kuntasektorin SOA-teknologialinjauksiin ja lainasi sieltä muutamia kirjoittamiani kappaleita palvelukeskeiseen arkkitehtuurin liittyen. Markkinaoikeus kumosi HSL:n päätöksen ja velvoitti HSL:n ottamaan Initin mukaan tarjouskilpailuun. Hieman ikäväkseni pitää myös todeta, että markkinaoikeus tulkitsi kirjoittamaani oikeammin ja ratkaisu oli mielestäni kyllä aivan oikea.
Uskon kuitenkin, että HSL:llä on ollut täysin perusteltu syy uskoa, etteivät kaikki toimittajien esittämät refenssitoteutukset vastaa heidän käsityksiään SOA:sta ja siten hankkeelle asetetut keskeiset tavoitteet jäävät toimittajien esittämissä SOA-tulkinnoissa saavuttamatta.
Mikä kilpailutuksessa sitten meni pieleen? Mitkä keskeiset asiat jäivät HSL:n hankintailmoituksesta puuttumaan? Mitä asioita hankintaorganisaation pitäisi palvelukeskeisten järjestelmähankintojen tarjouspyynnössä huomioida? Alla on tähän muutamia vinkkejä.
Palvelukeskeisten järjestelmien hankintoja on hyvä tarkastella vähintään seuraavista näkökulmista:
• Arkkitehtuurivaatimukset
• Palveluarkkitehtuurin hallinta ja ylläpito
• Teknologiat
• Yrityksen kokonaisarkkitehtuuri ja suhde SOA:aan.
Kaikkien näkökulmien tarkastelu on kuitenkin liian laaja tässä blogissa käsiteltäväksi, joten keskityn tässä blogauksessa arkkitehtuurivaatimuksiin.
Arkkitehtuurivaatimukset
Arkkitehtuurivaatimuksien määrittely epäonnistuu uskomattoman usein palvelukeskeisten järjestelmien hankinnoissa. Tämä oli myös HSL:n hankintailmoituksen kompastuskivi. SOA:sta on monenlaista tulkintaa, minkä vuoksi on ensisijaisen tärkeää kuvata tarjouspyynnössä mitä hankintaorganisaatio SOA:lla tarkoittaa. Helpoiten tämä onnistuu liittämällä SOA-teknologialinjaukset tarjouspyyntöön ja viittaamalla vaatimuksissa haluttuihin kohtiin linjauksista. Tarkemmat viitaukset dokumentin lukuihin ovat joissakin kohdin tarpeen siksi, että linjaukset sisältävät vaatimusten lisäksi myös suosituksia ja esimerkkejä.
HSL:n tapauksessa tähän olisi riittänyt pari lausetta, joissa olisi vaadittu linjausten noudattamista referenssitoteutusten kaikilta osin ja vaadittu SOA-kerrosten toteuttamista linjauksissa kuvatulla tavalla. HSL viittasi SOA-teknologialinjauksiin ensimmäisen kerran kuitenkin vasta vastineessaan markkinaoikeudelle, minkä vuoksi linjauksia ei voinut käyttää hylkäysperusteena.
Arkkitehtuurivaatimusten lähtökohdaksi kannattaa asettaa teknologialinjausten SOA-palveluvaatimukset. Näitä ovat mm. palveluiden uudelleenkäytettävyys ja koostettavuus. Välillä näiden tavoitteiden arvioinnissa ylikorostuu ESB-tuotteen käyttö. ESB on kuitenkin vain yksi toteutustapa eikä sen käyttö takaa toteutuksien palvelukeskeisyyttä. Myös markkinaoikeuden päätöksessä otettiin tähän asiaan kantaa. HSL on yhtenä hylkäysperusteistaan maininnut ESB:n käytön puuttumisen referenssitoteutuksista, mihin niin vastapuoli kuin markkinaoikeus puuttuivat voimakkaasti. Markkinaoikeus toteaa ratkaisussaan, ettei HSL ole voinut käyttää ESB:n puuttumista hylkäysperusteena, koska SOA-toimitus ei välttämättä edellytä ESB:n käyttämistä. Tämä on aivan oikea havainto eikä ESB:n käyttöä pidä sotkea arkkitehtuurivaatimuksiin. Teknologialinjausten SOA-palveluvaatimukset edellyttävät, että palveluiden pitää olla karkeustasoltaan erilaisia ja toisistaan koostettavissa, mikä edellyttää toteutukselta palveluiden kerrostamista. Tämä voidaan tehdä kuitenkin ilman palveluväylää, mikäli vain palveluvaatimusten toisesta vaatimuksesta eli palveluiden välisistä löyhistä kytköksistä huolehditaan riittävällä tasolla. ESB:n käyttöä suosittelen tarkastelemaan ennen kaikkea keskitetyn hallinnan ja ylläpidon näkökulmasta.
Palveluiden uudelleenkäytettävyyden arvioinnissa kannattaa tarkastella erityisesti tietokerroksen käsittelyä ja selvittää tapahtuuko se aina SOA-palveluiden kautta. Tyypillisesti järjestelmät, joissa SOA-palveluita käytetään pelkästään ulkoisiin integraatioihin, käyttävät sisäisesti tietokerrosta SOA-palveluiden ohi. Arviointia varten toimittajilta kannattaa pyytää arkkitehtuurikerroksien kuvaukset referenssitoteutuksista ja selvitys teknologialinjausten mukaisten SOA-palvelukerrosten ja tietokerroksen käytöstä tietojärjestelmässä.
