Ymmärrä ekosysteemi hankittavan ohjelmiston ympärillä

Oletko kuullut API:sta?

Kun lähtee suunnittelemaan organisaation ohjelmistoarkkitehtuuria, täytyy päättää, pyrkiikö etsimään kokonaisratkaisun vai haluaako kustakin osa-alueesta parhaan mahdollisen ratkaisun. Kokonaisratkaisulla tarkoitetaan ohjelmistoperhettä, josta löytyy lähes jokaiseen tarpeeseen toiminto tai osio. Hyvä esimerkki ohjelmistoperheestä on Microsoft-tuoteperhe, joka tarjoaa ratkaisuja dokumentinhallinnasta viestintään ja etäneuvotteluihin. Jos organisaatio valitsee tuoteperheen, järjestelmän toimittaja vastaa siitä, että järjestelmän osat keskustelevat keskenään, ja että tiedon siirtäminen tuotteiden välillä on helppoa. Järjestelmän toimittaja tekee myös kehitystyötä järjestelmään, joka tulee käyttäjien saataville ilman erillisiä kehittämispäätöksiä.

Toinen vaihtoehto on valita aina paras järjestelmä omalla osa-alueellaan, “best of breed”, jolloin voidaan paremmin huomioida myös organisaation erityistarpeet kyseistä järjestelmää kohtaan. Best of breed -mallissa organisaatio ei ole sitoutunut vain yhteen järjestelmään, jolloin ohjelmiston tai järjestelmän vaihtaminen on ketterämpää tarpeen mukaan. Toisaalta tässä mallissa on aina erikseen varmistettava järjestelmien yhteensopivuus, jotta käytettävyys säilyy ja tieto siirtyy ohjelmistojen välillä.

Ohjelmistojen yhteensopivuus

Nykyaikanen tapa varmistaa eri ohjelmistojen yhteensopivuus on suosia ohjelmistoja, joissa on avoin ohjelmointirajapinta, jonka kaikki ominaisuudet ovat julkisia, ja jota voi käyttää ilman rajoittavia ehtoja. Tämä edellyttää, että rajapintakuvaus ja sen dokumentaatio ovat avoimesti saatavilla, jolloin rajapintaa voi vapaasti käyttää esimerkiksi omien sovellusten tekemiseksi ja niiden testaamiseksi.

Ohjelmointirajapinta (engl. Application programming interface, API) on määritelmä, jonka mukaan eri ohjelmat voivat tehdä pyyntöjä ja vaihtaa tietoja, eli keskustella keskenään. Rajapinnan dokumentaatiosta ja testiaineistoista ei peritä maksua, mutta palvelun varsinaiseen tietosisältöön käsiksi pääsemisestä voidaan periä maksu tai pääsy voi edellyttää esimerkiksi palvelusopimusta.

Mikäli valitut ohjelmistot ovat moderneja, ohjelmistojen yhteensopivuus ei yleensä ole ongelma, sillä usein moderneissa ohjelmistoissa on valmiit ohjelmointirajapinnat. Mutta jos kokonaisuudessa on jokin vanha ohjelmisto, jossa rajapintoja ei ole, voi integroiminen tulla yllättävän kalliiksi. Ohjelmistojen kokonaisarkkitehtuuria suunniteltaessa tämä täytyy ottaa huomioon. Tehtävä ei ole yksinkertainen, sillä tarjousvaiheessa järjestelmätoimittajilla on taipumus aliarvioida merkittävästi integrointityön määrää ja siitä syntyviä lisäkustannuksia. Ei ole lainkaan poikkeuksellista, että tarjousvaiheessa integraatiotyöhön arvioitu kaksi henkilötyöpäivää muuttuu 20 päiväksi. Tällaisessa tilanteessa erityistä huomiota tulee kiinnittää sopimukseen ja sopimusehtoihin.

Myös oman organisaation riskinsietokyky on arvioitava ja tulisi pohtia, kuinka joustava oma organisaatio on, jos ohjelmiston käyttöönotto myöhästyy tai toimituskustannukset kasvavat. Best of breed -mallin ehdoton etu kaikesta huolimatta on se, että kaikki käytettävät ohjelmistot palvelevat täydellisesti organisaatiota, eikä kompromisseja tarvitse tehdä.

Kun kokonaisratkaisua mietitään, on tärkeää pohtia, kuinka pitkä on valitun ohjelmistoperheen tulevaisuus ja millaiset ovat valitun toimittajan tulevaisuudennäkymät. Ohjelmiston tulevaisuudenkestoa, ”future proofia”, pitäisi pystyä määrittämään jollain tavalla, sillä ohjelmistoa kohtaan haluttavat vaatimukset muuttuvat jo usein muutaman vuoden kuluessa sen valmistumisesta, joskus jopa toimitusvaiheessa. Ohjelmistoja tai ohjelmistoperhettä valitessa kannattaakin selvittää mahdollisimman laajasti ja eri lähteistä teknologian elinkaari ja toimittajan kyky lunastaa lupaukset.

Ohjelmistoprojektiin täytyy varata ohjelmistosta ja toimittajasta riippumatta riittävästi resursseja – siis aikaa, osaamista, rahaa ja päätöksentekokykyä. Ylivoimaisesti suurin syy ohjelmistoprojektien viivästymiseen on asiakkaan resursseissa, ei niinkään toimittajassa.

Kari Heikkilä
Kirjoittaja on Rubic HR Finlandin Managing Director.

Rubic HR Finland on riippumaton järjestelmähankintakonsultti, jonka Managing Directorina Kari Heikkilä toimii. Rubicin asiantuntijat auttavat järjestelmähankintojen muutoshallinnassa, vaativien järjestelmähankintojen valinnassa ja kilpailutuksessa, sekä johtavat näihin liittyviä projekteja. www.rubic.fi
Connect with Kari: