Miten auttaa hallitusta?

Osa kokeiluista lentää. (C) Christopher Michel, Flickr CC

Petri Malmelin kysyi LinkedIn:ssä edellisen kirjoitukseni perusteella osuvan kysymyksen:

Miten digiketterät yritykset voisivat konkreettisesti edesauttaa hallitusohjelman digikappaleen tahtotilan toteutumista?

Kysymys on hyvä ja ansaitsee pikaisen, mutta luonnollisesti alustavan vastauksen.

Hallitusohjelman mukaan hallitus haluaa digitalisaation tuloksena tuottavuusloikan. Eräinä keinoina hallitusohjelmassa on mainittu ketteryys ja kokeilukulttuuri, joiden mittariksi on valittu innovatiivisten hankintojen viiden prosentin osuus kaikista hankinnoista. Lisäksi tueksi on luvassa sekä säädöspohja systemaattiselle kokeilutoiminnalle, että joukko etukäteen valittuja kokeiluja. Hallitusohjelma lupaa myös parempaa johtamista ja prosesseja, mutta tässä kirjoituksessani keskityn ketteryyteen ja kokeiluihin.

Valtion auttaminen on tunnetusti hankalaa. Tämä ei johdu niinkään siitä, että valtio ei haluaisi apua tai siitä, että valtio jo osaisi kaiken. Auttamisen hankaluus johtuu pääosin valtion käyttöön juurtuneista toimintatavoista, jotka juontavat juurensa lainsäädännöstä ja muista säädöksistä.

Lainsäädäntöön ja säädöksiin on yritysten — varsinkin pienehköjen ohjelmistoyritysten — vaikeahkoa vaikuttaa. Asiantuntevalla lobbauksella voi kuitenkin vaikuttaa hallitusohjelmassa mainittuun säädöspohjaan. Keinoina voisivat olla muun muassa:

Onnistuneiden ketterien hankintojen mainostaminen

Ketterän kehityksen hankintamallien ja sopimusmallien esimerkkien esitteleminen ja mainostaminen. Monet valtionhallinnon yksiköt ovat jo onnistuneesti hankkineet ohjelmistoja ketterästi. Tämän osaamisen levittäminen koulutuksin, aamiaisseminaarein ja lehtikirjoituksin on hyvä keino edesauttaa hallitusohjelman toteutumista.

Kokonaisarkkitehtuurimenetelmien kehittäminen

Nykyinen TOGAF:sta johdettu ja tietohallintolaissa määrätty – JHS-179 kokonaisarkkitehtuurimalli ei sovi alkuunkaan yhteen ketterän kehityksen ja kokeilukulttuurin kanssa. Digiketterät yritykset voisivat kehittää uuden, ketterään ohjelmistokehitykseen ja julkiseen hankintaan sopivan arkkitehtuurikuvausmallin.

Kilpailumalli kokeiluihin

Kokeiluja varten digiketterät yritykset voisivat kehittää arkkitehtuurikilpailuja vastaavan kilpailumallin. Sen sijaan, että ohjelmiston hankkiva valtion virasto määrittelee ratkaisun, se määrittelisi ongelmansa ja julistaisi ratkaisukilpailun. Voittaja saisi projektin toteuttaakseen — tosin ketterästi ja valtion tuoteomistajan ohjaamana — ja muut osallistujat saisivat osallistumisestaan kohtuullisen korvauksen.

Koulutusohjelmia ketteryydestä

Erilaisten ketteryyteen ja kokeilevuuteen opettavien koulutusohjelmien järjestäminen valtion ohjelmistojen hankkijoille. Tämä koulutus voisi perustua vaikkapa tuoteomistajakoulutuksiin, mutta painottaa lisäksi hankintaan liittyviä seikkoja ja säädöksiä.

Avoimen koodin suosiminen

Uusien JIT2014-sopimusehtojen mukaisen avoimen koodin hankinnan suosiminen. Valtion varoin kehitettyjen ohjelmistojen on oltava avoimia mahdollisimman sallivalla lisenssillä ja kaikkien IPR:n on jäätävä valtiolle.

