Olen aktiivinen mobiili-internetin käyttäjä ja minua harmittaa. Aktiivisena käyttäjänä törmään usein verkkopalveluihin, jotka eivät tue mobiilikäyttöäni. Tilanteeni ja laitteeni huomioonottavan verkkopalvelun sijaan joudun kahlaamaan läpi isoja sivuja zoomaillen ja haluamani löytäminen on hankalaa. Joskus taas mobiililaitteeni kysyy, haluanko avata sivun mobiiliversion, jolloin uskoisin kadottavani jotain sivun sisällöstä. Kuulostaako tutulta? Erityisesti minua kuitenkin harmittaa, kun tiedän, ettei näin tarvitsisi olla.
Verkkopalvelun käyttöliittymän mukauttaminen erilaisille päätelaitteille on mahdollista. Se on jopa yksinkertaista. Tämä ei tarkoita, että sivuista luotaisiin erilliset mobiilisivut tai jopa erillinen mobiilisovellus. Se ei vaadi käyttäjältä valintaa siitä, haluaako hän käyttää sivujen mobiiliversiota. Sen sijaan ammattitaitoisesti toteutetut responsiiviset, eli mukautuvat, verkkopalvelut mahdollistavat palvelun sujuvan käytön kaikilla päätteillä – tietokoneella, tabletilla ja mobiililaitteella. Yksi verkkopalvelu, joka mukautuu kuhunkin näyttökokoon.
Yksinkertaiset ja ilmaiset kehykset, kuten suosittu Bootstrap, tarjoavat erinomaiset työkalut responsiivisen verkkopalvelun luomiseen. Näiden avulla toteutettuna lopputuloksena on verkkopalvelu, joka mukautuu jokaiseen näyttökokoon.  Hyvänä esimerkkinä responsiivisesta verkkopalvelusta toimivat yrityksemme nettisivut, joita juuri nyt katselet. Suosittelen kokeilemaan sivuja tietokoneella erikokoisilla selainikkunoilla, tabletilla ja älypuhelimella. Responsiivisuus on tässäkin tapauksessa saavutettu käyttämällä tukena valmista kehystä, joita löytyy mitä moninaisimpia ja uusia eri käyttötarkoituksiin sopivia tulee jatkuvasti lisää.
Ehkä aavistatkin, että mobiili-internetin käyttö ei ole ainoastaan minun juttuni. TNS Gallupin tuoreen tutkimuksen mukaan jo 45% suomalaisista käyttää sosiaalista mediaa matkapuhelimellaan. Lisäksi jo 17 % on sitä mieltä, että he turvautuvat tiedon etsinnässä mieluummin mobiili-internettiin kuin myyjään. Avanaden teettämä kysely taasen osoitti, että jopa 64% suomalaisyrityksistä työntekijöiden enemmistö käyttää älypuhelintaan työtehtävien hoitamiseen. Kehitys ei varmastikaan pysähdy tähän ja olipa kyseessä vapaa-aika tai työympäristö, verkkopalveluiden käyttö mobiililaitteilla tulee varmasti lisääntymään. Yhä useampi käyttäjä on siis harmistunut, kuten minä.
Tämä on myös varmasti se hetki, jolloin joku lukija ajattelee: ”Mutta meillä ei käytetä mobiililaitteita ja meillä on isot näytöt. Kyllä niihin mahtuu.”. Iso näyttökoko ei kuitenkaan ole tae sille, että käyttäjäkokemus olisi toivotunlainen ilman responsiivista toteutusta. Isot näytöt mahdollistavat useamman ikkunan aukiolon samalla näytöllä. Tällöin selainikkunan koko saattaa olla muu kuin, mille perinteinen verkkopalvelu on suunniteltu. Tällaisessa tilanteessa verkkosivu ei joko mahdu selainikkunaan tai käyttäjä joutuu joustamaan tarpeistaan ja isontaa selainikkunaa. Tällaisessakin tapauksessa responsiivinen verkkopalvelu kykenisi mukautumaan käyttäjän tarpeeseen ja käyttäjä voi pitää selainikkunan juuri sellaisen kokoisena kuin haluaa. Lisäksi responsiivinen toteutus mahdollistaa ylimääräisen tilan tehokkaamman käytön, jos käyttäjä käyttää verkkopalvelua isolla näytöllä ja täydellä ruudulla. Responsiivivuus mahdollistaa joustavuuden molempiin suuntiin.
Vaikka olenkin nyt puhunut käyttöliittymän joustavuudesta, mobiiliystävällisyys on kuitenkin muutakin. Todellinen mobiiliystävällisyys saavutetaan vasta, kun otetaan huomioon kunkin päätelaitteen käyttökonteksti ja tarpeet kussakin kontekstissa. Tyypillisesti käyttäjien tarpeet toimistolla palvelua käyttäessä ovat erilaiset kuin heidän tarpeensa esim. mobiilitilanteessa. Pelkkä näyttökokoon mukautuva verkkopalvelu ei ota tätä huomioon ja käyttäjä ei edelleenkään saa sellaista käyttäjäkokemusta, mikä hänelle oli mahdollista tarjota. Kun käyttäjien tarpeet eri konteksteissa tunnetaan, voidaan mainitsemiani kehyksiä hyödyntäen muodostaa verkkopalvelu, joka myös järjestää käyttöliittymäelementtejä sen mukaan, minkä laitteen kautta palveluun tullaan.
Kauppakeskus Citycenterin verkkopalvelu, jota Gofore on ollut toteuttamassa, on erinomainen esimerkki juuri tällaisesta mobiiliystävällisestä verkkopalvelusta. Sen lisäksi, että verkkopalvelu mukautuu eri näyttökokoihin vanhemmista älypuhelimista lähtien, niin palvelu huomioi tietotarpeet eri käyttökonteksteissa. Palvelu mm. nostaa aukioloajat ja yhteystiedot mobiilikäytössä selkeämmin esille, sillä se todettiin käyttäjätutkimuksessa erityistarpeeksi juuri mobiilikäytössä.
Kuten huomaat, ammattitaitoisesti toteutettuna verkkopalvelu voi nykyisin olla aidosti mobiiliystävällinen. Mutta mitä tarkoittaa tämä ’ammattitaitoinen’, jota käytän tässä jutussa usein? Mielestäni aidosti mobiiliystävällisen verkkopalvelun muodostaminen vaatii seuraavat ammattitaitoiset osaajat:

  • Käyttäjäkokemusasiantuntija, joka selvittää eri käyttökontekstien erityistarpeet
  • Käyttöliittymäsuunnittelija, joka suunnittelee responsiiviseksi soveltuvan käyttöliittymän
  • Sovelluskehittäjä, joka hallitsee eri kehysten käytön ja osaa toteuttaa responsiivisen verkkopalvelun

