Avoimen datan julkaisun motivaationa on lupaus avoimen datan parantavan verkoston kokonaistuottavuutta. Datan ollessa avoimesti satavilla, sitä voidaan hyödyntää useammassa osassa verkostoa, jolloin myös potentiaalista lisäarvoa syntyy useammassa osassa verkostoa. Ihanteellisesti avoimen datan käyttöönoton transaktiokustannukset ovat lähellä nollaa, koska datasta ei tarvitse maksaa, työaikaa ei kulu sopimusneuvotteluihin, eikä asianajajien palkkoihin sopimuksen laatimisessa. Sen lisäksi, että avoimien lisenssien luovat lakiteknisen ilmaisun sisällön avoimuudelle, niiden tärkein rooli on selkeyttää datan käyttäjälle ja julkaisijalle mitä avoin julkaiseminen tarkoittaa.
Avoimet sisältölisenssit kattavat niin avoimen lähdekoodin lisenssit, kuin avoimet taidelisenssit ja avoimen datan lisenssit. Voidaan myös mieltää avoimien API:en lisenssien kuuluvan tähän joukkoon henkisesti, vaikka palvelun ja sisällön ero onkin mielenkiintoinen semanttinen kysymys. Koodi on kuitenkin luonteeltaan erilaista kuin data tai taideteos, joille tarvitaan erilaisia lisenssejä. Kaikille lisensseille yhteistä on lupa sisällön käyttö omaan tarkoitukseen ja sisällön eteenpäin levittäminen. Riippuen sovellusalueesta kaupallinen hyödyntäminen ja sisällön muokkaaminen saattaa olla kiellettyä lisenssissä. Kaikki avoimet datasetit ja koodinpätkät eivät esimerkiksi ylitä teoskynnystä, jolloin niitä eivät suojaa tekijänoikeudet, mutta ne saattavat olla lähioikeuden alaisia.
Avoimien sisältölisenssien inspiraationa ovat olleet avoimen lähdekoodin lisenssit. Avoimen lähdekoodin lisenssit ovat mahdollistaneet avoimen lähdekoodin menestystarinat, kuten Linuxin, Mozillan, RedHatin ja Eclipsen. Avoimen lähdekoodin lisenssit ovat kuitenkin olleet edelläkävijänä, jonka vuoksi avoimen datan lisenssejä kohtaan ei ole yhtä suuria ennakkoluuloja kuin avointa lähdekoodia aikanaan. Myöskään avoimia sisältölisenssejä vastaan ei ole ollut mahdollista käydä yhtä mittavia ja tehokkaita pelottelukampanjoita, kuin avoimen lähdekoodin lisenssejä vastaan. Kuten avoimen lähdekoodin lisenssien käyttö, myös avoimien sisältölisenssien käyttö, sekä uhkaa vanhoja liiketoimintamalleja, että mahdollistaa uusia.
Ehkä oleellisin asia, minkä avoimen datan sisältölisenssien tekijät ovat oppineet avoimen lähdekoodin lisensseistä, on selkeyden ja yksinkertaisuuden tärkeys. Avoimen lähdekoodin lisenssejä on yli 60 tarkasti määriteltyä, sekä lukemattomia muita koodiin liitettyjä ilmaisuja joilla sen käyttö mahdollistetaan avoimena. Datalle suositeltuja avoimia sisältölisenssejä on alle kymmenkunta ja niistä on tarkoituksella yritetty tehdä mahdollisimman selkeitä ja yksinkertaisia. Avoimen lähdekoodin lisenssit voivat olla yli kymmenen sivua pitkiä ja käyttää ilmaisuja joiden merkitys ei aukea asianajajalle kuin ohjelmistokehittäjällekään. Tällöin lisenssi ei enää palvele tehokkaasti tarkoitustaan lisensoidun sisällön käytön mahdollistajana. Vastuuntuntoinen käyttäjä haluaa varmistaa oikeutensa käyttää koodia, jolloin hän joutuu käyttämään paljon aikaa lisenssin tutkimiseen tai rahaa asiantuntijapalveluun koodin ja lisenssin auditointiin.
Lisensseillä, kuten muille vastaavilla viestinnän työkaluilla, on tapana lisääntyä ja muuttua ajan myötä. Avoimen sisällön edelläkävijä, Creative Commons (CC) -yhteisö, taistelee tätä kehitystä vastaan. Uusia lisenssejä ei tehdä, mutta vanhoja päivitetään. CC-lisenssien rakenne on myös jossain määrin modulaarinen, joten niissä voidaan esimerkiksi määritellä minkä maan oikeusistuimien alla lisenssiä koskevat riidat tulee käsitellä muuttamatta lisenssiä. Modulaarisuuden vuoksi lisenssien sisältö voidaan ilmaista selkeästi muutamalla ikonilla. CC-lisenssien lähestyttävyys on tehnyt niistä suosittuja, sekä julkaisijoiden, että loppukäyttäjien keskuudessa. CC-lisenssit ovatkin loistava esimerkki, kuinka avoimen datan transaktiokustannuksia minimoidaan. CC-lisenssien modulaarisuuden vuoksi niille on kehitetty myös RDF-pohjainen kuvauskieli, jolloin lisenssien ehdot voidaan esittää myös koneluettavassa muodossa. Tällöin lisensoidun datan transaktiokustannukset voidaan hoitaa automaatiolla. CC on tehnyt myös julkaisijalle lisenssin valintaa helpottavan yksinkertaisen verkkopalvelun.
Kuitenkin suuret toimijat, kuten kansallisvaltiot, ovat syystä tai toisesta välttämättä halunneet määritellä omat lisenssinsä omalle datallaan. Se lisää lisenssien määrää ja käyttäjien mahdollisuuksia sekaannuksiin. Open Knowledge Foundation (OKF) ylläpitää avoimen lisenssin määritelmää ja listaa lisenssistä, jotka täyttävät tämän määritelmän eri osa-alueet. Lisäksi OKF:llä on ikoneja, joilla voi helposti ja käyttäjäystävällisesti merkitä avoimella lisenssillä lisensoitua data. OKF:llä on myös API, jossa sen analysoimien lisenssien kuvauksia on saatavilla koneluettavassa JSON-muodossa.
Vaikka tekijänoikeuskysymykset ja lisensointi ovat kiinnostavia, ei moni tykkää arpoa niitä kovinkaan pitkään, jos on juuri saanut omasta mielestään loistavan idean sovelluksesta, visualisoinnista tai liiketoimintamahdollisuudesta. Tästä syystä, ja ihan oman mukavuudenkin vuoksi, on hyvä olla tietoinen yleisimmistä avoimista sisältölisensseissä ja pitäytyä niissä. Yleisimmät lisenssit myös tarjoavat valmiiksi käyttäjä- ja koneystävällisiä lisenssien ilmaisut. On myös olennaista, että otettaessa käyttöön muita transaktiokustannuksia pienentäviä ratkaisuja, kuten datan löytämistä helpottavia tietovarantoja, niin myös niissä otetaan huomioon lisenssien mahdollisuudet ja selkeä esittäminen.

