Yhden HTML-sivun varaan rakennetut SPA-arkkitehtuurin (single-page application) web-sovellukset ovat tällä hetkellä web-kehityksen kuumin trendi responsiivisen suunnittelun ohella. SPA-sovelluksissa itsessään ei sinällään ole mitään uutta, ja sellaisia onkin rakennettu jo aina AJAX-pohjaisen tiedonsiirron läpimurrosta asti. Aiemmin tällaisten sovellusten kehittäminen oli kuitenkin suurten ja monimutkaisten sovellusten tapauksessa työlästä ja kallista, ja lopputuloksena oli usein läjä vaikeasti ylläpidettävää spagettikoodia. Nyt aika on kuitenkin kypsä SPA-sovellusten tuottavaan kehitykseen viime vuosien aikana merkittävästi parantuneen työkalutuen myötä.

Hyödyt ja haasteet

Miksi sitten SPA-arkkitehtuurin pohjalle rakennettu web-sovellus on perinteisiä, usean eri HTML-sivun varaan tehtyjä sovelluksia parempi? Ilmeisin syy on parantunut käyttökokemus turhien sivulatausten hävitessä, jolloin sovelluksen käytön aikana ei tule tilanteita missä selain näyttää tyhjää sivua sivulatauksen ollessa kesken. Näin käyttökokemuksesta saadaan paljon interaktiivisempi ja sivustosta kokonaisuutena käytettävämpi. Lisäksi SPA-sovellukset lataavat kerralla pienemmän määrän tietoa kuin usean sivun pohjalle rakennetut sovellukset, jolloin siirtymät eri näkymien välillä ovat kevyitä kun ainoastaan uudelle näkymälle välttämätön tieto tarvitsee siirtää verkon yli, mikä käytännössä näkyy käyttäjälle nopeina sivulatauksina.
SPA-sovellukset myös ohjaavat sovellusarkkitehtuurin kehittämistä enemmän API-lähtöiseen suuntaan selaimen ja palvelimen välisen REST-rajapinnan myötä, mikä mahdollistaa helposti myös muiden samaa REST-rajapintaa käyttävien sovellusten kehittämisen. REST voi toki olla perinteisemmänkin, useasta eri sivusta koostuvan web-sovelluksen pohjalla, mutta SPA-sovellusten kehittämisessä REST-rajapinnan huolellinen suunnittelu korostuu, koska käytännössä kaiken sovelluksen kannalta keskeisen siirrettävän tiedon pitäisi olla saatavilla sen kautta.
Yksi SPA-arkkitehtuurin keskeisiä etuja on myös skaalautuvuus. Koska SPA-sovelluksessa kaikki käyttöliittymän tila on tallessa selaimessa, palvelimelle tallennettavan sessiotiedon määrä on minimaalinen, mikä mahdollistaa suuren määrän rinnakkaisia sessioita vaatimattomallakin palvelininfrastruktuurilla.
SPA-arkkitehtuurin toteuttamiseen liittyy kuitenkin omat haasteensa. Esimerkiksi sivuhistorian hallinta, saavutettavuus, hakukoneoptimointi ja sivun avaaminen uudessa välilehdessä tai ikkunassa vaativat enemmän suunnittelua kuin perinteisissä sovelluksissa. Myös muistinhallinta selainpäässä on asia johon SPA-sovellusten toteutusvaiheessa on syytä kiinnittää erityistä huomiota. Käyttöliittymäsuunnittelun näkökulmasta taas korostuneessa roolissa on interaktioiden suunnittelu, kun sivusiirtymien esittäminen käyttäjälle on täysin sovelluksen hallinnassa. Kaikki näistä haasteista ovat kuitenkin ratkaistavissa, mutta on tärkeää että ne huomioidaan jo sovelluksen ja sen arkkitehtuurin suunnitteluvaiheessa.

Katsaus teknologiakentälle

