Kansallinen palveluväylä on ehkä merkittävin IT-projekti tällä hetkellä Suomessa, Apottiakin tärkeämpi. Se on luonteeltaan ristiriitainen: toisaalta siinä pyritään uudistamaan koko se tapa, jolla julkisia tietojärjestelmiä Suomessa tehdään. Toisaalta siinä saatetaan vain kaataa 120 miljoonaa sille jolla on syvimmät taskut. Ratkaisut hankkeen ja ehkä koko suomalaisen IT-palvelualan suunnasta tehdään lähikuukausina.

Kun olen seuraillut projektia vuoden verran melko läheltä, koen että minun täytyy kertoa mistä siinä nähdäkseni on kyse, ja mitä sille pitäisi tehdä.

Optimistin tarina

Tekniikkana palveluväylä on itse asiassa suhteellisen yksinkertaista: sovittu toimintatapa ja sovitut rajapinnat siihen, miten toisiin järjestelmiin otetaan yhteyttä. Yhteinen tapa tunnistaa käyttäjät ja tapa selvittää järjestelmien osoitteet. Useimmilla isoilla yrityksillä on jonkinlainen palveluväylä, mutta se on vain osalla pakollista perusinfraa, vähän kuin serverihallit tai nettikaapelointi. Se ei sinänsä ole mitään kauhean ihmeellistä, vaikka toki tarpeellista.

Kansallinen palveluväylä ei ratkaise järjestelmien yhteentoimintaa eikä sinänsä tuo kovin dramaattisia säästöjä. Suurin osa palveluväylään kohdistetuista odotuksista onkin täysin ylimitoitettuja, jos ajatellaan pelkkää väylää.

Mutta kyse on enemmästä kuin vain tietojärjestelmästä. Palveluväylähankkeen – tai kansallinen palveluarkkitehtuurin, kuten sitä nyttemmin kutsutaan – tavoitteena on mullistaa tapa, jolla suomalaisia tietojärjestelmiä tehdään. Hallituksen rakennepoliittisessa ohjelmassa marraskuussa kirjattiin:

“Toteutetaan viipymättä kansallinen sähköinen palveluväylä ja sähköinen tunnistautuminen kustannustehokkaasti sekä Viron yhteistyömahdollisuudet täysimääräisesti hyödyntäen.”

Kremlologian parhaiden perinteiden mukaisesti “viipymättä” ja “kustannustehokkaasti” tarkoittavat tässä, että hanke tehdään ketterästi eikä perinteisenä julkishallinnon mammuttiprojektina. “Viron yhteistyömahdollisuudet täysimääräisesti hyödyntäen” taas tarkoittaa avointa lähdekoodia. Voisihan sen sanoa paljon selvemminkin, mutta ei ole ollut tapana.

Rakennepaketin perustelumuistiossa (s. 71) asiaa selitetään lisää.

“Palveluväylä mahdollistaa tiedon välityksen organisaatioiden välillä yhdenmukaisesti sovituilla tavoilla (yhtenäiset tiedon kuvaukset, rajapintakuvaukset ja standardit) perustuen avoimiin rajapintoihin ja keskeisten osien osalta avoimeen lähdekoodiin. […]

Yhteentoimivuuden lisäksi Palveluarkkitehtuuri luo aiempaa paremmat liiketoimintaedellytykset yrityksille ja erityisesti PK-sektorille, sillä uusi toimintamalli ja avoimet rajapinnat parantavat niiden edellytyksiä osallistua julkisiin ICT-hankintoihin sekä mahdollisuuksia luoda uusia innovatiivisia palveluja julkista tietoa hyödyntäen.”

Tarkoitus on siis toteuttaa suuri julkinen softahanke kevyesti ja nopeasti ja siirtyä integraatioissa käytäntöön, jossa ne tehdään helposti ja toimivat sen sijaan, että niitä jarrutellaan ja rahastetaan niiden avulla toimittajaloukkua. Samalla avataan kaikki mahdollinen data ja rajapinnat ja siirrytään malliin, jossa strategiset julkiset tietojärjestelmät ovat avointa koodia, jotta niitä voidaan hyödyntää tehokkaammin.