Salum Abdul-Rahman

Salum Abdul-Rahman

Salum työskentelee Goforella teknisenä projektipäälllikkönä. Hänen yleisimmät roolinsa ovat scrum master ja coach joissa hän keskittyy avoimuuden ja oppimisen edistämiseen. Hänen on kiinnostunut kaikesta ketterään kehittämiseen liittyvästä, avoimesta lähdekooista sekä tietojohtamisesta,

Piditkö lukemastasi? Jaa se myös muille.

”Tieto liikkumaan” -periaate on viime vuosina vilahdellut useissa ICT-strategioissa ja arkkitehtuuriperiaatteissa. Kovan arkkitehtuuriväännön jälkeen on, jos hyvin on käynyt, löydetty tietoarkkitehtuurin integraatiopisteet ja saatu tieto integraatiototeutusten myötä yhteiskäyttöiseksi. Jokainen taistelu on käyty kehityshanke kerrallaan ja aidosti yhteentoimiva ja tehokas järjestelmäkokonaisuus on jäänyt kaukaiseksi. Matka on monessa organisaatiossa yhä kesken, kun tapetille ovat nousseet ulkoiset tiedon liikkumisen paineet avoimen datan kehityksen muodossa. Nyt yllättäen näyttääkin siltä, että tämä ulkoinen tekijä edesauttaa myös sisäistä tiedon liikkuvuutta enemmän kuin monet aiemmat yritykset yhteensä. Tiedon liikkuvuus on yhtäkkiä trendikästä ja halukkuutta on ilmassa ihan toiseen tapaan. Tilanne on siinäkin mielessä mielenkiintoinen, että ennen tietoa kaivettiin esiin järjestelmistä vasten tahtoisesti kysyntään vastaten, kun nyt kysynnän sijaan ollaankin ensin luomassa laajamittaista tarjontaa – tarjontaa ulkoisille ja samalla myös sisäisille toimijoille.
Avoin data puhuttaa. Paljon väännetään siitä, että onko kyse datasta vai tiedosta, mutta keskustelu ei oikein tunnu edistävän itse avaamista, palveluiden syntyä ja paljon rummutettujen hyötyjen saavuttamista. Määritelmiä ja tulkintoja on monia ja kummallakin käsitteellä on paikkansa – merkitys riippuukin ennen kaikkea tarkastelukulmasta. Kysymys on siitä, missä ja milloin tiedon merkitys ja arvo muodostuvat.
Alun perin data on synnytetty tai kerätty johonkin hyödyntäjäorganisaation omaan käyttötarkoitukseen, jolloin sille on sen käyttökontekstin kautta syntynyt arvo ja merkitys – datasta on tullut tietoa. Kun kertynyt tieto avataan julkisuuteen, katoaa alkuperäinen käyttöyhteys ja -merkitys, jolloin tieto palaa tietyllä tavalla datan asemaan. Avoimesta datasta syntyy jälleen merkityksellistä tietoa, kun sitä ladataan, siitä synnytetään palveluita ja sitä hyödynnetään eri yhteyksissä. Avaamisen ydin onkin juuri siinä, että alkuperäiselle tiedolle syntyy uusia merkityksiä ja hyötyjä uusissa käyttökohteissa. Tiedon arvo ei synny tiedon panttaamisessa, vaan sen hyödyntämisessä. Sama pyrkimys on taustalla myös aiemmassa sisäisessä tietoarkkitehtuurityössä.
Tietoa on valtavasti ja sitä pitää saada liikkumaan niin organisaatioiden kuin yhteiskunnan tasolla. Matka avausperiaatteista palveluihin on monisyinen, mutta toteutettavissa. Sitä edesauttaa vahva poliittinen tahtotila ja sitoutuminen. Valtion konserniohjaus on tässä suhteessa kuitenkin maltillinen eikä ota voimakkaasti kantaa siihen, miten avaamisen tulisi tapahtua. Konsernitasolla on linjattu periaatteet, loppu on pitkälti toteuttajien itsensä käsissä – tässä vaiheessa.
Tekemämme avoimen datan kehitystyö useilla kohdealueilla on jo nyt nostanut pintaan lukuisia haasteita ja kysymyksiä, joihin ei ole valmiita vastauksia tai jos on, niin ratkaisut eivät ole etenemispolulla kärkipäässä. Tämä on tie, jota pitää edetä etappi kerrallaan. Välillä on havaittu, että avoimeen dataan suhtaudutaan kertaluonteisena ponnistuksena, joka halutaan saada kerralla kuntoon ja hoidettua pois päiväjärjestyksestä. Valitettavasti täytyy kuitenkin todeta, ettei asianlaita ole näin, vaan nyt otetaan ensi askelia avoimeen suuntaan ja edessä on pidempi oppimis- ja kehittymisprosessi.
Jatkossa kysymys ei ole vain tietosisältöjen laajentamisesta ja avoimen datamassan kasvattamisesta, vaan tietoa tulee strukturoida lisää, synnyttää riippuvuuksia ja asiayhteyksiä, datan päivitystä ja ajantasaisuutta tulee parantaa, rajapintoja tulee kehittää standardoituun suuntaan ja palveluista tulee tehdä online-käyttöisiä – muutamia jatkokehitystarpeita nimetäkseni. Nythän pääosa data-avauksista lähtee siitä ajatuksesta, että palveluntuottaja lataa aineiston omaan käyttöönsä ja toteuttaa palvelut omien tietovarantojensa varaan. Visio semanttisesta verkosta ja suoraan toisiaan hyödyntävistä yhteentoimivista palveluista on vielä kaukana. Kysymys on jatkuvasta prosessista ja mitä paremmin tiedon julkaisu saadaan osaksi organisaation normaalia toimintaa, sitä vähemmän se aiheuttaa ylimääräisen työn tuskaa. Asiaan kannattaa siis panostaa ja miettiä avattavien tietojen lisäksi myös hallinta- ja tuotantoprosesseja.
Avoimen datan kehitys on jo nyt parantanut monessa organisaatiossa olennaisesti tilannekuvaa ja ymmärrystä organisaation tieto-omaisuudesta lisäten merkittävästi kyvykkyyttä vastata myös sisäisen järjestelmä- ja palvelukehityksen haasteisiin. Jotta tietoa on voitu lähteä avaamaan, on ensin jouduttu tekemään tietovarantojen kartoitusta sekä pohtimaan tietosisältöjä ja niiden merkityksiä itselle ja yhteiskunnalle. Ympyrä aiempiin ICT-strategialinjauksiin sulkeutuu ja tätä positiivista eteenpäin pyrkyä kannattaa hyödyntää aktiivisesti myös oman arkkitehtuurikyvykkyyden parantamiseen.

