Kuinka siirtyä Composable-arkkitehtuuriin?

Kun yritys on päättänyt siirtyä Composable Commerce -malliin, on aika pohtia kuinka se toteutetaan teknisesti. Yleisesti ottaen tähän on kaksi vaihtoehtoa: 1) kaikki kerralla vaihtoon tai 2) vaiheittainen siirtyminen. Pureudutaan seuraavaksi näihin kahteen tapaan toteuttaa migraatio Composable- eli mikropalveluarkkitehtuuriin.

Tämä on Composable Commerceen syventyvän artikkelisarjan toinen osa, ensimmäinen artikkeli löytyy täältä: Yksittäinen alusta vs Composable Commerce.

Vaihtoehto 1: Kaikki kerralla vaihtoon

Vanhojen järjestelmien täysi korvaaminen yhdellä kertaa katsotaan tyypillisesti riskialttiiksi ja kalliiksi toimenpiteeksi, joten se olisi syytä rajata vain erityistapauksiin.

Mikropalveluihin siirtyminen kerralla – Riskit

Kun migraatio tehdään yhdellä kertaa, vanhojen järjestelmien täydellinen korvaaminen mikropalveluilla sisältää seuraavanlaisia riskejä ja haasteita:

• Laajan olemassa olevan verkkokauppaliiketoiminnan prosessien uudelleenluominen edellyttää merkittävää määrää työtä, vaikka se tarkoittaisi vain uusien komponenttien käyttöönottoa tai konfigurointia.
• Uudelle alustalle siirtyminen vaatii huomattavasti aikaa ja resursseja ennen kuin se tuottaa samanlaista arvoa kuin vanha alusta. Ja siinä kohtaa uusi alusta ei ole vielä edes alkanut ansaita tuottoa investoinnille.
• Havaitsemme usein halun ”tehdä kaikki paremmin kuin aiemmin”, mikä tarkoittaa monien toimintojen rakentamista testaamattomiin oletuksiin perustuen. Jotkut näistä eivät osoittaudu hyödyllisiksi ja ovat siten resurssien hukkaa.
• Klassinen strategia riskin minimoimiseksi on ottaa ensin käyttöön joukko suunniteltuja ominaisuuksia MVP:n (Minimum Viable Product) muodossa. Tämä voi tosin aiheuttaa pettymyksiä puuttuvien toimintojen vuoksi.

Milloin harkita täydellistä mikropalveluihin siirtymistä?

Koska mikropalveluihin siirtymiseen kertaheitolla liittyy riskejä, tulee ajatusta harkita tarkkaan. On kuitenkin olemassa olosuhteita, joissa täysi siirtymä on tarpeellinen. Täysi järjestelmien korvaaminen on hyvä vaihtoehto esimerkiksi seuraavanlaisissa tapauksissa:

• Nykyiset järjestelmät ovat yrityksen pullonkaula
• Luodaan uutta digitaalista liiketoimintaa, esim. siirtyminen B2B:stä D2C-liiketoimintaan
• Olemassa olevat järjestelmät ovat liian kalliita ylläpitää tai niillä ei ole enää tukea

Vaihtoehto 2: vaiheittainen siirtyminen

Yleensä suosittelemme yrityksille vaiheittaista järjestelmien korvaamista, sillä sen sisältämät riskit ovat alhaisemmat kuin siirtymisen toteuttamisessa kertarysäyksellä. Vanhan verkkokauppa-alustan ja järjestelmien korvaaminen askeleittain tarkoittaa käytännössä:

• Aloitetaan muutos pienessä mittakaavassa ja käynnistetään uusi alusta vanhan rinnalle.
• Pidetään muutosten laajuus minimitasolla. Asetetaan ydinarkkitehtuuri ensin paikoilleen ja vastustetaan mahdollisesti heräävää halua yhdistää kaikki toiminnot uuteen alustaan välittömästi.
• Selvitetään mitä nykyisiä palveluita ja järjestelmiä voidaan hyödyntää myös uudessa ratkaisussa, kuten ERP, CRM, PIM, DAM, PSM, WMS, toimitusratkaisut jne. Näitä ei tarvitse korvata, ei ainakaan samanaikaisesti.
• Lanseerataan uusi alusta alkuun vain pienelle asiakasryhmälle ennen yleistä julkistusta – tätä voidaan kutsua ”pehmeäksi lanseeraukseksi”. Voidaan kutsua esimerkiksi työntekijöiden ystävät ja perheenjäsenet testaamaan uutta sivustoa jonkin kannustimen avulla. Näin voidaan kontrolloida testiryhmän kokoa. Lisäksi läheiset ovat ymmärtäväisempiä mahdollisille uuden sivuston ongelmille ja antavat usein palautetta mielellään.

mikropalveluihin siirtyminen vaiheittain – hyödyt

Näemme paljon etuja siinä, että vanhasta verkkokauppa-alustasta ja järjestelmistä siirrytään Composable-arkkitehtuuriin vaiheittain:

• Kun pienempiä muutoksia tehdään useammin, päästään jokaisen muutoksen kohdalla havainnoimaan sen vaikutuksia – ja tarvittaessa oikaisemaan kurssia.
• Liiketoiminta voi reagoida muutoksiin myös arvaamattomilla tavoilla, esimerkiksi esiin nousevalla muutosvastarinnalla tai odottamattomilla pullonkauloilla. Vaiheittain etenevän korvausprosessin ansiosta näihin ilmiöihin voidaan vastata pidemmällä aikavälillä, eivätkä kaikki sivuvaikutukset tule käsiteltäväksi samanaikaisesti.
• Yrityksellä on toimiva ratkaisu käytössä koko ajan, ilman katkoksia.
• Jokaisen muutoksen yhteydessä yrityksen käytössä on aina turvallinen varasuunnitelma, jos yksittäinen muutos epäonnistuu tai vie odotettua kauemmin.
• Yksittäisten sovellusten ja järjestelmien ominaisuudet ja hyödyt saadaan käyttöön nopeammin, sillä ei ole tarvetta odottaa koko järjestelmän valmistumista.
• Matkan varrella voidaan tunnistaa komponentteja, joita ei tarvitsekaan siirtää osaksi uutta teknologiaa, jos huomataan siirtämisen vaivan ylittävän sen hyödyt. Kertarysäyksellä tehtävässä muutoksessa näin tapahtuu vähemmän todennäköisesti, sillä lopputulos ei ole välttämättä selkeä vielä silloin, kun suunnitelmia aletaan määritellä.
• Vaikka vaiheittain etenevä lähestymistapa voi tuoda hieman korkeammat kokonaiskustannukset täydelliseen korvaamiseen verrattuna, alhaisempi riski oikeuttaa tämän eron kustannuksissa.
• Kun uusi teknologia avaa uusia liiketoiminnan mahdollisuuksia, yrityksen toiminta ehtii sopeutua ja kehittyä sen mukana, jotta nämä mahdollisuudet voidaan hyödyntää.

Kuinka toteuttaa vaiheittainen siirtyminen?

Jos päädytään vaihtoehtoon numero kaksi ja Composable-arkkitehtuuriin halutaan siirtyä vaiheittain, voidaan prosessi aloittaa muutamalla eri tavalla:

1. headless-arkkitehtuuri ensimmäisenä askeleena

Headless-arkkitehtuurissa frontend ja backend erotetaan toisistaan. Frontendin eli esityskerroksen irrottaminen verkkokauppa-alustasta lisää joustavuutta muutosten tekemiseen “verhojen takana”, sillä ne eivät vaikuta negatiivisesti asiakkaiden käyttökokemukseen. Esityskerroksen irrottaminen nykyisestä alustasta voi olla teknisesti suuri muutos, mutta ei kovinkaan merkittävä organisatorisella tasolla.

