Historia
Kun kauan odotettu Magento 2:n ensimmäinen versio julkaistiin vuonna 2015, tuntui loogiselta, että uusia suuria kehitystöitä ei olisi järkevää tehdä Magento 1:n pohjalta. Sittemmin suurin osa Magenton (eli 2.0.x ja 2.1.x) varaan rakennetuista kaupoista on jo uudessa ohjelmistossa, mutta on loogista, että uuden ohjelmiston ensimmäisiin versioihin tarvitaan useita päivityksiä. Siksi siirtyminen niistä nykyään uusimpaan pikkuversioon (esim. 2.0.x tai 2.1x siirtyminen uusimpaan versioon 2.3.x) voi merkitä suurempia investointeja, sillä Magento on parantanut uusia versioita merkittävästi yhteisön tuella.
Annetaan nyt lyhyt katsaus Magento 2:n aiemmista versioista siirtymisen vivahteisiin. On tärkeää ymmärtää, että ensimmäisten versioiden käyttöikä on virallisesti päättynyt:
Magento 2.0.x – tuki päättyi maaliskuussa 2018.
Magento 2.1.x – tuki päättyi kesäkuussa 2019.
Magento 2.2.x – tuki päättyi joulukuussa 2020.
Miksi Magento 2:n ensimmäisiä pieniä versioita ei enää kehitetä? Vastaus:
- Sekä yhteisön että Magenton oman tiimin tekemät muutokset ovat niin merkittäviä, että ne vaativat suuria tarkistuksia;
- Sähköisen liiketoiminnan kehitysnopeus on kasvanut, mikä asettaa entistä suurempia vaatimuksia ohjelmistoille;
- Useiden ohjelmistoversioiden tukeminen on kalliimpaa, ja verkkokauppoja on ”helpompi” saada päivittämään, koska tuskin kukaan koskaan rakentaa vanhan version varaan.
”Loputtomat päivitykset.”
Useita vuosia sitten oli tehtävä päätös: rakennetaanko verkkokauppa Magento 1:n vakaalle versiolle, josta tulee muutaman vuoden kuluttua perintö, vai otetaanko riski uudella versiolla. Ymmärrettävästi monilla kauppiailla on nyt kysymys – rakensin kaupan uudelle alustalle, mutta nyt tarvitsen taas suuren päivityksen? Ja toiseksi, jos investointi 2.3:een päivittämiseen tehdään, milloin tämä matka on tehtävä uudelleen?
Viimeisimmän version 2.3.x loppupäivämäärää ei ole ilmoitettu tähän mennessä. Kehittäjinä voimme sanoa, että tämä on jo ”kypsä” versio, joka on laadukas ja jonka käyttöikä on varmasti pidempi, vaikka 2.4.x:n pitäisi olla huomattavasti parempi. Lisäksi mielestämme 2.2-versio on jo nyt hyvä ohjelmisto, ja sen päivittäminen 2.3:een on vähemmän aikaa vievää. Ongelmana ovat versiot 2.0 ja 2.1. Jotkut kauppiaat ovat jälkikäteen syyttäneet itseään tai kehittäjää, vaikka itse asiassa ongelma on ohjelmiston yleisen elinkaaren logiikan ymmärtämisessä.
Vanhan version lisäksi kaupan omistaja voi tuntea itsensä panttivangiksi – vanhan version kehittämiseen ei tunnu kannattavan investoida, ja uusi investointi tuntuu vielä suuremmalta. Toinen ikävä yllätys on se, että monet kolmannet osapuolet eivät tue vanhojen versioiden moduuleja ja uudet moduulit on tehty vain uusimpia versioita varten. Jos haluat ehkä jatkaa vanhalla versiolla vielä jonkin aikaa, joissakin tapauksissa voi olla tarpeen investoida downgradeen (mikä ei ehkä ole huono ajatus liiketoiminnan kannalta).
Vähemmän on enemmän?
Tärkeä vivahde, joka yleensä unohdetaan, on se, että mitä suurempi IT-järjestelmä on, sitä kalliimpaa sen ylläpito ja muuttaminen/päivittäminen on. Uusia ratkaisuja analysoitaessa on otettava huomioon enemmän mahdollisuuksia, testitapauksia, asianmukaista dokumentaatiota jne. on täytettävä enemmän. Hyvä verkkokauppa ei ole koskaan valmis, ja on luonnollista ottaa ideoita niin asiakkailta kuin kilpailijoiltakin, jotta kauppaa voidaan jatkuvasti parantaa.
Päivityskustannuksiin vaikuttaa myös kolmansien osapuolten kehitys eli se, kuinka paljon kauppias on halunnut säästää sähköisen kaupankäynnin kehittämisessä käyttämällä valmiita ratkaisuja. Yksi Magenton eduista on laaja kehittäjä-/yhteisöverkosto ja ohjelmiston modulaarisuus. Jos kauppias haluaa jonkin toiminnallisuuden, on mahdollista saada se halvalla moduulikaupasta ja lisätä se verkkokauppaansa, mutta ilmaisia lounaita ei ole. On houkuttelevaa katsoa Themeforestista erilaisia mielenkiintoisia malleja, ja mieluummin muutama sata dollaria UX-analyysiin kuin kymmeniä tai satoja tunteja räätälöityyn ratkaisuun.
”Joku on jo tehnyt sen, käytetään sitä!” on hyvä argumentti säästää myymälän kehityskustannuksissa, mutta on otettava huomioon ratkaisun kestävyys ja yhteensopivuus muiden moduulien kanssa. On olemassa kauppoja, jotka ovat vanhoja, täynnä valtavaa määrää hyvin erilaisia moduuleja, jotka on tehty toimimaan yhdessä ja joiden päivittämiselle ei ole aika-arviota. Tällöin aluksi suotuisasta lisäosasta voi tulla ongelma.
Päivitysprosessi on seuraava: moduulit ja erikoisratkaisut kartoitetaan, kaupasta tehdään kopio kehityspalvelimelle, päivitys tehdään ja kauppa testataan. Korjausprosessin aikana tarkistetaan, onko kolmannen osapuolen moduuleista olemassa uudempia versioita. Jos kyseisistä moduuleista ei ole uudempia versioita, kehittäjän on päivitettävä kolmannen osapuolen moduuli itse, ja joskus se kannattaa korvata kokonaan toisen palveluntarjoajan moduulilla. Tämä koskee erityisesti Magento 2:n aiempia pieniä versioita, joissa muutokset ovat suurempia.
Emme sano, että valmiita ratkaisuja ei pitäisi käyttää – se on riskinarviointitehtävä ja riippuu paljon kauppiaasta ja hänen suunnitelmistaan. Me Lumavilla olemme vähentäneet asiakkaidemme pitkän aikavälin riskejä siten, että emme enää kehitä uusia kauppoja valmiiden mallien pohjalta, suosimme kokeiltua ja testattua kehityskumppania silloin, kun tarvitaan moduuleja, ja meillä on jokaisessa projektissa varatiimi, joka myös tuntee projektin.
Tulevaisuus?
Nyt kun sähköinen kaupankäynti on kasvanut kriisin aikana fyysisten myymälöiden kustannuksella, yhä useammat vähittäiskauppiaat ymmärtävät, että kilpailukykyinen sähköisen liiketoiminnan ratkaisu on pikemminkin pakollinen kuin kätevä. Kuten näemme, myös kehittäjät ovat sopeutumassa ja tarjoavat nopeammin markkinoille saatettavia, huoltovapaita paketteja, mutta onko tämä taikasauva? Jos sähköistä liiketoimintaa halutaan rakentaa, miksi ylipäätään investoida kehitystyötä ja ylläpitoa vaativiin alustoihin ja valita sen sijaan vuokrausratkaisut, joissa kaikki on jo valmiina?
Sähköistä liiketoimintaa ei voida pitää kilpailuna vaan pikemminkin taisteluna. Asiakas ostaa tavaransa aina yhdestä paikasta, ja kuuluisa viikinkiajan anekdootti ”Taistelussa pärjäsimme hyvin, mutta tulimme toiseksi…” pätee tässäkin tapauksessa. Tosiasia on, että mitä enemmän vaatimuksia sähköisille yrityksille asetetaan, sitä enemmän vaatimuksia asetetaan myös niiden alustoille. Jos Magento haluaa olla maailman edistynein sähköisen liiketoiminnan alustan tarjoaja, voidaan odottaa, että se itse miettii jatkuvasti, miten se voi tarjota uusia teknisiä ratkaisuja, jotka auttavat sen käyttäjiä saamaan kilpailuetua. Se, tarvitseeko ja voiko kauppias ottaa kaiken vauhtiin ja lähteä heti mukaan, on jo jokaisen oma liiketoimintapäätös.
Yhteenvetona kolme kohtaa:
- On liiketoiminnallinen päätös, investoidaanko luotettavuuteen vai valitaanko edullinen valmisratkaisu ja milloin ja kuinka usein verkkokauppa päivitetään. Se riippuu pääasiassa siitä, miten kilpailukykyinen ala on.
- Mitä monimutkaisempi järjestelmä on, sitä enemmän aikaa vievät ylläpito ja päivitykset, mukaan lukien analyysien ja testauksen määrä.
- Kilpailevalla alalla ei voida olettaa, että uusia alustoja ei tarvitse koskaan päivittää, ja muutoksia tehdään vähemmän. Päinvastoin.
Kuten Magento 1 -päivitysten kohdalla, myös Magento 2:n suurten päivitysten tekeminen tai toteuttaminen on liiketoimintapäätös. Jos tarvitset tietoa siitä, mikä päivityspolku olisi yrityksellesi paras, ota meihin yhteyttä, niin löydämme yhdessä ratkaisun.
