Vähän ehkä kulunutkin sanonta on, että jos sovelluskehittäjälle annettaisiin vapaat kädet valita, niin verkkosivustot rakennettaisiin aina viimeisimmillä ja trendikkäimmillä välineillä, asiakkaan toiveista ja etenkin kustannuksista välittämättä. Verkkopalveluiden tapauksessa voitaisiin tällöin tarkoittaa esimerkiksi headless-mallin mukaista sisällönhallintaa, Reactin tai Vuen kaltaisia JavaScript-ohjelmistokehyksiä sekä niitä täydentäviä mikropalveluja ja ohjelmistokirjastoja, joista moni ei välttämättä ole koskaan kuullutkaan.
North Patrol on suunnitteluun erikoistunut konsulttitoimisto. Suunnittelemme, autamme teknologiavalinnoissa, kilpailutamme. Emme myy toteutusprojekteja, emmekä lisenssejä, olemme aidosti asiakkaan puolella.
3.4.2023
Ensikuulemalta ehkä pelottava ajatus. JavaScript-pohjainen sovelluskehittäminen on kuitenkin viime vuosina ottanut isoja harppauksia eteenpäin, eikä se enää ole asiakkaankaan kannalta pelkästään suuri ja tuntematon uhka. Verkkopalveluissa hyödynnetään myös entistä enemmän valmiita tuotteita ja/tai alustaratkaisuja, eikä kaikkea enää tarvitse tehdä täysin pitkästä tavarasta. Moneen tarpeeseen räätälöity ratkaisu voi muutenkin sopia paremmin kuin esimerkiksi monoliittinen verkkosisällön julkaisujärjestelmä.
Kaikki verkkopalvelut rakennetaan räätälöiden
Termi ”räätälöity ratkaisu” alkaa myös olemaan jo hieman vaikeasti määriteltävissä, ja ehkä vähän vanhahtavakin. Yksikään verkkopalvelu ei tänä päivänä synny ilman jonkinasteista räätälöintiä. Ennemminkin pitäisi puhua koostettavista ratkaisuista, tai kuten kolmannella kotimaisella usein puhutaan, composable-arkkitehtuurin mukaisista ratkaisuista. Näissä verkkopalvelukokonaisuus toteutetaan tyypillisesti erilaisia, jopa hyvin itsenäisiä komponentteja yhdistelemällä.
Verkkopalvelu voidaan rakentaa esimerkiksi siten, että sisällönhallinnasta huolehtii yksi sovellus, raakadatan varastoinnista toinen, datan rikastamisesta kolmas, hakupalvelusta neljäs ja käyttäjälle näkyvästä esityskerroksesta viides. Ja liikenne näiden välillä hoidetaan modernien ohjelmointirajapintojen, kuten REST, välityksellä.
Suosittuja koostamisen teknologioita
North Patrolin konsultoimiin kilpailutuksiin jätetyissä tarjouksissakin on yhä useammin mukana ainakin joitakin composable-mallin mukaisia elementtejä. Näissä liikennöinti eri osien välillä tapahtuu useimmiten juuri REST-rajapintakutsuilla. Usein ratkaisuissa on hyödynnetty myös suosituimpien alustaekosysteemien, kuten Microsoft Azure, Google Cloud Platform ja Amazon Web Services, tarjoamia valmispalveluja, joita yhdistelemällä melkeinpä ratkaisu kuin ratkaisu voidaan rakentaa. Silloin tosin tyypillistä on, että pysytellään pitkälti yhden ekosysteemin sisällä.
Alla joitakin poimintoja niistä teknologioista, joita meille useimmin tulee vastaan. Ratkaisut ovat toki aina asiakaskohtaisia ja sovitetaan niihin tarpeisiin ja järjestelmiin, jotka tilanteeseen parhaiten sopivat.
Sisällönhallintaan tarjolla paljon tuttujakin tuotenimiä
Sisällönhallintaan yleisin ratkaisu on edelleen aika perinteinen, useimmiten WordPress tai Drupal, mutta myös headless-ratkaisut ovat selkeästi nostamassa päätään. Headless-ratkaisuista selkeästi ykkönen Pohjoismaissa on tällä hetkellä Contentful, mutta myös Prismic, Sanity ja Strapi ovat suosittuja. Tästä aiheesta kannattaa lukea lisää aikaisemmasta jutustamme Suosituimmat rajapintalähtöiset CMS-tuotteet Suomessa ja Pohjoismaissa.
Teknologiavalinta on vuosikymmenen investointi
Teknologiaratkaisuissa ei kannata tehdä valintojaan kuumimpien trendien mukaan, vaan soveltuvuuden, skaalautuvuuden, ylläpitokokemuksen, yhteensopivuuden ja elinkaarikustannuksien ehdoilla. North Patrol auttaa näkemään teknologiavaihtoehtojen plussat ja miinukset puolueettomasti, konkreettisesti ja kaukonäköisesti.
JavaScriptiä käyttöliittymäkerroksen rakentamiseen
Vaikka sisällönhallintajärjestelmäksi tarjottaisiinkin vaikkapa WordPressiä, mukaan on usein liitetty erilaisia JavaScript-pohjaisia osakokonaisuuksia. Käyttöliittymäkerros tai sen osa on tällöin useimmiten rakennettu siten, että pohjalla on joko React tai Vue ohjelmistokehys, jota on täydennetty erilaisilla käyttöliittymän rakentamiseen tarkoitetuilla kirjastoilla ja/tai ohjelmistokehyksillä.
Reactin kanssa paljon käytettyjä käyttöliittymäkirjastoja/-kehyksiä ovat mm. MaterialUI ja React Bootstrap. Suorituskykyä, skaalautuvuutta ja tietoturvaa taasen pyritään kohentamaan Gatsbyn tai Next.js:n kaltaisilla kokonaisuuksilla. Vue-toteutuksissa vastaavia ratkaisuja tarjoavat esimerkiksi Bootstrap Vue, Nuxt.js ja Gridsome.
Pisimmälle vietyjen laajennusten ympärille on myös syntynyt varsin uskottavaa liiketoimintaa. Tästä hyvänä esimerkkinä on mm. Vue Storefront, joka on tuotteistanut kokonaisen verkkokaupan esityskerroksen ja tarjoaa sitä palveluna eri teknologioilla tuotetuille verkkokauppa-alustoille.
Taustajärjestelmiä mukaan tarpeen ja tarkan harkinnan perusteella
Taustajärjestelmien liittäminen kokonaisuuteen vaatii aina tarkkaa harkintaa. Kaikki järjestelmät eivät tarjoa moderneja rajapintoja ja/tai rajapintojen muokkaaminen tarvetta vastaavaksi voi olla yllättävän työlästä. Usein on myös niin, että taustajärjestelmään tallennettu data ei sovellu sellaisenaan verkossa hyödynnettäväksi. Silloin pitää miettiä voidaanko dataa rikastaa jossain toisessa järjestelmässä, onko taustajärjestelmään tehtävä muutoksia vai pitääkö tarpeeseen keksiä jotain aivan muuta. Nämä pohdinnat on aina tehtävä tapauskohtaisesti.
Helpompia tapauksia ovat ns. Saas-palvelut, jotka useimmiten tarjoavat joustavat rajapinnat jo valmiiksi. Tällaisia ovat esimerkiksi hakupalvelut, joista kannattaa lukea lisää aikaisemmasta jutustamme SaaS-hakuratkaisut kotimaisilla sivustoilla 2023.
Asiakkaillamme on myös usein käytössä erilaisia tapahtumienhallintaratkaisuja tai varausjärjestelmiä, kuten Lyyti, ja sellainen on usein helposti liitettävissä kokonaisuuteen. Myös erilaisia, pienempiä ja isompia chat-ratkaisuja, kuten NinChat, Giosg tai Rocket.chat, on markkinoilla paljon ja ne ovat helposti lisättävissä kokonaisuuteen. Verkkomaksamiseen liittyvissä tarpeissa mukaan saatetaan liittää myös esimerkiksi Paytrailin, Shopifyn tai vaikkapa Lippu.fi:n kaltaisia elementtejä.
Hieman hankalampia tapauksia ovat sitten varsinaiset liiketoimintajärjestelmät, eli vaikkapa asiakkuudenhallintaratkaisut tai tuotetiedonhallintaan käytettävät taustajärjestelmät. Niiden tietomallit on usein suunniteltu liiketoiminnan pyörittämisen näkökulmasta eikä välttämättä sisällön esittämiseen verkkosivuilla, joten oikeanlaisen tiedon kaivaminen niistä saattaa vaatia isompaakin jumppaa. Siitä huolimatta voi hyvin olla, että jumppa kannattaa silti tehdä.
Kuulostaa modernilta ja toimivalta, eikö vain? Miksi kaikkia verkkopalveluja ei sitten kannattaisi rakentaa näin? Pohditaanpa hetki mallin plussia ja miinuksia.
Koostamisen edut
Composable-mallin kiistattomana etuna voidaan pitää ainakin tietynlaista joustavuutta. Kaikki munat eivät ole samassa korissa ja yksittäisiä toiminnallisia kokonaisuuksia voi kehittää toisistaan riippumatta. Palikoita voidaan testata itsenäisemmin, mikä nopeuttaa kehitystyötä ja helpottaa laadunvarmistusta. Kokonaisia palikoita voi myös tarpeen mukaan korvata toisilla, ja jos jotain ei löydy valmiina, palikka voidaan toteuttaa itse.
Teknisesti malli mahdollistaa myös selkeämmän ja paremmin roolitetun kokonaisarkkitehtuurin verkkopalvelulle. Selkeä roolitus on erityisen tärkeää tilanteissa, jossa verkkopalvelukokonaisuus rakennetaan erilaisten taustajärjestelmien, kuten tuotetietokannan, varausjärjestelmän tai asiakkuudenhallintajärjestelmän ympärille. Asiakkaalle näkyvä osa on tällöin usein vain jäävuoren huippu, ohut pintakerros, joka sisältää vain vähän varsinaista toimintalogiikkaa.
Mikään teknologia ei vielä takaa onnistumista
Composable-mallia perustellaan usein myös yhtenäisemmällä asiakaskokemuksella, suorituskyvyllä, kehitystyön ketteryydellä ja nopeudella sekä monilla muilla sellaisilla argumenteilla, joiden toteutuminen on erityisen paljon kiinni siitä, miten hyvin tai huonosti toteutus suunnitellaan ja tehdään. Ja näissä asioissa korostuu tietenkin paitsi toimittajan myös tilaajan organisaation asiantuntemus, kun eri järjestelmät pitää saada keskustelemaan keskenään.
Hyvänkin arkkitehtuurin päälle on täysin mahdollista tehdä sutta ja sekundaa.
Koostamisen haasteita
Rakennuspalikoiden itsenäisyys muodostaa toisaalta myös merkittävän haasteen. Koska kokonaisuuden osia voidaan kehittää toisistaan riippumatta, toisinaan jopa eri organisaatioissa ja toisistaan tietämättä, muutosten hallintaan on kiinnitettävä erityisen paljon huomiota. Yllättäen ilmaantuvat muutokset tietorakenteisiin tai rajapintoihin saattavat aiheuttaa palikoiden yhteensopimattomuusongelmia ja pahimmillaan halvaannuttaa koko palvelun. Kaikkien osapuolten on pidettävä toisensa ajan tasalla jatkuvasti.
Toinen palikoiden erillisyydestä seuraava asia on, että palvelun ylläpitäjien on usein sukkuloitava useiden eri järjestelmien välillä saadakseen aikaan halutunlaisen lopputuloksen. Käyttökokemus ei välttämättä aina ole sitä, mitä vaikka viestinnällisten verkkosivustojen ylläpidossa ollaan totuttu käyttämään. Tämä luo haasteita myös esimerkiksi koulutusten suhteen.
Rajapintaistettujen palvelujen käyttö edellyttää myös keskimääräistä enemmän teknistä osaamista. Jos jotain menee pieleen, riittävän osaavaa teknistä tukea on oltava saatavilla hyvin nopeasti. Erityisesti JavaScript-pohjaisiin kirjastoihin tulee päivityksiä jatkuvasti, niiden julkaisua, yhteensopivuutta ja vaikutuksia on seurattava jatkuvasti ja ne pitää osata myös päivittää olemassa oleviin järjestelmiin ilman ongelmia.
Tästä seuraa mm. asia, jota ei ehkä niin usein tule ajateltua: Koostetuissa ratkaisuissa nimenomaan ylläpitovaiheen isot työmäärät ja kustannukset usein yllättävät. Kokonaisuus vaatii tyypillisesti monoliittiseen ratkaisuun verrattuna enemmän jatkuvaa hoivaa ja huolenpitoa. Vaikka ensimmäinen tuotantoversio syntyisikin ketterästi ja nopeasti, kokonaisuuden elinkaarikustannukset voivat olla moninkertaiset monoliittisempaan ratkaisuun verrattuna.
Laajempien kokonaisuuksien ratkaisu
Koostettavat ratkaisut sopivat tyypillisesti parhaiten nimenomaan sellaisten laajojen palveluiden alustaksi, joihin liittyy monimutkaisia käsittelyprosesseja, joissa on tarve yhdistellä tietovirtoja eri lähteistä ja joille tavoitellaan pitkää elinkaarta. Loppukäyttäjälle näkyvä osa palvelua on tällöin vain pieni osa kokonaisuutta. Esimerkkinä voisi olla vaikkapa B2B-verkkokaupat, joiden tuotedata on organisaation sisäisissä järjestelmissä ja joihin halutaan persoonallista brändileimaa, mutta valmiista verkkokauppa-alustoista ei löydy sopivaa ratkaisua.
Pitkän elinkaaren takaamiseksi on kuitenkin aina varmistettava, että teknistä osaamista löytyy jatkossakin, ja että euroja löytyy takataskusta myös pitkään ylläpito- ja jatkokehitysvaiheeseen.
Koostaminen ei siis ole hopealuoti, joka sopii kaikille ja kaikenlaisiin palveluihin. Pieniäkin verkkopalveluja voi toki suunnitella composable-mallin mukaan, mutta usein niihin tarpeisiin löytyy kustannustehokkaampia ja käyttäjäystävällisempiäkin ratkaisuja. Arkkitehtuuri kannattaakin suunnitella jo varhaisessa vaiheessa ja puntaroida eri vaihtoehtojen etuja ja haittoja huolella.
Teknologiavalinta on vuosikymmenen investointi
Teknologiaratkaisuissa ei kannata tehdä valintojaan kuumimpien trendien mukaan, vaan soveltuvuuden, skaalautuvuuden, ylläpitokokemuksen, yhteensopivuuden ja elinkaarikustannuksien ehdoilla. North Patrol auttaa näkemään teknologiavaihtoehtojen plussat ja miinukset puolueettomasti, konkreettisesti ja kaukonäköisesti.
Lue lisää aiheesta
- Julkaisujärjestelmät ja verkkokauppa-alustat Suomessa
- Suosituimmat rajapintalähtöiset CMS-tuotteet Suomessa ja Pohjoismaissa
- Datakatsaus: Webin teknologiat Suomessa 2022
- Gartnerin näkemyksiä verkkokauppamarkkinan kehityksestä
- Case: Paulig uudisti yritysasiakkaidensa verkkokaupan
- Forresterin katsaus ketteriin sisällönhallintajärjestelmiin
- Contentfulin hyödyntäminen sisällönhallintajärjestelmänä
- Katsaus Suomen suosituimpiin julkaisujärjestelmiin ja verkkokauppa-alustoihin
PS. Sinua voisi kiinnostaa tulossa oleva ilmainen webinaarimme: Digitaaliset asiointipalvelut – Erilaiset konseptit ja toteutuksen eri vaihtoehdot (11.12.2024 klo 10:00). Ilmoittaudu webinaariin