Avoin lähdekoodi ei mene koskaan hukkaan

Digiketterät yritykset voisivat tuoda esimerkein esille, että epäonnistunutkin avoimen koodin projekti on usein paradoksaalisella tavalla menestys. Syntynyt lähdekoodi toimii näet seuraavien, onnistuneiden projektien osana. Avoimien projektien työ ei mene koskaan kokonaan hukkaan.

Kumppanikoodareiden suosiminen

Mitä parempi osaaminen valtion eri yksiköillä on, sitä paremmin ne pystyvät hankkimaan ohjelmistoja ketterästi ja sitä ketterämmin ne pystyvät kokeilemaan asioita.

Avoimien ohjelmistojen ja kirjastojen mahdollisuuksien esitteleminen

Mitä paremmin avoimesti saatavilla olevat ratkaisut ovat tiedossa, sitä huonommin kilpailutuksissa pärjäävät suljettuja järjestelmiä tarjoavat, kankeat ohjelmistoyritykset.

Muitakin keinoja on. Niitä voi esittää vaikkapa kommentoimalla tätä kirjoitusta. Tärkeintä kuitenkin on huomata, että tulevan hallituksen aikana valtion tapa hankkia ohjelmistoja tulee muuttumaan. Koska hankintatoimi on laeista ja säädöksistä huolimatta ihmisten välistä toimintaa, on olennaista, että digiketterät yritykset ylläpitävät hyviä ja avoimia yhteyksiä valtiolla ohjelmistoja hankkiviin ihmisiin. Olisi myös toivottavaa, että hallituskauden aikana asiantuntevat ihmiset voisivat vaihtaa työpaikkoja yritysten ja valtion virastojen välillä. Osaaminen siirtyy parhaiten ihmisten mukana.

Tämän artikkelin on kirjoittanut Matti Kinnunen ja sitä ovat sittemmin muokanneet muut Codenton työntekijät.

Ajatuksia hallitusohjelmasta ja digitalisaatiosta

Sipilän hallituksen 36-sivuisesta hallitusohjelmasta kaksi sivua käsittelee digitalisaatiota. Hallitus on huomannut, että tietokoneiden ja ohjelmistojen parempi käyttäminen saattaa – hallitusohjelman sanoin – johtaa tuottavuusloikkaan sekä yksityisellä että julkisella sektorilla.

Hallitus lupaa rakentaan yhden luukun digitaaliset palvelut, jotka nostavat tuottavuutta ja ovat käyttäjälähtöisiä. Avoimuutta on tulossa lisää, sääntely vähenemässä ja toimintaympäristö on suotuisa muun muassa teolliselle internetille.

Hallituksen tavoitteet ovat jaloja ja kannatettavia. Entä keinot? Keinoina hallitus käyttää – morsiuspuvun tapaan – jotain uutta, jotain vanhaa, jotain lainattua ja jotain sinistä. Virosta on lainattu periaate “hallinto saa kysyä vain kerran samaa asiaa”. MyDatan korostaminen on melko uutta hallitusohjelmisssa. Vanhaa on lupaus purkaa entiset prosessit ja korvata ne uusilla, mutta digitaalisilla. Sinistä – tai sinisilmäistä – ovat yleiset julistukset muutosjohtamisen organisoinnin vahvistamisesta ja vaikutusarvioinnin laatua valvovan elimen perustamisesta.

Erityisen uutta ja lupaavaa on kokeilukulttuurin käyttöönotto. Sitä varten hallitus on perustamassa ohjelman, joka koostuu isoista ja pienistä kokeiluista. Hallitus myös haluaa, että julkisista hankinnoista viisi prosenttia on jatkossa innovatiivisia – eli todennäköisesti jollakin tavalla uusia ja ennennäkemättömiä.

