Sami Somero Goforen hallitukseen

Sähköisten palvelujen kehittäjä Gofore Oy täydentää hallitustaan vahvalla yrittäjäkokemuksella. Huhtikuun alussa hallituksen jäseneksi on liittynyt kokenut IT-yrittäjä ja kasvuyritysten aktiivinen taustavaikuttaja Sami Somero.
Neljä vuotta sitten Somero jätti menestyksekkään uran IT-yrittäjänä ja toimii nyt usean kasvuyrityksen hallituksessa, toisissa myös partnerina.
– Olen mukana yrityksissä, jotka ovat oman alansa aallonharjalla edistämässä toimialansa muutosta tunnistetussa murrosvaiheessa ja joille murros on mahdollisuus kasvuun. Gofore on juuri tällainen, Sami Somero sanoo.
– Gofore on erityisesti vahva julkisten sähköisten palvelujen kehittäjä ja uudistaja.  Sen arkkitehtuuriosaaminen tuo kehittämiseen kokonaisnäkemystä ja toimintamallit joustavuutta, joita tarvitaan, kun hallinnon tietojärjestelmät ja palvelut mullistuvat lähivuosina.
Sami Someron nimi yhdistetään ohjelmistotalo Almareen ja sen kasvuun kymmenessä vuodessa ensin kansainväliseksi Plenwareksi ja myöhemmin Cybercom Finlandiksi.  Goforen hallituksessa Somero näkee roolikseen toimia uusien näkökulmien avaajana ja totuttujen tapojen kyseenalaistajana.
– Yrityksen liiketoiminta on erinomaisessa kunnossa ja yhteishenki  poikkeuksellisen hyvä. On hienoa olla mukana tukemassa yrityksen kasvun jatkumista.
Goforen hallituksessa jatkavat Timur Kärki, Ali Saadetdin ja Petteri Venola.

Goforella huippuvuosi

Goforelle vuosi 2013 oli kaikilla mittareilla menestys. Yrityksen liikevaihto oli 6 miljoonaa euroa, jossa on kasvua edellisvuodesta 62 prosenttia. Työntekijöiden määrä kasvoi yli 40 prosenttia ja on nyt noin 70. Kasvusta huolimatta yrityksen talous on vahvoissa kantimissa. Liikevoitto oli lähes 15 prosenttia liikevaihdosta.
– Viime vuosi oli meille yhdeksäs peräkkäinen kannattavan kasvun vuosi, ja kasvu-uralla aiomme myös jatkaa. Sami Someron saaminen mukaan hallitustyöskentelyymme tukee vahvan kasvun strategiaamme, sanoo Timur Kärki, Gofore Oy:n toimitusjohtaja ja yksi yrityksen perustajista.
sami somero_2014
Lisätietoja
Gofore Oy, toimitusjohtaja Timur Kärki, 040 828 5886 timur.karki@gofore.com

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.

Using Akka with Spring

The project I currently work in is a Service Oriented Architecture (SOA) based system for the Finnish National Board of Education. The system is responsible for the whole joint application period in which (at the moment) all secondary education can be applied for. Our team is responsible for the actual calculation of points for each applicant and the final layout of students for each school.
In order to make a difference between applicants there is a set of formulas for each school that score applicants based on different rules. These formulas are modelled as a tree of functions, in which the number of branches, the number of nodes and the depth of the tree is unlimited. The actual calculation of each application is implemented as a separate Scala module, which is both fast enough and forced to execute the operation incrementally. However, these function trees are also exposed for the modelling interface through a REST API implemented with JavaSpring, and JAX-RS. Each function in the tree is a complex object with multiple relations to other objects. The tree needs to be fetched and constructed in a single recursive loop that started to take tens of seconds to complete for the most complex formulas. I wanted to make this operation faster by processing each branch and node concurrently.
Before joining Gofore last autumn, I had developed almost entirely with Scala for at least a year. As a Scala developer, I was of course familiar with the awesome Akka library, which is

”a toolkit and runtime for building highly concurrent, distributed, and fault tolerant event-driven applications on the JVM.”