Mutta oletko kenties jo ehtinyt teettää itsellesi verkkopalvelun, joka ei ole responsiivinen? Älä heitä vielä kirvestä kaivoon, sillä on mahdollista, että tilanne on korjattavissa. Mainitsemani Kauppakeskus Citycenterin verkkopalvelu ei aiemmin ollut responsiivinen. Ammattitaitoisella työllä niistä kuitenkin saatiin jälkikäteen responsiiviset, ilman merkittäviä lisäkustannuksia tahi sivuston toteuttamista uudestaan. Luonnollisesti kuitenkin suosittelen, että työ mobiiliystävällisyyden hyväksi aloitetaan heti projektin alussa.
 

Avatar

Arto Puikkonen

Arto on kokenut palveluiden muotoilija ja UX-suunnittelija. Hän on urallaan huolehtinut kymmenien web-, mobiili- ja työpöytäsovellusten muotoilusta. Arton ydinosaamista ovat käyttäjätyö sen moninaisimmissa muodoissaan sekä käyttöliittymäsuunnittelu. Goforella Arto vastaa yrityksen muotoilupalveluista

Linkedin profile

Piditkö lukemastasi? Jaa se myös muille.

Ohjelmistojen kehittäminen poikkeaa monesta tekniikan alasta merkittävästi abstraktin luonteensa takia. Kaikkein monimutkaisimmat insinöörien rakennelmat löytyvät tietojärjestelmistä; kompleksisimmatkaan perinteisen tekniikan alojen kuten kone- tai rakennustekniikan rakennelmat eivät pääse monimutkaisuudessa lähellekään ohjelmistotekniikkaa. Ohjelmistotekniikassa on myös huomattavasti vaikeampi hahmottaa rakennettavan asian koko ja monimutkaisuus.

