Onko sinulla aikaa arkkitehtuurille?

Olin taannoin kuuntelemassa kahden australialaisen tutkijan esitystä siitä, kuinka hyvin datatieteilijät ymmärtävät, mitä ohjelmistoarkkitehtuuri tarkoittaa ja miten he siihen ylipäätään suhtautuvat.

Tutkijat jakoivat osallistuneet kolmeen ryhmään, datatieteilijöihin, ohjelmistoarkkitehteihin ja ohjelmistoinsinööreihin. Tutkimusaineistona oli nettilomake, jossa oleviin kysymyksiin osallistujat vastasivat.

Aikapulan syynä huono arkkitehtuuri

Tuloksista selvisi, että kaikki kolme ryhmää olivat yleisesti yhtä mieltä sekä arkkitehtuurin määritelmästä että tärkeydestä. Samalla tapaa ryhmät olivat yhtä mieltä siitä, että tekninen velka on pahasta, vaikka sen määrittely oli jo hankalampaa.

Ehkä hieman huvittavasti datatieteilijät katsoivat tuottavansa paljon teknistä velkaa siinä, missä insinöörit kokivat joutuvansa maksamaan sen omina työtunteinaan. Kun tutkimuksessa kysyttiin arkkitehtuurin merkityksestä osallistuneiden omaan työhön, kävi ilmi, ettei arkkitehtejä lukuun ottamatta muilla ole aikaa eikä tarvittavaa tukea arkkitehtuurin pohtimiseen.

Datatieteilijöiden vastaukset ovat ymmärrettävissä, sillä ohjelmistotyö ei varsinaisesti kuulu heidän toimenkuvaansa. Datatieteilijät tuottavat ohjelmistojen käyttämiä algoritmeja, mutta niiden integroiminen on kuitenkin ohjelmistoinsinöörien työtä.

Mutta se, ettei ohjelmistoinsinööreillä ole omassa työssään aikaa tai tukea arkkitehtuurin pohtimiseen, jäi häiritsemään minua. Siitähän se suurin aikapula juuri johtuu: huonosta arkkitehtuurista.

Ohjelmistoarkkitehtuuri on ohjelmiston ominaisuus eikä sen kuvaus

Törmään aika ajoin virheellisiin käsityksiin sekä ohjelmistoarkkitehdeistä että -arkkitehtuurista. Liian helposti arkkitehtuuriksi luullaan PowerPoint -laatikoita ja kieli poskessa piirrettyjä UML-sekvenssidiagrammeja, jotka ovat samalla tavalla vanhentuneita kuin keskiaikaiset maailmankartat.

Arkkitehti taas on joidenkin mielestä (joskus ihan oikeutetusti) henkilö, joka luulee edellä mainittujen dokumenttien muuntuvan koodiksi maagisella Jira-työkalulla.

Yrityksessämme käytämme arkkitehdeistä nimeä “koodaava arkkitehti” välttääksemme ennakkoluuloja ja tuodaksemme heti esille sen, että arkkitehdit koodaavat myös eivätkä piirrä pelkästään laatikoita.

Arkkitehtuuri ei ole kuvaus ohjelmiston rakenteesta tai sen suunnitellusta toiminnallisuudesta. Arkkitehtuuri ei ole jotain, mikä tehdään ensin ja sitten käskytetään muille. Se ei ole kokoelma dokumentteja tai läjä automaattisesti generoituja luokkakaavioita sokeroituna ohjelmoijien koodiin upottamilla kommenteilla. Eikä se varsinkaan ole muutama viivoilla yhdistetty PowerPoint-laatikko värikoodattuna lukijan ymmärrystä helpottamaan.

Wikipedia määrittelee ohjelmistoarkkitehtuurin näin:

“Software architecture refers the fundamental structures of a software system and the discipline of creating such structures and systems. Each structure comprises software elements, relations among them, and properties of both elements and relations.”

Ohjelmistoarkkitehtuuri on siis ohjelmiston ominaisuus eikä sen kuvaus. Se on jotain, mikä on olemassa, halusimme sitä tai emme. Ohjelmistoarkkitehtuuri koostuu ohjelmistoon luoduista rakenteista, elementeistä ja elementtien välisistä suhteista.

Huonon arkkitehtuurin vastakohta on käytännöllinen arkkitehtuuri

Douglas Martin esitti kirjassaan ”Book Design: A Practical Introduction” ajatuksen, joka resonoi vahvasti oman käsitykseni kanssa ohjelmistoarkkitehtuurista:

“Questions about whether design is necessary or affordable are quite beside the point: design is inevitable. The alternative to good design is bad design, not no design at all.”

Toisin kuin designin yhteydessä, sanoisin mieluummin, että huonon arkkitehtuurin vastakohta ei ole hyvä arkkitehtuuri vaan käytännöllinen arkkitehtuuri. Silloin emme joudu semanttiseen labyrinttiin kinastelemaan siitä, mikä on hyvää, vaan voimme tutkia, kuinka ohjelmiston arkkitehtuuri tukee niitä muutostarpeita, joita ohjelmistolle syntyy sen elinkaaren aikana.

Käytännöllisen ja huonon arkkitehtuurin eron huomaa ohjelmistoprojektissa alun kuherruskuukauden jälkeen. Kuherruskuukaudella tarkoitan sitä aikaa, kun projektissa saadaan tehdä ominaisuuksia vapaasti ja ollaan vasta kulkemassa kohti ensimmäistä MVP:tä.

Tämän ajanjakson jälkeen erilaisia muutostarpeita ilmaantuu eri sidosryhmiltä. Muutostarpeet eivät sinänsä ole ongelma, vaan merkki siitä, että projektitiimi oppii ohjelmistonsa käyttötarpeista aidossa kommunikaatiossa käyttäjien kanssa.

Muutostarpeita hallitessa käy nopeasti ilmi se, ettei tiimi voi olla ketterä, jos se joutuu taistelemaan jatkuvasti arkkitehtuuria vastaan. Monoliitin kehittäminen ketterän tiimin vaatimissa inkrementeissä on mahdotonta.

Hyvänä käytännön esimerkkinä tällaisesta huonosta arkkitehtuurista on jokaiselle suomalaiselle ohjelmistoalan työntekijälle tuttu kerrosarkkitehtuuri, jossa ohjelmisto on jaettu backend-, frontend- ja mobiilikerroksiin. Jokaisesta kerroksesta vastaa yksi tiimi. Loppukäyttäjälle mielekkäät toiminnallisuudet vaativat jokaisen tiimin panosta ja backlogien yhteensovittamista. Kuinka tiimit voivat olla päätösvaltaisia, hajautettuja ja autonomisia, jos yksikään ei lopulta voi tehdä mitään mielekästä toiminnallisuutta itse alusta loppuun?

Menestyneillä ohjelmistoilla on yleensä huonoin arkkitehtuuri

Käytännöllinen arkkitehtuuri taas mahdollistaa uusien toiminnallisuuksien nopeamman ja helpomman kehittämisen. Kun arkkitehtuuri ei vastusta tekemistä, voidaan tiimit järjestää niin, että ne voivat kehittää uusia toiminnallisuuksia muista riippumatta.

Korkealla tasolla vastuut eri ohjelmistokomponenttien välillä on jaettu niin, ettei niiden välillä ole turhia riippuvuuksia. Komponentit ovat sekä modulaarisia että yksinkertaisia. Matalalla tasolla tämä jättää ohjelmistoinsinöörille tilaa toteuttaa halutut toiminnallisuudet järkevällä tavalla.

Hieman paradoksaalisesti menestyneillä ohjelmistoilla on yleensä huonoin arkkitehtuuri. Ohjelmistot ovat olleet olemassa pitkään, ja ne ovat ajan saatossa muokkautuneet kauas alun idealistisista arkkitehtuurikuvauksista. Kuitenkin ilman arkkitehtuurillista vaivannäköä ohjelmistot eivät olisi eläneet niin pitkään, että niistä olisi tullut menestyneitä.

Ohjelmiston arkkitehtuuri elää ja muuttuu jatkuvasti. Se on ohjelmiston ominaisuus. Tiedämme, että hallitsematon muutos johtaa kaaokseen, joten meidän, arkkitehtien ja insinöörien, tulee yhdessä paimenten tavoin pitää huoli, että tuo muutos pysyy kurissa ja menee hallittuun suuntaan.

Älä pelkää arkkitehtuuria

Eräs toinen puhuja samaisessa tapahtumassa, mistä tämänkin kirjoituksen aihe tuli, piti mielenkiintoisen esityksen otsikolla “Good enough architecture”. Hän kävi läpi tosielämän esimerkkejä siitä, kuinka huono ohjelmistoarkkitehtuuri oli ajanut yrityksiä erilaisiin ahdinkoihin.

Esityksen päätteeksi hän antoi ohjelmistoarkkitehdeille viisi ohjetta, joista kolme ensimmäistä sopii mielestäni kaikille ohjelmistotyötä tekeville:

  1. Don’t be afraid of architecture
  2. Choose the simplest thing that works
  3. Create evolvable structures

Välttyisimme monelta ongelmalta, jos kaikki alalla ymmärtäisivät jokaisen kooditason päätöksen ja siitä seuraavan kompromissin olevan osa syntyvää ohjelmistoarkkitehtuuria. Ongelmien välttämiseksi kaikkien tulisi noudattaa myös edellä mainittuja kolmea ohjetta tasapuolisesti.

Enkä haluaisi enää kuulla väitettävän, ettei meillä ole aikaa arkkitehtuurille. Oikeasti meillä ei ole aikaa sen kaaoksen pyörittämiseen, kun arkkitehtuurin antaa muodostua ilman ohjausta.

Chief Architect
Teemu Stenhammar