Simply put, it enables and simplifies the development of Reactive Applications with Actors. Actors are small entities with mailboxes that run concurrently and communicate with each other through asynchronous messaging. The actor model is a powerful and easy to understand abstraction for both concurrency and asynchronous messaging. Akka has bindings for both Scala and Java with very few (if any) fundamental differences and if you know one you know both. If you are interested in more detailed introduction to Akka and the Actor model you could check out for example this blog post.
I knew that with Akka I could develop the concurrent implementation, but I had zero understanding on how well Akka and Spring would play together. At first I gave it shot by myself, which lead to a series of epic failures. Fortunately, I found this great Typesafe Activator template that included a configuration file for setting up an Actor system aware of Spring’s Application Context. With the help of the template (and now knowing that when running tests with HSQDB and Akka you should set the database transaction control to MVCC) everything has worked smoothly and much faster. Unfortunately, I didn’t run any specific tests to measure the exact improvement gain from the concurrent processing, but at least now the slowest tree construction takes well under ten seconds meaning that the most complex formulas take many hundred percents less time to construct.
Below is a simplified example of one of our services and actors. There is a method in the service layer (getFunctionRecursively) which takes an ID of the root node in the function tree, fires up the Actor System, creates the master actor and asks the master to construct the formula.
https://gist.github.com/kjsaila/e42654ebafa013d4a0b0
The actual Actor is quite simple. The receive method is mostly interested in messages with the type of Recursion or Function. When it receives a Recursion message it will fetch the current tree’s (or subtree’s) root Function and starts to construct its subtrees by spawning a new Actor for each of nodes. If the actor receives a Function message it knows that it’s from one of the child actors and adds the function to the set of constructed children. Finally the root actor responds with the fully constructed formula to the method in the service layer.
https://gist.github.com/kjsaila/a8edcbca68684e28cb58
As a developer familiar with Scala, I wasn’t surprised of how well and easily the actors worked. I wasn’t even that amazed for the simplicity of concurrent programming since Scala has many relatively easy ways for getting it done. However, in the Javaland it is usually a much harder thing (Java 8 will help to some degree) and for that reason I advise all of you Java developers to take Akka for a spin.
Side note: I recently heard about a framework called Reactor which share some commonalities with Akka. It would be nice to test it as well.

Avatar

Kalle Säilä

Linkedin profile

Piditkö lukemastasi? Jaa se myös muille.

Liikenteen turvallisuusvirasto Trafi on valinnut Goforen puitesopimustoimittajaksi sähköisen asioinnin palvelujensa kehittämiseen. Ensimmäinen hanke tämän sopimuksen puitteissa alkoi maaliskuussa 2014.
Trafi haluaa tarjota asiakkailleen kattavan ja helppokäyttöisen sähköisen palvelukokonaisuuden. Sen käyttäjiä ovat mm. yksityishenkilöt, liikenneammattilaiset ja välillisesti kaikki liikenteessä liikkujat ja matkustajat.
Trafin kilpailutuksessa Gofore sai kolmesta valitusta puitetoimittajasta parhaat pisteet. Sopimuskausi kestää viisi vuotta. Goforen alihankkijana Trafi-yhteistyössä toimii Ambientia Oy.
Aiemmin Gofore ja Trafi ovat tehneet yhteistyötä Liikenteen turvallisuusviraston kokonaisarkkitehtuurimenetelmien ja sähköisen asioinnin viitearkkitehtuurin kehittämisessä.
Lisätietoja:
Gofore Oy
Juha Virtanen
Liiketoimintajohtaja, sähköisten palveluiden rakennustoimisto
050 413 3136
juha.virtanen@gofore.com

Avatar

Juha Virtanen

Juhan vastuulla on Goforen myynnin ja asiakkuuksien johtaminen. Erityisesti Juhan sydäntä lähellä on maailman muuttaminen paremmaksi uusien digitaalisten innovaatioiden ja toimintatapojen kautta. Tällä hetkellä Juhan tärkeimpänä tehtävänä on kehittää Goforesta Suomen parasta asiakasarvoa tuottava digitalisoinnin kumppani.

Piditkö lukemastasi? Jaa se myös muille.

Julkisten tietovarantojen avaamisen ympärillä tapahtuu. Isoja datan avauksia on tehty, ja ministeriöissä ja virastoissa laaditaan avoimen tiedon suunnitelmia ja mietitään avoimen toimintamallin strategisia ja teknisiä linjauksia.
– Julkisen hallinnon toimijoiden suhtautuminen tietovarantojen avaamiseen on viime vuosina muuttunut selvästi myönteisemmäksi, sanoo valtiovarainministeriön neuvotteleva virkamies Anne Kauhanen-Simanainen.
Kauhanen-Simanainen koordinoi kansallista avoimen tiedon ohjelmaa, joka vauhdittaa julkisten tietovarantojen avaamista purkamalla esteitä ja luomalla käytäntöjä, puitteita ja välineitä tiedon avaamiselle.
Koordinaattorin paikalta avautuu laaja näkymä toimijakenttään. Ainakin yksi selitys asenteiden muutokseen löytyy Kauhanen-Simanaisen mukaan organisaatioista itsestään.
– Monessa talossa on menossa toimintakulttuurin muutos, ja tiedon avaaminen tukee sitä. Avoimen tiedon hyödyt yhteiskunnalle ja kansantaloudelle ymmärretään, ja nähdään, että nyt ollaan yhdessä luomassa edellytyksiä jonkin uuden syntymiselle.

