Composable commerce käytännössä: milloin modulaarinen verkkokauppa kannattaa?

Composable commerce on ennen kaikkea arkkitehtuurinen ajattelumalli

Composable commercea ei kannata ajatella yksittäisenä teknologiana, tuotteena tai verkkokauppa-alustana. Kyse on pikemminkin arkkitehtuurisesta ajattelu- ja toimintamallista.

Perinteisessä ratkaisussa verkkokaupan eri toiminnallisuudet voivat sijaita yhden suuren järjestelmän sisällä. Samasta alustasta löytyvät esimerkiksi käyttäjien hallinta, tuotteet, sisällöt, kampanjasäännöt ja monet muut verkkokaupan tarvitsemat ominaisuudet.

Composable-mallissa nämä toiminnot voidaan sen sijaan jakaa erillisiksi komponenteiksi, jotka keskustelevat keskenään rajapintojen kautta. Yksi järjestelmä voi siis vastata asiakasdatasta, toinen sisällöistä, kolmas tuotehausta ja neljäs kampanjoista. Lisäksi kokonaisuuteen voidaan rakentaa omia palveluita sellaisiin toimintoihin, joita valmiit tuotteet eivät ratkaise tarkoituksenmukaisesti.

Commerce on tässä yhteydessä vain yksi composable-ajattelun sovellusalue. Samaa modulaarista periaatetta voidaan käyttää muissakin verkkopalveluissa, mutta verkkokauppa tarjoaa käsitteelle konkreettisen kontekstin: siinä tarvittavat toiminnallisuudet ovat yleensä helposti tunnistettavissa.

Monoliitti ja composable eivät välttämättä sulje toisiaan pois

Composable-ratkaisu asetetaan helposti vastakkain niin sanotun monoliittisen verkkokauppa-alustan kanssa. Jaottelu ei kuitenkaan ole aivan näin mustavalkoinen.

Kun organisaation kokonaisarkkitehtuuria tarkastellaan riittävän korkealta tasolta, myös monoliittinen verkkokauppa-alusta voi olla yksi osa composable-kokonaisuutta. Ero tulee näkyvämmäksi, kun tarkastelua rajataan itse verkkokauppaan.

Monoliittisessa verkkokaupparatkaisussa toiminnallisuudet ovat saman järjestelmän sisällä ja enemmän tai vähemmän sidoksissa toisiinsa. Composable-ratkaisussa käyttäjähallinta, sisällönhallinta, kampanjat tai muut toiminnot voivat olla itsenäisiä komponentteja.

Eroa voi havainnollistaa talon rakentamisella. Perinteinen verkkokauppa-alusta muistuttaa talopakettia: saat pitkälle valmiin kokonaisuuden, jota voidaan muokata, mutta toimittaja ja järjestelmä määrittelevät samalla tietyt rakenteelliset rajat sille, mitä voidaan tehdä.

Composable-mallissa lähtökohtana on ennemmin tontti. Ensin määritellään, mitä tarvitaan, ja sen jälkeen kokonaisuus suunnitellaan tätä tarvetta varten. Vapautta on enemmän, mutta samalla myös suunnittelun merkitys kasvaa.

Headless ja mikropalvelut eivät tarkoita samaa asiaa kuin composable

Composable commercen yhteydessä puhutaan usein myös headless-ratkaisuista ja mikropalveluista. Ne liittyvät samaan arkkitehtuurikeskusteluun, mutta tarkoittavat eri asioita.

Headless tarkoittaa käytännössä sitä, että asiakkaalle näkyvä käyttöliittymä eli frontend on irrotettu taustajärjestelmästä. Käyttöliittymä keskustelee taustalla olevien järjestelmien kanssa rajapintojen kautta.

Headless voi siis olla osa composable-ratkaisua, ja käytännössä näin usein onkin, mutta headless itsessään ei vielä tee arkkitehtuurista composablea.

Mikropalvelut ovat puolestaan enemmän tekninen toteutustapa. Sen sijaan, että suuri määrä toiminnallisuuksia olisi yhden sovelluksen tai palvelimen sisällä, niitä voidaan pilkkoa pienemmiksi itsenäisiksi palveluiksi.