Avatar

Juha Siltanen

Juha on kokonaisarkkitehtuurin ja lean-kehittämisen asiantuntija. Juha johtaa Goforen muotoilupalveluita ja niiden kehittämistä.

Piditkö lukemastasi? Jaa se myös muille.

Menestyksekäs vuosi 2013

Gofore Oy:n vuosi 2013 oli kaikilla mittareilla menestys. Liikevaihtomme oli 6,0 M€. Liikevoitto oli 880 t€ (14,8 % liikevaihdosta), ja tilikauden lopullinen voitto verojen jälkeen oli 662 t€. Liikevaihtomme kasvoi vuodesta 2012 62 % ja liikevoittomme yli 100 %. Oli loistava vuosi siis – kiitos kaikille asiakkaillemme, kumppaneillemme, ja tietenkin työntekijöillemme!
Kasvumme perustuu asiakaskuntamme rohkeaan panostukseen uusien tehokkaampien toimintaprosessien, niitä tukevien tietojärjestelmien sekä sähköisten asiointipalveluiden kehittämisessä. Olemme yhdessä asiakkaidemme kanssa rakentamassa uutta tietoyhteiskuntaa, jossa myös IT-palveluiden tarjoajilta odotetaan uutta kykyä tukea asiakasta toiminnan ja tietoteknisen ympäristön murroksessa. Edustammekin kehittämisen uutta aikakautta asiakaslähtöisellä, avoimella ja luotettavalla toiminnallamme.
Viime vuoden lopulla tehdyn asiakastyytyväisyyskyselyn vapaasanakommenteista 70 prosentissa vastauksista esiintyi termi asiantunteva tai osaava, 39 prosentissa esiintyi sana ketterä tai joustava. 35 prosentista vastauksista löytyi sana luotettava tai rehellinen. 98 prosenttia asiakkaistamme myös suosittelisi meitä kollegoilleen. Eniten aiemmasta kyselystä oli muuttunut palveluidemme merkitys asiakkaillemme – asiakkaamme mieltävät palvelumme entistä tärkeämmiksi toiminnalleen.
Henkilökunnan tyytyväisyyttä henkilöstöjohtamiseen olemme mitanneet vuosittain LeadIT-tutkimuksella. Goforen työilmapiiri sai annettujen kouluarvosanojen keskiarvona 9,47 ja yhteishenki 9,45. Nämä ovat hienoja lukemia kasvuyritykselle. Meille on tärkeää, että henkilökuntamme viihtyy työtehtävissään – vain näin voimme tarjota laadukasta palvelua hymyssä suin asiakkaillemme.
Tänä vuonna tavoittelemme lähes yhdeksän miljoonan euron liikevaihtoa. Henkilöstön määrä on kasvanut 25 prosenttia alkuvuoden aikana ja ennakoimme, että vuoden lopussa meitä goforelaisia on yli 90.