Talous uudistuu, hallinto tehostuu

Julkishallinnolla on valtavat varannot julkista tietoa. Tämä tieto ollaan nyt Suomessakin avaamassa uudelleenkäytettävään muotoon ja saataville. Anne Kauhanen-Simanainen kertaa perustelut:

  • Se on kansataloudellisesti järkevää, sillä tiedon uudelleenkäyttö luo mahdollisuuksia uusiin palveluihin ja uudelle liiketoiminnalle.
  • Hallinnon sisäinen tehokkuus paranee, kun päällekkäistä tiedonkeruuta ja hallintaa voidaan karsia.
  • Hallinnon läpinäkyvyys paranee ja demokratia vahvistuu, kun esimerkiksi tietoja yhdistämällä ja havainnollistamalla voidaan parantaa asioiden ymmärrettävyyttä ja muodostaa uutta tietoa päätöksenteon tueksi.
  • Koulutuksen ja tutkimuksen aineistot monipuolistuvat. Sillä on suuri merkitys tulevaisuuden kilpailukyvyn kannalta.

USA ja Iso-Britannia globaalin trendin kärjessä

Ajatuskulku avoimen tiedon (open data) -aatteen takana on karkeasti pelkistettynä tämä: Uuden kasvun merkittävin tekijä on kyky soveltaa teknologiaa. 2000-luvulla kehityksen draiveri on tieto- ja viestintäteknologia. Data on sen raaka-ainetta, ja avaamalla valtavia tietovarantojaan julkinen hallinto luo mahdollisuuksia uudelle liiketoiminnalle ja uusille palveluille.
Yhdysvalloissa ja Isossa-Britanniassa hallinnon datan avaaminen on jo otettu osaksi toimintapolitiikkaa ja strategioita, ja EU on ohjannut PSI- eli Public Sector Information -direktiivillään jäsenmaita helpottamaan julkisen tiedon avaamista jo vuosituhannen vaihteesta.

Suomessa hallituksen kärkihanke

Suomessa valtio tarttui asiaan kolmisen vuotta sitten järein toimin. Julkisen tiedon hyödyntämisen edistäminen julkisia tietovarantoja avaamalla on kirjattu hallitusohjelmaan kärkihankkeeksi kilpailukyvyn painopistealueella, ja tavoite on keskeinen julkisen hallinnon ICT-strategiassa, ICT2015-työryhmän ehdotuksissa ja hallituksen rakennepoliittisessa ohjelmassa.
Tämä kaikki on tuonut valtionhallinnon organisaatioihin painetta ryhtyä toimiin julkisten tietovarantojensa avaamiseksi, ja muutamia isoja tietovarantoavauksia on jo toteutettukin.
Teknisiä edellytyksiä datan avaamiselle ja uudelleenkäytölle luo vuoden 2014 aikana rakentuva kansallinen dataportaali, josta löytyvät tiedot julkisen hallinnon tietovarannoista.

Laillisesti, teknisesti ja maksutta

Data on avointa silloin, kun se on laillisesti, teknisesti ja maksutta kaikkien saatavilla ja uudelleenkäytettävissä kaupallisiin ja ei-kaupallisiin tarkoituksiin.
– Teknisen ja laillisen uudelleenkäytettävyyden edellytysten suhteen olemme pitkällä, sillä kansallinen dataportaali on valmistumassa osana yhteentoimivuuspalvelujen kokonaisuutta, ja ehdotus datan avoimen lisensoinnin JHS-suositukseksi on tulossa käsittelykierrokselle vielä tänä keväänä, Anne Kauhanen-Simanainen sanoo.
–  Maksuttomuus toteutuu jo monen ison tietovarannon, esimerkiksi Maanmittauslaitoksen ja Ilmatieteenlaitoksen datan osalta. Eteneminen laajojen tietovarantojen avaamisessa ei onnistu kertaheitolla, koska myyntituloja saavien virastojen pitää pystyä sopeuttamaan datan avaamisen vaikutukset talouteensa pidemmällä ajalla.
Tavoitteena on, että kaikki merkittävät tietovarannot saadaan avoimiksi tällä vuosikymmenellä.