Mikropalvelu voi vastata esimerkiksi yhdestä tarkasti määritellystä liiketoimintasäännöstä tai verkkokaupan toiminnosta.

Myös mikropalvelut voivat siis olla composable-arkkitehtuurin osia, mutta composable commerce ei edellytä sitä, että kaikki rakennetaan mikropalveluina.

Milloin composable commercea kannattaa harkita?

Yksiselitteistä rajaa ei ole, jonka jälkeen verkkokauppa pitäisi automaattisesti rakentaa composable-mallilla. Teknologiavalinnan pitäisi lähteä tarpeesta eikä siitä, että jokin tietty arkkitehtuurimalli on ennalta päätetty oikeaksi.

Yksi keskeinen kysymys on organisaation nykyinen järjestelmäarkkitehtuuri. Etenkin suuremmilla yrityksillä on yleensä jo useita verkkokaupan tarvitsemia komponentteja: ERP, CRM, asiakasdatan hallintaa, tuotetietoa, sisällönhallintaa tai muita liiketoimintajärjestelmiä.

Silloin kannattaa kysyä, mitä verkkokauppaa varten todella tarvitaan uutena ja mitä olemassa olevista järjestelmistä voidaan hyödyntää suoraan.

Jos tarvittava tieto ja liiketoimintalogiikka ovat jo muualla, kokonaisen uuden verkkokauppa-alustan tuominen niiden väliin ei välttämättä tuota vastaavaa lisäarvoa.

Toinen composablea puoltava tekijä on liiketoiminnan muuttuminen. Modulaarisuuden hyöty korostuu ympäristössä, jossa verkkopalvelua kehitetään jatkuvasti ja liiketoiminnan tarpeisiin voi tulla suuriakin suunnanmuutoksia.

Kun kokonaisuus muodostuu erillisistä osista, niitä voidaan kehittää, korvata tai lisätä ilman, että koko verkkokaupparatkaisua täytyy välttämättä uusia samalla kertaa.

Verkkokauppa ei aina tarvitse verkkokauppa-alustaa

Ajatus voi tuntua aluksi ristiriitaiselta: voidaanko verkkokauppa todella rakentaa ilman varsinaista verkkokauppa-alustaa?

Kyllä voidaan. Joissakin tilanteissa se voi olla jopa tarkoituksenmukaisempi ratkaisu.

Valmis verkkokauppa-alusta toimii hyvin, kun kaupankäynnin malli on suhteellisen suoraviivainen. Jos yritys myy esimerkiksi tuotteita, joissa variaatioita ovat lähinnä koko, väri tai vastaavat perustiedot, valmiiden alustojen tarjoama toimintamalli vastaa usein tarpeeseen erittäin hyvin.

Tilanne muuttuu, kun kaupankäyntiprosessiin tulee paljon yrityskohtaisia erityispiirteitä. Eri tuotekategorioihin voi esimerkiksi liittyä erilaisia sääntöjä tai lainsäädäntöä, tilaus voi vaatia hyväksyntää tai myyjän osallistumista, eikä prosessi enää vastaa yksinkertaista mallia, jossa asiakas lisää tuotteen ostoskoriin, maksaa sen ja tuote toimitetaan.

Tällaisessa ympäristössä valmis verkkokauppa-alusta ei välttämättä enää tuota samaa hyötyä.

Turha välikerros voi tehdä arkkitehtuurista tarpeettoman monimutkaisen

Erityisen kiinnostava tilanne syntyy silloin, kun yrityksen varsinainen liiketoimintalogiikka ja data ovat jo esimerkiksi ERP-järjestelmässä.

Jos tämän päälle tuodaan valmis verkkokauppa-alusta, ERP:n sisältämä data joudutaan usein sovittamaan verkkokauppa-alustan omaan tietomalliin. Tietoa siirretään järjestelmästä toiseen ja muokataan siihen muotoon, jota uusi järjestelmä odottaa.

Jos verkkokauppa-alusta ei samalla tuo kokonaisuuteen olennaista uutta toiminnallisuutta, voidaan päätyä rakentamaan ja ylläpitämään välikerrosta lähinnä siksi, että organisaatio on lähtenyt oletuksesta, että verkkokauppa tarvitsee verkkokauppa-alustan.

