Pyörän uudelleen keksiminen ei kannata. Sovelluksia kehittäessä pyrimme uudelleenkäyttämään mahdollisimman usein valmiita ratkaisuja. Räätälöidyn sovelluksen rakentaminen nähdään usein valmiin tuotteen käyttöönottoa kalliimpana. Tosiasiassa valmiita tuotteita pitää niitäkin muokata, ja perinteisesti ns. räätälöity softa koostuu sekin valmiista komponenteista ja kirjastoista. Sovellusta rakentaessa, ja ostaessa, on oleellista tietää missä kohtaa itse tekeminen oikeasti kannattaa.
Sovelluskehityksessä kannattaa aina käyttää mahdollisimman paljon valmiita toteutuksia tai komponentteja, sillä niiden varsinainen kehitys on todella kallista. Esimerkiksi jonkin yksinkertaisen asian saanee toteutettua pienellä vaivalla, mutta monet kyseiseen asiaan liittyvät rajatapaukset, ongelmalliset syötteet tai poikkeukset saattavat ilmetä vasta liian myöhään. Valmiissa, muiden jo käyttämässä komponentissa, ainakin yleisimmät ongelmat ovat todennäköisesti jo korjattu tai otettu huomioon. Itse tekemisen, ja siihen arvioidun ajankäytön, on jo useamman vuosikymmenen ajan tiedetty olevan kallista ja haastavaa.
Räätälöinti ja erikoistuminen
Räätälöity sovelluskehitys nähdään usein sovelluksen rakentamisena niin sanotusti tyhjästä. Tällöin sovellus koostetaan joko matalan tason komponenteista tai jopa kaikki tehdään itse. Oletusarvoisesti näin tekeminen on hidasta ja kallista, mutta lopputulos eksaktia ja tarkkaa.
Räätälöinnin vastakohtana nähdään yleensä valmiin julkaisujärjestelmän tai vastaavan käyttö, jossa pienellä vaivalla saadaan sovellukselle lähes valmiit raamit. Näitä raameja toki joudutaan veivaamaan, ja vähintään ulkoasu kustomoidaan. Näissä tapauksissa asiat tehdään usein ennaltamääritetyllä, tietyllä tavalla, sen ollessa nopeinta ja edullisinta. Tiettyihin teknologioihin erikoistuneet tekijät ovat luonnollisesti tehokkaita omalla osaamisalueellaan. Mukavuusalueen ulkopuolelle loikkaaminen voi olla kiusallista. Pitkälle erikoistuneet saattavat venyttää osaamisalueensa rajoja, jolloin lopputulos ilmenee kyseisen teknologian perversiona tai esimerkiksi suboptimaalisena käyttökokemuksena.
Emme usko tällaisiin “hopealuoteihin”, vaan etsimme aina projektiin sopivan teknologian. Kaikilla on tietysti omat preferenssinsä ja näkökantansa, mutta valinta perustuu toimittajariippumattomuuteen, tekniseen soveltuvuuteen, sekä tietyllä tasolla tekjiöiden mieltymyksiin ja yleiseen fiilikseen teknologisen kehityksen kulusta.
Myyntiargumentti
Sovellusta määritellessä, ja varsinkin myyntivaiheessa, puhutaan paljon teknologiavalinnoista. Usein keskustelua ohjaa toimittajan erikoistuminen tiettyyn teknologiaan, tai ostajan ajan henkeen ja hypeen perustuviin harhaluuloihin. Itse tarkastelemme mahdollisia teknologioita nimenomaan niiden projektiin soveltuvuuden kannalta.
Maailma on täynnä valmiita järjestelmiä ja ilmaisia palikoita, joita voidaan helposti “ottaa käyttöön”. Näin päästään nopeasti vauhtiin ja kustannuksia sekä aikaa säästyy näennäisesti paljon. Iljettävän usein näitä komponentteja kuitenkin joudutaan korjailemaan, laajentamaan tai muokkaamaan. Tämä on käytännössä myös räätälöintiä, mutta eri tasolla.
Törmäämme jatkuvasti palveluihin, joissa teknologiavalinnat ovat tehty sillä perusteella, että “siihen alustaan on vaan niin helppo kytkeä ilmaisia, valmiita palikoita”. Tähän voi johtaa innokkaat myyjät, heikko ymmärrys toteutettavasta hankkeesta, ostajan harhaluulot tai aiemmat kokemukset teknologioista.
Harhaluuloja ja illuusioita saattavat aiheuttaa ns. muodissa olevat asiat ja “ison maailman” trendit. Tätä kirjoittaessa, esimerkiksi taikasana “Big Data” saa ihmisiä rakentamaan Hadoop klustereita ja kaiken maailman virveleitä, vaikka todellisuudessa muutama SQL kysely ja huolella kirjoitettu datan käsittelijä riittäisi.
Uutta järjestelmää tehdessä siihen kerätään kaikki edellisestä järjestelmästä kerätyt opit ja pyritään tekemään kaikki paremmin. Ja kaikilla mausteilla. Välttäessä edellisen järjestelmän virheet, tehdään sen sijaan uusia. Aiemmat kokemukset tietystä teknologiasta ovat harvoin yksiselitteisiä. Kokemukseen voi vaikuttaa teknologia, toimittaja, ostaja, projektiympäristö, toimintatavat tai työyhteisö. Menneisyyttä tarkastellessa, ja ennen teknologian halveksumista tai kehumista, kannattaa miettiä kokonaisuutta.
Integraatiot
Laajoja kokonaisuuksia, kuten esimerkiksi laskutusjärjestelmää tai pankkimaksuja harvoin kannattaa toteuttaa itse. Tällöin voidaan säästää kustannuksissa integroimalla oma järjestelmä kolmannen osapuolen tuottamaan palveluun. Kahden järjestelmän välille rakennettu integraatio on usein paperilla yksinkertainen, mutta käytännössä sellaisen toteuttaminen on usein todella kallista.
Integraation toteuttaminen vaatii tietynlaista teknistä osaamista, mutta suurimmat haasteet koituvat yleensä dokumentaation puutteista, kommunikaation hitaudesta ja väärinymmärryksistä. Julkisiin ja paljon käytettyihin palveluihin integroiminen onnistuu käytännössä helpoiten, kun taas sisäiset tai on-demand integraatiototeutukset sisältävät valitettavan paljon kolmannen osapuolen järjestelmän testausta.
Integraatiotia kannattaakin toteuttaa vain silloin kun siitä saatava hyöty on oleellista, ja vastaavan itse toteuttaminen tulisi kalliiksi tai aikaavieväksi.
Karrikoitua vertailua
| valmis ratkaisu | räätälöity | |
|---|---|---|
| aloitus | nopea ja halpa aloitus, jos ei lisenssimaksuja tai vastaavia | hidas aloitus ja mittava investointi |
| muutosten hallinta | hidas aloitus ja mittava investointi | muutokset parhaimmillaan nopeita ja kevyitä |
| integrointi toisaalle | hidasta ja vaikeaa, ellei jo valmis komponentti; silloin helppo ja nopea | keskivaikeaa, riippuen integroinnin kohteesta |
| integrointi toisaalle | erikoistuminen → tehokkuus | laajempi perusasioiden ymmärrys, oppiminen, sopeutuvuus |
| myynti ja teknologiavalinnat | hypettämistä, teknologian myynti sopimattomaan tarkoitukseen | myydään lopputuote, ei teknologiaa |
| harhaluulot | hulluimmallekin teknologiavalinnalle löytyy toimittaja | määritetään tarpeet ennen teknologiavalintaa |
| konventiot | toimittaja varmasti löytyy hulluimmallekin teknologiavalinnalle | yleensä vapaampaa tekemistä, suurempi riski tehdä todella väärin |
Skaala
Yksikään projekti ei ala nikkelin louhinnalla, käyttöjärjestelmän rakentamisella, tai oman ohjelmointikielen suunnittelulla. Tarpeesta riippuen, käytämme valmiita kirjastoja, “frameworkia” tai julkaisujärjestelmää. Ulkoisia kirjastoja käytämme aina, ja joskus julkaisemme omia. Kaiken kaikkiaan, käytämme niin paljon valmista kuin mahdollista, ja olemme valmiita opettelemaan uutta. On hyvä tietää mitä ei tiedä, eli mitä opetella seuraavaksi tai mitä vaihtoehtoja on olemassa.
Räätälöinti ja palastelu on usein järkevää, ja tavoitteena on tehdä niitä juuri sopivasti. Monesti ratkaisu koostuu sekä valmiista tuotteista, että itse tehdyistä kokonaisuuksista.
Lisää aiheesta
In Defense of Not-Invented-Here Syndrome
Build vs. Buy: How to Know When You Should Build Custom Software Over Canned Solutions