Suljetut rajapinnat tulevaisuudessa poikkeus

Gofore on sisällä avoimen tiedon ja julkisen datan avaamisen prosesseissa monella tasolla. Se tekee kokonaisarkkitehtuurityötä ministeriöiden ja virastojen kanssa, rakentaa Valtiokonttorin kumppanina yhteentoimivuuspalvelujen portaalikokonaisuutta ja on toteuttanut avoimen datan koulutuksia, tieto-omaisuuden ja -varantojen kartoituksia, tiedon avaamiseen tähtääviä suunnitelmia sekä avoimen datan rajapintojen ja palveluiden kuvauksia useille julkisen hallinnon asiakkailleen.
Goforen toimitusjohtaja Timur Kärki on eri yhteyksissä muistuttanut, että nyt tehtävä suljetun datan avaaminen on vasta ensimmäinen askel matkalla kohti avointa tietoa.
– Olemassa olevien järjestelmien tieto on lähtökohtaisesti teknisesti suljettua, vaikka tieto sinänsä olisi täysin julkista. Tulevaisuudessa lähtökohtana pitää olla avoimuus. Lainsäädäntöön perustuvista käyttörajoituksista pidetään kiinni, mutta muuten kaikki rakennetaan alun alkaen avoimeksi, Kärki sanoo.
– Juuri näin, Anne Kauhanen-Simanainen vahvistaa.
– Se merkitsee julkisessa hallinnossa isoa ajattelutavan muutosta, mutta toteutuu sitä mukaa kun elinkaarensa päähän tulleita järjestelmiä uusitaan.

Koulutuksella hyödyt kotiin

Taloustaantumassa tiedon avaaminen nähdään erityisesti kilpailukyvyn edistäjänä, ja nopeita tuloksia odotetaan.
Anne Kauhanen-Simanainen painottaa myös muiden osa-alueiden tärkeyttä ja nyt alkaneen työn pitkää aikaperspektiiviä.
– Itse näen, että koulutuksella on ratkaiseva rooli siinä, miten me Suomessa pystymme tulevaisuudessa hyödyntämään kotimaisia ja kansainvälisiä avoimia tietovarantoja. Kun ihmisillä on tietoa ja taitoa löytää ja yhdistellä erilaista dataa, syntyy uusia palveluja ja uutta liiketoimintaa, joita emme osaa edes kuvitella.
TEKSTI Marketta Tammisto, Effet

Avatar

Riikka Nurminen

Piditkö lukemastasi? Jaa se myös muille.