Avatar

Timur Kärki

Timur on Gofore Oy:n toimitusjohtaja ja yksi perustajaosakkaista. Hänellä on yli viidentoista vuoden kokemus haasteellisista tietojärjestelmien kehittämishankkeista. Erityisen kiinnostunut Timur on Suomen pelastamisesta onnistuneilla ja innovatiivisilla sähköisillä palveluilla yhdessä Goforen asiakkaiden ja työntekijöiden kanssa. Timur itse konsultoi asiakkaita liittyen kokonaisarkkitehtuurityöhön, vaatimusmäärittelyihin sekä kilpailutusprosesseihin.

Linkedin profile

Piditkö lukemastasi? Jaa se myös muille.

Sunnuntaina hallitus ja oppositio yhdessä esittelivät uuden sosiaali- ja terveyspalvelujen järjestämismallin. Nykyisten erva-alueiden laajuiset viisi sote-aluetta toimivat vuodesta 2017 alkaen kaikkien sote-palvelujen järjestäjänä. Saamme siis tähän maahan edistyksellisen sote-palvelurakenteen, jossa sekä sosiaali- että terveyspalvelut, niin perus- kuin erikoistasolla integroidaan yhdeksi kokonaisuudeksi. Tämä lupailee mm. alueellisen eriarvoisuuden vähenemistä ja asiakaslähtöisiä, ehjiä palveluketjuja. Nämä lupaukset eivät kuitenkaan toteutudu itsestään, vaan näkemystä, toimenpiteitä ja tukea vaaditaan kaikilta – myös tiedonhallinnan ammattilaisilta – epäonnistumisen välttämiseksi.
Kiinnostavaa uudessa sote-mallissa on mm. se, että se luo haluttaessa edellytykset ”raha seuraa potilasta” -tyyppiselle toiminnalle, jossa eri sote-palvelujen tuottajat – niin julkiset kuin yksityiset – asetetaan markkinaehtoisesti samalle viivalle ja asiakas itse tekee lopullisen valinnan. Ainakin uudet sote-alueet ovat riittävän suuria kyetäkseen kilpailuttamaan eri tuottajia keskenään. On lupa odottaa, että nykyistä selkeämmin erotetaan palvelun järjestäjän ja tuottajan roolit toisistaan.
Joka tapauksessa asiakkaan oma valinnanvapaus palvelutuottajan valinnassa kasvaa tulevaisuudessa. Tämä koskee niin perustason palveluja, kuten terveysasemapalveluja, kuin erikoissairaanhoidon palveluja, joissa asiakas hakee parasta mahdollista hoidon laatua, vaikka joutuisikin matkustamaan hieman kauemmaksi. Uusi palvelurakenne osaltaan todennäköisesti vauhdittaa tätä kehitystä, koska se mm. mahdollistaa nykyistä laajemman erikoissairaanhoidon palveluiden ja osaamisen keskittämisen.
Asiakkaan liikkuvuuden ehdoton edellytys on, että myös asiakkaan tiedot kulkevat hänen mukanaan. Nykytilassa tämä on suuri puute, kuten kaikki paperisia lähetteitä tai CD-levyllä olevia röntgenkuvia kuljettaneet tietävät. Valtakunnalliset Kanta-palvelut, kuten eArkisto, parantavat tilannetta tullessaan käyttöön, mutta kaikkeen alueen operatiiviseen tiedonvaihtoon ne tuskin tuovat nopealla aikataululla ratkaisua.
Tulevan lainsäädännön yksityiskohdista emme tiedä vielä mitään – sitä ryhdytään nyt valmistelemaan virkamiestyönä – mutta olettaa saattaa, että järjestämisvastuuta seuraa myös vastuu ja valta ohjata tietohallintoa ja kehittää kokonaisarkkitehtuuria. Kunkin uuden sote-alueen sisällä toimii tällä hetkellä kymmeniä sote-palveluja tuottavia organisaatioita, joilla on vähintään yhtä paljon eri potilas- ja asiakastietojärjestelmiä toimintansa tukena. Sote-alueen tietohallinnon agendalle pompsahtaa varmasti korkealle kirjavan, epäyhteentoimivan ja kalliin järjestelmäkentän konsolidointi. Järjestämisvastuun ja palvelujen tuottamisen erottaminen kuitenkin jättää aina tilaa paikallisille ja organisaatiokohtaisille tietojärjestelmäratkaisuille, joten ”yksi järjestelmä kaikkien käyttöön” tuskin ratkaisee ongelmaa tulevaisuudessakaan.
Alueellisen potilas- ja asiakastiedon yhteentoimivuuden ratkaisemiseksi tarjoaisin sen sijaan perusjärjestelmistä ja niiden toimittajista riippumatonta tietovarantoa. Kansainvälisestikin laajaa kiinnostusta herättäneet IHE/XDS-standardiin perustuvat ratkaisut lupaavat juuri tätä. Malli ei edellytä tietojen keskittämistä yhteen fyysiseen tietovarantoon, vaan se voi myös perustua tietojen hajauttamiseen lähemmäksi operatiivisia tietojärjestelmiä. Malli täydentää tulevia valtakunnallisia tietojärjestelmäpalveluja, eivätkä nämä investoinnit oikein tehtyinä ole päällekkäisiä.
Tässä on varmasti ensimmäisiä pähkinöitä purtavaksi tulevien sote-alueiden tietohallinnosta vastaaville. Mikäli tiedonjakoa ei pystytä ratkaisemaan, jää suuri osa palvelurakenteella tavoitelluista hyödyistä saavuttamatta. Se olisi sääli, eikä varsinainen sulka hattuun meille ICT-ratkaisujen roolia tuottavuuden nostamisessa korostaville.
Tuoko suunniteltu sote-ratkaisu sinusta parannusta nykyiseen sote-tietojärjestelmien kenttään?

