Avoin ohjelmistoliiketoiminta ja kokonaisarkkitehtuuri

Problematiikka

Ohjelmistoprojekteissa on pitkään tiedetty, että suuruuden ekonomia ei yleensä toimi. Vanha viisaus eli ”yksikään tietohallintojohtaja ei ole saanut potkuja, kun ostaa IBM:ltä” on kenties muuttunut yhden erisnimen verran, mutta tilanne on yhä sama. Suuruudella perustellaan lähinnä korkeaa hintaa ja tämä käytännössä aiheuttaa merkittävää tehottomuutta. Tehottomuus taas johtaa budjettien ja aikataulujen räikeään ylittämiseen. Toisaalta pienuuden ekonomia tai paremminkin ketterät menetelmät eivät myöskään auta. Esimerkiksi ketterät menetelmät johtavat usein siihen, että projektin toteutus- budjetti- ja sisältövastuu siirretään lähes täysmääräisenä asiakkaalle. Pieniin toimittajiin liittyy myös merkittäviä epävarmuustekijöitä sekä yritysten pysyvyyden että toimituskyvyn suhteen. Pienten yritysten kenttä on kirjava ja alalla on monenlaista toimijaa. Puheet ovat yleensä kuitenkin samat, eli suuret.

Lähtökohdat

Ohjelmistoliiketoiminnan tehokkuus määrittyy monen muuttujan voimin, keskeisiä ovat mm. toimittajan pyrkimys mahdollisimman suureen katteeseen, asiakkaan valistuneisuus, toimitukseen liittyvät epävarmuustekijät ja yhteinen kyky määritellä liiketoimintatarve. Alalla usein käytetty esimerkki on suuri konsulttitalo, joka valitsee asiakkaalle järjestelmän: ensin kirjoitetaan laaja raportti n. 20 eri järjestelmästä ja lopputulemana suositellaan omaa järjestelmää. Tämä suositus toimitetaan sitten mojovan hintalapun kanssa!

Kunnon lähtökohdat ohjelmistoprojektille ovat yksinkertaisemmat:

1. Onnistunut ja uskottava liiketoimintatarpeen ja tavoitteiden määrittely sekä
2. Kumppanin valinta. Jos nämä lähtökohdat ovat kunnossa ohjelmistoprojektin onnistumisen todennäköisyys kasvaa merkittävästi ja päinvastoin.

Suuret ohjelmistot ja kilpailukyvyn harha

Esimerkiksi ERP- ja CRM-ohjelmistojen markkinoilla suurimmat toimijat kattavat lähes koko markkinan. Tämä aiheuttaa mielenkiintoisen tilanteen, koska tällöin ohjelmistojen käyttöönotosta saatava kilpailuetu on käytännössä minimaalinen. Voidaan toki argumentoida, että ohjelmiston käyttöönottovaiheessa saavutetaan kilpailuetua, mutta todellisuudessa oletettu etu jää minimaaliseksi, kun kaikki toimijat käyttävät samaa, usein joustamatonta, ohjelmistoa.

Runsas 20 vuotta sitten avoimen lähdekoodin ohjelmistot tarjosivat tähän ongelmaan ratkaisumalleja. Voidaan kuitenkin väittää, että optimaalinen tapa on yhdistää asiakkaan liiketoimintaan räätälöity koodi yleisesti käytettyihin usein avoimen lähdekoodin piirissä oleviin valmiisiin ohjelmistomoduuleihin.

Kestävä tapa ratkaista kilpailukyvyn harha on liiketoimintamalli, josta seuraavassa käytetään nimitystä avoin liiketoimintamalli.

Avoin liiketoimintamalli

Suljettu liiketoimintamalli tarkoittaa sitä, että toimittaja pyrkii monin eri tavoin sitomaan asiakkaan valittuun ohjelmistoon ja arkkitehtuuriin niin, että siitä irtautuminen on liian kallista tai vaivalloista. Tällöin puhutaan yleisesti asiakas- / toimittajalukosta. Lähes kaikki ohjelmistoalan toimijat pyrkivät tähän. Osa avoimesti, osalla taas tämä on piiloagenda. Avoin liiketoimintamalli tarkoittaa sitä, että asiakkaalle annetaan mahdollisuus lopettaa yhteistyö toimittajan kanssa siten, että kehittämistyö voi jatkua, eikä irtautuminen aiheuta ratkaisevia kustannuksia. Huomionarvoista on, että tämän pitää toteutua myös käytännön, ei pelkästään puheiden, tasolla. Avoimen liiketoimintamalliin toteutuskelpoisuus on merkittävästi parantunut viime aikoina, kun työasemissa on siirrytty selainpohjaisiin käyttöliittymään ja palvelimet ovat korvautuneet pilvipalveluilla. Keskeisiä lähtökohtia tai edellytyksiä avoimen liiketoimintamallin onnistumiselle ovat samaan aikaan tarkka ja kokonaisvaltainen liiketoimintatarpeen ja -tavoitteiden määrittely sekä avoimen liiketoimintamallin mahdollistava kokonaisarkkitehtuurin laatiminen.

 