SPA-sovellusten haasteita ratkaisemaan on viime vuosina kehitetty monia apuvälineitä, joiden avulla SPA-sovellusten rakentaminen on helpottunut huomattavasti verrattuna muutaman vuoden takaiseen tilanteeseen. Keskeinen kulmakivi SPA-sovelluksessa on selainpäässä käytettävä JavaScript MVC-kehys, jonka varaan selainpään sovellusarkkitehtuuri on järkevää rakentaa. MVC-kehyksen avulla sovelluksen rakenne selkeytyy ja tarve kirjoittaa suuria määriä koodia DOMin käsittelyyn pienenee, mikä tosin riippuu paljon kehyksen tarjoamista ominaisuuksista ja abstraktiotasosta. Sopivan MVC-kehyksen käyttäminen voi parhaimmillaan parantaakin tuottavuutta merkittävästi.
Tämän artikkelin kirjoitushetkellä on selkeästi erotettavissa kolme vahvaa kehystä ja niiden ympärille muodostunutta yhteisöä, jotka ovat saaneet suurta suosiota web-kehittäjien keskuudessa: Backbone.jsAngularJS ja Ember.js. Näistä Backbone on ominaisuuksiltaan yksinkertaisin, ja tarjoaa vain välttämättömimmät rakennuspalikat selainpään arkkitehtuurin rakentamiseen. Tämän takia se on hyvä valinta sellaisten sovellusten rakentamiseen joiden arkkitehtuuri halutaan pitää tiukasti omassa hallinnassa ilman suuria kehyksen asettamia rajoitteita. Backbone ei kuitenkaan sellaisenaan ole paras mahdollinen valinta mikäli tällaista kustomoitavuustarvetta ei ole, ja sen päälle kannattaakin valita jokin Backbonea laajentava kehys, joka tarjoaa valmiina usein käytettäviä rakenteita joita Backbone ei suoraan tue. Esim. Marionette.js sopii hyvin tällaiseksi Backbonen päälle valittavaksi laajennokseksi. Vaikka Backbonen 1.0-versio ilmestyi vasta kuluvan vuoden maaliskuussa, on sitä käytetty jo pitkään monilla merkittävillä web-sivustoilla, ja sen ympärille onkin ehtinyt muodostua todella vahva yhteisö.
AngularJS sen sijaan tarjoaa paljon laajemman pohjan sovellusten rakentamiseen kuin Backbone, ja on siten tuottavuuden suhteen erinomainen valinta. Angular on Googlen kehittämänä kehyksenä saanut nopeasti ympärilleen jatkuvasti kasvavan yhteisön, ja on kaikista tarjolla olevista kehyksistä varmasti yhteensopivin tulevaisuuden selainstandardien ja niiden mahdollistamien ominaisuuksien kanssa. Esimerkiksi mallimuutosten kuunteleminen ja HTML-merkinnän laajentaminen omilla komponenteilla ovat tällaisia ominaisuuksia jotka löytyvät tulevaisuuden selaimista, ja joita voi jo nytkin jossain määrin kokeilla Chrome Canarylla. Tämä on ehkä suurin syy valita Angular, koska se tavallaan toimii siltana nykyisten ja tulevaisuuden selainten ominaisuuksien välillä. Lisäksi Angularin suunnittelussa on annettu erityishuomiota testattavuudelle selainpäässä harvoin nähdyn riippuvuuksien injektoinnin kautta.
Ember.js ei vielä kirjoitushetkellä ollut saavuttanut 1.0-versiojulkaisun merkkipaalua, mutta kovin kaukana se ei kuitenkaan enää ole (release candidate 4 ilmestyi kirjoitushetken aikoihin, ja se on Emberin kehitystiimin mukaan jo hyvin lähellä lopullista 1.0-versiota). Emberin ehkä suurimpana vahvuutena, ja samalla heikkoutena, on pitkälle viety automaattinen objektien luominen ja alustaminen nimeämiskäytäntöjen kautta, mikä mahdollistaa parhaimmillaan erittäin korkean tuottavuuden, mutta samalla asettaa kehittäjälle enemmän rajoitteita kuin muut vastaavat kehykset. Tämän takia Emberiä ei voikaan käyttää järkevästi vain osana kehitettävää selainpään toteutusta, vaan se käytännössä määrää koko selainpään arkkitehtuurin itse. Lisäksi Ember ei vielä kirjoitushetkellä ole niin kypsä kuin esimerkiksi Angular tai Backbone, mikä käytännössä näkyy Emberin APIn epävakautena. Esimerkiksi juuri ilmestyneessä RC4:ssä on potentiaalinen taaksepäin yhteensopimaton muutos. Tämä APIn kypsymättömyys on kuitenkin ohimenevä haitta ja korjaantunee 1.0-julkaisun myötä.
Näiden suurten kehysten lisäksi on olemassa monia muitakin vaihtoehtoja, eikä työkalutuen puute enää olekaan este SPA-sovellusten rakentamiselle. Lähitulevaisuudessa eräs varteenotettava vaihtoehto voi olla myös futuristinen, vielä kehityksessä oleva kehys Meteor, joka tarjoaa aivan uudenlaisen tavan rakentaa reaktiivisia SPA-sovelluksia pitämällä näkymässä esitettävän mallitiedon synkronoituna palvelimen ja kaikkien selainistuntojen välillä ja mahdollistamalla kaiken API-koodin suorittamisen sekä selain- että palvelinpäässä. Meteor mahdollistaakin monimutkaisten sovellusten rakentamisen verrattain pienellä ohjelmakoodin määrällä, ja tämä tuottavuuden nousun trendi on varmasti keskeinen tekijä jatkossakin uusien SPA-kehysten tullessa saataville.
Yhden sivun varaan pohjautuvat web-sovellukset ovatkin varmasti tulevaisuuden tavallisin malli web-sovellusten rakentamiselle, ja nykypäivänäkin monen web-sovelluksen pohjalle valitaan SPA-arkkitehtuuri, jollei koko sivuston laajuisesti, niin ainakin osalle kehitettävää sivustoa. Javascript MVC-kehysten tarjoamat tuottavuusedut ovat merkittävä syy SPA-sovellusten yleistymiselle, ja lisäksi SPA-sovellusten yleiset edut painavat vaakakuppia SPA-sovellusten puolelle monen uuden web-sovelluksen arkkitehtuurin valinnassa.