Mikael Nylund

Mikael Nylund

Mikael on Goforen toimitusjohtaja. Hän on työskennellyt Goforessa vuodesta 2010 lähtien ja auttanut sinä aikana lukuisia organisaatioita polulla kohti digitaalista liiketoimintaa. Mikael ajattelee, että parempi tulevaisuus tehdään teknologian avulla ihmisten ehdoilla.

Piditkö lukemastasi? Jaa se myös muille.

Ketterä konsultti kertoo keveästi kehittämisestä ja kokonaisarkkitehtuurista

Lean-ajattelu ja ketterät menetelmät ovat tulleet vahvoina mukaan ohjelmistoprojekteihin, mutta laajempien kokonaisuuksien hallintaan ei vielä ole vakiintuneita toiminta-tapoja. Samoin ketterät menetelmät tuovat uusia haasteita kokonaisarkkitehtuurin tekemiseen.
Ketterä ohjelmistokehitys (Agile Software Development, ASD) nostaa asiakkaan tarpeen täyttämisen toimivan ohjelmiston kautta tärkeimmäksi arvoksi. Samalla ketteryys antaa asiakkaalle mahdollisuuden muuttaa mieltään ja hioa ratkaisua paremmaksi nopeilla toimituksilla. Toisaalta vastuu kokonaisuuden ymmärtämisestä jää pitkälti tuoteomistajan taakse.
Lean-kehitys (lean-development) taas tähtää kaiken turhan työ eliminointiin. Turhaksi työksi lasketaan myös ennenaikaisesti valmistuneet välituotokset. Toinen olennainen osa Lean-periaatteita on kokonaisuuden ymmärtäminen ja sen jatkuva kehittäminen. Lean on siis enemmänkin tapa ajatella asioita, kuin varsinainen menetelmä toteuttamiseen.
Kokonaisarkkitehtuuri (tai yritysarkkitehtuuri, KA) on työkalu jäsentää kokonaisuutta. Mielestäni KA-mallit ovat mainioita työkaluja tuon kokonaiskuvan rakentamiseen ja ylläpitämiseen, mutta kokonaisuuksista keskusteltaessa KA-kehys on aivan liian tarkka.
KA-kehyksestä kannattaa poimia toiminnan kannalta oleelliset kohdat ydinkaavioon (core diagram). Tämä yhden sivun kuva toimii mainiosti nemawashin, lean-ajattelun konsensuksen, rakentajana. KA-tuotokset on siis mahdollista esittää muutenkin kuin plunttana paperia. Toyotallakin, jota pidetään yhtenä Lean ajattelun merkittävimmistä kehittäjistä, päätökset tehtiin yhden A4:n perusteella, mihin oli tiivistettynä kaikki oleellinen.
Monimutkaisen kokonaisuuden puristaminen yhteen sivuun on työlästä. Usein tuntuukin kuin jokin oleellinen yksityiskohta jäisi kertomatta. Todellisuudessa asia on kuitenkin lukijan kannalta toisin, esiin nousevat vain tärkeät asiat, kun turha hälinä jää pois. Taustalla on tietysti paljon näkymätöntä työtä, jotta oleellinen on saatu tiivistettyä. Mutta näkymätön ei ole tarpeetonta. Oman kokemukseni mukaan juuri tuo työ on perusta sekä sitouttamaiselle että viestinnälle, joita kollegani Erkki (arkkitehtuurin arvo syntyy viestinnastä) ja Juha (mallinna pohdi sitoututa päätä) ovat omissa kirjoituksissaan kattavasti käsitelleet.

Ihannoi kevyttä, suunnittele rauhassa ja toteuta ketterästi.

Oman kokemukseni mukaan edellä mainitut menetelmät sopivat hyvin yhteen ja tukevat toisiaan. Menetelmät perustuvat laajalti samanlaisiin / samoihin ideologioihin ja perimmäinen tavoite asiakas- arvon tuottamisesta on sama. Menetelmillä on vain oma soveltamisalueensa, rajauksensa, jossa ne toimivat. Samoin kuin istutuslapio ja kaivinkone, molemmilla voi kaivaa, mutta ne eivät ole järkeviä samoissa töissä.
Itse olen jäsentänyt menetelmät seuraavasti. Aluksi tarvitsemme päämäärän eli missä haluamme olla pitkällä tähtäimellä. Seuraavaksi omista arvoistamme rakentuu linjaukset, kuinka haluamme päämäärän saavuttaa. Tälle tasolle voidaan nostaa myös kehittämisen ideologioita, kuten esimerkiksi edellä mainittu Lean.
Seuraavaksi tarvitsemme tietoa, tiedon keräämiseen käy oivasti KA-mallit, kuten esimerkiksi Kartturi. Malli antaa meille tukea tiedon jäsentämiseen järkeviksi kokonaisuuksiksi ja yleensä myös neuvoo millaista tietoa tarvitaan. Mallin avulla voidaan myös haarukoida kehitettävät alueet / kohteet.
Sitten se hankala kohta. Tarvitaan päätös mistä aloittaa. Korkean tason päätöksiin sopii pohjaksi hyvin ydinkaavio tai nemawashi-tyyppinen lähestyminen, jossa oleellinen tiivistetään ymmärrettäväksi, helposti kommunikoitavaksi kokonaisuudeksi yhdessä sidosryhminen kanssa. Yleensä nämä ’oleelliset asiat’ ovat juuri niitä, joiden kehittämistä halutaan ylätasolla seurata.
Okei, meillä on päätös, ja eikun tekemään. Tässä vaiheessa innostuneisuus tarttuu ja kaikki haluavat päästä tekemään ja kokeilemaan. Agile-menetelmät ovat tässä aivan mainioita, koska arvon tuottamisesta saadaan havaintoja jo hyvin varhaisessa vaiheessa.
Tässä tekemisen huumassa arkkitehtuurin ylevät periaatteet usein hämärtyvät, jopa unohtuvat. Agile-kehitys vaatii arkkitehdeiltä kurinalaisuutta; täytyy vahvasti pitää kiinni niistä oleellisista, tärkeistä päätöksistä, jotka alussa linjattiin. Toisaalta agilen työtavat vaativat vahvaa osallistumista, edestä johtamista. Ohjelmistokehittäjien heimo kun pitkälti noudattaa meritokratian periaatteista tekemisessään. Mikäli tuoteomistaja ei tässä vaiheessa huolehdi myös ratkaisun suhteesta kokonaisuuteen ollaan vaarallisilla vesillä. Yksittäinen projekti voi edelleen onnistua mainiosti, mutta se ei täytä paikkaansa kokonaisuudessa.
Fanfaarien soidessa juhlitaan kehitystyön tulosta. Kaikki ovat tyytyväisiä ja homma on valmis. Mutta hetkinen ei tämä ollut vielä tässä. Maljapuheissa on syytä katsoa peruutuspeiliin. Mitä opimme? Mikä meni hyvin? Mikä huonosti? Mitä voimme tehdä paremmin? Näiden oppien kanssa lähdetään taas uudelle kierrokselle Demingin ympyrää.

