Voiko räätälöidyn ohjelmistoratkaisun ostaa ilman toimittajaloukkua?

Räätälöity ratkaisu on ytimeltään aina asiakaskohtainen ratkaisu, jollaista ei ole toista samankaltaista maailmassa. Tätä ainutkertaisuutta voi toki vähentää käyttämällä joitain yleisiä komponentteja osaratkaisuna, mutta yleensä osista muodostuva kokonaisuus on ainutlaatuinen. Tämä ainutlaatuisuus taas aina muodostaa sidoksen siihen tahoon, siihen tiimiin, joka on ratkaisun alunperin rakentanut. Mikään dokumentaatio tai hyvin kuvailtu ja muotoiltu koodi ei tätä haastetta ratkaise täysin.

Räätälöityjen ratkaisujen ensisijainen toimittajaloukku muodostuukin nykyisin siihen ratkaisun rakentaneeseen tiimiin. Mitä monimutkaisempi kokonaisuus, mitä enemmän erilaisia komponentteja, mitä enemmän integraatioita, mitä enemmän järjestelmä tekee tiedon uudelleenmuotoilua, sitä enemmän ratkaisu sitoutuu niihin asiantuntijoihin, jotka järjestelmän ovat alunperin rakentaneet.

Sopimuksellista toimittajaloukkua näkee nykyisin aika harvoin

Aiemmin ehkä oli ongelmana myös sopimuksellinen sitoutuminen, kun toimittajat yrittivät tehdä räätälöityjä ratkaisuja asiakkaille ja vaatia samalla myös omistajuutta tekemäänsä koodiin. Tämä ei enää mene alalla läpi kuin ehkä kaikkein kokemattomimmille ostajille. Nykyisin lähtökohtana on yleensä, että asiakas saa vapaat käyttöoikeudet ja jatkokehitysoikeudet räätälöityihin ratkaisuihin, eikä täten toimittajalla voi olla sopimuksellista sidosta tekemäänsä räätälöityyn ratkaisuun.

Toimittajat tosin usein ylikorostavat tätä sopimuksellista näkökulmaa. Moni väittää, että tämä sopimuksellinen asia hoitaa täysin ratkaisun siirrettävyyden kolmannelle osapuolelle. Tämä väite on todella kaukana todellisuudesta.

Nykyisin eksoottiset teknologiavalinnat ovat varsin yleinen toimittajaloukun syy

Käytännössä vahva sidos toimittajaan tai tiimiin voi syntyä vaikka sopimuksellisesti ei mitään sidosta olisikaan. Tiukka sidos voi syntyä erikoisista teknologiavalinnoista tai valituista, erikoisista toteutusmalleista. Tällaiset toimittajaloukut ovatkin varsin yleisiä ohjelmistoalalla, jossa on hyvin vähän aidosti paikkansa vakiinnuttaneita teknologioita tai toimintatapoja. Lähes jokainen ohjelmistotiimi tekee joitain asioita aivan omanlaisella tavallaan, ja jokaisella tiimillä on omat suosikkiteknologiansa.

Tiimit eivät myöskään itse kovin hyvin edes tiedosta yleensä sitä, miten eksoottisia heidän toimintatapansa ovat. Harvalla kun on näkyvyyttä laajemmin alalle, joten omassa firmassa vakiintunut toimintatapa voi tuntua aivan tavalliselta asialta, vaikka kukaan muu Suomessa ei tekisi vastaavalla tavalla asioita.

Tämä on kenties se isoin yksittäinen haaste räätälöityjen ohjelmistojen ostamisessa, erityisesti jos ostaja ei ole kokenut räätälöityjen ratkaisujen ostaja. Miten valita vakiintunut malli, jos kukaan ei tiedä, mikä on vakiintunutta ja mikä eksootillista?

Vakiintuneet teknologiavalinnat ovat turvallisempia, mutta mistä tietää, mikä on vakiintunutta?

Räätälöityjen ratkaisujen ostajan tulisikin tuntea markkinaa poikkeuksellisen paljon, jotta pystyy tekemään kestäviä ratkaisuja, ja ainakin jollain tavalla ennakoimaan mahdollista tiimin vaihtamista jossakin pisteessä. Monen räätälöidyn ratkaisun elinkaarihan on helposti kymmenen vuotta, monet elävät jopa 20 vuotta, joten käytännössä kehitys- ja ylläpitotiimi voi hyvinkin vaihtua monta kertaa elinkaaren aikana. Täten kestävien ratkaisujen valintaan kannattaa panostaa valmisteluvaiheessa, jotta ei joudu koodaamaan isoja osia ratkaisusta uusiksi jo muutaman vuoden päästä – tai joudu sen yhden tiimin vangiksi toimittajaloukkuun.