Kuka tahansa näkee, että pilvenpiirtäjä tai Juutinrauman silta on paljon suurempi ja haastavampi rakennelma kuin omakotitalo tai Hämeensilta tai että uuden automallin suunnittelu ja valmistus vaatii enemmän työtä ja maksaa enemmän kuin polkupyörän. Ulkopuolisen on vaikea tietää pitäisikö tietojärjestelmän toteutuksen kestää vuosia vai kuukausia ja pitäisikö sen maksaa miljoonia vai kymmeniä tuhansia.
Toinen ero ohjelmistotekniikassa konkreettisiin tekniikan aloihin on tuotantotyön ja tuotantotyöläisten puuttuminen; ohjelmistojen rakentamiseen liittyvä työ on suunnittelutyötä. Usein käytetty – ja Goforenkin käyttämä – analogia rakennustekniikkaan voi monesti olla harhaanjohtava. Ohjelmistotuotannossa ei ole kirvesmiehiä tai liukuhihnatyöntekijöitä, koska kokoonpanotyön hoitaa tietokone. Toki suunnittelutyötä on erilaista ja jos analogiaa rakennustekniikan puolelle halutaan hakea, niin voitaisiin verrata vaikka yleiskaava-, asemakaava-, rakenne- ja sähkösuunnittelun eroja.
Tässä blogissa keskityn erityisesti ohjelmiston tuotantotyöhön eli siihen rutiininomaiseen osuuteen, jonka tietokone tekee ihmisen puolesta, ja miten se hoidetaan automaattisesti palvelinpohjaisia ohjelmistoja rakennettaessa. Tällaisia ovat suurin osa nykyään käytetyistä yritys- ja kuluttajajärjestelmistä sekä julkishallinnon järjestelmistä. Käyttöliittymänä on useimmiten WWW-selain tai mobiililaite.

Automaatio kehitysympäristössä

Ohjelmistokehityksessä pääosissa on suunnittelu, jossa formaalilla tavalla kerrotaan tietokoneelle mitä sen pitää tehdä. Tämä tehdään käyttäen ohjelmointikieliä, markup-kieliä ja erilaisia ohjelmistokehitystyökaluja. Ohjelmointi sekä työkalujen käyttö ja konfigurointi on suunnittelutyötä. Formaalin suunnitelman eli ohjelman muuttamisen lopulliseksi ajettavaksi järjestelmäksi hoitaa tietokone suunnittelijan formaalien ohjeiden mukaan.
Kehittämiseen liittyy olennaisena osana kehitysympäristön työkalujen, ohjelmistojen ja palvelinten valitseminen ja näiden asentaminen. Ensimmäistä kertaa tehtäessä tämä on ilman muuta suunnittelutyötä, mutta toistuessaan voi muodostua rutiiniksi. Tietotekniikassa on se mukava puoli, että kaikki rutiinit voidaan ja pitää automatisoida, niin tämäkin.
Tietojärjestelmän kehitysympäristö pitää saada pystyyn parissa minuutissa kun mukaan lasketaan kehittäjän aktiivinen työaika; kalenteriajassa aikaa voi kulua muutamia minuutteja enemmän. Kehitysympäristöllä tarkoitan kaikkia kyseisen järjestelmän kehittämiseen liittyviä välttämättömiä ja hyödyllisiä välineitä mahdollisesti käyttöjärjestelmästä lähtien ja sisältäen esimerkiksi kääntäjän, IDEn, sovelluspalvelimen, tietokannat, sähköpostipalvelimen, palveluväylän, ldap-palvelimen, mahdolliset vpn-yhteydet kehitysverkkoon, mallinnustyökalun, sql -työkalun. Näiden asentamiseen liittyvä suunnittelutyö toki vie aikaa, mutta tämä tehdään vain kerran jonka jälkeen ympäristö on kaikkien, myös uusien kehittäjien käytettävissä parissa minuutissa.
Kehitystyökalut ja varusohjelmistot tai niiden versiot usein vaihtuvat kesken järjestelmän rakentamisen, mutta se ei ole ongelma. Päivitys tehdään kerran, jonka jälkeen uusi kehitysympäristö päivitettyine työkaluineen on saatavissa jokaisen kehittäjän käyttöön automaattisesti yhdellä komennolla. Kehittäjä voi tarvittaessa myös tehdä valintoja kehitysympäristössä käytössä olevista työkaluista ja vaikuttaa sen konfiguraatioon. Ympäristö on kuitenkin standardoitu ja tärkeimmiltä osiltaan samanlainen kaikkien kehittäjien kesken.

Jatkuva integraatio ja testaus