Composable-ajattelu mahdollistaa toisen lähestymistavan. Jos esimerkiksi ERP pystyy jo hoitamaan tarvittavan liiketoimintalogiikan ja datan, sitä voidaan hyödyntää suoremmin ja rakentaa tarvittava integraatiokerros sen ympärille.

Näin vältytään ainakin osalta turhasta datan muuntamisesta ja uuden järjestelmän aiheuttamasta kerroksesta.

Mistä verkkokaupan perustoiminnallisuudet tulevat ilman yhtä alustaa?

Valmiin verkkokauppa-alustan etuna on, että suuri määrä tarvittavia ominaisuuksia tulee mukana. Composable-arkkitehtuurissa nämä ominaisuudet täytyy ratkaista erikseen.

Tämä ei kuitenkaan tarkoita, että kaikki pitäisi rakentaa itse.

Käyttäjien ja asiakkaiden hallinta

Suuremmassa organisaatiossa asiakasdata löytyy usein jo CRM:stä, CDP:stä tai muusta asiakkuuksiin liittyvästä järjestelmästä.

Silloin lähtökohta voi olla tämän olemassa olevan järjestelmän hyödyntäminen sen sijaan, että sama asiakasdata rakennettaisiin uudestaan verkkokauppa-alustalle.

Käyttäjän autentikointi ja loppukäyttäjälle näkyvän tilin hallinta voidaan puolestaan toteuttaa erillisillä autentikointipalveluilla. Vaihtoehtoja on tarjolla sekä pilvipalveluina että muilla toteutusmalleilla.

Olennaista on, ettei käyttäjähallinnan puuttuminen yhdestä keskitetystä verkkokauppa-alustasta tarkoita, ettei toimintoa pystyttäisi toteuttamaan.

Kampanjat ja alennussäännöt

Kampanjat havainnollistavat hyvin composable-ratkaisujen mahdollisuuksia mutta myös niiden haasteita.

Markkinointiin, kuten sähköpostiviestintään, on tarjolla suuri määrä valmiita palveluita. Verkkokaupan sisäiset kampanjasäännöt voivat sen sijaan olla haastavampi kokonaisuus.

Yksinkertaiset säännöt ovat suoraviivaisia toteuttaa. Tällaisia ovat esimerkiksi ilmainen toimitus tietyn ostoskorin arvon jälkeen tai määrätty prosenttialennus tuotteelle tai tuoteryhmälle.

Sääntö voidaan kytkeä vaikkapa tuotteen tai tuoteryhmän tietoihin, jolloin muu järjestelmä osaa soveltaa sitä.

Kun kampanjalogiikka muuttuu monimutkaisemmaksi, myös toteutus muuttuu vaativammaksi. Valmiita enterprise-tason ratkaisuja on olemassa, mutta pelkästään kampanjasääntöjä varten ei välttämättä ole tarkoituksenmukaista ottaa käyttöön raskasta järjestelmää.

Toinen vaihtoehto on rakentaa yrityksen tarpeeseen oma sääntökone. Se voi tarjota hyvin tarkasti halutut toiminnallisuudet, mutta monimutkaisen kampanjalogiikan toteuttaminen vaatii vastaavasti enemmän työtä ja investointia.

Tällainen kampanjamoottori on myös hyvä esimerkki mikropalvelusta osana composable-kokonaisuutta. Varsinainen logiikka voidaan toteuttaa itsenäisenä palveluna, kun taas kampanjoiden ylläpitäjän käyttöliittymä voidaan sijoittaa esimerkiksi sisällönhallintaan tai verkkokaupan muuhun hallintanäkymään.

Haku ja personointi

Myös tuotehakuun ja personointiin voidaan käyttää erillisiä, tähän tarkoitukseen kehitettyjä palveluita. Personointiominaisuuksia voi löytyä esimerkiksi kampanjatyökaluista ja hakuratkaisuista.

