Hävitä oma ohjelmistoarkkitehtuuri
25.03.2009 | Lare Lekman | 2 Kommenttia
Oma ohjelmistoarkkitehtuuri on jätteen salakavala ilmentymä, jota tarvitaan todellisuudessa ehkä yhdessä projektissa sadasta. Ellei yrityksenne kehitä avaruussukkulan ohjelmistoa, pärjäätte todennäköisesti loistavasti alan parhailla käytännöillä ja tunnetuilla sovelluskehyksillä.
Pyörän uudestaan keksiminen on asiantuntijoiden märkä uni, mutta bisnekselle se voi olla tuhoisan kallista. Oma arkkitehtuuri sitoo ratkaisun kehittäjiinsä, joilta sitten vaaditaan tekninen arkkitehtuurikuvaus selvittämään kuinka viritys toimii. Kun joku ei sittenkään arvosta ratkaisun hienouksia, on vika tietenkin kuulijassa. Eniten rahaa poltetaan kehittämällä “joustavaa arkkitehtuuria”, josta murto-osa tulee lopulta käyttöön. Valtavan jätevuoren lisäksi kasvavat ylläpitokustannukset, jatkokehityksen monimutkaisuus ja dokumentoinnin sekä koulutuksen tarve.
Ketterä kehitys suhtautuu arkkitehtuuriin kriittisesti: Kaikki mikä ei tuota asiakkaalle lisäarvoa on jätettä. Yksinkertaisen määritelmän mukaan omaa ohjelmistoarkkitehtuuria kannattaa välttää kuin ruttoa. Arkkitehtuuria onkin opittu kehittämään ketterästi vain siinä laajuudessa, kuin on tarpeen kehitysjaksossa vaadittujen ominaisuuksien toteuttamiseksi.
Tuottavin vaihtoehto on hävittää oma arkkitehtuuri kokonaan. Tämä on mahdollista valitsemalla valmis sovelluskehys ja tunnettu arkkitehtuuri, joista löytyy kattava ja aktiivisesti ylläpidetty dokumentaatio. Näin oman arkkitehtuurin lisäksi katoavat teknisen perimätiedon ja dokumentaation tarve.
Esimerkiksi Ruby on Rails on MVC-arkkitehtuuria käyttävä sovelluskehys verkkopalveluiden nopeaan kehittämiseen. Jokainen sovellus sisältää identtisen hakemistorakenteen ja arkkitehtuurin ajatuksella convention over configuration, joten verkkopalvelun dokumentoimiseksi riittää periaatteessa tämän kappaleen linkit. Kehitystiimin tarvitsee vain sopia yhtenäisestä koodauskäytännöstä, jonka jälkeen voidaan keskittyä oleelliseen eli asiakkaiden lisäarvon tuottamiseen.
Ketterässä kehityksessä ohjelmistoja ei rakenneta helposti muokattavaksi vaan ne säilytetään yksinkertaisina ja helposti muokattavina. Hävitä rohkeasti oma arkkitehtuurisi, ellei sen kehittämisellä ja ylläpidolla saavuteta mittavaa lisärvoa.