Yksittäisten kehittäjien työ integroituu yhteen toisten työn kanssa versionhallinnan ja jatkuvan integraation (CI) palvelimen kautta. Tämän tulee tapahtua nopeassa syklissä, tyypillisesti useita kertoja päivässä. CI-palvelin tekee automaattisesti järjestelmän rakennukseen liittyvät toimet (build) eli kääntää lähdekoodin, ajaa testit (mm. yksikkö- ja integraatiotestit) ja laskee järjestelmän metriikan. Build tuottaa myös järjestelmän ajettavan version, joka asennetaan automaattisesti jatkuvasti päivittyvään testiympäristöön. Järjestelmästä on siis aina testattavissa uusin ja tuorein versio. Automaattinen asennus sisältää myös järjestelmän tietokannan ja siihen tarvittavat migraatiot.
Rakennettavan järjestelmän automaattisen asennuksen lisäksi myös itse testiympäristö käyttöjärjestelmineen, varusohjelmistoineen ja konfiguraatioineen asennetaan ja päivitetään automaattisella prosessilla.
Jatkuvasti päivittyvän testiympäristön lisäksi tarvitaan pysyvämpi testiympäristö, jonne järjestelmän versio asennetaan ihmisen päätöksestä “nappia painamalla”. Uusi stabiili versio voidaan asentaa aina esimerkiksi kehitysiteraation päätteeksi. Järjestelmän asennus tapahtuu saman automaation avulla kuin jatkuvasti päivittyvän testiympäristön kanssa ja ilman muita manuaalisia toimenpiteitä kuin napin painaminen.
Myös pysyvä testiympäristö asennetaan ja päivitetään automaattisella prosessilla. Ympäristöjen väliset erot on kuvattu ympäristökohtaisessa konfiguraatiossa.
Jatkuvan testiympäristön ja tuotantoympäristön välissä voi olla useita muitakin testausympäristöjä. Tärkeimpänä näistä on staging-ympäristö, joka vastaa tuotantoympäristöä täysin mm. palvelinten klusteroinnin ja kuormantasauksen osalta.
Lienee jo selvää, että sekä kaikki järjestelmän asennukset kaikkiin ympäristöihin että ympäristöjen asennukset tapahtuvat automaattisesti ilman manuaalisia toimenpiteitä. Kaiken pohjana on sama suunnittelutyö, joka suurimmalta osalta on tehty jo kehitysympäristön ja ensimmäisen testiympäristön synnyttyä. Uusia ympäristöjä saadaan hetkessä pystyyn lähes rajaton määrä.

Tuotanto

Oleellista on, että myös tuotantoympäristöä koskee sama automatiikka kuin muita ympäristöjä. Järjestelmän tuotantopäivitys on yhtä kevyt operaatio kuin päivitys testiympäristöön. Järjestelmä on päivitettävissä tuotantoon automaattisesti napin painalluksella tarvittaessa useita kertoja päivässä. Myös tuotannon palvelin- ja varusohjelmistot voidaan päivittää napin painalluksella eikä riskiä ole, koska prosessi on täysin automaattinen ja jokainen päivitys on koeistettu jo testiympäristöissä.

Työkaluja

Tuotantoprosessin automatisointi on arkipäivää ja rakennettavissa nykypäivänä yleisesti käytössä olevilla työkaluilla. Aiheesta riittäisi kerrottavaa toiseenkin blogiin, joten tyydyn tässä mainitsemaan esimerkinomaisesti muutamia mahdollisia, ainakin Java-maailmassa käytettyjä, työkaluja ja avainsanoja: virtualisointi, Vagrant, Gradle, Maven, Flyway, Jenkins, Puppet, Chef, bash.

Yhteenveto

Automatisoidun tuotantoprosessin suunnittelu vaatii työtä ja osa työstä on rakennettavasta järjestelmästä riippuvaista. Aivan pienessä projektissa tuotantoprosessin täydellinen automatisointi ei välttämättä maksa itseään takaisin, mutta niissäkin tärkeimmät osat pitää ehdottomasti automatisoida.
Jos omassa projektissasi tehdään joitakin rutiiniasioita käsin, en olisi yllättynyt tai huolestunutkaan, vielä. Mutta ensi vuonna alkavassa yli miljoonan euron projektissa näiden asioiden pitäisi olla kunnossa.

Avatar

Sami Kallio