Ja tämä toimivien tietojärjestelmien kulttuuri on tietenkin tarkoitus laajentaa koskemaan julkista sektoria yleisestikin – kuten on tehty Virossa. Rakennepaketissa ennakoidaan tästä saatavan kansantalouden tasolla puolen miljardin vuotuiset hyödyt. Siis 500 000 000 euroa joka vuosi.

Tässä vaiheessa varmaan ymmärrätte, miksi olen innoissani hankkeesta. Tässä yritetään tehdä monia niistä asioista, joista olen puhunut viime vuosina. Toisaalta tämä ei ole ainoa totuus hankkeesta, sillä on myös synkempi puoli.

Pessimistin tarina

Taloussanomat kertoi tammikuussa, kuinka palveluarkkitehtuurihanke on “120 miljoonan euron ontto kuori” ja rahojen käytölle ei ole olemassa suunnitelmaa. IT-hankkeiden tunnettu kriitikko, Professori Tomi Voutilainen taas epäilee, että siitä on tulossa teknologiavetoinen uudistus, jossa unohdetaan loppukäyttäjien tarpeet. Valitun teknologiankin järkevyyttä kyseenalaistetaan, eikä luvattujen puolen miljardin hyötyjen toteutumisesta ole vielä mitään näyttöä.

Vastaavia tietojärjestelmien yhteentoimivuuteen tähtääviä hankkeitahan on tehty Suomessa ennenkin, ks esim. Julkishallinnon perustietovarantojen rajapinnat (PERA)  tai Valtion yhteinen integraatiopalvelu (VIA). Molemmissa on varmasti tehty paljon sinänsä tarpeellista työtä, mutta kumpikaan ei ole ratkaissut yhteentoimivuuden ongelmia, vaan integraatio on edelleen ihan yhtä jähmeää.

Epäilyksille on siis perusteita. Isoissa julkisissa IT-hankkeissa yleensä päädytään tekemään raskas mammutti, myöhässä ja yli budjetin, tuottaen samalla toimittajaloukku, joka hidastaa kehitystä ja maksaa jatkossakin. Pitäisi olla vahvat perustelut, miksi tällä kertaa kävisi eri tavalla.

Koodin avoimuus hankkeessa on myös hiukan epäselvää. Sitran Mirjami Laitinen sanoi Sitran Real Time Economy-seminaarissa että palveluväylä ei ole avointa koodia, eikä jaettavissa muille. Että se on väärinkäsitys. Sittemmin tosin olen kuullut, että Laitisen esittämä käsitys olisi väärinkäsitys.

Internet-huhun mukaan koodi olisi avointa vain osittain, eikä kaikkea lähdekoodia saataisi. Vahvistusta ei ole, mutta näiden huhujen uskottavuutta lisää se, että Suomen ja Viron välisessä sopimuksessa ei mainita avoimuudesta tai ylipäänsä lähdekoodista mitään.

Kaiken tämän kruunaa, että hankkeessa on nyt onnistuttu käyttämään ensimmäinen vuosi saamatta aikaan paljoakaan. On toki kirjoitettu kokonaisarkkitehtuuri ja pidetty seminaareja. Kumpikaan ei varsinainen ketterän hankkeen avauspaukku. Kehitysympäristökin on tiettävästi pystytetty, mutta kenellekään ei anneta pääsyä siihen.

Palveluväylä näyttääkin tällä hetkellä avoimen koodin hankkeelta, jonka koodiin ei pääse käsiksi; ketterältä hankkeelta, jossa tehdään kaikkea paitsi koodataan ja kehittäjäyhteisönrakentamishankkeelta, jossa kehitysympäristöihin ei pääse kukaan käsiksi. Ja 120 miljoonaa olisi tarkoitus käyttää toistaiseksi tuntemattomaan kohteeseen.

Kumpi kuvaus tilanteesta sitten on totta? Molemmat, ja vain aika näyttää, kumpi perii voiton.

Todellisuudella on vielä tällä hetkellä edellytykset kummankin toteutumiselle. Palveluväylästä voi tulla se käännekohta, jossa jälkikäteen huomataan julkiset IT-hankkeiden kurssin kääntyneen kohti toimivaa ja järjellistä. Tai siitä voi tulla yksi pahimpia esimerkkejä siitä, miten IT:n varjolla vedetään rahat yksityiseen taskuun saamatta mitään toimivaa aikaiseksi. Lähikuukaudet ratkaisevat, kummasta tarinasta tulee totuus.