Aiemmin moni räätälöityjen ratkaisujen ostaja valitsi useimmiten Microsoft-teknologiat tai Java-teknologiat Suomessa, koska näiden elinkaarikestävyyttä pidettiin parhaana. Nykyisin myös PHP-pohjaiset ja Javascript-pohjaiset ratkaisut ovat yleistyneet myös ympäristöissä, joilta odotetaan pitkää elinkaarta.

Valitun ohjelmointikielen merkitys on myös jossain määrin vähentynyt, kun yhä useammin räätälöidyt ratkaisutkin sijoitetaan jonnekin isolle pilvialustalle (kuten Amazonin AWS, Microsoftin Azure tai Googlen Cloud Platform), joiden sisällä voidaan nojata erilaisiin palveluihin rajapintojen avulla, eikä näin taustalla olevalla ohjelmointikielellä ole niin suurta merkitystä. Ostajan näkökulmasta tällainen rakentaminen tietysti on ihan yhtä lailla sidosteisuutta valittuihin komponentteihin ja siihen, kuinka näitä komponentteja on päätetty käyttää räätälöidyssä ratkaisussa.

On siis aivan mahdollista päätyä sekaympäristöihin, joissa käytetään monia erilaisia ohjelmointikieliä ja hyvin erilaisia komponentteja, ja voi jopa argumentoida, että tällainen on usein ihan järkevää tekemistä. Ostajan kannalta tämä toki vain vaikeuttaa asioita, vaikka ratkaisun ensimmäinen pystytys saattaisikin nopeutua.

Täten fiksujen valintojen tekeminen on vain korostunut viime vuosina. Fiksu ostaja perehtyykin perusteellisesti siihen, mitä ratkaisuja tiimi ehdottaa, ja mitä tämä tarkoittaa ratkaisun elinkaarelle ja jatkokehitettävyydelle. Miten helppoa tehtyjä valintoja on muuttaa myöhemmin? Pystytäänkö järjestelmää kehittämään haluttuun suuntaan? Jos käyttäjämäärät kasvavat, kestääkö arkkitehtuuri?

Kestävät toimintatavat ja looginen arkkitehtuuri auttaa jatkokehityksessä, mutta kuka tietää mikä on järkevä toimintatapa ja mikä on kestävä arkkitehtuuri?

Jos kestävien teknologiavalintojen valinta kuulosti haastavalta, vieläkin vaikeampi asia ovat valitut toimintatavat räätälöidyn ratkaisun pystytyksessä. Esimerkiksi integraatioiden toteutuksen voi varmasti tehdä juuri niin monella tapaa kuin on eri ohjelmistotiimejä tekemässä. Tällä hetkellä myös käyttäjille näkyvät käyttöliittymäkerrokset tehdään hyvin vahvasti käsityönä tiimin toimesta, eikä tähän alueeseen ole juurikaan vakiintuneita toimintamalleja. Täten vaikka ostaja olisi itse kokenut ohjelmistoarkkitehti, ei kaikkiin alueisiin ole yksinkertaisesti mahdollista valita vakiintuneita malleja.

Antautuminen haasteen edessä ei silti ole suositeltavaa. Esimerkiksi arkkitehtuuri on asia, joka on hyvin tilannekohtainen asia. Ei ole olemassa täydellistä arkkitehtuurimallia, vaikka tästäkin asiasta jotkut julistavat hyvin yksiulotteisia totuuksia. Joihinkin kokonaisuuksiin on järkevää soveltaa jonkinlaista mikropalveluarkkitehtuuria, toiset sovellukset kannattaa tehdä perinteisemmin yhtenäisemmällä sovellusarkkitehtuurilla, joskus tarvitaan vain perusteltua osittamista loogisiin kokonaisuuksiin. Joskus tärkeintä on tehdä itsenäinen rajapintakerros uuden sovelluksen ja taustajärjestelmien väliin. Mikään näistä ei ole pakollista tehtävää joka kerta, vaan olennaista on pohtia eri malleja ja valita soveltuvin.