Sami on kokenut ohjelmistoarkkitehti ja huippuasiantuntijoista koostuvan tiimin vetäjä. Hän on osallistunut lukuisten erilaisten yksityisektorin ja julkishallinnnon tietojärjestelmien kehittämiseen vakuutusjärjestelmistä mediasektorille ja joukkoliikenteestä rahastotoimintaan Suomessa ja ulkomailla.

Piditkö lukemastasi? Jaa se myös muille.

Onnistumisen seminaari

Gofore järjesti perjantaina 7.6.2013 Onnistumisen seminaarin, jonka teemana olivat julkisen hallinnon hankkeet, joissa on menestyksekkäästi yhdistetty kokonaisarkkitehtuuriajattelua ja ketterää kehitystä.
Timur Kärki
Tilaisuuden aluksi Goforen toimitusjohtaja Timur Kärki kertoi kokonaisarkkitehtuurityöstä ja ketterän kehityksen yhteensovittamisesta. Vaikka ketterä kehitys on pitkään ollut käytössä yksityisen sektorin ohjelmistohankkeissa, se on vasta aikoina alkanut vakiintumaan myös julkiseen hallintoon.
Julkisuudessa on uutisoitu varsin usein tietojärjestelmähankkeista, jotka eivät ole onnistuneet. Kuitenkin muun muassa Gofore on ollut mukana lukuisissa hankkeissa, joita voidaan selkeästi pitää onnistuneina. Seminaarin anti rakentui onnistuneille hankkeille, joista olivat goforelaisten lisäksi kertomassa Marika Leed Kelasta, Teija Inkilä Sosiaali- ja terveysministeriöstä ja Jarkko Oksala Tampereen kaupungilta.

Kelan verkkosivuston ketterä uudistaminen

Marika Leed
Kansaneläkelaitos Kela on toteuttanut viime syksystä lähtien kela.fi-verkkosivuston uudistamista. Gofore valikoitui toimittajakumppaniksi Hanselin teknisen IT-konsultoinnin puitesopimuksen kilpailutuksen seurauksena. Kesäkuun 2013 alkuun Kelassa työskennellyt kehittämispäällikkö Marika Leed kertoi verkkosivuston uudistamisen olleen ensimmäinen laaja ketterällä menetelmällä toteutettu uudistushanke, jonka pääpaino on parantaa tietojen löydettävyyttä ja käyttäjäkokemusta palvelussa.
Uudistaminen on onnistunut kokonaisuudessaan erinomaisesti, ja ketterän Scrum-menetelmän myötä kela.fi-sivusto vastaa aiempaa paremmin kuluttajien tarpeisiin. Goforen rooli palvelun kehittämisessä on ollut merkittävä, ja Kela on pitänyt Goforea luotettavana toimittajakumppanina, jonka vahva asiantuntemus ketterästä ohjelmistokehityksestä on nivoutunut kiinteäksi osaksi Kelan kokonaisarkkitehtuuriperiaatteita. Erilaisille päätelaitteille responsiivisesti skaalautuva kela.fi vastaa aiempaa huomattavasti paremmin kuluttajien vaatimuksiin.

Kokonaisarkkitehtuurin kytkeminen tekemiseen

Juha Siltanen
Goforen vanhempi palveluarkkitehti Juha Siltanen kertoi puheenvuorossaan, miten kokonaisarkkitehtuuriajattelu kytkeytyy ja saadaan linkittymään käytännön tekemiseen. Kokonaisarkkitehtuurissa on kyse nimenomaan organisaation toiminnan jäsentämisestä, ja suurimpana haasteena valtionhallinnossa on kokonaisarkkitehtuurityön kytkeminen toiminnan kehittämiseen. Kokonaisarkkitehtuurityö tulee valitettavan usein mukaan aivan liian myöhäisessä vaiheessa toiminnan kehittämiseen. Tästä syystä kokonaisarkkitehtuurityön tavoitteet eivät realisoidu kovinkaan hyvin. Mitä pidemmällä ollaan määrittely- ja suunnitteluvaiheessa, sitä pienemmiksi kokonaisarkkitehtuurin vaikutusmahdollisuudet kaventuvat.
Kuitenkin arkkitehtuurityö on mahdollista ottaa aiemmassa vaiheessa mukaan kehitystyöhön, kunhan se huomioidaan kehittämistä suunniteltaessa, suunnitelma myös toteutetaan ja kehittäminen toteutetaan suunnitellulla tavalla. Suunnitelmallisuus ja kokonaisarkkitehtuuri näkyvät ketterien menetelmien hyödyntämisessä hieman eri tavoin, mitä perinteissä vesiputousmallin mukaisessa ajattelussa: suunnittelu ja tekeminen vaiheistetaan eri tavalla. Itse asiassa kokonaisarkkitehtuurin suunnittelulla kehitettävä kokonaisuus tunnistetaan, rajataan ja suunnitellaan systemaattisemmin. Kokonaisarkkitehtuurin tulee olla osa normaalia kehittämisprosessia ja arkkitehtuurisuunnittelu tulee ottaa mukaan mahdollisimman varhaisessa vaiheessa. Ketterä kehitys vaiheistaa ja jakaa kehitystyötä helpommin hallittaviin kokonaisuuksiin.

