Verottajan uudet IT-kujeet

Verohallinnossa on lähdössä käyntiin massiivinen IT-projekti, jossa uudistetaan lähes kaikki verotuksessa käytettävät tietojärjestelmät. Verohallinnon nykyinen tietojärjestelmäkenttä on monimutkainen ja hajanainen, mikä aiheuttaa ylläpitoon kustannuspaineita (ylläpidon kokonaiskustannukset ovat 40 miljoonaa euroa vuodessa). Verohallinnon tietojärjestelmäuudistusprojekti tulee olemaan noin viisivuotinen ja budjetiltaan kymmeniä miljoonia euroja.

Uudistuksella tavoitellaan verohallinnon tietojärjestelmien kokonaiskustannuksista (total cost of ownership) leijonan osan muodostavien ylläpitokustannusten alentamista 20-40%. Lisäksi tavoitteena on parantaa tietojärjestelmien ketteryyttä (time-to-live) sekä pyrkimys kasvattaa verovirkailijoiden työn tuottavuutta (productivity).

Erityisen verohallinnon projektista tekee sen suuren koon lisäksi ratkaisun pohjaaminen kaupallisiin valmisohjelmistoihin (commercial-of-the-shelf, COTS). Valmisohjelmistoilla pyritään ratkaisun sisäiseen standardointiin ja rakentamaan järjestelmä, joka on muuallakin vastaavan laajuisessa vaativassa käytössä.

Tarkoituksena on valjastaa suuri määrä valmisohjelmistoja verohallinnon tarpeisiin. Haasteen asettaa se, että mikään valmisohjelmisto ei luonnollisesti voi suoraan paketista tukea suomalaisen verohallinnon prosesseja, joten tarvitaan ratkaisujen räätälöintiä. Julkisuudessa lausuttujen tavoitteiden mukaan räätälöinnit pyritään minimoimaan, mutta kysymys kuuluukin, miten tämä käytännössä saavutetaan?

Kun projektin tavoitteena on toteuttaa tietojärjestelmä valmisohjelmistoilla, hyvän ratkaisuarkkitehtuurin (solution architecture) suunnittelu sekä projektin laajuuden hallinta (scope management) ovat avainasemassa. Tavoitteena on, että valmisohjelmistojen ominaisuuksia käytetään optimaalisesti ja ratkaisun räätälöintiä tehdään sopivasti.

Ratkaisuarkkitehtuurin tulee määritellä, millä valmisohjelmistolla kukin kokonaisratkaisun toiminnallinen vaatimus (functional requirement) toteutetaan, miten ei-toiminnalliset vaatimukset (non-functional requirement) otetaan huomioon, huolehtia valmisohjelmistojen keskinäisestä yhteensopivuudesta (interoperability) sekä tarpeen mukaan määritellä täydentäviä ratkaisun komponentteja, jotka eivät perustu valmisohjelmistoihin. Ratkaisuarkkitehtuurin puutteellisuudesta johtuvia tyypillisiä ongelmia ovat valmisohjelmistojen epäselvät tehtävät, epärealistiset ei-toiminnalliset vaatimukset, valmisohjelmistojen yli- tai aliräätälöinti tai niiden yhteensopimattomuus.

Projektin laajuuden hallinnan tulee pitää huolta, että tietojärjestelmän kokonaisuudistustavoitteesta huolimatta ei sorruta valmisohjelmistojen yliräätälöintiin. Joskus projektin tilaaja (liiketoiminta) voi nähdä, että projektin suuri koko oikeuttaa myös toiminnallisten vaatimusten monimutkaistamisen tai lukumäärän kasvattamisen, jopa projektin aikana. Tämä on usein myös toimittajan intressi, koska se tietää toimittajalle lisää työtä. Tällaisessa tilanteessa projektipäällikön ja projektiohjausryhmän tulee kysyä: onko todella niin, että valmisohjelmiston standardina (tai pienellä räätälöinnillä) tarjoama toiminnallisuus ei riitä, vaan suurempaa räätälöintiä todella tarvitaan. Päätöksissä on tärkeää huomioida, että räätälöimällä ratkaisua menetetään joka askeleella valmisohjelmistojen tuomia ratkaisun standardointiin ja ylläpitokustannusten alentamiseen liittyviä hyötyjä.

Verohallinnon edellinen tietojärjestelmäuudistus 1990-luvulla tuotti kansalaisille sähköisen veroehdotuksen ja jatkokehitys 2000-luvulla on entisestään parantanut verohallinnon sähköisiä palveluita. Verohallinnon aiempia uudistusprojekteja voisi pitää jopa julkishallinnon malliesimerkkinä asiakasprosesseista lähtevästä tietojärjestelmäkehityksestä. Toivotan verohallinnolle ja toimittajille voimia ja onnea seuraavaan vaativaan hankkeeseen!