Miten hallituksen ohjelma täysin toteutuessaan vaikuttaisi suomalaiseen ohjelmistoteollisuuteen, johon Codentokin lukeutuu? Ainakin seuraavia positiivisia ja jo kauan odotettuja asioita voisi toivoa:

  • Julkinen hankinta siirtyy vesiputousprojekteista ketteriin projekteihin. Enää ei ensin tehdä esiselvitystä, selvitystä, määrittelyä ja sitten toteutusta, ja kaikkia vielä eri konsulttien ja ohjelmistofirmojen voimin. Jatkossa julkishallinto ostaa ohjelmistonsa ketterinä kehitysprojekteina – samaan tapaan kuin vaikkapa Helsingin yliopisto ja Aalto yliopisto jo nyt tekevät.
  • Hansel rakentaa konsulttien CV-pankin. Konsulttien ei tarvitse jokaista kilpailutusta varten täyttää uudestaan samoja tietoja aiemmista hieman poikkeavaan lomakkeeseen. Tämä säästää tuhansia työpäiviä seka yksityisellä, että julkisella puolella.
  • MyData – eli kansalaisen omistusoikeus itseään koskevaan tietoon – vahvistuu. Suomeen syntyy tähän liittyvää osaamista ja yrityksiä, jotka pystyvät laajenemaan ulkomaille. Pieniä, ketteriä kokeiluita syntyy osittain myös julkisen rahoituksen tuella. Kela, verottaja, ja sairaanhoito ovat avoimesti mukana tässä työssä.
  • Hallituksen lupaama “innovatiivinen palvelualusta terveydenhuollon alueella” ei voi tarkoittaa muuta kuin avointa Apottia. Mitä ilmeisimmin hallitus lopettaa nykyisen Apotti-projektin ja korvaa sen avoimella, suomalaisin voimin toteutettavalla terveydenhuollon järjestelmällä. Järjestelmä luonnollisesti hankitaan ketterästi. Tuloksena syntyy uutta liiketoimintaa ja avautuu vientimarkkina uudelle, innovatiiviselle ja avoimelle terveydenhuollon alustalle.
  • Innovatiivisten hankintojen viiden prosentin osuus kaikista hankinnoista tarkoittaa, että osan julkisista hankinnoista oletetaan epäonnistuvan. Tämä luo aivan uudenlaisen dynamiikan ohjelmistojen tekemiseen: voidaan tehdä ohjelmistoja kilpailuja, hackathoneja jne. hyödyntäen. Voidaan myös ostaa ohjelmistoja, joilla ei ole jo kymmenen vuoden historiaa todisteenaan ja rasitteenaan.
  • Innovatiivisuuden ja palvelualttiuden nostaminen virkamieshyveiksi tarkoittaa – yhdessä esimerkiksi esineiden internet -ohjelman kanssa – johtajien ja tekijöiden liikkumista julkisen ja yksityisen sektorin välillä. Pelkästään nykyisiä virkamiehiä uudelleen sijoittamalla ei innovatiivisuus todennäköisesti kasva.

Kun hallitus vielä on päättänyt vähentää ICT-kuluja, on tunnelma ohjelmistofirmoissa toiveikas. Tämän hallituksen aikana on mahdollista päästä kankeasta ja suljetusta vähitellen ketterään ja avoimeen.

Tämän artikkelin on kirjoittanut Matti Kinnunen ja sitä ovat sittemmin muokanneet muut Codenton työntekijät.

Uusia ajatuksia ohjelmistojen omistamisesta

Miten uudet SaaS-palvelut, avoimen lähdekoodin räjähdysmäinen lisääntyminen, avoimen tiedon hyödyntäminen ja muuttuneet ohjelmistokehitysmenetelmät vaikuttavat ohjelmistojen omistamiseen? Kuka omistaa ohjelmiston? Onko sillä merkitystä? Miten omistajuutta ja omistuksia olisi viisainta hallita?

Näistä kysymyksistä keskusteltiin valaisevien puheenvuorojen johdolla Codenton järjestämässä aamiaisseminaarissa Korjaamolla 21. toukokuuta. Puhujina olivat Baswaren Hannu Kokko, HSL:n Kerkko Vanhanen ja Codenton Petri Aukia.

Ohjelmistojen omistaminen tuotekehityksen näkökulmasta