Avatar

Henri Heiskanen

Henri on kokenut front-end web-kehitykseen painottunut ohjelmistosuunnittelija. Hän on ollut mukana suunnittelemassa ja toteuttamassa sekä suosittuja kuluttajapalveluita että suuria yritystietojärjestelmiä. Henri on rakentanut laajoja yhden sivun JavaScript-sovelluksia ammattilaisuransa alusta asti ja seuraa aktiivisesti uusia tuulia web-kehityksessä.

Linkedin profile

Piditkö lukemastasi? Jaa se myös muille.

Kokonaisarkkitehtuuri (englanniksi Enterprise Architecture, EA)  on laaja käsite, jolle on muotoutunut erilaisia määritelmiä. Julkishallinnossa käytetään nykyään laajalti seuraavaa valtiovarainministeriön määritelmää: ”Kokonaisarkkitehtuuri kuvaa, kuinka organisaation toimintaprosessit, tiedot ja järjestelmät toimivat kokonaisuutena.”
Kokonaisarkkitehtuurin ydin onkin nimenomaisesti niiden suhteiden määrittelyssä, jotka nivovat erilaiset elementit toimivaksi kokonaisuudeksi, eikä välttämättä aina niinkään yksittäisten elementtien detaljoidussa kuvauksissa. Jotta kuvaus voitaisiin suorittaa menestyksekkäästi, on löydettävä sopivat työvälineet ja menetelmät, joilla tämä suhteellisuus saadaan esitettyä.
Julkishallinnon kokonaisarkkitehtuurityössä yleisesti pohjana käytettävät JHS 179 (julkisen hallinnon suositus 179) sekä Kartturi-malli tarjoavat kumpikin oletusarvoisena kuvausmenetelmänä Microsoft Excel pohjaisten lomakkeiden täyttämistä. Näiden lomakkeiden täyttö toimii sinänsä melko hyvin yksittäisten asioiden kuvaamiseen, mutta ei tarjoa ohjelmallista tukea elementtien liittämiseksi toisiinsa.
Toisaalta elementtien välisten suhteiden kuvaamiseen voidaan käyttää graafisia piirtotyökaluja kuten Microsoft Visio, mutta niillä ei saada mielekkäästi mallinnettua elementtien sisältöjä siten, että tätä tietoa voitaisiin jatkojalostaa.
Parhaimpaan lopputulokseen päästään käyttämällä varsinaisia kokonaisarkkitehtuurin mallinnukseen suunnitelluja työkaluja. Suomalaisen QPR Software Oyj:n kehittämä QPR EnterpriseArchitect on suhteellisen yksinkertainen ja helposti omaksuttava mallinnustyökalu, johon on saatavissa valmiiksi rakennettu Kartturi-mallipohja. Ohjelman käyttöliittymä on saatavissa myös suomenkielisenä. Näistä syistä johtuen tämä on erityisen sopiva työkalu julkishallinnossa suoritettavaan kokonaisarkkitehtuurityöhön.
Työkalun Kartturi-mallipohjan kuvauskielenä on monipuolinen ja laajalti käytetty ArchiMate-kuvauskieli. Tätä mallipohjaa voidaan myös helposti muokata, mikäli se ei joiltain osin täytä kulloistakin mallinnustarvetta.
Malleja voidaan luoda niin graafisina kaavioina kuin lomakemuotoisena esityksenäkin yksittäisiä kenttiä täyttämällä. Kaaviot auttavat hahmottamaan kokonaisuuksia sekä mallinnusta suoritettaessa että malleja jälkikäteen tutkittaessa. Niihin voidaan tuoda erilaisia ArchiMate elementtejä ja näiden elementtien välille voidaan piirtää rakenteellisia suhteita, jotka heijastuvat automaattisesti lomakkeisiin.
Syötettyä tietoa voidaan tarkastella monista näkökulmista. Sillä saadaan muun muassa tuotettua erilaisia matriiseja. Esimerkiksi tietojärjestelmäpalveluelementtien ja prosessielementtien välisistä suhteista saadaan automaattisesti aikaiseksi tietojärjestelmäpalvelut-prosessit -matriisi, mitä voidaan hyödyntää muutoksenhallinnassa. Matriisi kertoo mihinkä prosesseihin tietyn tietojärjestelmäpalvelun muuttaminen vaikuttaisi.
Työkalussa ja sen kartturipohjassa on kuitenkin myös omat puutteet ja rajoitteensa elementtien välisten suhteiden hallinnassa. Vakiokonfiguraatiossaan se ei erottele yhteyksien suuntia. Kaavioon voidaan esimerkiksi piirtää käyttösuhde elementtien A ja B välille, mutta elementtien attribuuteista ei käy ilmi se, käyttääkö elementti A elementtiä B vai onko tilanne päinvastainen. Onneksi tämä puute on mallintajan korjattavissa kartturipohjaa editoimalla. Toinen ja astetta vakavampi puute liittyy identtisten suhteiden kuvaamiseen useammassa eri kaaviossa. Käytettäessä suhteet automaattisesti kaavioista lomakkeille vievää relaatiomallinnusta ei identtistä suhdetta voi esiintyä useammassa kaaviossa. Siis jos esimerkiksi prosessissa X mallinnetaan, että se käyttää tietojärjestelmäpalvelua A, jonka toteuttaa tietojärjestelmä B ei prosessissa Y voi enää esittää tätä A:n ja B:n välistä suhdetta, vaikka se tähänkin liittyisi.
QPR EA työkalua voi käyttää myös palvelinpohjaisesti. Tämä mahdollistaa saman mallin yhdenaikaisen työstämisen useamman mallintajan toimesta. Tätä palvelimelle tuotettua mallia päästään tarkastelemaan myös erillisen portaalinäkymän kautta. Portaalin kautta tarkasteltuna mallia voidaan suodattaa erilaisin suodattimin ja näin saadaan poimittua tiedosta kulloinkin oleelliset osuudet. Portaalin käyttö on myös, jos mahdollista, vieläkin helpompaa kuin itse QPR EA työkalun käyttö ja se mahdollistaakin tehdyn arkkitehtuurityön tarkastelun laajemmalle joukolle. Tämä varmistaa osaltaan sitä, että tuotettu kokonaisarkkitehtuurikuvaus ei jää pölyttymään jonkin järjestelmän uumeniin vaan se tullaan ottamaan hankkeissa käyttöön.

Avatar

Antti Leinonen

Piditkö lukemastasi? Jaa se myös muille.

Gofore Oy on valittu puitesopimustoimittajaksi Hanselin johdon konsultointipalvelujen nelivuotiseen (2013-2017) puitejärjestelyyn, joka on astunut voimaan 6.5.2013. Gofore on mukana puitejärjestelyn osa-alueella E, joka koskee hanke- ja projektihallintapalveluja. Osa-alueen palveluihin sisältyy muun muassa hanke- ja projektihallinnan käytäntöjen ja menetelmien kehittäminen, hankesuunnittelu ja varsinaiset projektipäällikköpalvelut.
Olemme mukana myös Hanselin teknisen IT-konsultoinnin puitejärjestelyssä (2011-2015), jonka puitteissa olemme työskennelleet erityisesti kokonaisarkkitehtuurin, kehittämishankkeiden valmistelun ja johtamisen sekä sovelluskehityksen hankkeissa useiden eri hallinnonalojen kanssa. Hanke- ja projektihallinnan osa-alueen myötä täydennämme valtionhallinnon asiakkaiden palvelutarjontaamme muun muassa laajojen hankkeiden hankesuunnitteluun ja projektipäällikköpalveluihin.
Hansel-puitesopimustoimittajien joukossa Gofore erottuu vahvalla kokemusperäisellä arkkitehtuuriosaamisella. Hanke- ja projektihallinnan käytäntöjen linkittäminen arkkitehtuurityöhön sekä ketterään, vaiheittaiseen kehittämiseen on erikoisosaamistamme, joka vastaa mainiosti julkisen sektorin tämän hetkisiin haasteisiin. Väitämme, että tietojärjestelmäprojekteissa voi onnistua. Väitämme myös, että me tiedämme onnistumisen lääkkeet. Ota yhteyttä, niin kerromme lisää.
 
Lisätietoja: 
Mikael Nylund
Vanhempi palveluarkkitehti
Liiketoimintavastaava, IT-johdon asiantuntijapalvelut
mikael.nylund@gofore.com

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.

Perinteisen relaatiomallin hylkäävät, ns. NoSQL-tietokannat ovat tehneet tuloaan valtavirtaan viime vuosina. NoSQL-järjestelmien tavoitteena on tietokantakerroksen helppo, pitkälti automatisoitu horisontaalinen skaalattavuus ja tietomallin joustavuus. Tilaus tällaisille järjestelmille syntyi alunperin massiivisia käyttäjä- ja tietomääriä vaativien web-sovellusten (Google, Amazon, Facebook, Twitter, …) tarpeista, mutta nykyään ne eivät enää ole vain jättiläisten työkaluja.

Taustaa