Julkishallinnon tuottaman ja omistaman datan avoin saatavuus on yksi hallinnon läpinäkyvyyden mittareista. Ei toki ainoa eikä merkittävinkään, mutta oikein sovellettuna ja hyödynnettynä avoin data on yksi keino, jolla saamme tehostettua suomalaisen yhteiskunnan toimintaa. Jotta tuo tavoite saavutetaan, meidän on tiedettävä miten datan avaaminen tulisi tehdä. Samoin on ymmärrettävä mitä avoin data ja avoin tieto itse asiassa ovat. Ne kun eivät ole sama asia.
Datan avaamisen pohdinta tulee aloittaa strategisten tavoitteiden tunnistamisesta: miksi dataa avataan, mitä datan avaamisella tavoitellaan ja mitä seurannaisvaikutuksia datan avaamisella on. Samoin on ymmärrettävä, mitä datan ja tiedon avaamisella halutaan nimenomaisesti välttää tai estää tapahtumasta. Näin siksi, että avoimeen dataan ja avoimeen tietoon liittyvät mahdolliset ongelmat eivät niinkään ole luonteeltaan teknisiä vaan ensisijaisesti toiminnallisia ja taloudellisia. Etenkin kun vaikutukset ovat yleensä peruuttamattomia; jos data on avattu julkiseen käyttöön, se on vapaassa jakelussa eikä sitä saada enää suljettua. Toki on huomattava, että vaikka kerran avattua dataa ei saada enää suljettua, se kuitenkin vanhenee jollain aikavälillä. Vaikka datan julkaisu voi osoittautua vääräksi ratkaisuksi, niin virheistä voidaan oppia. Lyhyellä aikavälillä aikaansaatu vahinko voidaan laskea osaksi oppimisprosessia.
Teknisesti ottaen datan avaaminen on suoraviivaisempaa. Yksinkertaisimmillaan avoin data voi olla missä tahansa muodossa olevaa rakenteetonta dataa, joka on tehty julkisesti saataville. Kehittyneemmässä lähestymistavassa avoimeen dataan voidaan lisätä rakenteisuutta, avoimia ja sovellusriippumattomia tietoformaatteja, niistä voidaan tehdä osoitettavissa olevia tietoalkioita tai dataan voidaan sisällyttää kontekstisidonnaisia linkityksiä. Kontekstisidonnaisuuden myötä avoimesta datasta voidaan jalostaa avointa tietoa, jolla onkin sitten jo kertaluokkaa enemmän sisäänrakennettua arvoa. Kontekstisdonnaisuuden yhteydessä on huomioitava, että monissa tapauksissa datan avaaja on investoinut aikaa ja rahaa kontekstisidonnaisuuden tuottamiseen, mikä osaaltaan on yksi sisäänrakennetun arvon komponentti.
Tekniikka sikseen, mutta mihin asioihin olisi sitten kiinnitettävä huomiota, kun julkishallinnon tuottamaa ja jalostamaa dataa halutaan avata? Kokemuspohjaisesti olemme havainneet, että aiheeseen liittyvät pohteet on hyödyllistä jakaa viiteen eri näkökulmaan, joita kutakin voidaan tarkastella verraten itsenäisesti.
Ensimmäinen käsiteltävä teema kattaa datan avaamisen tavoitteiden tarkastelun; miksi julkinen toimija ylipäänsä haluaa avata dataa ja millaisia kokonaishyötyjä avaamisella tavoitellaan. Minimissään tavoite voi olla tehdyn poliittisen päätöksen toteuttaminen. Toisaalta tavoite voi myös olla tietyn toimialan tukeminen ja kaupallisten toimijoiden liiketoimintamahdollisuuksien avaaminen.
Kun tavoitteista on sovittu, on analysoitava mitä tiettyä dataa halutaan avata. Tähän liittyvässä tarkastelussa on ymmärrettävä ne rajoitteet ja mahdollisuudet, joita kuhunkin avattavaan datalajiin liittyy. Olennaista on, että avattava data on sellaista, jolla on paitsi kysyntää datan kuluttajien keskuudessa, myös avattuna kaikille osapuolille turvallista. Datan avaaminen ei saa rikkoa julkiselle viranomaiselle asetettuja velvoitteita ja vastuita. Tällöin on varmistettava, että avaamisesta ei koidu ennakoimattomia seuraamuksia dataan liittyvän arvoketjun toimijoille. Esimerkkinä vaikkapa se, että avaamalla aiemmin suljettua tai suojattua dataa, julkinen toimija vahingossa tulee neutraloineeksi oman asiakkaansa liiketoimintamallin.
Kun tiedetään, mitä tavoitellaan ja mitä tarjotaan, on myös ymmärrettävä mikä on avattavan datan kohdeyleisö ja mitä arvopotentiaalia tälle yleisölle tarjotaan. Se, että data laitetaan julkiseen verkkoon saataville ja toivotaan, että joku sitä käyttää, johtaa harvoin kokonaisuuden kannalta parhaaseen tai edes riittävään lopputulokseen. Onnistuneeseen datan avaamiseen kuuluu se, että julkinen toimija pyrkii ennakoimaan, ketkä avattavaa dataa tulevat käyttämään ja miten haluttu arvo syntyy avattua dataa jalostamalla. Näin siitäkin huolimatta, että avoimen datan suuri potentiaalinen arvo on myös ennakoimattomissa käyttötavoissa. Ennakoimattomien datan käyttäjien ja toivottujen datan käyttäjien arvon muodostamisen haaste on myös datan avaamisen viestinnän suunnittelussa. Viestinnäksi kun ei riitä, että avoin data on jossain julkisen levyn kulmalla hakukoneiden saatavilla. Hyvin suunniteltu ja toteutettu viestintä on yksi keskeinen onnistumisen mahdollistaja.
Tavoitteiden ja hyötyjen lisäksi on ymmärrettävä käytössä oleva operatiivinen tapa, jolla julkinen toimija tunnistaa, kerää, verifioi, hyödyntää ja julkaisee datansa. Käytännössä julkisen toimijan on tarkasteltava omia datan käsittelyyn liittyviä käytänteitä varmistaakseen sen, että julkaistava avoin data on vain ja ainoastaan sellaista dataa, joka on nimenomaisesti avoimeksi tarkoitettu. Julkisyhteisön sisäisten prosessien kannalta tämä tarkoittaa sitä, että ei-avoimen datan ja avoimen datan käsittelytavat on määritelty ja toteutettu siten, että datan avaaminen on aina tietoinen toimenpide. Tällöin painopiste on nimenomaisuudessa: vain ja ainoastaan avoimeksi tarkoitettua dataa syötetään avoimen datan julkaisuprosessiin.
Viidentenä tarkasteltavana aihekokonaisuutena on syytä pitää myös riskien ja väärinkäytösten hallintaa. Tämä pohjautuu siihen, että julkisten toimijoiden hallussa on datakokonaisuuksia, jotka kuvaavat erilaisiin ihmiselämän osa-alueisiin liittyviä ilmiöitä. Avattavan datan osalta lähtökohtana on, että mikään avattavista datakokonaisuuksista ei aiheuta tai niiden ei pitäisi aiheuttaa yksittäiselle kansalaiselle tai ryhmälle kansalaisia heidän turvallisuuteensa tai yksityisyyden suojaansa liittyviä ongelmia. On kuitenkin olemassa skenaarioita, joissa sinänsä harmittomia yksittäisiä datakokonaisuuksia yhdistelemällä ja analysoimalla voidaan saada aikaan tietokokonaisuuksia, jotka yhdisteltyinä mahdollistavatkin potentiaalisesti hyvinkin huolestuttavien käyttötapojen esiintymisen.Tällaisiakin esimerkkejä historiasta kyllä löytyy.
Yllä esitetyt näkökohdat muodostavat käytännössä minimitason sille tahtotilan tarkastelulle, joka julkisen viranomaisen tulee käydä läpi ennen siirtymistä suljetun datan avaamisen tekniseen toteuttamiseen.