Baswaren Hannu Kokko kertoi ohjelmistojen omistajuudesta tuotekehityksen kannalta. Kokon mukaan maailma on yhtäkkiä täynnä vaihtoehtoja. Tuotekehityksen pitää valita käytettävät komponentit, tietokantamallit (SQL vs NoSQL), kaupallisten ja avoimen lähdekoodin komponenttien välillä, käytettävät pilvialustat (Azure vs. Google vs. Amazon) ja niin edespäin. Valintaa ei helpota saatavissa olevien avoimen koodin lähdekirjastojen suuri määrä: erilaisia JavaScript projekteja on Githubissa yli 300 000. Osa niistä on hyödyllisiä.

Miten sitten valita mitä tehdä, mitä teettää muilla ja mitä omistaa? Kokko on työssään todennut seuraavat periaatteet ja nyrkkisäännöt hyödyllisiksi.

  • Ensinnäkin, ei pidä tehdä ohjelmistoja, jotka ovat vaikeita ja jotka eivät lisää kilpailukykyä. Ne on parempi ostaa valmiina.
  • Toiseksi, järjestelmien välisiä integraatiomalleja ei kannata pyrkiä keksimään itse, ennen kuin on tarkistanut löytyykö sopiva.
  • Kolmanneksi, jo ratkaistuja ongelmia ei kannata ratkaista uudestaan: ei tehdä omaa käyttöliittämäkehikkoa, ei omaa transaktiokonetta, ei omaa raportointikonetta eikä omaa sovellusten hallintajärjetelmää – kaikkiin näihin on olemassa valmiit ja usein myös avoimet vaihtoehdot.

Näiden pohdintojen jälkeen on päätettävä kuka ohjelmiston toteuttaa. Kokon mukaan olennaista on ymmärtää tilaavan organisaation oma ydinosaaminen niin liiketoiminnassa, kuin sen digitalisoinnissa. Näitä ei pidä ostaa ulkopuolelta. Järjestelmän rakentaminen ja erityisesti järjestelmien välinen integraatio on mahdollista, ja osin syytäkin, ostaa ulkopuolelta. Ostamisessa on kuitenkin oltava varovainen: olennainen arkkitehtuuriosaaminen on pidettävä omissa käsissä, on ostettava osaamista eikä tuotteita, ja osaamista on syytä ostaa useilta eri toimittajilta toimittajaloukkujen välttämiseksi.

Kokon viestin voisi tiivistää: älä tee, jos saat valmiina, mutta varmista aina oma osaaminen.

 

karo1Uusi Reittiopas avoimella lähdekoodilla ja avoimin rajapinnoin

HSL:n Kerkko Vanhanen kertoi HSL:n uudesta avoimeen koodiin ja tietoon perustuvasta Reittioppaasta. Uusi Reittiopas korvaa yli 10 vuotta käytössä olleen nykyisen Reittioppaan, joka on palvellut HSL:n miljoonaa päivittäistä asiakasta hyvin. Koska asiakkaiden odotukset ovat kuitenkin kasvaneet, teknologia on kehittynyt, ja kun vielä lippujärjestelmä uudistuu ja reaaliaikainen ajoneuvotieto on saatavissa koko HSL:n alueella, on tullut aika uusia Reittiopas.

HSL ja Liikennevirasto aloittivat uuden Reittioppaan kehittämisen vuosi sitten. Kehittämisprojektin periaatteet ovat olleet alusta asti selvät: Reittiopasta kehitetään koko Suomen kattavaan mobiilikäyttöön, lähdekoodi on avoin, rajapinnat ovat avoimet ja tarjoavat sovelluskehittäjille samat tiedot kuin HSL:n omalle mobiilikäyttöliittymälle. Kehitystiimissä on mukana HSL:n ja Liikennevirastojen kumppanikoodareitten lisäksi eri ohjelmistoyrityksistä hankittuja, osaamisensa perusteella valittuja koodareita ja Reittioppaan perustana ovat avoimet ohjelmistot, erityisesti OpenTripPlanner.

Näistä periaatteista seuraa hyvin yksinkertainen omistajastrategia.

  • HSL ja Liikennevirasto maksavat tuotteen rakentamisen.
  • HSL ja Liikennevirasto omistavat tuotteen
  • Työstä maksetaan toimittajille käytettyjen resurssien mukaan
  • Toteutuksen ja integroinnin riskit ovat HSL:n ja Liikenneviraston.