Tässä siis hahmotelma, mitä nähdäkseni pitää tehdä, jotta optimistin tarina voittaa.

Suuntaviivoja hankkeelle

Hankkeelle tarvitaan täsmälliset tavoitteet. Abstrakteista visioista pitää päästä yksi askel alaspäin konkreettisesti mitattavalle tasolle. Tällaisia täsmällisiä suuria tavoitteita näen hankkeella kolme:

1. Jokainen tieto on yhdessä ja vain yhdessä paikassa (master data). Muut tiedon tarvitsijat hakevat sen tästä tunnetusta paikasta, mahdollisesti käyttäen välikopioita, mutta säilyttämättä koskaan omaa rekisteriä.
2. Kansalaisille tarjotaan mahdollisuus nähdä omat tietonsa ja tarkistaa kuka niitä on katsellut. Tämä toteutetaan kaikelle väylään kytkettävälle tiedolle.
3. Projektissa ei luoda uusia toimittajaloukkuja. Olemassa olevat toimittajaloukut tunnistetaan ja joko rajataan vaikutuksiltaan tai puretaan.

Ensimmäinen tavoite on se mitä julkishallinto saa: selkeämmän ja toimivamman arkkitehtuurin kaikelle tiedolle ja siten toiminnalleen. Ministerienkin visioiman reaaliaikaisen verotuksen tai kuntien tuottavuusharppauksen.

Toinen tavoite on se mitä kansalaiset saavat: vahvemman hallinnan omaan dataansa, ensimmäisen askeleen kohti digitaalista kansalaisuutta eikä vain kuluttajuutta.

Kolmas tavoite taas on se mitä alan yritykset saavat: uudenlaisen lähtökohdan siihen, miten tietojärjestelmiä ostetaan, askeleita kohti toimivaa ja tehokasta markkinataloutta.

Nämä tavoitteet on oikeastaan kirjattu muodossa tai toisessa hankkeen asiakirjoihin, tiivistin ne vaan konkreettisemmiksi. Nämä tavoitteet on syytä pitää kirkkaana mielessä kaikessa toiminnassa, sillä kaiken toiminnan tulee niitä edistää. Eikä ole poissuljettua, että tavoitteita voisi olla muutama lisääkin, nämä olivat vain ne mitä minä näen.

Konkreettisesti projekti on syytä rakentaa mahdollisimman ketteräksi ja avoimeksi.

Ketteryys tarkoittaa tässä etenkin nopeita konkreettisia käyttöönottoja ja pieniä osaprojekteja. Ei vuoden mittaista suunnitteluhanketta, vaan pieniä kokeiluhankkeita, ja niiden pohjalta seuraavia pienehköjä hankkeita.

Avoimuus taas tarkoittaa mukaan ottamista. Palveluväylään on tarkoitus integroida aluksi kymmeniä, sitten satoja tietojärjestelmiä ja myös sitä käyttäviä järjestelmiä on potentiaalisesti vähintään satoja. Kaiken tämän tekeminen keskusjohdetusti ja erilaisilla kahdenvälisillä sopimuksilla veisi vuoskymmenen. Siksi pitää tehdä kaikki mahdollinen, jotta kukin virasto, kunta tai yritys voi toteuttaa omia integraatioitaan mahdollisimman itsenäisesti ja helposti.

Sitä varten tarvitaan avoimet testi- ja kehitysjärjestelmät, joilla integraatioita voi kokeilla, vapaasti käytettäviä esimerkkikoodeja, ohjeita, jne. Vielä enemmän tarvitaan väylä käyttävien ja kehittävien ihmisten yhteydenpitoa.

Palveluväylän kehittämiselle ja käytön tueksi pitää rakentaa avoimia keskustelun ja yhteistyön alustoja. Siis esimerkiksi ottaa käyttöön Github, pitää säännöllisiä avoimia seminaareja, tehdä metadatan standardointi avoimesti ja julkisesti, kutsuen kaikki kiinnostuneet mukaan jne. Petri Aukia luonnostelee joitakin hyviä käytäntöjä blogauksessaan.