STM:n Valtimo-hanke

Teija Inkilä
Sosiaali- ja terveysministeriön työsuojeluosaston ylitarkastaja Teija Inkilä kertoi Valtimo-hankkeesta, joka on tutkitusti julkisen sektorin tehokkain tietojärjestelmäprojekti. Hankkeessa Gofore tuotti ketteriä menetelmiä hyödyntäen nykyaikaiset tietojärjestelmät työsuojeluvalvonnan käyttöön. Tavoitteena oli lisätä työsuojeluvalvonnan vaikuttavuutta ja laatua sekä parantaa työn tuottavuutta. Tavoitteena oli myös toteuttaa tietojärjestelmä laadukkaasti, kustannustehokkaasti ja aikataulussa. Kaikki nämä tavoitteet toteutuivat varsin hyvin.
Ketterää kehitystä pidettiin toimivana, koska suunnitelmia on mahdollista tarkentaa ja muuttaa tietojärjestelmätyön edetessä, jolloin ideoita syntyy runsaasti. Koska järjestelmää pääsee kokeilemaan jo rakennusvaiheessa, konkretisoi se tavalliselle ihmiselle järjestelmän toimintatapaa. Järjestelmän käyttäjät pystyvät kehittämisvaiheessa vaikuttamaan millainen järjestelmästä tulee.
Onnistunut ohjelmistohanke muodostuu useasta pienemmästä kokonaisuudesta. Kun järjestelmäsuunnittelu on tehty toimintalähtöisesti, tavoitteet tulee määritellä mitattaviksi ja niistä on pidettävä kiinni. Suuren hankinnan toteuttaminen pienissä paloissa iteratiivisesti mahdollisti nopean reagoinnin projektin aikana kohdattuihin haasteisiin.  Julkishallinnon kilpailutus edellyttää läpinäkyvyyttä, ja Valtimon tapauksessa Goforen asiantuntevuus sekä avoin ja riippumaton toimintatapa oli onnistumisen edellytyksenä.

Tampereen kaupungin kokonaisarkkitehtuurityö on jatkuva toiminto

Jarkko Oksala
Gofore ja Tampereen kaupunki ovat tehneet pitkään yhteistyötä kokonaisarkkitehtuurin kehittämiseksi. Tietohallintojohtaja Jarkko Oksala kertoi, kuinka kokonaisarkkitehtuuriajattelua on toteutettu jatkuvana toimintona Tampereen kaupungilla.
Kokonaisarkkitehtuurityön tavoitteena on samanaikaisesti parantaa kykyä hyödyntää IT:tä toiminnan kehittämisessä, mutta myös tehostaa kehittämisen ohjausta. Oleellista on, että kokonaisarkkitehtuurityö on jatkuvaa ja iteroituvaa toimintaa. Käytännössä arkkitehtuurikuvaukset kytketään projekteihin toimialuearkkitehtuurin kautta. Kokonaisarkkitehtuurin jatkuvasta toiminnoista vastaavat arkkitehtuuriryhmä, kehittämis- ja ohjausryhmät sekä projektien ohjausryhmät. Arkkitehtuuriryhmä tukee päätöksentekoa arkkitehtuurin keinoin ja arvioi projektin arkkitehtuurinmukaisuutta ja tukee kehittämisprojektia arkkitehtuuriasioissa. Kehittämis- ja ohjausryhmät hyväksyvät arkkitehtuurilinjaukset ja kehittämissuunnitelmat. Projektin ohjausryhmä käynnistää arkkitehtuurin tavoitetilan mukaiset kehittämisprojektit.
Käytännössä projektien arkkitehtuurin hallinta jakautuu kokonaisarkkitehtuurin hallinnan ja kehityskohteen tarkemman arkkitehtuurin yhteensovittamiseen. Ideointivaiheessa pyritään karsimaan päällekkäisiä ideoita ja valitsemaan niistä soveltuvimmat, jotta esiselvitysvaiheessa linjauksia voidaan noudattaa. Määrittely- ja suunnitteluvaiheessa tuotetaan ensimmäinen version kehityskohteen kokonaisarkkitehtuurikuvauksesta. Kilpailutuksen ja hankinnan aikana tarkennetaan ratkaisuarkkitehtuurin kuvaus.