Composable-mallin kannalta olennaista ei ole yhden tietyn tuotteen valinta. Olennaista on mahdollisuus valita kuhunkin tehtävään ratkaisu, joka vastaa sekä yrityksen tarpeita että käytettävissä olevaa budjettia.

Useampi komponentti ei välttämättä tarkoita kalliimpaa ylläpitoa

Composable-arkkitehtuurista syntyy helposti mielikuva, että suuri määrä erillisiä komponentteja tekisi siitä automaattisesti vaikean ja kalliin ylläpitää.

Käytännössä tilanne ei ole näin yksinkertainen. Liiketoiminnan tai verkkokaupan ylläpitäjän näkökulmasta composable-ratkaisu voi parhaimmillaan näyttää lähes samalta kuin monoliittinen järjestelmä. Käyttäjä työskentelee muutamassa tarvitsemassaan käyttöliittymässä, vaikka niiden alla toimiva tekninen arkkitehtuuri muodostuisikin useista eri osista.

Myöskään monoliittinen verkkokauppa ei yleensä elä tyhjiössä. Etenkin suuremmissa ympäristöissä sen ympärille rakennetaan integraatioita muihin järjestelmiin, ja myös nämä integraatiot on ylläpidettävä. Siksi ylläpitokustannuksia ei voida päätellä yksin siitä, onko arkkitehtuuri monoliittinen vai composable.

Ylläpidon työmäärään vaikuttaa myös se, miten komponentit toteutetaan. SaaS-palvelun toimittaja vastaa oman palvelunsa ylläpidosta, ja pilvipalveluilla voidaan vastaavasti ulkoistaa infrastruktuurin ylläpitämistä palveluntarjoajalle sen sijaan, että kaikkea ajettaisiin ja ylläpidettäisiin itse.

Jonkun on silti vastattava kokonaisuudesta. Arkkitehtuurin eri osien elinkaarta täytyy seurata, vanhenevat teknologiat ja versiot tunnistaa ja kokonaisuuden toimivuudesta huolehtia.

Composable ei poista ylläpitoa, vaan muuttaa sitä, mistä ylläpidettävä kokonaisuus muodostuu.

Monimutkainen kaupankäyntiprosessi voi hyötyä modulaarisuudesta

Hyvä esimerkki composable-ajattelun hyödyistä on autokaupan verkkopalvelu, joka rakennettiin alun perin perinteisen verkkokauppa-alustan päälle. Ratkaisun kehittyessä huomattiin kuitenkin, ettei valmis verkkokauppamalli vastannut hyvin auton myynnin monimutkaiseen prosessiin. Auton ostaminen poikkeaa olennaisesti suoraviivaisesta verkkokauppatilauksesta, joten myös digitaalinen kaupankäyntiprosessi vaatii tavallista enemmän yritys- ja tuotekohtaista logiikkaa.

Kokonaisuutta vietiin tämän vuoksi composable-suuntaan, jossa hyödynnettiin mikropalveluita, SaaS-palveluita ja asiakkaan omia järjestelmiä. Olennaista ei ollut löytää yhtä alustaa, joka yrittäisi ratkaista koko prosessin, vaan yhdistää eri tarpeisiin soveltuvat komponentit yhdeksi toimivaksi kokonaisuudeksi.

Composable ei kuitenkaan tarkoita vain suuria ja raskaita hankkeita. Toisenlaisessa tapauksessa verkkokauppa-alusta oli käytännössä toiminut vain ERP:n ja verkkopalvelun välisenä kerroksena, vaikka varsinainen liiketoimintalogiikka oli jo ERP:ssä. Tällöin verkkokauppa-alusta voitiin poistaa ja korvata suoraviivaisemmalla integraatiokerroksella.

Myös tällainen ratkaisu voidaan nähdä composable-arkkitehtuurina, kun kokonaisuus suunnitellaan modulaariseksi ja myöhemmin laajennettavaksi. Uusia osia voidaan lisätä tarpeen mukaan ilman, että arkkitehtuurin keskellä on yksi kaiken määrittelevä järjestelmä.

Composable vaatii enemmän suunnittelua projektin alussa