Kaikki palveluväylän koodi ja mahdollisimman suuri osa integrointikoodista on syytä julkaista netissä avoimella lähdekoodilla. Ei niinkään mistään periaatteellisesta syystä, vaan koska se helpottaa uusien tahojen mukaantuloa ja nopeuttaa uusia integrointeja, kun jo tehdystä työstä voi oppia. Ei ole ollut kerta eikä kaksi, kun avoimen koodin bugi on korjattu sitä käsittelevän palaverin aikana, tai sen myöhästyessä. Avoimuus myös estää palveluväylä-integraatiota muodostumasta taas uudeksi toimittajaloukuksi.

Ja koska rahaa on jonkin verran käytettävissä, projekti voi kannustaa sillä virastoja mukaan toimintaan – ja toimintatapoihin.

Yllä kuvaamani tavoitteet ja toimintatavat tarkoittavat vallankumousta siinä, miten tietojärjestelmähankkeita Suomessa tehdään. Ne ovat totta kai paras tapa saada palveluväylä nopeasti toimintaan ja käyttöön. Mutta softa on tässä viime kädessä sivuroolissa, tärkeintä onnistumisen kannalta on muuttaa toimintatapoja ja ajattelutapoja.

Ja siksi tärkein yksittäinen ratkaisu on, millaisia ihmisiä hanketta vetämään palkataan. Sellaisen tuloksen saa, millaiset tekijät palkkaa.

Ensinnäkin, pitää palkata osaavia.

Pätevyyttä on monenlaista, ja montaa erilaista osaamista tässä tarvitaankin: poliitista, teknistä, byrokratiaa, muutosjohtamista… Ei tule olemaan helppo homma. Mutta on helppoa keksiä yksi minimiehto, jonka onnistuminen edellyttää: hankkeeseen tarvitaan ihmisiä, jotka ymmärtävät miten ohjelmistoja tehdään.

Vielä konkreettisemmin: jotta hanke voisi onnistua pitää palkata ihmisiä, jotka ovat joskus tehneet työkseen ohjelmointia, mieluiten vielä muualla kuin julkisen sektorin hovihankkijoilla. Kaikkien ei tarvitse vanhoja koodereita, mutta puolet porukasta olisi syytä olla.

Hankkeessa on tarkoitus levittää toimintatapoja, joilla softaprojektit voivat onnistua (sen sijaan että muuttuvat tahmeiksi mammuteiksi). Ja näiden tapojen levittämisessä auttaa paljon, jos oikeasti ymmärtää miten ja miksi ne toimivat.

Toisekseen, pitää palkata muutosta haluavia.

Tehtäessä muutoshanketta avain on totuttujen toimintatapojen muuttamisessa. Tarkoitus on tehdä asiat eri tavalla kuin ennen, ja siksi olisi hyvä palkata ihmisiä, jotka haluavat tehdä asiat paremmin kuin ennen. Haluavat sitä niin paljon, että ovat valmiita näkemään vähän vaivaakin, jotta hanke onnistuisi. Jos näin ei tehdä, hanke tuskin voi onnistua.

Kolmannekseen, pitää palkata ihmisiä, jotka uskaltavat rikkoa totuttuja toimintatapoja.

Kun tarkoitus on muuttaa toimintatavat, halun lisäksi tarvitaan valmiutta rikkoa vakiintuneet käytännöt. Vallankumousta ei tehdä pelkästään kabineteissa pullaa syömällä.

Näillä eväin lähtisin itse liikkeelle.

Teksti on lakujaan julkaistu Hyvä renki -blogissa, joka käsittelee suomalaisen tietoyhteiskunnan ongelmia ja ratkaisuja

Tilanne nyt, 30.1.2013:

Apotti on Helsingin ja Uudenmaan sairaanhoitopiirin (HUS) sekä kuuden pääkaupunkiseudun kunnan hanke potilastietojärjestelmän hankkimiseksi yhdessä. Hankintapäätöksiä tehdään parhaillaan ja järjestelmä on tarkoitus valita loppuvuodesta.

EPIC on wisconsinlaisen Epic Systems Corporationin toteuttama potilastietojärjestelmä, jota Accenture tarjoaa HUSille ja kunnille. Hankkeen alkuvaiheet ovat herättäneet huolen, että kilpailutusta olisi pedattu niin että Epic voittaisi sen.

Espoo on Helsingin länsiosissa sijaitseva 250 000 asukkaan kunta, joka päätti juuri olla lähtemättä mukaan Apotti-hankkeeseen.