Kartturin nuotein maaliin

Kilta-sali
Goforen liiketoimintajohtaja Mikael Nylund kertoi tilaisuuden lopuksi, miten kokonaisarkkitehtuurityön hyödyt toteutuvat pitkäjänteisen ja systemaattisen soveltamisen tuloksena. Puolestaan kehittämisprojektien arkkitehtuurituki ja arkkitehtuurilinjausten jalkauttaminen tekee arkkitehtuurityöstä vaikuttavaa.
Kaikkiin näihin Gofore tarjoaa kokonaisarkkitehtuurin hallinnan palvelun Kartturin, joka tukee organisaation jatkuvaa kokonaisarkkitehtuurityötä. Kartturi tarjoaa yhdessä palvelussa arkkitehtuurimenetelmän, jota on käytännössä hyödynnetty lukuisissa julkisen hallinnon hankkeissa, asiantuntijat sekä parhaat käytännöt.

Avatar

Janne Pehkonen

Janne on kokenut julkisen sektorin kokonaisarkkitehti, joka uskoo ihmiskeskeiseen hyvinvointiyhteiskuntaan. Hän on suunnittelemassa tulevaisuuden Suomea, jossa asiakaskeskeisen ajattelun paradigman muutoksen ja digitaalisen transformaation kautta ihminen nostetaan keskiöön.

Piditkö lukemastasi? Jaa se myös muille.