Sitten Internetin alkuaikojen interaktiivisille web-sovelluksille asetettavat vaatimukset ovat muuttuneet merkittävästi. Potentiaalisia käyttäjiä on ympäri maailmaa, minkä seurauksena käyttäjä- ja datamäärät voivat olla valtavia ja sovelluksilta odotetaan jatkuvaa saatavuutta. Toisaalta kuormitus on usein vaihtelevaa ja sovellusten pitää sopeutua tähän joustavasti. Tämän kehityksen rinnalla on tapahtunut myös teknologisia mullistuksia: verkot ovat nopeutuneet, muisti halventunut ja virtualisointitekniikat kehittyneet. Kaiken tämän myötä sovellusten infrastruktuuri on muuttunut. Nykyään web-sovellukset ovat usein hajautettuja ja horisontaalisesti skaalautuvia. Horisontaalisella skaalautuvuudella tarkoitetaan sitä, että kapasiteettia kasvatetaan lisäämällä sovelluspalvelimia (halpaa perusrautaa/virtuaalipalvelimia) sen sijaan, että hankittaisiin uusi, usein hyvin hintava tehopalvelin. Hajautuksella parannetaan myös vikasietoisuutta ja mahdollistetaan sovellusten päivittäminen ilman käyttökatkoja.
Pelkkä sovelluspalvelimien hajauttaminen ei kuitenkaan riitä, vaan myös tietokannan täytyy skaalautua. Relaatiotietokantojen perinteinen skaalausmalli on ollut vertikaalinen, eli hankitaan järeämpää rautaa – tämän lähestymistavan ongelmia ovat kuitenkin korkea hinta ja joustamattomuus. Myös tietomallin jäykkyys voidaan tietyissä tapauksessa nähdä relaatiotietokantojen ongelmana. Nykyajan web-sovellukset ovat usein ”work-in-progress”, eli toiminnallisuuksia lisätään ja muokataan lennossa, jolloin tietotarpeetkin voivat muuttua nopeasti. Relaatiotietokannoissa skeema pitää kuitenkin määritellä etukäteen ja muutokset ovat hankalia toteuttaa.

Enter NoSQL

Yllämainittuihin ongelmiin uudenlaisia ratkaisuja lähtivät ensimmäisinä miettimään mm. Google ja Amazon. Tämän kehityksen tuloksena syntyneitä relaatiomallin hylkääviä ja helppoa skaalautuvuutta korostavia tietokantaratkaisuja alettiin kutsua NoSQL-tietokannoiksi. Kyseisen buzzwordin alle mahtuu monenlaista viritystä ja kaikki ideat eivät ole uusia, mutta usein yhteistä näille tuotteille on mm.:

  • Ei skeemaa, tallennettava tieto voi olla muodoltaan vaihtelevaa
  • Usein tietorakenteeltaan avain-arvo varastoja (key-value store)
  • Tiedon automaattinen, sovellukselle näkymätön hajautus useille palvelimille, joita voidaan lisätä ja poistaa joustavasti
  • Hajautettujen hakujen tuki

NoSQL-ratkaisut voidaan tiedon tallennustavan mukaan jakaa karkeasti kolmeen tyyppiin: Key-value store, Columnar Database (Column-oriented DB) ja Document Store. Näistä käyttötavaltaan yksinkertaisin on Key-Value store, jossa tieto tallennetaan avain-arvo-pareina hajautetusti. Yksinkertaisimmillaan tietorakenne on distributed hashtable (DST) ja kaikki operaatiot tehdään avaimien perusteella. Key-Value storet soveltuvat tilanteisiin, jossa pitää tallentaa tehokkaasti suuria määriä vaihtelevan muotoista dataa, johon kohdistetaan vain yksinkertaisia hakuja (esim. click-stream data). Tunnetuimpia tuotteita ovat RedisAmazon DynamoMembase ja Oracle NoSQL DB.
Columnar Database on samantapainen kuin key-value store, mutta siinä avain voi viitata useisiin arvoihin, jotka on ryhmitelty (column families). Columnar Database –tyyppinen tietokanta mahdollistaa key-value-storea hieman monipuolisemman tietojen käsittelyn. Esimerkkejä tämäntyyppisistä NoSQL-tuotteista ovat mm. Google BigTable, Apache CassandraHbase.
Monipuolisimmat mahdollisuudet tiedon käsittelyyn tarjoavat Document store -tyyppiset tietokannat. Niissä tieto tallennetaan rakenteisena dokumenttina, usein tallennusmuotona JSON tai sen variantti. Dokumentit jaotellaan kokoelmiin, joita voi karkeasti verrata relaatiokannan tauluihin. Toisin kuin esimerkiksi key-value storeissa, järjestelmä on tietoinen dokumenttien sisällöstä. Tämä mahdollistaa monipuolisemman käsittelyn ja hakuja ja päivitysoperaatioita voidaan kohdistaa myös dokumentin osiin. Esimerkiksi MongoDB tarjoaa melko monipuolisen valikoiman erilaisia hakuoperaatiota kuten loogiset operaattorit ja regexp-vertailut.

