Tarpeeton monimutkaisuus on IT-alan ammattitauti. Joka kerta kun olen siivonnut jonkin vanhan järjestelmän päältä, alta on löytynyt ratkaisu joka olisi voinut olla puolet pienempi, puolet halvempi ja kaksi kertaa selkeämpi. Ja silti siinä oli päädytty siihen monimutkaiseen versioon.

Se ei yleensä johdu pahuudesta. Se johtuu viidestä asiasta, jotka ovat inhimillisempiä kuin haluaisimme myöntää.

1. "Emme ihan tiedä mitä teemme, mutta emme voi sanoa sitä ääneen"

Kun kukaan ei oikein tiedä miten ongelma pitäisi ratkaista, turvallisin tapa on rakentaa jotain joka näyttää siltä kuin tietäisi. Moniosainen arkkitehtuuri. Microservicet. Eventbussi. Kerros kerroksen päälle, ja jokainen kerros perusteltavissa omalla diakuvalla.

Lopputulos on järjestelmä jota kukaan ei ymmärrä kokonaisuudessaan — mutta jokainen osa on "best practice". Yksinkertainen toteutus olisi paljastanut, että rakentajat eivät oikeastaan tiedä mitä ongelmaa ratkaistaan. Monimutkainen toteutus peittää sen.

Epävarmuus puetaan rakenteeseen. Se maksaa pidemmällä tähtäimellä enemmän kuin se, että joku olisi myöntänyt: "emme vielä tiedä, kokeillaan pientä ja katsotaan."

2. Monimutkaisuus on budjettivaluuttaa

Kun haluat lisää henkilöstöä, lisää lisenssejä tai lisää konsulttitunteja, tarvitset perustelun. Yksinkertainen ratkaisu ei näytä perustelulta. Monimutkainen näyttää.

Esitys johtoryhmälle kahden Postfix-palvelimen asentamisesta ei saa kukaan innostumaan. Esitys "strategisesta sähköpostialustasta" jossa on monitorointi, korkean saatavuuden redundanssi, sertifikaatinhallinta-alusta ja "skaalautuvuus tulevaisuuden tarpeisiin" saa. Molemmat tekevät saman asian. Toinen maksaa kymmenen kertaa enemmän.

Tämä ei tarkoita että kaikki budjettiperustelut ovat valheellisia. Tarkoittaa vain, että alalla on huomattu: monimutkaisuus myy budjetissa helpommin kuin yksinkertaisuus. Se on kannustin johon ihmiset reagoivat.

3. Monimutkaisuus on työpaikkavakuutus

Jos olet ainoa henkilö joka ymmärtää, miten järjestelmä toimii, sinua ei voi irtisanoa. Se on ikävä totuus, jonka harva sanoo ääneen — mutta ilmiö on niin yleinen, että sille on jopa termi: bus factor, eli kuinka moni ihmisiä voi jäädä bussin alle ennen kuin projekti kaatuu.

Kukaan ei suunnittele järjestelmää tarkoituksella työpaikkavakuutukseksi. Mutta kun valinta on selkeän, dokumentoidun ratkaisun ja "oman erityisen sovelluksen" välillä, moni valitsee jälkimmäisen puolitiedostaen. Dokumentointi lykkääntyy. Koodi on vain omassa päässä. "Kysy minulta, kyllä minä tiedän."

Tämä on ymmärrettävää yksilötasolla. Yrityksen näkökulmasta se on riski, josta maksetaan aina jossain vaiheessa.

4. Toimittajan matematiikka palkitsee monimutkaisuutta

Jos toimittajaa maksetaan tunneista, pisimmän tien ratkaisu on myös tuottavin. Jos toimittajaa maksetaan lisensseistä, suurin lisenssipaketti on myös tuottavin. Jos toimittajaa maksetaan ylläpidosta, monimutkainen järjestelmä on parempi tulonlähde kuin yksinkertainen.

Tämä ei tarkoita että toimittajat ovat epärehellisiä. Tarkoittaa että insentiivit osoittavat toiseen suuntaan kuin asiakkaan etu. Kirjoitin aiemmin esimerkin tästä: IBM tarjosi 150 tuntia, Postfix-relay ratkaisi saman 15 tunnissa. Ero ei ollut osaaminen vaan motivaatio etsiä lyhin tie.

Kun tunnit ovat valuutta, pisimmällä tiellä on enemmän valuuttaa.

5. "Best practice" -kulttuuri ilman kontekstia

Google, Netflix, Amazon ja Meta julkaisevat arkkitehtuurinsa. Ne ovat mielenkiintoisia. Ne ovat oppimisen arvoisia. Ja ne on rakennettu ongelmiin, joita kymmenen hengen suomalaisella pk-yrityksellä ei ole.

Silti olen nähnyt useammin kuin kerran 20 hengen firman, jolla on Kubernetes-klusteri, service mesh, kolme ympäristöä ja CI/CD-putki joka rakentaa 40 mikropalvelua. Alla pyörii kaksi PHP-sovellusta ja yksi MySQL-tietokanta, jotka olisivat mahtuneet yhdelle virtuaalipalvelimelle.

"Best practice" ilman kontekstia tarkoittaa "kopioimme jonkun muun ongelmaan tehtyä ratkaisua ja asennamme sen ongelmaan, jota meillä ei ole." Se on kulttinen käyttäytyminen, joka maksaa rahaa ja aikaa mutta tuntuu turvalliselta, koska "niin kaikki tekevät."

Miksi tämä on tärkeää

Monimutkaisuus ei ole vain kallista. Se on hitaan oppimisen lähde. Mitä enemmän liikkuvia osia järjestelmässä on, sitä vaikeampi on ymmärtää missä vika on kun jokin menee rikki. Sitä vaikeampi on kouluttaa uusi työntekijä. Sitä vaikeampi on muuttaa mitään, kun liiketoiminta muuttuu.

Yksinkertainen ratkaisu on ylivoimaisesti arvokkaampi kuin monimutkainen saman ongelman ratkaisu. Sitä ei myydä yhtä hyvin, koska se ei näytä siltä että siinä olisi "tehty mitään". Mutta se on se, joka toimii viiden vuoden päästäkin ilman että joku joutuu sitä uudelleen selittämään.

Mitä tästä opitaan

Kun joku esittää teille monimutkaisen ratkaisun, kysykää aina: mikä tässä on se yksinkertaisin muoto joka silti toimisi? Jos vastaus on "se ei toimisi, koska...", kuunnelkaa tarkasti ja arvioikaa perustelut. Jos perustelut ovat teoreettisia — "tulevaisuuden skaalautuvuus", "mahdolliset uudet tarpeet", "joustavuus muutoksiin" — olette todennäköisesti katsomassa monimutkaisuutta joka ei palvele teidän oikeita ongelmianne.

Yksinkertaisuus ei ole sama asia kuin laiskuus. Se on tiukempaa ajattelua. Se on päätös olla rakentamatta sitä, mitä ei tarvita. Se on rohkeutta sanoa "emme tarvitse tätä" silloinkin kun joku tarjoaisi sen teille.

Ja jos sisäpuolelta katsottuna kukaan ei osaa tai uskalla tehdä sitä päätöstä, ulkopuolinen silmä on yleensä paras tapa päästä alkuun.

Onko teillä IT-ympäristössä kohta, joka tuntuu monimutkaisemmalta kuin sen pitäisi olla? Digitaalinen remontti alkaa siitä, että katsotaan uudestaan ja puretaan se minkä voi purkaa. Järkivahti on sama asia jatkuvana palveluna: ulkopuolinen näkökulma, joka estää monimutkaisuuden ryömimisen takaisin.