Uuden Reittioppaan nykytilaan voi tutustua http://matka.hsl.fi/-sivulla . Koska koodi on julkaistu EUPL v1.2 ja AGPLv3 lisenssein, kuka tahansa voi tutustua siihen ja käyttää sitä “copy-left & share alike” -periaatteen mukaisesti.

 Ohjelmistojen tuotannon ja omistamisen uudet tuulet

Codenton Petri Aukian mukaan ohjelmistojen tuotannossa ja omistamisessa on käynnissä disruptio. Muutaman vuoden takaiset käytännöt ja nyrkkisäännöt eivät enää päde. Maailma on muuttumassa huimaa vauhtia. Uudet, pääosin avoimet kehitystyökalut yhdessä pilvipalveluiden kanssa ovat luoneet alati kasvavan joukon uusia mobiilisovelluksia, rajapintoja ja SaaS-palveluita. On syntynyt kokeileva kulttuuri: on mahdollista tehdä sovelluksia ja ottaa niitä laajaan käyttöön suhteellisen pienin kustannuksin. Uusien, ainutlaatuisten asioiden tekeminen on paljon nopeampaa kuin ennen.

Aukian mukaan ohjelmistot voi jakaa kolmeen eri luokkaan.

  • Teetetyt sovellukset eli tiettyyn – mieluusti kilpailukykyä luovaan – tarpeeseen luodut sovellukset (esim HSL:n uusi Reittiopas)
  • Valmissovellukset eli jonkin tietyn yleisesti tunnetun tarpeen täyttävät valmiit, mutta käyttöönottoprojekteisssa räätälöitävät sovellukset (esim SAP, Oracle, Sharepoint)
  • SaaS-palvelut eli vakiintuneeseen tarpeeseen pilvestä palveluna sellaisenaan ostettavat sovellukset (esim. Google Drive, Basecamp, Dropbox)

Sovellusten jaottelu

Yleisesti kussakin sovelluskategoriassa teetetyistä sovelluksista tulee vähitellen valmissovelluksia ja sitten SaaS-palveluita. Samalla sovellusten ainutlaatuisuus vähenee ja ne muuttuvat sellaisenaan hankittaviksi palveluiksi. Koska SaaS-palveluiden muokkaaminen on lähes mahdotonta, ja koska uudet ohjelmistokehitysmenetelmät sallivat nopeat käyttöliittymät ja palveluiden yhdistämisen käyttöliittymisssä, SaaS-palveluiden päälle on mahdollista rakentaa kilpailukykyä parantavia, ainutlaatuisia teetettyjä sovelluksia.

vertailu

Kokonaisarkkitehtuurin kannalta Aukian analyysi antaa uuden näkökulman sovellusten elinkaaren miettimiseen. Sovelluksia olisi syytä pyrkiä aktiivisesti siirtämään teetetyistä valmisohjelmistoihin ja valmisohjelmistoista SaaS-palvelujen käyttöön. Mikäli jonkin asian voi ostaa palveluna, sitä ei kannata itse omistaa – on parempi vapauttaa voimavarat kilpailukykyä luovien teetettyjen ohjelmistojen luomiseen. Ohjelmistoja on käsiteltävä, kuten muutakin omaisuutta: sijoitettava arvoaa kasvattaviin ja vuokrattava arvoaa menettävät.

Ohjelmiston ostamisessa ja sopimuksia tehtäessä on myös ymmärrettävä mihin kolmesta luokasta ostettava ohjelmisto kuuluu, jotta on mahdollista keskittyä olennaisiin asioihin. Aukian mukaan näitä ovat seuraavat.

sopimus 1

sopimus 2

Codento tarjoaa palvelua ohjelmistojen haltuunottoon Aukian esittämän jäsentelyn mukaisesti. Haltuunotto kestää kaksi kuukautta, minkä jälkeen Codento auttaa hallitsemaan ohjelmisto-omaisuutta samaan tapaan, kuin sijoitusneuvoja hoitaa asiakkaidensa omaisuutta.