Lähteet:

Lean principles – http://en.wikipedia.org/wiki/Lean_software_development
The Agile Manifesto – http://www.agilemanifesto.org/principles.html
Jeanne W. Ross, Peter Weill, David Robertson, Enterprise Architecture As Strategy: Creating a Foundation for Business Execution http://www.amazon.com/Enterprise-Architecture-Strategy-Foundation-Execution/dp/1591398398
Jeffrey Liker, The Toyota Way, http://www.amazon.com/The-Toyota-Way-Management-Manufacturer/dp/0071392319
Rodríguez Pilar, COMBINING LEAN THINKING AND AGILE SOFTWARE DEVELOPMENT HOW DO SOFTWARE-INTENSIVE COMPANIES USE THEM IN PRACTICE http://urn.fi/urn:isbn:9789526203324
Nemawashi – http://en.wikipedia.org/wiki/Nemawashi
Ronald D. Moen, Clifford L. Norman, Clearing up myths about the Deming cycle and seeing how it keeps evolving www.apiweb.org/circling-back.pdf
Guy Sereff, Orbus software, esitys, The Agile Enterprise Architect – Working effectively with Sprint Teams, Backlogs and Scrum Masters
 

Avatar

Tommi Palm

Linkedin profile

Piditkö lukemastasi? Jaa se myös muille.