Kokonaisarkkitehtuuri

Tällä sanalla on lähes yhtä monta tulkintaa ja tulkitsijaa. Tässä yhteydessä kokonaisarkkitehtuuri tarkoittaa täysin liiketoiminnalliseen määrittelyyn perustuvaa, konkreettista kuvauksista järjestelmän teknisistä, toiminnallisista ja tietomalliin liittyvistä piirteistä. Kokonaisarkkitehtuurin avulla usein liian abstrakti toiminnallinen määrittely muutetaan konkreettiseksi niin, että alkuperäiset tavoitteet ja toimintamallit saadaan kuvattua eksaktisti niin, että tämän pohjalta voidaan toteuttaa ohjelmiston implementointi. Edellä esitetyssä kuvassa tämä näkyy ihmisten muuttumisessa tikku-ukoiksi ja päinvastoin.

Kokonaisarkkitehtuurin tulee olla modulaarinen. Toiminnallinen määrittely on aina laaja ja usein hyvin abstrakti. Kuvassa suppilon yläosasta lähemmäksi keskustaa. Tästä syystä konkretisointi on haastavaa ja usein myös työlästä. Laajennettavuuden ja joustavuuden vaatimukset voivat usein olla modulaarisuuden ja eksaktiuden vaatimusten kanssa ristiriidassa. Nämäkin tulee kuitenkinhuomioida täysimääräisinä.

Kokonaisarkkitehtuurin tulee tarjota selkeät ohjeet ja rajaukset järjestelmän rajaamiseen. Arkkitehtuurissa tulee määritellä

1. Osajärjestelmien keskinäiset rajapinnat.
   Kuvassa osajärjestelmät on esitetty kokonaisarkkitehtuurin alapuolella numeroituina ja rajapinnat näiden välissä pystysuorassa, sekä
2. Osajärjestelmien käyttäjärajapinnat.
   Nämä on esitetty kuvassa numeroitujen osajärjestelmien alareunassa. Keskeisen kokonaisarkkitehtuurin idea on, että näin tilaaja voi jakaa osajärjestelmien toteutusvastuuta useille toimittajille, myös yhtäaikaisesti.

Kokonaisarkkitehtuurin laatija ja omistajuus

Vastuu kokonaisarkkitehtuurista ja sen omistajuus pitää olla organisaatiolla itsellään. Kuvassa tätä kuvaa talo kokonaisarkkitehtuuriosuuden yläpuolella. Vastuuta ja omistajuutta ei pidä ulkoistaa. Muussa tapauksessa tuloksena on fundamentaalinen asiakaslukko asiakkaan jäädessä arkkitehtuurin todellisen omistajan varaan. Kokonaisarkkitehtuurin laadintaan voi toki käyttää kumppaneita. Usein asiantuntijuus jakaantuu niin, että jopa usean kumppanin käyttö on perusteltua. Tältä osin kokonaisarkkitehtuurikin voi olla modulaarinen. Vastuu, omistajuus ja kokonaisnäkemys tulee kuitenkin olla asiakkaalla itsellään. Myös osakokonaisuuksien toteuttamiseen liittyvään kilpailutukseen ja projektinhallintaan voi käyttää kumppaneita. Tällöinkin kokonaisarkkitehtuuri ja sen omistajuus asettaa rajaukset ja lähtökohdat.

Kokonaisarkkitehtuuri ja avoin ohjelmistoliiketoiminta

Edellä esitetyn perusteella on mahdollista parantaa merkittävästi tietotekniikan hyödyntämisen tehokkuutta. Avoin ohjelmistoliiketoiminta mahdollistaa parhaimmillaan räätälöityjen sovellusten tarjoaman kilpailuedun, joka on saavutettavissa asiakaslukittuihin valmisohjelmiin verrattuna jopa edullisemmalla kustannustasolla. Avoin ohjelmistoliiketoiminta yhdistettynä optimaalisesti toimivaan monitoimittajaympäristöön tarjoaa Suomen mittakaavassa mahdollisuuden miljardiluokan säästöihin. Edellä esitetyn mallin ohella pitää vain muistaa alussa mainitut lähtökohdat: liiketoimintatarpeen määrittely ja kumppanin valinta.