haltuunotto

Tämän artikkelin on kirjoittanut Matti Kinnunen ja sitä ovat sittemmin muokanneet muut Codenton työntekijät.

Tietoturvassa perustukset on tehtävä ensin

Kaikille on päivänselvää, että talon perustukset on rakennettava ennen seiniä ja kattoa. Täsmälleen sama koskee myös tietoturva-arkkitehtuuria. Perustuksia ei voi koskaan tehdä seinien jälkeen, eikä tietoturvaa jälkikäteen.

Tietoturva on aika kompeli ala, josta alan ulkopuoliset ymmärtävät vain vähän. Siksi vedän mutkat suoriksi ja käytän tässä blogipostauksessa allegorioita fyysisestä maailmasta. Pyydän anteeksi turva-alan vanhoilta kollegoiltani – tarkoitus pyhittää keinot.

Suomen Kuvalehden jutussa projektipäällikkö kertoo, että hankkeen tässä vaiheessa ei ole vielä työskennelty vilpintahtoisten toimijoiden estämiseksi. Se kertoo siitä, että hankkeessa ollaan rakentamassa taloa ennen perustuksia. Komea ulkokuori ilman perustuksia.

Tietoturva-alan ammattilaiset ovat tottuneet siihen, että järjestelmien kehittäjätiimeiltä jää huomaamatta tuhansia pikkuvirheitä. Siksi osaava arkkitehti suuunnittelee sovelluksen niin, että vain muutama kohta pitää tehdä erityisen huolella, ettei yksi tai edes kaksi yksittäistä virhettä voi kaataa koko systeemin turvallisuutta.

Hyvin suunniteltuun järjestelmään on siksi vaikea hyökätä edes kesken kehitysvaiheen. Kruununjalokivet talletetaan tavalla, jossa kohdista, joihin pääsee käsiksi, ei pääse siihen, mitä suojataan. Arkkitehtuurin ja tietoturvan miettimiseen ja suunnitteluun on alussa käytettävä riittävästi aikaa. Vaikka miten olisi olevinaan kiire, niin näitä asioita ei voi siirtää myöhempiin vaiheisiin.

Hyvä esimerkki turvan oikein tekemisestä on pankin kassaholvi. Isoissakin pankeissa holviin tehdään vain yksi ovi, jotta se voidaan tehdä niin laadukkaaksi kuin mahdollista ja sitä voidaan valvoa haukan tavoin. Ennen kuin holviin pääsee on ensin pitänyt päästä monenmoisten turvattujen kerrosten läpi. Ulko-ovet on lukittu, tiloissa on hälytykset, asiakkaita ei päästetä tiskin taakse eikä kassakaappiinkaan pääse, ennen kuin monet lukot on ohitettu.

Kassaholvi on turvallinen, vaikka osa lukoista olisi kierrettävissä.

Huono tietoturva-arkkitehtuuri sen sijaan on kuin vanha seurojentalo, jonka kaikki ovet johtavat isoon huoneeseen, jonka keskelle rahakasa on jätetty. Hyökkääjällä on monta ovea, joista valita ja puolustajan resurssit on jaettu niin laajalle, ettei ovista saada pankkiholvitasoisia. Turvasuunnitelma on, että talon muuten valmistuttua, oviin laitetaan jumalattoman kalliit lukot.

Jälkikäteen väkisin tehdyt turvaratkaisut eivät koskaan voi olla yhtä laadukkaita tai helppokäyttöisiä kuin alun perin hyvin suunniteltu turvallisuus. Tietoturvakeijuja, jotka lopuksi ratkovat pulmat ripottelemalla taikahiekkaa järjestelmien päälle, on vain saduissa.