Avatar

Mikko Kolehmainen

Mikko Kolehmainen is a Leading Consultant with extensive experience in software engineering, architectural work, project management, strategy development and organization management. With exceptionally wide-ranging experience, he is able to effectively analyze business strategy objectives and describe them as business-oriented and business-driven requirements for an organization.

Linkedin profile

Piditkö lukemastasi? Jaa se myös muille.

Millainen Suomi on 30 vuoden kuluttua? Näin pitkällä ajanjaksolla voi tulla isojakin mullistuksia yhteiskunnallisesti tai poliittisesti. Joitakin asioita voidaan kuitenkin ennustaa liittyen tietotekniikan hyödyntämiseen yhteiskunnan tukena. Internet-of-things, Big Data ja pilviteknologiat ovat vielä hypeä, mutta jo nyt ne muodostavat perustan täysin uudentyyppisille palveluille. Tämä tuleekin tarpeeseen, sillä ilman teknologian tuomaa palveluiden tehostumista meillä olisi väestön ikääntymisen myötä vääjäämättä edessä elintason dramaattinen aleneminen.
Mutta miltä ne palvelut näyttävät tulevaisuudessa?

  • Terveydenhuolto tulee nojaamaan oleellisesti enemmän tietoteknisiin mahdollisuuksiin. Timur-vaari pystyy jollakin päätelaitteella seuraamaan terveydentilansa tärkeimpiä suureita. Itsediagnoosi onnistuu kotoa käsin, jolloin kysymyksiin annettavat vastaukset yhdistetään tietoon perimästäni, sairaushistoriaani, minuun kytkettyjen antureiden tuloksiin sekä sen hetkiseen lääkitykseeni. Tämän diagnoosin tuloksena voidaan antaa hoito-ohjeita tai jopa määrätä lääkityksiä. Toki voin saada myös lähetteen lääkärille. Jos saan sairauskohtauksen kadulla kävellessä, apu on paikalla jo ennen kuin itse huomaan kohtauksen tulevan, kun antureiden tuottama tieto yhdistetään terveyspilvessä jo aiemmin tunnistettuun riskiin.
  • Oppiminen on mullistunut täysin. Oppivelvollisuuden suorittamiseen on tullut erilaisia koulunkäynnin ja etäoppimisen hybridimalleja. Opettajista on tullut oppimisen valmentajia, joiden stressi ei muodostu enää kokeiden korjaamisesta. Kirjakustantamoiden valtakausi tiedon lähteenä on murtunut – digitaalisia ja interaktiivisia aineistoja on tarjolla kansainvälisesti palkitussa koulutuspilvessämme pilvin pimein. Toisaalta kaikki mitattava oppiminen ei tapahdu omien rajojemme sisällä, vaan myös kansainvälisiin sähköisiin oppimismateriaaleihin tukeudutaan – tämän mahdollistaa kansainvälinen yhteistyö. Oppiminen on nykyistä tasa-arvoisempaa alueellisesti. Toisaalta taas pystytään hyödyntämään lasten eri kasvuvaiheiden herkkyyskausia oppimiselle ja tarjoamaan syvempiä sisältöjä vaiheittain. Matemaattisesti lahjakkaiden lasten osaaminen lukioiässä on luonnontieteiden osalta aivan eri tasolla kuin nykyään.
  • Liikenne perustuu hyvin vähäisessä määrin enää yksityiskäytössä oleviin autoihin. Autot ovat yhteiskäyttöisiä ja tarpeen mukaan käytettävissä. Julkinen liikenne on tehokasta ja liikennemääriä ennakoivaa. Autot eivät tarvitse kuljettajia. Liikenneonnettomuudet ovat erittäin harvinaisia. Kukaan ei jaksa enää ihmetellä sitä että auton sijainti on virkavallan tiedossa.
  • Asiointipalvelut ovat oletusarvoisesti sähköisiä, ja täysin ennakoivia. Asioimisen tarve on hyvin vähäistä, kun kansalaiset ovat osa digitaalista ekosysteemiä. Enää ei siis tarvitse käydä ilmoittamassa eskarilaista kouluun ensi syksyksi, eikä liioin anoa tiskillä passia ulkomaille matkustaakseen.
  • Kukaan ei enää muista, mitä tarkoitettiin sanalla palvelin (”se oli se sellainen johon laitettiin ne palvelut, kun kaikilla oli omansa”).
  • Kukaan ei puhu avoimesta datasta, koska tiedon panttaajat on laitettu häpeäpaaluun jo moneen kertaan. Tietoa yhdistellään ja uusia innovaatioita syntyy arkisesti olemassa olevien tietovarastojen varaan. Data on isoa ja luonnollisesti myös saatavilla.