Seuraava Clojure Finland tapaaminen järjestetään Goforen Helsingin toimistolla Kampissa keskiviikkona 26.3. klo 18 alkaen. Tapaamisessa kuullaan uusista Clojure-toteutuksista sekä punotaan uusia juonia Clojuren hyödyntämiseksi eri hankkeissa ja organisaatioissa.
Katso tarkempi ohjelma, tilaisuuden puhujat ja ilmoittaudu mukaan! Tarjolla myös hyvää ruokaa ja juotavaa.
Clojure on yksi seuraavan sukupolven moderneista funktionaalista kielistä. Kielen ominaisuuksia voidaan helposti hyödyntää myös muiden teknologioiden kanssa, koska Clojure toimii Java Virtual Machinen päällä. Gofore on uusien teknologioiden ja toimintatapojen edelläkävijänä ylpeä saadessaan isännöidä seuraavaa Clojure Finlandin tapaamista.
Clojure Finland on Suomessa toimiva Clojure-ohjelmointikielestä kiinnostuneiden ihmisten kasvava yhteisö, joka kokoontuu säännöllisesti jakamaan kokemuksia ja kuulumisia Clojuren käytöstä niin työ- kuin harrasteprojekteissa.

Avatar

Riikka Nurminen

Piditkö lukemastasi? Jaa se myös muille.