Yhteiset käsitteet ovat kaiken ihmisten välisen kommunikaation perusta. Tämä pätee myös kokonaisarkkitehtuurityössä ja ehkä siinä jopa aivan erityisesti, koska tavoitteena on tuottaa kuvauksia yhteisellä ja yhteensopivalla tavalla. Siksi käsitteiden määrittelyyn ja sen varmistamiseen, että kaikki jakavat nämä samat määritelmät, käytetty aika ei koskaan ole hukkaanheitettyä. Aina löytyy yllätyksiä sen suhteen, että jo pitkään viljellyt käsitteet eivät merkitsekään työhön osallistuville samaa, vaan ne saattavat vaatia paljonkin lisää keskustelua ja rajaamista ennen kuin ne ymmärretään yhteisellä tavalla. Kun käsite on kerran selkeästi määritelty, se helpottaa kommunikointia ja asioiden dokumentointia. Se myös helpottaa omaa ajattelua ja asioiden jäsentelyä.
Jokaisessa organisaatiossa on omat toimialaan liittyvät käsitteensä, joiden määrittely usein tehdään kyseisen organisaation kokonaisarkkitehtuurityössä. Julkishallinnon kokonaisarkkitehtuurityön viitekehyksen sisällä on myös paljon sellaisia käsitteitä, jotka ovat kaikille yhteisiä. Nämä ovat itse menetelmään liittyviä käsitteitä, sellaisia kuten palvelu tai sidosryhmä. Kokonaisarkkitehtuurityössä on pitkälti kyse yhteentoimivuuden varmistamisesta ja tästä syystä olisi olennaisen tärkeää, että nämä käsitteet ymmärretään kaikkialla julkishallinnossa samalla tavalla, jotta tuotokset olisivat yhtenäisiä.  Miten organisaatiossa voidaan määritellä sidosryhmiä, jos koko käsitettä ei ole ylipäänsä määritelty?
Tällä hetkellä kokonaisarkkitehtuurityötä käynnistettäessä onkin välttämätöntä, että myös itse menetelmään liittyvät käsitteet, ei vain toimialan käsitteet, käydään organisaation sisällä läpi ja määritellään mitä niillä tarkoitetaan kaikissa ka-tuotoksissa, jotta nämä olisivat yhteensopivia. Toivottavaa kuitenkin olisi, että tulevaisuudessa julkishallinnon käytössä olisi yhteiset määritelmät menetelmän käsitteistölle. Eri organisaatioissa tehtävää työtä helpottaisi ja tuotosten yhteensopivuutta parantaisi, jos voitasiin lukkoonlyödä, että tietty käsite tarkoittaa tiettyä asiaa kaikissa julkishallinnon ka-menetelmän määrityksissä, ohjeistuksissa ja dokumenteissa.
Julkishallinnolle yhteinen kokonaisarkkitehtuurityön peruskäsitteiden määrittely löytyy Valtiovarainministeriön dokumentista ”Kokonaisarkkitehtuurin käsitteitä ja termejä”. Tämä dokumentti on kuitenkin suppea ja osittain puutteellinen. Esimerkiksi  kokonaisarkkitehtuurityön keskeinen käsite palvelu määritellään seuraavasti: ”Palvelulla tarkoitetaan toiselle osapuolelle tarjottua toiminnallista tai teknistä palvelua.” Käsite kuvataan siis viittaamalla siihen itseensä – palveluun. Lisäksi viitataan käsitteisiin toiminnallinen ja tekninen ilman, että näiden määritelmiä on kuvattu missään. Palvelu– käsitteen yhteinen ymmärtäminen olisi kuitenkin olennaisen tärkeää, sillä ka-työ on täynnä erilaisia palveluita: tietojärjestelmäpalveluita, ylätason toiminnallisia palveluita, teknologiapalveluita, jopa SOA-palveluita. Kaikista näistä saatetaan huolettomasti puhua yleisesti palveluina asiayhteydestä riippuen. Tärkeää olisikin kuvata erityyppisten palveluiden merkitys ja erot, keskinäiset suhteet ja palvelutaksonomia, eli palveluiden luokittelu.
Mielenkiintoisen kokonaisuuden muodostavat myös käsitteet sidosryhmä, toimija, rooli ja organisaatio. JHS-179 ottaa tähän kantaa seuraavasti: ”Toimijoilla tarkoitetaan tässä sekä organisaation sisäisiä ja ulkoisia tilaajia ja tuottajia, organisaation palveluiden asiakkaita sekä muita organisaation toimintaan vaikuttavia tai siinä huomioitavia sidosryhmiä”.  Määritelmä on hyvin laaja ja jättää epäselväksi mikä on näiden käsitteiden keskinäinen suhde ja mitä itse asiassa kuvataan silloin kun kuvataan organisaation sidosryhmiä. Ovatko esimerkiksi sisäiset tuottajat sidosryhmiä vai tarkoitetaanko sidosryhmillä ainoastaan organisaation ulkopuolisia tahoja? Ja ovatko sidosryhmät todellakin aina toimijoita? Käytännössä käsitteiden määrittelyn epäselvyys johtaa tilanteeseen, jossa jokainen määrittelee ja kuvaa sidosryhmät ja toimijat hiukan eri tavalla ja näin ollen tuotetut kuvaukset eivät ole yhteensopivia.
Käsitteillä on erilaisia merkityksiä eri asiayhteydessä. Palvelu tai vaikkapa tieto voi merkitä monenlaista tilanteesta riippuen. Käytännön arkkitehtuurityön onnistumisen kannalta olisi kuitenkin olennaista tietää mitä käsitteet nimenomaan julkishallinnon kokonaisarkkitehtuurimentelmässä tarkoittavat. Tarvitsemme yhteiset ajattelun ja kommunikaation välineet, joita voisimme käyttää ilman väärinymmärryksen vaaraa. Tällöin aikaa säästyisi myös varsinaiseen työhön, kun keskustelua tietyn käsitteen merkityksestä ei tarvitsisi avata joka arkkitehtuuriprojektissa aina uudelleen.

Avatar

Kristiina Härkönen

Kristiina on kokenut it-alan asiantuntija, jolla on laaja-alainen kokemus tietojärjestelmien kehittämisestä ja tietojärjestelmäprojektien hallinnasta. Hän on toiminut lukuisien ohjelmistoprojektien eri vaiheissa vastaten ohjelmistojen määrittelystä ja suunnittelusta sekä projektien aikataulun ja etenemisen seurannasta. Lisäksi Kristiinalla on kokemusta kokonaisarkkitehtuurityöstä, ohjelmistotuotannon prosessien kehittämisestä ja järjestelmähankkeiden auditoinnista. Kristiinan erityisosaamista ovat projektinhallinnan menetelmät, tietojärjestelmien määrittely ja suunnittelu sekä kokonaisarkkitehtuuri.

Linkedin profile

Piditkö lukemastasi? Jaa se myös muille.