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ä.

Avatar

Mika Varjus

Mika on kokenut ohjelmistoarkkitehti ja kokonaisarkkitehtuurikonsultti. Hänellä on erityisen laaja kokemus tieto- ja palveluarkkitehtuurien kokonaisvaltaisesta kehittämisestä. Hän on yli seitsemäntoista vuoden työhistoriansa aikana ollut päävastuullisena suunnittelijana useissa kymmenissä eri tietojärjestelmähankkeissa ja omaa toistakymmentä sertifikaattia eri aihealueilta, kattaen mm. ohjelmistotuotannon prosessit ja menetelmät, testauksen, tietokannan hallintajärjestelmät ja sovelluspalvelinympäristöt. Tietovarastoinnista hänellä on CDVP2 - Data Vault 2.0 Certified Practitioner –sertifikaatti.

Linkedin profile

Piditkö lukemastasi? Jaa se myös muille.

Kuten ohjelmistosuunnittelussa, myös projektin hallinnassa turvaudutaan usein huonoihin ratkaisuihin. Projektipäällikön yksi tehtävä onkin reagoida ajoissa, jos projekti ohjautuu väärään suuntaan. Olen koonnut alle muutamia projektin hallintaan liittyviä antisuunnittelumalleja, joihin itse olen työelämässä törmännyt.
Nimi: Koodausta, perkele!
Kuvaus: Kun projekti alkaa jäädä tavoitteistaan jälkeen, unohdetaan prosessimalli ja laaduntarkkailu. Koko projektitiimi keskittyy projektissa vain koodirivien tuottamiseen.
Tunnistaminen: Projektitiimi alkaa laistaa prosessimallin hyvistä käytännöistä. Analyysityökalut kertovat koodilaadun nopeasta heikkenemisestä. Toiminnallisuuksia ei dokumentoida eikä testata. Projektitiimi tekee ylitöitä.
Syy: Projekti on jäänyt aikataulusta jälkeen.
Seuraukset: Järjestelmän laadun heikkeneminen. Tiimin työmotivaation heikkeneminen.
Ratkaisu: Projektin aikataulun pidentäminen. Järjestelmän laajuuden pienentäminen.
Nimi: Prosessimallismi.
Kuvaus: Projekti on uskollinen tietylle prosessimallille, joka on usein ainoa minkä projektipäällikkö osaa. Projektiiimi, asiakas ja toteutettava järjestelmä vaatisivat kuitenkin erilaista lähestymistapaa.
Syy: Projektipäällikön kokemattomuus. Projektipäällikön aiempi onnistuminen valitulla prosessimallilla.
Tunnistaminen: Tiimin jäsenet ja asiakas kritisoivat prosessimallin käytäntöjä jatkuvasti. Projekti ei pääse flow-vaiheeseen1 missään vaiheessa.
Seuraukset: Tiimin työmotivaation heikkeneminen. Projektin aikataulun ylitys.
Ratkaisu: Projektipäällikön tutustuminen eri prosessimallien hyviin ja huonoihin piirteisiin kirjallisuuden ja koulutusten avulla. Huolelliset retrospektiivit2.
Nimi: Jumalatiimiläinen.
Kuvaus: Projektissa tekninen osaaminen ja hiljainen tieto ovat keskittyneet tietylle projektin henkilölle.
Syy: Väärin allokoidut työtehtävät. Vääränlainen projektitiimi. Kokematon projektipäällikkö.
Tunnistaminen: Muiden projektitiimiläisten jatkuva avuntarve. Projekti ei pääse flow-vaiheeseen missään vaiheessa.
Seuraukset: Projektin aikataulun ylitys. Tiimin työmotivaation heikkeneminen.
Ratkaisu: Hiljaisen tiedon siirtäminen muulle projektitiimille esimerkiksi dokumentoinnin, koulutusten ja pariohjelmoinnin3 avulla. Projektityökalujen vaihtaminen/kehittäminen tiedonvaihtoa paremmin tukevaksi.
Nimi: Homeopaattinen projektipäällikkö.
Kuvaus: Valitaan hyvä projektitiimi ja toimiva prosessimalli projektille. Projektipäällikkö ei kuitenkaan hoida työtehtäviään.
Syy: Huonosti motivoitunut projektipäällikkö. Projektipäällikkö allokoitu muihin työtehtäviin.
Tunnistaminen: Yleinen epätietoisuus projektin tilasta ja suunnasta. Projektipäällikkö usein tavoittamattomissa. Projektitiimi tekee projektipäällikön työtehtävät.
Seuraukset: Tiimin työmotivaation heikkeneminen. Projektin aikataulun ylitys.
Ratkaisu: Avoin keskustelu projektipäällikön ja hänen esimiestensä kesken. Projektipäällikön projektin ulkopuolisten työtehtävien minimointi. Projektipäällikön vaihtaminen.
Nimi: Asiakas on aina oikeassa.
Kuvaus: Unohdetaan muut projektiin liittyvät rajoitukset ja tehdään kaikki, mitä asiakas ehdottaa ja haluaa.
Syy: Kokematon projektipäällikkö. Asiakkaalla liian suuri vaikutusmahdollisuus toimittajaan.
Tunnistaminen: Asiakkaan ehdottamat muutokset priorisoituvat aina muiden tehtävien edelle. Projektitiimillä monta työtehtävää kesken yhtä aikaa.
Seuraukset: Kannattamaton projekti. Projektin aikataulun ylitys.
Ratkaisu: Avoin keskustelu asiakkaan kanssa muutostenhallinnasta. Toimivan muutostenhallintaprosessin suunnittelu ja käyttöönotto. Projektin sopimusmallin muuttaminen tuntipohjaiseksi.
Nimi: AD/HD
Kuvaus: Projektipäällikkö osallistuu kaikkeen projektissa tapahtuvaan toimintaan. Tiimin jäseniä ei vastuuteta.
Syy: Projektipäällikön kokemattomuus. Projektitiimin kokemattomuus. Projektipäällikön vahva tekninen tausta.
Tunnistaminen: Projektipäällikkö osallistuu projektin jokaisen ongelman ratkaisuun. Projektipäällikkö tekee jatkuvasti ylitöitä.
Seuraukset: Projektipäällikön työuupumus
Ratkaisu: Avoin keskustelu projektipäällikön ja muun projektiryhmän välillä projektin roolituksista. Projektipäällikön ja muun projektitiimin tutustuminen eri prosessimallien hyviin ja huonoihin piirteisiin kirjallisuuden ja koulutusten avulla.
Nimi: Päällikkö sinisilmä
Kuvaus: Projektipäällikkö keskittyy vain projektin sisäisiin tehtäviin eikä kommunikoi johdon suuntaan riittävästi. Organisaatiossa huomio kiinnittyy muihin projekteihin.
Syy: Johdon kokemattomuus. Projektipäällikön kokemattomuus.
Tunnistaminen: Projektitiimin ja johdon välillä on näkemyseroja siitä, missä tilassa projekti on. Projektitiimin ja johdon välillä on näkemyseroja siitä, mikä on johtanut projektin onnistumiseen/epäonnistumiseen.
Seuraukset: Johto tekee projektista vääriä johtopäätöksiä. Tiimin työmotivaation heikkeneminen.
Ratkaisu: Kommunikointisääntöjen suunnittelu ja toteutus projektipäällikön ja johdon välille. Säännöllinen lobbaus projektin tilasta muulle organisaatiolle.
Blogisarjani viimeisessä kirjoituksessa annan ohjeita juuri työnsä aloittaville projektipäälliköille. Lue myös blogisarjan muut osat: Hyvä projektipäällikkö: kommunikoija ja päätöksentekijä, Prosessimallit eivät ole hopealuoti ohjelmistoprojektien onnistumisessa ja Projektitiimi: projektin tärkein resurssi.
1 flow-vaihe tarkoittaa projektin yhteydessä vaihetta, jolloin projektitiimin tuottavuus on tehokkaimmillaan. Flow-vaihe alkaa, kun projektitiimi hitsautunut yhteen ja suurimmat projektin tekniset haasteet on ratkaistu.
2 itse olen havainnut hyväksi retrospektiivimalliksi James Shoren and Shane Warden kuvaaman mallin: The Art of Agile Development: Retrospectives
3 pariohjelmoinnissa kaksi ohjelmistosuunnittelijaa työskentelee yhdessä, yhtä tietokonetta käyttäen. Pariohjelmointi on tehokkainta projektin alussa, uuden henkilön liittyessä projektiimiin tai kun hiljaista tietoa halutaan nopeasti siirtää toiselle henkilölle.

Avatar

Juhana Huotarinen

Juhana on kokenut ohjelmistoprojektien vetäjä, joka on erikoistunut Lean-ajattelun ja ketterien menetelmien käyttöönottoon suurissa julkisen sektorin tietojärjestelmähankkeissa. Viime vuosina hänet on pitänyt kiireisenä mm. Trafi, Valtori (Valtiokonttori), Opetushallitus, Kela ja Liikennevirasto. Aiemmin työurallaan Juhana on toiminut myös projektipäällikkönä ja ohjelmistosuunnittelijana. Juhanan ajatuksia voi lukea lisää hänen asiantuntijablogeistaan sekä Twitteristä.

Linkedin profile

Piditkö lukemastasi? Jaa se myös muille.