Composable-ratkaisun tarjoama vapaus on samalla yksi sen suurimmista haasteista. Valmista verkkokauppa-alustaa käyttöönotettaessa järjestelmä tuo mukanaan rakenteita, toimintatapoja ja valmiiksi tehtyjä teknisiä valintoja. Ne voivat joskus tuntua rajoituksilta, mutta samalla ne tekevät suuren määrän päätöksiä asiakkaan puolesta.

Composable-arkkitehtuurissa vastaavia valmiita rajoja ei lähtökohtaisesti ole. Siksi projektin alussa tarvitaan enemmän määrittelyä ja suunnittelua: on tarkasteltava itse verkkokauppaa laajempaa kokonaisarkkitehtuuria, tunnistettava olemassa olevat järjestelmät ja niiden vastuut sekä päätettävä, mitkä toiminnallisuudet kuuluvat mihinkin osaan kokonaisuutta.

Sen sijaan, että lähtökohta olisi yksinkertaisesti ”tarvitsemme verkkokaupan”, pitäisi tarkastella laajemmin sitä, mitä digitaalisen kaupankäynnin kokonaisuuden todella täytyy tehdä ja mitä yrityksellä on jo valmiina. Kun mahdollisuuksia on paljon, projektille täytyy myös itse määritellä riittävän selkeät rajat. Kaikkea mahdollista ei kannata toteuttaa vain siksi, että composable-arkkitehtuuri sen sallii.

Composable ei ole paras ratkaisu, jos verkkokaupan halutaan vain pysyvän ennallaan

Composable-ajattelun keskeinen hyöty on mahdollisuus kehittää kokonaisuutta liiketoiminnan mukana. Komponentteja voidaan vaihtaa, uusia toimintoja lisätä ja arkkitehtuuria muuttaa sitä mukaa, kun tarpeet kehittyvät.

Samasta syystä composable ei välttämättä ole oikea lähtökohta tilanteeseen, jossa tavoitteena on pystyttää verkkokauppa ja jättää se sen jälkeen mahdollisimman pitkälti ennalleen. Jos kaupankäynnin toimintamalli on vakiintunut, tarpeet ovat yksinkertaisia eikä suurempia muutoksia ole näkyvissä, valmis verkkokauppa-alusta voi olla tarkoituksenmukaisempi ratkaisu.

Composable on kiinnostavimmillaan silloin, kun arkkitehtuurilta halutaan nimenomaan kykyä muuttua liiketoiminnan mukana. Sen tarjoama joustavuus tuottaa eniten arvoa ympäristössä, jossa myös digitaalisen kaupankäynnin tarpeiden oletetaan muuttuvan ja kehittyvän.

Tekoäly ei muuta composable-ajattelun perustaa – mutta lisää uuden valintakysymyksen

Tekoäly ei itsessään muuta composable commercen perusajatusta. Kyse on edelleen siitä, miten kokonaisuus rakennetaan ja miten eri toiminnallisuudet jaetaan komponentteihin. AI voi kuitenkin tulla yhdeksi näistä komponenteista, jolloin arkkitehtuurin näkökulmasta olennaiseksi nousevat esimerkiksi käytettävä malli, sen toteutusympäristö ja tapa, jolla dataa käsitellään.

Valmiisiin kaupallisiin alustoihin rakennetaan yhä enemmän niiden omia AI-toimintoja. Käyttäjän näkökulmasta tämä voi olla helppo ratkaisu, mutta samalla organisaatio sitoutuu alustan tekemiin teknologiavalintoihin ja siihen, miten kyseinen palvelu käsittelee sille annettua dataa. Tällä voi olla erityistä merkitystä yrityksille, joilla on tarkkoja vaatimuksia esimerkiksi sille, millä maantieteellisellä alueella dataa voidaan käsitellä.

Composable-ratkaisussa AI voidaan nähdä yhtenä valittavana komponenttina muiden joukossa. Käytettävä ratkaisu voidaan valita yrityksen omien vaatimusten mukaan, ja tarvittaessa myös sen toteutusympäristöön voidaan vaikuttaa. Näin tekoäly ei ole automaattisesti sidottu siihen ratkaisuun, jonka verkkokauppa-alustan toimittaja on päättänyt tarjota osana omaa palveluaan.