Työkalu tehtävän mukaan

Relaatiotietokantojen asema oli pitkään niin vahva, että uuden sovelluksen kehitystä aloitettaessa ei välttämättä edes pohdittu muita vaihtoehtoja. Tarjolla olevien tietovarastoratkaisuiden lisääntyessä on havahduttu siihen, että myös tiedon tallentamistavan tulisi määräytyä sen mukaan, minkälaista tietoa ollaan tallentamassa, miten sitä käsitellään, missä muodossa se esitetään jne. Jopa saman sovelluksen sisällä voidaan käyttää useita erityyppisiä tietovarastoja (ns. Polyglot Persistence). Tämä kuitenkin edellyttää järjestelmän suunnittelijoilta syvällistä tietämystä erilaisen ratkaisujen vahvuuksista ja riskeistä.
Yksi relaatiotietokantojen eduista on niiden ylivoimainen kypsyys verrattuna NoSQL-tuotteisiin. Nimensä mukaisesti ne ovat vahvoilla myös silloin kun käsiteltävä tieto sisältää paljon sisäisiä viittauksia ja niitä halutaan hyödyntää tiedon yhdistelyssä. Myös vahvasti määritelty tietomalli voi joissakin tapauksessa olla hyödyksi, sillä se tekee tiedon käsittelyn ennustettavaksi ja virheet paljastuvat aikaisessa vaiheessa.
NoSQL-tuotteet sopivat edelleen parhaiten suurta skaalautuvuutta vaativiin järjestelmiin. Usein tieto voi olla luonteeltaan sellaista, että tiukkoja eheysvaatimuksia ei ole (esim. erilaiset tilastotiedot), mikä mahdollistaa löyhemmän transaktionaalisuuden ja tätä kautta helpomman hajautuksen. Automatisoitu skaalautuvuus tekee NoSQL-kannoista erityisen sopivia tallennusratkaisuja pilvipalveluissa. Näissä tyypillisesti mahdollistetaan tarvittavan palvelinkapasiteetin, mukaan lukien tietokantapalvelimet, ostaminen joustavasti niin, että hinta skaalautuu tarpeen mukaan. Toisaalta NoSQL-kantojen edut ovat joskus vain näennäisiä. Esimerkiksi käytettävä tietomalli joudutaan usein optimoimaan sen mukaan millaisia hakuja tehdään, mikä on ristiriidassa mainostetun joustavuuden kanssa.
Goforelta löytyy osaamista NoSQL-ratkaisuista sekä pilvipalveluiden että perinteisemmän ohjelmistoarkkitehtuurin mukaisesti rakennettujen sovellusten parista. Asiantuntijamme ovat mm. olleet mukana toteuttamassa Fonectan hakupalveluita Amazonin pilvialustalle. Tiimi Goforelaisia on myös mukana rakentamassa Oppijan verkkopalveluita, jossa relaatiotietokannan lisäksi on käytössä MongoDB mm. opiskeluhakemusten tallennukseen. Kehitys on NoSQL-rintamalla erittäin aktiivista, joten odotettavissa on, että teknologiat kypsyvät ja standardeja syntyy. Seuraamme kehitystä mielenkiinnolla.

Avatar

Antto Sierla

Antto on monipuolinen IT-osaaja, joka on toiminut ohjelmistosuunnittelijana ja arkkitehtina useissa vaativissa tietojärjestelmäprojekteissa, suurista kuluttajaportaaleista IdM-tuotteisiin. Hänen ydinosaamisensa on Java-palvelinsovelluksissa, mutta uran varrella kokemusta on kertynyt useista muistakin teknologioista. Anton viimeisin aluevaltaus on kokonaisarkkitehtuuri, jonka osa-alueista häntä kiinnostaa erityisesti tietoarkkitehtuuri.

Linkedin profile

Piditkö lukemastasi? Jaa se myös muille.

Nykyajan tietoyhteiskunta perustuu sähköisille palveluille, ja yhä suurempi osa hyödynnettävästä tiedosta on sähköisessä muodossa. Jotta organisaatiot pystyvät tehokkaasti kehittämään tietojärjestelmiään ja liiketoimintaansa, tarvitaan avuksi kokonaisarkkitehtuuria. Sen avulla mahdollistetaan sähköisten palveluiden kehittyminen. Samalla pystytään myös hallitsemaan aiempaa paremmin sähköisiä asiakirjatietoja ja sähköistä arkistointia.
Ennen vanhaan arkistointi oli helppoa, paperit täytyi ainoastaan lajitella ja siirtää sopivasti jaoteltuihin kansioihin. Tämän jälkeen kansiot siirrettiin arkistotiloihin. Entäpä nykyään? Sähköisessä muodossa olevan tiedon arkistointi edellyttää uusia toimintatapoja, jotta tietopääoma ei katoa, vaan säilyy käytettävänä ja ylläpidettävänä myös tulevaisuudessa. Sähköisen tiedon arkistointi tulisikin toteuttaa kiinteänä osana muuta toiminnan kehittämistä ja samalla tehtävää kokonaisarkkitehtuurityötä.
Kokonaisarkkitehtuurin osa-alueista tietoarkkitehtuurin tavoitteena on jäsentää, määrittää ja kuvata kriittisimmät tietotarpeet, jotka liittyvät organisaation keskeisimpiin prosesseihin. Tietoarkkitehtuurityössä luodaan yhteinen näkemys organisaation keskeisestä tietopääomasta ja helpotetaan tiedon ja informaation käyttöä, hyödyntämistä ja löytämistä.
Organisaation tiedonhallinnan perusedellytyksenä on puolestaan ajantasainen ja sähköisiä toimintatapoja tukeva arkistonmuodostussuunnitelma, AMS. Tietoyhteiskunnan tarpeisiin vastaa eAMS, joka tarkoittaa sähköistä arkistonmuodostussuunnitelmaa. Se on organisaation tehtäväluokitukseen perustuva määritys, jossa kuvataan organisaation hoitamien tehtävien käsittelyvaiheet, niissä kertyvät asiakirjatyypit ja tarkenteet sekä niiden oletusmetatietoarvot. eAMS toimii myös organisaation tiedonohjaussuunnitelmana.
eAMS perustuu arkistolaitoksen SÄHKE2-normille, ja sen tarkoituksena on olla asiakirjatietojen oletusmetatietoarvojen lähteenä sekä ohjata tietojärjestelmässä asiakirjatiedon käsittelyä ja hallintaa. eAMS:n on tarkoitus integroitua kiinteäksi osaksi tietojärjestelmiä niin, että käyttäjä ei edes tiedä sen olemassaolosta. Jos julkisen hallinnon organisaatio haluaa siirtyä vain sähköiseen arkistointiin pysyvästi säilytettävän materiaalin osalta, sen täytyy laatia eAMS, jonka on kytkeydyttävä samalla tehtävään kokonaisarkkitehtuurityöhön. eAMS:n muodostamisessa on paljon samaa sisältöä mitä on tietoarkkitehtuurityössä. Se on tärkeä tiedonhallinnan työkalu, kertoo organisaation toiminnasta ja toiminnan rakenteesta. Tästä syystä aiempi AMS tulee huomioida kokonaisarkkitehtuurityön aloitusvaiheessa – ja erityisesti tietoarkkitehtuurityötä tehtäessä.
Organisaatioiden toiminnan sujuvuuden voidaan olettaa perustuvan tiedonhallintaan varsinkin aloilla, joilla tehdään tietotyötä. Mikäli toiminnan perustana on tiedonhallinta, olisi suotavaa, että se olisi mahdollisimman jäsentynyttä, hallittua ja koottuna loogisiin kokonaisuuksiin. Organisaatiot muuttuvat ajan kuluessa ja samoin käy liiketoimintaprosesseille ja niitä varten kehitetyille tietojärjestelmille. Sen sijaan tieto on pysyvämpää ja tietoarkkitehtuuri nimenomaisesti pyrkii huolehtimaan, että tieto on jäsentynyttä ja yhdenmukaisesti käsiteltävissä riippumatta tietojärjestelmistä tai teknisistä rajapinnoista. Eli tietoarkkitehtuurilla vaikutetaan siihen, miten tietoa voidaan välittää eri järjestelmien välillä noudattamalla vaikkapa SÄHKE2-normin vaatimuksia.
Tietoarkkitehtuuria työstettäessä täytyy huomioida, että hyödynnettävä tieto määritelty jonkin yleisesti hyväksytyn standardin mukaisesti ja että se on siirrettävissä eri osapuolten välillä esimerkiksi XML-formaatissa. Myös arkistolaitoksen SÄHKE2-normin tehtäväluokituksen metatietomäärittelyssä edellytetään siirrettävän tietosisällön luokittelua. Tietoarkkitehtuurityö ja sähköinen arkistonmuodostussuunnitelma linkittyvät siis tiiviisti yhteen, joten organisaation tulee huomioida eAMS:ia laatiessaan nykyiset arkistointikäytännöt ja toisaalta tulevaisuuden tarpeet, joiden kehittäminen onnistuu parhaiten systemaattisella kokonaisarkkitehtuurityöllä.

Avatar

Janne Pehkonen

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

Piditkö lukemastasi? Jaa se myös muille.