Mistä sitten tietää, että oman tiimin sovellusarkkitehti osaa tehdä juuri sopivimmat suunnitelmat ja ratkaisut? Ei mistään, tietenkään. Siksi tälläkin alueella kannattaa kilauttaa kaverille, kysyä yleisöltä ja ehkä myös kokeilla onneaan, eli pyytää näkemyksiä mahdollisimman monelta asiantuntijalta, ehkä jopa teetättää arkkitehtuurisuunnitelma kahdella eri taholla. Tällainen tekeminen on aivan tyypillistä esimerkiksi monissa insinööritieteissä, oli kyse rakentamisesta tai rakettitieteestä. Yksittäisten asiantuntijoiden rajallista tietämystä paikataan hyödyntämällä tärkeissä osa-alueissa useita kokeneita asiantuntijoita, jotka tekevät jokainen itsenäisen näkemyksen ratkaisusta. Asiakkaan tehtävä on arvioida ja vertailla, ja valita paras ehdotus, ehkä jopa tehdä oma yhdistelmänsä eri ehdotuksista.

Joskus on vain pakko vaihtaa toimittajaa, eikä sitä kannata pelätä

Räätälöityjen tietojärjestelmien elinkaaret voivat olla todellakin niin pitkiä, että kehitystiimiä on pakko vaihtaa elinkaaren aikana, jopa useita kertoja. Tätä ei kannata kuitenkaan pelätä liikaa, vaikka edellä mainitut keinot kannattaakin käyttää. Hyvin tehty valmistelu, järkevät teknologiavalinnat ja hyvät toimintamallit kaikki auttavat myös kehityskumppanin vaihdoksessa, jos sellaiseen tilanteeseen päädytään.

Räätälöityjen ratkaisujen kohdalla kehityskumppanin vaihto on yleensä aina melko kallis harjoitus, koska uusi toimittaja joutuu perehtymään tehtyyn koodiin, käytettyihin kirjastoihin ja komponentteihin. Pelkästään haltuunotto, perehtyminen ja uusien kehitysympäristöjen pystytys voi tuoda asiakkaalle kymmenien tuhansien eurojen kustannukset – ja isojen järjestelmien kohdalla haltuunotot voivat olla paljon enemmänkin.

Haltuunottoprojektin kustannuksia ei kuitenkaan kannata pelätä. Hyvä käytäntö on esimerkiksi yhdistää haltuunottoprojektiin mahdollisimman paljon myös kehitystehtäviä, jotta uudella tiimillä on heti konkreettista tekemistä käsillään. Tällä tavalla uuden järjestelmän opettelu onnistuu parhaimmillaan samalla kertaa, kun uusia ominaisuuksia kehitetään ja vanhoja parannellaan. Tällainen haltuunottomalli on esimerkiksi North Patrolin suosittelema malli asiakkailleen, jotka haluavat tai joutuvat vaihtamaan kehityskumppania kesken järjestelmän elinkaaren.

Se todellinen riski kehityskumppanin vaihdoksessa on nimittäin se, että uusi toimittaja ei koskaan pääse kunnolla sisälle järjestelmän toimintaan, vaan kehityskustannuksien taso nousee pysyvästi, kun uusi toimittaja joutuu työskentelemään itselleen tuntemattoman ympäristön, heikon dokumentaation ja monenlaisten tiimille outojen kirjastojen ja komponenttien kanssa.

Tämäkin korostaa vain sitä, miten tärkeä on valmisteluvaihe ja siinä tehtävät ratkaisut, jos räätälöidylle ratkaisulle halutaan pitkää elinkaarta ja hyvää jatkokehitettävyyttä.

Ei ole hopealuotia, on vain hyvää valmistelutyötä, joka tuottaa kestäviä ja jatkokehitettäviä ratkaisuja.

Aina on jonkinlainen toimittajasidos, mutta riskin tasoon voi vaikuttaa paljon

Vastauksena otsikon kysymykseen: Ilman jonkinlaista toimittajaloukkua ei voi ostaa räätälöityjä ratkaisuja, mutta toimittajaloukun tiukkuutta voi hallita paljonkin hyvällä valmistelulla, ja sama työ tuottaa myös ratkaisuja, jotka edistävät räätälöidyn ratkaisun elinkaarta ja helpottavat jatkokehittämistä.

Räätälöidyn ratkaisun fiksu ostaminen vaatii paljon tietotaitoa ja kokemusta ostajalta, ja myös kokeneen ostajan kannattaa tehdä hyvät pohjatyöt, jotta pystyy tekemään valintoja ja vaatimuksia, jotka kantavat pitkälle ja tuottavat hyviä lopputuloksia.

Lue lisää: Web-sovellukset ja näiden tekniikat – kaikki artikkelit Vierityspalkissa