Viikko sitten Accenture ja Epic Systems Corporation järjestivät Epicin esittelyn pääkaupunkiseudun valtuutetuille. Paikalla oli tusinan verran valtuutettuja Vihreistä, Perussuomalaisista, Kokoomuksesta ja RKP:stä. Tilaisuudesta löytyy laaja FB-kommenttithreadi, mutta yhteenvedon ja tulkinnan lukee helpommin tästä. Kaikki tiedot perustuvat Epicin asiantuntijoiden vastauksiin, poislukien mahdolliset väärinymmärrykseni.

Ensinnäkin Epic on käytettävyydeltään oikeasti hyvä. Tai no, selvästi parempi kuin nykyään suomessa käytössä olevat järjestelmät. Monimutkaisen ammattilaistyökalun käyttäminen ei ole ihan yksinkertaista hommaa ikinä. Mutta ainakin demossa klikkailumäärät vaikuttivat järjellisiltä eikä tiimalasia tarvinnut tuijottaa.

Teknisesti EPIC sen sijaan on vanhanaikainen. Sen ydin on kirjoitettu 60-luvun MUMPS-kielellä, joka on nykynäkökulmasta naurettava ja suurin osa käyttöliittymästä on Visual Basicin versiolla 6, jonka virallinen tuki lopetettiin jo 2008. Kuulema tosin Epicillä on Microsoftin kanssa sopimus joka takaa riittävän tuen.

Suurempi ongelma on kuitenkin, että Epic on myös toimintamalliltaan vanhanaikainen. Se on yksi suuri järjestelmä, joka ratkaisee kaikki ongelmat. Kolmansien osapuolien lisäosia ei suosita. Itse asiassa Epic ei tarjoa rajapintoja kolmansille osapuolille lainkaan, vaan integraatioita tehdään ainoastaan asiakkaan suorasta pyynnöstä. Rajapintojen tarkemmasta luonteesta en saanut vastauksia.

Suljettuus menee niin pitkälle, että tosiaan edes kuvia käyttöliittymästä tai tarkkoja ominaisuuksia ei haluta näyttää julkisesti. Myyntitapa muistuttaa 80-luvun kabinettipolitiikkaa, jossa vain asianomaiset tietävät mitä oikeastaan ostettiin ja myytiin, ja hekään eivät saa sitä kenellekään kertoa. Sairaaloiden IT-maailma ei ehkä ole korruptoitunut, mutta siltä tämä taatusti näyttää. Epicin edustajien mukaan syy salailuun on, että sillä estetään kilpailijoita kopioimasta Epicin ominaisuuksia.

Mielenkiintoisesti, Epic kuitenkin tarjoaa koko lähdekoodinsa asiakkaan käyttöön (mutta vain asiakkaan, ei alihankkijoiden). Ensisijainen syy tähän on juridinen: kyse on escrow-palvelua vastaavasta ratkaisusta, jollaista isot asiakkaat usein vaativat. Koodi kuitenkin myös auttaa asiakkaan mahdollista omaa integraatiotyötä. Ilkeämielisesti voisi tulkita, että kyetäkseen käyttämään rajapintoja täytyy siis nähdä ne toteuttava koodikin.

Lähtökohtaisesti siis Epicin laajennokset ja jatkokehityksen tekee Epic Systems Corporation kampuksellaan Wisconsinin Veronassa (vastaa suunnilleen Lempäälää). Jos asiakas haluaa järjestelmältä jotain ominaisuuksia, ne joko löytyvät ennestään, Epic lisää ne järjestelmään niin parhaaksi harkitessaan, tai niitä yksinkertaisesti ei saa mistään. Tietojärjestelmä on käytännössä sama asia kuin toimintatapojen ohjaus, joten tällainen hallinnan menetys tarkoittaa, että terveydenhuollon toimintatapojen kehittäminen ulkoistetaan Wisconsiniin.

Modernit ohjelmistojärjestelmät perustuvat ”ekosysteemiin”, jossa kokonaisuutta orkestroiva yhtiö tekee vain ydinosat tarjonnasta, ja lukuisa joukko pienempiä yrityksiä kehittää kukin omia laajennoksiaan. Hyviä esimerkkejä ovat vaikka Salesforce, jonka asiakkuudenhallintajärjestelmään saa muokkauksia ja laajennoksia sadoilta yrityksiltä tai SAP, jonka toiminnanohjausjärjestelmä on pikemminkin ohjelmointialusta, jonka päälle konsulttitalot koodaavat toiminnanohjauksia. Tai alaa huonommin tunteville vertaus vähän kauempaa: vanha Nokian puhelinkehitys vastaan Applen ekosysteemi ja kaikki applikaatiot.

