Tuskailetko parhaillaan digipalvelun kanssa, jonka käyttöliittymä huutaa uudistusta, mutta jonka datamalliin et haluaisi puuttua? Etsikö tapaa, jolla uudistaa digipalvelun arkkitehtuuria, mutta kokonaisvaltaiselle taustainfran uudistukselle ei ole resursseja? Tässä blogiartikkelissa kerromme, milloin voit tuoda digipalvelusi tähän päivään välittämättä vanhoista taustajärjestelmistä.
Milloin voit edetä digihankkeessa välittämättä taustainfrasta?
Jos digipalvelunne on tullut elinkaarensa päähän, suosittelemme lähtökohtaisesti aina kokonaan uuden rakentamista. Silloin kehityksessä voidaan huomioida liiketoiminnan ja käyttäjäkunnan tarpeet ilman menneisyyden painolastia.
Tiedämme, ettei kokonaan uuden palvelun kehittäminen ole kuitenkaan aina mahdollista esimerkiksi kustannus- tai aikataulupaineen vuoksi. Voit edetä digikehityksessä puuttumatta taustajärjestelmiin, jos
- digipalvelun tietomallit ja logiikka vastaavat edelleen tarpeisiin, mutta käyttöliittymä on jo vanhentunut,
- digipalvelun tietomallit ja data palvelevat edelleen tarkoitustaan, mutta logiikka ja rajapinnat sekä käyttöliittymä vaativat uudistusta.
Kehittämistä voidaan havainnollistaa esimerkiksi tornilla. Tärkeintä on ymmärtää, että järjestelmää voi uusia käytännössä ylhäältä alaspäin, mutta ei juuri päinvastoin.
Tällaisen kerroksellisen kehittämisen lisäksi olemassa olevaa järjestelmää voidaan kehittää tai sen käyttökokemusta parantaa rakentamalla uusi digipalvelu sen rinnalle. Rinnakkaisen palvelun avulla tyypillisesti täydennetään olemassa olevan ratkaisun ominaisuuksia tai helpotetaan sen käytettävyyttä. Uusi digipalvelu tyypillisesti hyödyntää olemassa olevan ratkaisun rajapintoja tai dataa.
Olemassa olevan digipalvelun kehityksen parhaimmat käytänteet ovat samat kuin uudenkin palvelun kehityksessä: kuuntele loppukäyttäjiä, etene suunnitelmallisesti, testaa nopeasti ja kehitä jatkuvasti. Ota avuksesi myös nämä neljä täsmävinkkiä:
- Suunnittele projekti huolellisesti ja määritä kerrokset johon haluatte puuttua tai toisaalta säästää.
- Suunnittelu tulee tehdä vanhan ja säilytettävän osan ehdoilla. Kaikkia toivottuja uudistuksia ei välttämättä ole mahdollista tehdä. Varmista, että myös loppukäyttäjät ymmärtävät tämän, eivätkä odota kaikkien muutosideoiden siirtyvän automaattisesti tuotantoon.
- Hyväksy se, ettet voi varautua kaikkeen. Erityisesti uusien rajapintojen rakentamisessa kannattaa varautua dataan liittyviin haasteisiin.
- Sparraa suunnitelmaa yhdessä konsultin kanssa, joka tuntee valitut (käytössä olevat ja uudet) teknologiat. Emme suosittele lähtemään projektiin lainkaan, jos käytössä olevaan teknologiaan ei löydy asiantuntijaa.
Lopuksi rohkaisemme sinua aloittamaan työn heti. Uudistuksen lykkääminen vain lisää riskiä asiakkaiden ja myynnin menettämiselle ja esimerkiksi tietoturvauhkille.
Kolme esimerkkiä onnistumisesta.
Lopuksi esittelemme kolme tapausta, joissa käyttöliittymä- ja logiikkakerrosten uudistukset ratkaistiin kustannustehokkaasti ja ilman taustajärjestelmään koskemista. Toivottavasti näistä on sinulle hyötyä!
Rajapintojen kuvaaminen mockup-versioina tehostaa tiimien välistä työtä.
Logistiikka-alan ERP:in eli toiminnanohjausjärjestelmän käyttöliittymä koettiin monimutkaiseksi ja kankeaksi. Käyttöliittymän lisäksi logiikkakerroksen monoliittisesta arkkitehtuurista luovuttiin. Nyt käyttöliittymä ja taustajärjestelmä ovat erotettu toisistaan rajapinnan avulla.
Käyttöliittymä- ja arkkitehtuuritiimien välistä yhteistyötä helpotettiin määrittelemällä ja kuvaamalla rajapinnat ensimmäisessä vaiheessa mockup-versioina. Mockup-versiot ovat kuin luonnoksia, joita on helppo testata menemättä heti varsinaiseen kehitysympäristöön. Esimerkiksi Swagger on erinomainen työkalu rajapintojen dokumentointiin ja testaamiseen.
Uusi chat-ominaisuus helpottamaan sisäistä tiedonjakoa.
Toiminnan- tai tuotannonohjausjärjestelmät ovat tyyppiesimerkkejä liiketoimintakriittisistä järjestelmistä, joiden kanssa pyritään etenemään mahdollisimman pitkään ilman kokonaisvaltaista uudistusta.
Uusia ominaisuuksia voi kuitenkin kehittää olemassa olevan palvelun rinnalle käytettävyyden ja toimintamallien tueksi. Esimerkiksi toiminnanohjausjärjestelmää voidaan täydentää chat-palvelulla, joka helpottaa sisäisiä tiedonkulun prosesseja. Kokemuksemme mukaan dataa tai tiedostoja hyödyntävien ominaisuuksien kehittämisessä on kriittistä varmistaa
- että data säilyy eheänä, vaikka sitä käytetään kahdessa eri järjestelmässä.
- että tiedostojen käyttöoikeudet ja niihin liittyvät vaatimukset toteutuvat myös silloin, kun tiedostoja jaetaan uuden palvelun kautta.
Kokonaisvaltainen päivitys datamalliin koskematta.
Kolmantena esimerkkinä on asiakkaamme Jutelin kokonaisvaltainen radioalusta, joka sisältää työkalut radiolähetyksen suunnitteluun, medianhallintaan ja lähetystoimintaan. Järjestelmäuudistuksen tavoitteena oli
- siirtyä työasemakohtaisista asennuksista selainkäyttöisyyteen,
- helpottaa medianhallintaa siirtämällä toiminnallisuuksia pilveen,
- uudistaa ohjelmistokieli, jotta varmistetaan myös tulevaisuudessa osaajien löytäminen,
- helpottaa järjestelmän ylläpitoa ja tukea.
Järjestelmäuudistus oli hyvin kokonaisvaltainen käyttöliittymän sekä logiikan ja rajapinnan kerroksilla. Jutel halusi kuitenkin säilyttää järjestelmän taustalla olevan datamallin. Siksi Jutel päätti, ettei tässä vaiheessa ryhdyttäisi kokonaan uuden järjestelmän rakentamiseen.
Jutel on erinomainen esimerkki siitä, kuinka merkittäviä uudistuksia ja päivityksiä, sekä käyttöliittymän muutoksia järjestelmiin voidaan toteuttaa ilman, että datamalliin tarvitsee puuttua.
Haluatko sparrata ajatustasi? Ollaan yhteydessä.
Kuten aikaisemmin mainitsimme, suunnitelmaa on hyvä sparrata toisten asiantuntijoiden kanssa. Ehkä yhdessä pohtimalla löytäisimme keinon, jolla sinäkin voit edetä digipalvelusi kanssa puuttumatta sen taustainfraan.
Haluatko kuulla lisää?
Ota yhteyttä Janneen