Lisätietoa: Tietoviikko

IT tulee töpselistä, eikun pilvestä

Muutamia vuosia sitten alkanut pilvilaskenta-trendi ei ota laantuakseen. Trendin huipulla suurten IT-talojen johtajat parhaimmillaan (tai pahimmillaan) yksinkertaistivat pilvilaskennan siten, että pilvet tekevät IT:sta yhtä helppokäyttöistä kuin sähkö. Vertaus on ihailtavan visionäärinen, mutta pilvilaskentaan liittyy vielä runsaasti sekä hallinnollisia että teknisiä käytännön haasteita.

Mitä pilvilaskenta sitten oikein on? Pilvilaskenta tarkoittaa tietoteknisen palvelun suorittamista palvelun käyttäjälle läpinäkymättömässä virtuaalisessa ympäristössä. Pilvipalvelun käyttäjä ottaa yhteyden palveluun tietoverkon yli. Pilvipalvelut jaetaan hierarkkisesti kolmeen luokkaan (edeltävä taso sisältää jälkimmäiset tasot): 1) Software as a Service (SaaS), 2) Platform as a Service (PaaS), 3) Infrastructure as a Service (IaaS).

Pilvilaskenta ei ole sama asia kuin palvelinten virtualisointi, jossa yksittäinen fyysinen palvelin abstrahoidaan käyttöjärjestelmän kannalta näkymättömäksi. Jo alimmalla IaaS-tasolla pilvipalvelu abstrahoi koko fyysisen infrastruktuurin sisältäen tallennusratkaisut ja verkon konfiguraatioineen. Ylimmällä SaaS-tasolla abstraktio ulottuu aina sovellustasolle asti.

Käytännön esimerkki SaaS-pilvipalvelusta on internet-sähköposti, joka ei vaadi mitään asennuksia käyttäjän koneelle internet-selainta lukuunottamatta. PaaS-pilvipalvelu puolestaan voi olla esimerkiksi webhotelli, jonne käyttäjä voi luoda internet-sivut (HTML), ohjelmoida dynaamista sisältöä (esim. PHP) ja rajoitetusti asentaa ohjelmistoja (kuten tietokanta tai blogi). IaaS-pilvipalvelu sen sijaan tarjoaa vain teknisen virtuaalisen ympäristön, mutta kaikki ohjelmistot ovat käyttäjän vastuulla.

Pilvipalveluilla voidaan korvata perinteisiä konesaleja ja liiketoimintasovelluksia sekä tehostaa palvelutuotantoa. Kapasiteetinhallinnan näkökulmasta pilvipalveluiden arvolauselma on ilmeinen: 1) fyysisen infrastruktuurin ja alustojen hankinta- ja ylläpitokustannus on toimittajan volyymiedun ansiosta matalampi, 2) toimittajan kapasiteettijouston ansiosta muutoksia on mahdollisuus tehdä nopeasti tilannekohtaisen tarpeen mukaan, 3) toteutunut kustannus perustuu todelliseen käyttöön ja kiinteä kustannuskomponentti on ennakoitavissa.

Haasteita pilvipalveluiden käyttöönotolle asettavat kuitenkin siihen liittyvät migraatiokustannukset sekä yritysten riskienhallinnalliset vaatimukset. Peruskysymys on, miten ulkoisia pilvipalveluja tulisi ylläpitää ja hallinnoida, jotta laadulliset vaatimukset täyttyvät hyväksytyllä riskitasolla, mutta kuitenkin kustannusedut saavutetaan. Kaikkia liiketoimintasovelluksia ei voida teknisistä, integraatio- tai suorituskykysyistä siirtää ulkoiseen pilvipalveluun.

Yhtenä ratkaisuna pidetään esim. nk. hybridimallia, jossa osa pilvipalveluista tuotetaan yrityksen sisäisestä pilvestä ja osa ulkoisesta pilvestä palvelukohtaisista kustannussäästömahdollisuuksista ja vaatimuksista riippuen. Aina sovelluksia jää myös kokonaan pilvien ulkopuolelle. Erityisesti ulkoisten pilvipalveluiden hallinnoinnissa tulee kiinnittää erityistä huomiota tietoarkkitehtuuriin, selkeisiin tietoturvalinjauksiin, oikean palvelutason valintaan.

Pilvilaskennan kehitys tulee jatkumaan ja se tulee varmasti jäämään osaksi yritysten IT-arkkitehtuureita ja palvelutuotantomalleja. Viimeksi tällä viikolla Forrester hämmensi keskustelua väittämällä, että pilvilaskenta ei olekaan IT:n tulevaisuus – ainakaan kokonaisuudessaan. Aika näyttää.

Lisätietoa: cio.com