Heti alkuun tunnustan saman kuin alkuvuodesta työhaastattelussa: kokonaisarkkitehtuuri on itselleni käsitteenä entuudestaan tuntematon. Nyt kuluneiden viikkojen aikana olen lukenut aihetta käsittelevää kirjallisuutta ja materiaalia sekä keskustellut uusien kollegojeni kanssa, jotta saisin muodostettua itselleni jonkinlaisen kuvan aiheesta. Olen myös tutustunut muutamaan julkisesti saatavilla olevaan esimerkkitapaukseen, kuten kuntasektorin käyttövaltuushallinnan viitearkkitehtuuriluonnokseen ja julkisen hallinnon sähköisen asioinnin viitearkkitehtuuri –dokumenttiin.
Alun ihmettelyn jälkeen tekee mieli provosoivasti kysyä, onko kokonaisarkkitehtuuriajattelussa sittenkään mitään uutta. Onko kyseessä jälleen uusi hype-sana?
Kokonaisarkkitehtuurille ei ole olemassa yksikäsitteistä määritelmää, vaan eri henkilöt saattavat käyttää termiä tarkoittamaan vähän eri asioita. Ymmärtääkseni kokonaisarkkitehtuurityön voisi kuitenkin kiteyttää niin, että siinä on kyse kokonaisvaltaisesta ja eri tasoja sisältävästä, ylhäältä alas etenevästä toimintalähtöisestä suunnittelusta ja mallinnuksesta. Samalla tavallahan kuitenkin jo perinteinen kaupunkilaisjärkikin saa useimmat meistä ajattelemaan, tai ainakin sen kai pitäisi. Itsekin olen tietoisesti pyrkinyt näin toimimaan vetäessäni erilaisia ohjelmistoprojekteja ja IT-palveluja. Hankkeen alussa olen pyrkinyt selvittämään itselleni ja koko tiimille, miksi jotakin ollaan tekemässä, kenelle ja millä ehdoilla. Joskus olen ehkä hämmentänytkin asiakasta tai esimiestäni kyselemällä ”turhia”. Tämän jälkeen on kuitenkin ollut helpompi lähteä tarkentamaan yksityiskohtaisesti varsinaista toteutusta tai konkreettista toimintaa, kun laajempi kuva on selkeytetty.
Suomen mittakaavassa yksi merkittävä uusi asia kokonaisarkkitehtuuriin liittyen on vuonna 2011 säädetty laki julkisen hallinnon tietohallinnon ohjauksesta eli tietohallintolaki. Se velvoittaa julkisen hallinnon toimijat käyttämään kokonaisarkkitehtuurimenetelmiä omassa toiminnassaan. Jo ennen tietohallintolakia Julkisen hallinnon tietohallinnon neuvottelukunta (JUHTA) on antanut suosituksen JHS 179, joka määrittelee kokonaisarkkitehtuurimenetelmän ja antaa suositukset kokonaisarkkitehtuurin eri osa-alueiden kuvausten laatimisesta. Julkisella puolella kokonaisarkkitehtuurityölle on siis lain kautta pakotettu tarve.
Kokonaisarkkitehtuurityö ei todellakaan ole mitään salatiedettä, vaan lopulta kyse on melko helposti omaksuttavista asioista. Silti (tai siksi?) olen jo nyt vakuuttunut siitä, että kokonaisarkkitehtuurityöstä on mahdollista saada selviä hyötyjä. Se formalisoi ja antaa kehyksiä kattavalle, eri sidosryhmiä ja tasoja huomioivalle suunnittelulle. Näin eri asiat tulevat automaattisemmin huomioiduksi tietojärjestelmätyössä, eikä mikään osa-alue unohdu. Lisäksi pitkäjänteinen ja kokonaistehokas suunnittelu korostuu, ja eri tietojärjestelmähankkeet lähestulkoon pakotetaan toistensa kanssa yhteensopiviksi. Mikäänhän ei periaatteessa estä samojen hyötyjen saavuttamista ilmankin kokonaisarkkitehtuurityötä, mutta liian usein IT-projektit ovat jääneet irrallisiksi ja siiloutuneiksi palasiksi organisaatioiden sisällä. Jonkinlaista kokonaisvaltaista ajattelua ja suunnittelua tarvitaan joka tapauksessa, ja juuri tähänhän kokonaisarkkitehtuuri tähtää.
 

Avatar

Rami Huovinen

Rami on monessa liemessä keitetty IT-alan ammattilainen, jolla on laaja-alaista kansainvälistä kokemusta ohjelmistotuotannosta, konsultoinnista ja erilaisista IT-palveluista. Käytännön työkokemuksen ohella hän on myös suorittanut sertifioinnit projektinhallinnasta (PRINCE2 Foundation & PMP), ketterästä ohjelmistokehityksestä (Certified Scrum Master) sekä IT-palveluiden hallinnasta ja johtamisesta (ITIL v3 Foundation). Nykyisin hän työskentelee projektinvetotehtävien lisäksi hanke- ja projektinhallinnan kehittämisen parissa.

Linkedin profile

Piditkö lukemastasi? Jaa se myös muille.