Kaikki teknologiset mahdollisuudet edellä kuvattuihin palveluihin ovat jo olemassa. Väitänkin, että tällä hetkellä on poikkeuksellisen iso kuilu siinä, kuinka hyviä palvelut voisivat olla, mutta eivät ole, koska monimuotoiset käytännöt ja rakenteet estävät palveluiden muodostumista. Internet ja mobiliteetti yhdistettynä tiedon prosessointikyvyn kasvamiseen ovat muodostaneet tilanteen, jossa tietotekniset mahdollisuudet ovat osin käsityskykymme ulkopuolella.
Itse olen miettinyt, ovatko nyt tekeillä olevat kunta- ja sote-uudistukset alkuunkaan riittäviä. Koska tulevaisuuden palveluissa tietotekniikka on kaikkien palveluiden keskiössä, kuntien rooli palveluiden järjestämisessä tulee väkisinkin muuttumaan. Palveluiden kehittäminen kunta- ja hallinnonalarajojen muodostamissa kahdensuuntaisissa siiloissa ei johda järkevien sähköisten palveluiden muodostumiseen. Tässä joudumme lähtemään takamatkalta moneen muuhun maahan verrattuna.
Me Goforessa haluamme olla parhaita uuden suomalaisen sähköisen palveluekosysteemin arkkitehteja ja rakentajia. Me autamme asiakkaitamme onnistumaan niissä pienissä askelissa, joita on mahdollista ottaa ja näin hanke hankkeelta, projekti projektilta edetä kohden tehokkaampaa yhteiskuntaa ja parempaa yhteistä hyvinvointia.
Tällä hetkellä työskentelemme asiakkaidemme kanssa muun muassa yllä mainittujen asioiden parissa. Mikael Nylund kirjoitti vähän maanläheisemmin sote-uudistuksesta juuri viime viikolla. Opetushallituksen kanssa teemme hartiavoimin Oppijan verkkopalveluita. Liikennevirastolle tarjoamme arkkitehtuurin kehittämisen palveluita. Avoin tieto ja data koskettavat asiantuntijoitamme laajalti.
Olemme onnekkaita, kun saamme olla mukana uudentyyppisen tietoyhteiskunnan suunnittelussa ja rakentamisessa.

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.

SOAP vs REST

