Hävitä oma ohjelmistoarkkitehtuuri
25.03.2009 | Lare Lekman | Kommentoi
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.
En aivan käsitä mitä tarkoitat ohjelmistoarkkitehtuurilla. Alan terminologia on puhki kulunutta ja epämääräistä mutta onko esimerkiksi mahdollista kirjoittaa riviäkään koodia ilman että jo se yksi koodirivi muodostaisi ohjelmiston arkkitehtuurin?
Mielestäni ohjelmistoa ei voi luoda ilman että sillä olisi “arkkitehtuuri”, oli se sitten suunniteltu etukäteen tai luotu inkrementaalisesti kehitysjaksoissa ohjelmoinnin yhteydessä. Arkkitehtuuria on mahdotonta hävittää, se on olennainen osa ohjelmistoa.
Sovelluskehyskään ei sellaisenaan ratkaise asiakkaan ongelmia, vaan se tarvitse tuekseen koodia. Usein oliomaailmassa puhutaan domain-mallista missä koodissa esiintyvät rakenteet ja termit heijastelevat tosimaailmaa. Yksinkertaiset tietokantapohjaiset Web-sivusta ovat asia erikseen eikä sellaisissa kenties domain-mallia tarvita. Mutta eikö vähänkään monimutkaisemman ohjelmiston domain-mallin rakenne ole olennainen osa ohjelmiston arkkitehtuuria?
Näkisin käsitteet siten, että sovellusarkkitehtuurin muodostaa domain-malli joka on sovelluskehysten ja kirjastojen kautta sidottu oikeaan maailman kuten vaikkapa tietokantaan ja käyttäjän Internet-selaimeen. Ohjelmistoarkkitehtuuria ei täten voi hävittää vaikka käytössä olisi millainen sovelluskehys.
Kuten kirjoitit ketterässä kehityksessä kaikki mikä ei tuo lisäarvoa on haaskuuta. Täten arkkitehtuuria pitäisi suunnitella ja toteuttaa juuri sen verran kuin on tarpeen, eikä tippaakaan enempää. Yleiskäyttöisten (”geneeristen”) ohjelmistojen, arkkitehtuurien saatika sovelluskehysten kehittäminen on rahan tuhlausta, ellei yrityksen bisnes ole niiden myynti.
Ari,
Ohjelmistoarkkitehtuurilla tarkoitan järjestelmän teknisiä ratkaisuja, en varsinaista sovelluslogiikkaa.
Usein arkkitehtuuri yli- tai alikorostuu. Nuorempi ohjelmistokehittäjä ei ymmärrä koodaavansa pyörää uudestaan ja vanhempi innostuu pyytämättä rakentamaan “parempaa versiota” kirjastosta tai sovelluskehyksestä, josta olisi saatavilla laadukas, ylläpidetty ja dokumentoitu avoimen lähdekoodin ratkaisu.
Liiketoimintaa ymmärtävä ohjelmistoarkkitehti hävittää yrityksen sisäiset arkkitehtoniset himmelit, valitsee sopivan valmiin sovelluskehyksen kirjastoineen ja keskittää näin tiiminsä ajankäytön asiakkaan lisäarvoon. Arkkitehtuuria ei voi hävittää, mutta omat viritykset voi.