Myös headlessiin siirtyminen voidaan vaiheistaa. Esimerkiksi tuotekatalogin navigaatio voidaan toteuttaa uudella esityskerroksella, mutta jättää monimutkaiset kassaprosessit vanhaan esityskerrokseen (olettaen, että verkkokauppamoottori säilyy samana). Vanhan ja uuden esityskerroksen voi tyylitellä visuaalisesti samanlaisiksi, jolloin siirtymä saadaan vaikuttamaan täysin saumattomalta. Ja kun siirtymä headless-arkkitehtuuriin on toteutettu, on helpompaa jatkaa vanhan kokonaisuuden osiin purkamista ja näin siirtyä kohti mikropalvelupohjaista arkkitehtuuria.

2. Aloita muuttamalla yksi toiminto

Vaihtoehtona on myös aloittaa matka kohti Composable-arkkitehtuuria vaihtamalla yksi tietty toiminto uuteen, best-of-breed sovellukseen tai palveluun. Voidaan esimerkiksi implementoida uusi headless-sisällönhallintajärjestelmä, ja ohjelmoida esityskerros noutamaan sisällöt tästä uudesta CMS:stä.

Loppukäyttäjä ei välttämättä huomaa mitään eroa, mutta organisaatiolla on tämän jälkeen käytössään alansa huippua edustava sisällönhallintajärjestelmä, joka tarjoaa verrattomia etuja sisältöjen hallintaan ja työnkulkuihin. Näin voidaan verkkosivuston työstämisen ohella alkaa kehittää organisaation sisällönhallintaa, ja jopa lisätä mukaan kokonaisuuteen uusia kanavia.

Tämän jälkeen voidaan yhä useampia toimintoja siirtää palveluiksi, kuten personointi ja mahdollisesti jopa kassa, kunnes vanha alusta toimii enimmäkseen erilaisten transaktioiden kautta. Lopulta ollaan vapaita siirtymään myös aiempaa virtaviivaisempaan verkkokauppamoottoriin, jos niin halutaan.

3. Totuuden lähteen siirtäminen

Etenemistavaksi voidaan valita myös ”totuuden lähteen” siirtäminen pois yksittäiseltä alustalta, vaikka data yhä kopioitaisiin verkkokauppa-alustalle. Tuotteet voidaan siirtää esimerkiksi PIM-järjestelmään.

Tämän jälkeen tuotetietoa voidaan johtaa ja rikastaa entistä paremmin ja käyttää uudelleen myös verkkokaupparatkaisun ulkopuolella. Tällöin verkkokauppa-alustan tuotteiden tiedot täytetään ja päivitetään PIM-järjestelmän puolella.

PIM-järjestelmän hyödyntäminen voidaan näin aloittaa heti ja tehdä samalla tulevaisuuden migraatio helpommaksi: uuden verkkokauppa-alustan integroiminen tähän kokonaisuuteen on helpompaa, kuin siirtyminen PIM-järjestelmään ja uuteen verkkokauppamoottoriin yhtäaikaisesti.

Lue aiheesta: PIM osana Composable Commerce -matkaa

Oikeiden kumppanien valinta

Jotta vaiheittainen lähestymistapa onnistuu, on hyvä etsiä palveluntarjoajia, jotka noudattavat MACH-periaatteita. MACH Alliance kokoaa yhteen useita teknologiatoimittajia, jotka ovat todennettuja Composable-arkkitehtuurin osaajia – yhden tulevaisuudenkestävän sateenvarjon alla. Lisäksi on hyvä selvittää millaisia connectoreita ja kiihdyttimiä kumppani on aiemmin rakentanut, jotta pyörää ei tarvitse keksiä uudelleen.

Me Vaimolla teemme läheisesti yhteistyötä partneriemme – Adobe, commercetools ja Contentful – kanssa, jotka ovat MACH Alliance -järjestöön kuuluvia palvelutoimittajia. Meidän tavoitteemme on ylläpitää alansa parhaiden kumppanien, työkalujen ja toiminnallisuuksien kokonaisuutta, voidaksemme tarjota Composable-arkkitehtuurin valitseville asiakkaillemme ihanteellisimmat rakennuspalikat oman kokonaisuuden luomiseen.