Ylioppilastutkintolautakunta on valinnut erityisen vaikean tien. Heidän mallinsa turvallisuus perustuu siihen, että yleiskäyttöistä tietokonetta yritetään saada kuriin ja kontrolliin. Ehkä tietoturva-arkkitehtuuri olisi pitänyt rakentaa toisin? Ongelma on sama, jonka kanssa matkapuhelin- ja konsolipelivalmistajat painivat jatkuvasti. Miten varmistaa, ettei pikku-Petteri ohita tehdyn kopiosuojauksen rajoja omaksi edukseen? Tuossa onnistuminen on vaikeaa maailman suurimmille laitevalmistajille, jotka toimittavat samalla kertaa niin koneen kuin sen sovelluksenkin.

Ehkä joudumme tottumaan siihen, että ylioppilasarvosana ei ole yhtä luotettava lukiomenestyksen mittari kuin ennen.

Uuden digitaalisen maailman tärkeitä järjestelmiä kehittäville asiakkaillemme ehdotan ainakin seuraavien peukalosääntöjen noudattamista:

  1. Varmista, että järjestelmällä on arkkitehti, joka on tehnyt vastaavan vaativuusasteen hankkeita turvallisesti ennenkin.
  2. Varmista, että arkkitehdillä on aikaa ja valtaa tietoturvaongelmien ratkaisemiseen.
  3. Luo uhkista ja riskeistä dokumentti yhdessä arkkitehdin kanssa ja hae tälle valitulle riskitasolle hyväksyntä ylimmältä johdolta.
  4. Älä siis lyö toiminnallisuutta lukkoon ennen kuin arkkitehtuuri on valmis. Turvallinen järjestelmä voi olla helpompi tehdä, jos toiminnalisuus ei olekaan ihan tarkalleen sellainen, kuin konseptivaiheessa oli suunniteltu.
  5. Älä anna arkkitehdin keksiä uusia tapoja suojata järjestelmääsi. Ei talojakaan varten suunnitella uusia lukkoja.
  6. Kysy kunkin osa-alueen osalta, mitä tapahtuisi, jos ulkopuolinen löytäisi siitä hyödynnettävissä olevan haavoittuvuuden. Varmista näin, että turvamalli ei ole yksikerroksinen.
  7. Kysy jokaisen turvaratkaisun osalta, miten se on tarkoitus testata. Testaamattomat ratkaisut ovat turvattomia.
  8. Käy läpi, mitä tapahtuu, jos turvaratkaisut silti pettävät. Tuleeko hälytyksiä ja jääkö jäljelle edes kuvaus siitä, mitä pääsi tapahtumaan?
  9. Loppujen lopuksi varmista, että arkkitehtuuri näyttää suoraviivaiselta. Monimutkaiset arkkitehtuurit ovat useimmiten myös turvattomia.

Codento valittu Hanselin IT-konsultointi 2015 – 2019 -puitesopimuksen alueille A, B ja F

Hanselin IT-konsultointi 2015 – 2019 -puitesopimuskilpailutuksen tulokset saivat lainvoiman 5.5.2015. Voimme nyt nöyrinä ja samalla ylpeinä kertoa, että Codento ja yhteensä 51 loistavaa alihankkijakumppaniamme jatkavat työtä onnistuneiden julkishallinnon IT-projektien eteen myös uudessa Hansel-puitesopimuksessa.

Codenton palveluita saa uuden IT-konsultointi 2015 – 2019 -Hansel-sopimuksen kautta seuraaville alueille:

  • A: Projektinhallinta- ja integraattoripalvelut
  • B: Määrittely- ja arkkitehtuuripalvelut
  • F: Tietoturvallisuus, auditoinnit ja varautuminen

Tuloksista tarkemmin Hanselin omilla sivuilla:
https://www.hansel.fi/uutiset/it-konsultoinnin-hankintapaatokset-ovat-nyt-lainvo
https://www.hansel.fi/uutiset/hankintapaatokset-it-konsultoinnista 

“Olemme innoissamme kilpailutusvoitosta”, kertoo Codenton julkishallinnon asiakkuuksista vastaava Tommi Ullgrén. “Meidän hommanamme on poistaa asiakkaiden stressiä ja tehdä julkishallinnon IT-hankkeista parempia ja onnellisempia. Sitä työtä pääsemme nyt jatkamaan.”

Muutosagentin työrukkanen on siis hihat käärittynä valmiina projektien kimppuun. Ota yhteyttä.