Like almost all Web developers out there, I’ve always been familiar with SOAP but unlike many others (before joining Gofore), I hadn’t actually used anything SOAP related ever. When I started to develop and consume Web Services and/or APIs back in the days, I jumped straight to the REST train. Back then, SOAP seemed like old school and even worse, was based on XML. XML has many great qualities, but when a JavaEE developer deals with APIs, it doesn’t sound fun with all that overhead and complex parsing libraries.
If some of you are not familiar with SOAP and REST, I’ll explain a few fundamental differences between them. First of all, REST is not a protocol. It’s a paradigm for a set of architectural constraints. REST is all about resources with unique identifiers (e.g., unique URLs in the Web world). These resources can be consumed and manipulated through the four HTTP methods (GET, POST, PUT, DELETE). When accessed, a resource can be represented in any format such as JSON or XML. REST doesn’t care that much about anything else than the actual resources. No security, no transactions, no predefined format, no contract. Just resources. Everything else is left for the developer to deal with by other means.
SOAP, on the other hand, is a protocol. A Protocol that focuses on structured information exchange. Each message delivered over SOAP is wrapped inside an XML Envelope containing information about the nature of the message and details how to process it. SOAP is not in anyway restricting the type of the information or the methods you can use to manipulate these resources, but it always comes with detailed instructions on how to proceed with what you get. Through extensions SOAP is also a whole lot of more than a REST-like resource layer. You can get almost anything you could ever need to implement your service such as the previously mentioned security and transactions. SOAP tries to solve the whole puzzle.
In a nutshell, with REST you get easy to understand and easy to access APIs (at least for Web developers), but there is no guarantees on the structure of the message, very loose coupling between the services and lots of freedom. With SOAP, you get detailed information about the structure of the message and instructions how to process it, but because it’s not just HTTP, you need complex libraries and tools to do the processing and Web Service access for you (there are mature libraries for this such as Apache CXF). Even testing SOAP resources is hard because of the added abstraction (for consuming REST resources you only need an HTTP client). However, the complexity of SOAP also gives it more power on the protocol level and makes it possible to extend it with additional features. The tight coupling and advanced features of SOAP are useful if not mandatory in some use cases but in many cases it’s also a downside. For example, if your Web Application/Service needs both internal (e.g., for AJAX) and external APIs, you can easily combine these two if you use REST but it’s next to impossible to do with SOAP in a simple and concise way.
You can probably tell that I prefer REST to SOAP. However, the project I currently work in sounded like the dreamland for SOAP if there is one. It’s a high profile public administration’s project that is based on Service Oriented Architecture (SOA). Furthermore, the public facing services are actively used only a couple of times a year and a short period of time (when new applicants are applying to different schools during spring and autumn) which means that everything must work seamlessly under heavy load. Even a short downtime or malfunction means not only bad publicity but also a possible failure for the whole national joint application period.
Given the circumstances and the fact that the project organization is huge with different teams from several companies developing APIs independently, the APIs need to be well documented, work as expected, remain stable, and remain somewhat immutable or when altered it should be somehow communicated to the consumer services. REST might sound a bit too flexible, a bit too simple, a bit too uncoordinated, and a bit too light for the scenario. SOAP does not. It’s strict. It’s complex. It’s heavy. In another words, it’s a contract and it means business. Government level business.
The project has been ongoing for a long time, and the debate between the usage of SOAP vs REST in the project has lasted almost from the day one (to my knowledge). The current status is that in many of the services there is both but for different APIs. So far the SOAP services have worked quite nicely but have required a lot more work than the REST APIs. In addition, we have now reached a point where we have operations requiring several thousand (if not tens of thousands) requests to the other services and without multithreading in our Apache Camel routes, these operations would take days to complete. The consumed REST resources have worked without bigger problems with multithreading but the CXF library used with the SOAP resources isn’t apparently thread safe. For us, it’s going to be much faster operation to replace all the SOAP APIs with REST APIs than find a new library for working with our existing SOAP services. If SOAP had been used for other things besides just messaging (which could have been the case if there would have been only server-to-server communication) this would have been a major drawback. SOAP itself is of course not to blame but the library. Still my point was that if you try to find that one monolithic solution for all the problems and it fails, you are in big trouble.
All in all, although I’m a fan of type safety and all that kind of things, I still personally think that in most cases there’s more cons than pros with SOAP and it’s more suited to waterfall model based development than agiledevelopment. SOAP does shine on some cases, but unfortunately these cases are almost always the ones not visible to the public. REST is not perfect either and leaves much more responsibility for the developer, but still it suites better for the modern Web.

Avatar

Kalle Säilä

Linkedin profile

Piditkö lukemastasi? Jaa se myös muille.