Ekosysteemiin on menty, koska mikään yksi yhtiö ei yksinkertaisesti pysty kehittämään todella monimutkaisia järjestelmiä kaikkia asiakkaita hyvin palvelevalla tavalla. Ekosysteemi tuottaa paremman lopputuloksen. Se myös sitouttaa asiakkaat paremmin. Vaikka kaikki innovaatiot ovat kilpailijoiden kopioitavissa, ei asiakas halua luopua ekosysteemistä, koska menettää kaikki sen sisältämät palvelut. Ajattele siirtymistä iPhonesta takaisin nokialaiseen.

Mutta kuten sanottu, Epic on ekosysteemin antiteesi. Epic on Nokia. Se on kilpailijoitaan edellä käytettävyydessä samaan tapaan kuin Nokian puhelimet olivat kymmenen vuotta sitten. Eli kilpailijat ovat vaan vielä huonompia. Nykyisillä toimintatavoilla se jää aikanaan väistämättä jälkeen, kun joku kilpailija kykenee ekosysteemin rakentamaan.

Teollisuuspoliittisesti Epicin suljettuus on isompi ongelma kuin STX:n risteilijätilauksen menetys. Uuden risteilijän hytit ja muuta alihankintaa tehtäneen Suomessa ja suurimman osan töistä tekevät samat puolalaiset aivan riippumatta siitä, onko telakka Turussa vai Saint-Nazairessa. Sen sijaan Epicin alihankintatöitä ei Suomeen tippuisi, ainoana poikkeuksena Accenturen asennusdiili.

Terveydenhuollon tarkoitus ei tietenkään ole tuottaa rahaa IT-yhtiöiden kassaan (vaikka toisin voisi joskus luulla alan sopimuskäytäntöjä katsoessa). Mutta kotimaisen alan teollisuuden alasajo on ongelma muutoinkin kuin taloudellisesti. Innovaatiot terveydenhuollon paremmaksi palvelemiseksi syntyvät tarpeiden ja mahdollisuuksien ristiaallokossa, silloin kun järjestelmää kehittävät ja sitä käyttävät ovat läheisesti tekemisissä. Sitä ei tapahdu samalla tavalla 8000 kilometrin päähän.

Siriuksessa visioitu yksi kansallinen potilastietojärjestelmä olisi kansallinen katastrofi. Se tappaisi Suomesta kaiken kyvyn kehittää ja innovoida terveydenhuollon järjestelmiä ja pikkuhiljaa heikentäisi terveydenhoidon laatuamme.

Espoon päätöksen tärkein seuraus onkin, että Apotista ja Epicistä ei voi sellaista tulla. Integraatiot on nyt pakko tehdä kunnolla, eikä voida yrittää kiertää niiden tarvetta kikkailemalla yhteisellä järjestelmällä.

Ehkä parasta mitä nyt voi tapahtua on, että Epic otetaan käyttöön yhdessä sairaanhoitopiirissä tai kunnassa Suomessa, mutta ei muualla. Silloin sen parempi käytettävyys asettaa standardin sille, miten kelvollinen järjestelmä toimii. Sitten käy se, mitä Epic yrittää salailullaan välttää, eli kilpailijat kopioivat sen käytettävyyden ja ideat. Pikkuhiljaa saattaa syntyä suomalaisia järjestelmiä osaksi kansainvälistä potilastietojärjestelmien ekosysteemiä.

Ajatus vain Suomeen tehtävästä järjestelmästä on osoittautunut huonoksi. Mutta suljettujen potilastietojärjestelmien siirtomaaksi ryhtyminen ei ole sen parempi idea. Pitää tavoitella kansainvälisesti toimivia järjestelmiä, joiden ekosysteemissä myös suomalaiset alan yhtiöt menestyvät. Suurin vastuu on nyt alan yrityksillä saada kerrankin jotain kelvollista tuotettua, mutta se vaatii, että julkishallinto ei estä kehitystä.