Teknologiavalinnoissa kannattaa säilyttää mahdollisuus vaihtaa suuntaa

Sama periaate ulottuu tekoälyä laajemmalle. Composable-arkkitehtuuria suunniteltaessa kannattaa miettiä jo etukäteen, kuinka helposti yksittäinen komponentti tai teknologia voidaan tarvittaessa vaihtaa. Yksi tapa pienentää riippuvuutta yksittäisestä toimittajasta on hyödyntää mahdollisuuksien mukaan avoimia teknologioita tai valita kaupallinen palvelu siten, että vastaava ratkaisu on saatavilla myös muualta.

Ajatuksena on välttää tilanne, jossa liiketoiminnan kannalta kriittinen toiminto sitoutuu niin voimakkaasti yhteen SaaS-palveluun, että siitä irtautumisesta tulee myöhemmin erittäin vaikeaa. Sama ajattelu voi ulottua myös infrastruktuuriin. Vaikka esimerkiksi tietokanta hankittaisiin hallinnoituna pilvipalveluna, sen taustalla oleva teknologia voidaan mahdollisuuksien mukaan valita niin, että tietokanta on tarvittaessa siirrettävissä toiseen ympäristöön.

Mahdollisuus vaihtaa suuntaa korostuu, kun palveluiden hinnoittelu, dataa koskevat vaatimukset tai tarjolla olevat teknologiat muuttuvat. Jos kriittinen liiketoimintalogiikka rakennetaan kokonaan yhden suljetun palvelun sisälle, palveluntarjoajan tekemät muutokset vaikuttavat suoraan myös yrityksen liikkumavaraan.

Composable-ratkaisun arvo ei siksi ole vain siinä, että tänään voidaan valita kuhunkin tarpeeseen sopivimmat komponentit. Olennaista on myös se, ettei tämän päivän valinnoilla tarpeettomasti suljeta pois huomisen vaihtoehtoja.

Älä aloita työkalusta – aloita tarpeesta ja katso riittävän pitkälle eteenpäin

Composable commerce tiivistyy lopulta melko yksinkertaiseen ajatukseen: teknologian pitäisi seurata liiketoiminnan tarvetta, ei päinvastoin. Kun verkkokauppaa tai muuta digitaalisen kaupankäynnin ratkaisua lähdetään uudistamaan, keskustelua ei siksi kannata aloittaa siitä, mikä alusta tai työkalu halutaan ostaa. Parempi lähtökohta on kuvata, mitä halutaan saada aikaan, ja arvioida vasta sen jälkeen, millaisella arkkitehtuurilla ja teknologioilla tavoite kannattaa ratkaista.

Samalla pitäisi katsoa tämän hetken tarpeita pidemmälle. Juuri nyt tarvittava ratkaisu voi poiketa huomattavasti siitä, mitä liiketoiminta tarvitsee muutaman vuoden kuluttua. Suunnittelussa onkin tärkeää ymmärtää paitsi tämän päivän ongelma myös se, mihin suuntaan liiketoiminta on menossa ja millaisia muutoksia digitaaliseen kaupankäyntiin voi sen myötä tulla.

Tämä ei tarkoita, että kaikki tulevaisuuden tarpeet pitäisi toteuttaa heti. Tarkoitus on pikemminkin rakentaa ratkaisu siten, että sitä voidaan kehittää myöhemmin eikä nykyhetken valinnoilla tarpeettomasti suljeta tulevaisuuden vaihtoehtoja.

Composable commerce ei siis ole itseisarvo eikä automaattisesti perinteistä verkkokauppa-alustaa parempi ratkaisu. Yksinkertaiseen ja vakiintuneeseen kaupankäyntiin valmis alusta voi olla juuri oikea valinta. Kun yrityksellä on sen sijaan jo merkittävä järjestelmäympäristö, kaupankäynnin prosessit ovat yksilöllisiä ja liiketoiminnan täytyy pystyä muuttumaan, modulaarinen arkkitehtuuri tarjoaa toisenlaisen lähtökohdan: verkkokaupan sijaan voidaan rakentaa juuri se kaupankäynnin kokonaisuus, jota liiketoiminta oikeasti tarvitsee.