Organisaatio

Haastatteluista ilmeni, että organisaatiossa ei ymmärretä mallintamisen tärkeyt-tä eikä sen vuoksi kannusteta mallintamiseen tai siihen kouluttautumiseen. Or-ganisatorisiksi luokitelluilla haasteilla (kuvio 17) on merkittävä vaikutus aiem-min esitettyihin mallintamistyöhön ja tiimityöskentelyyn liittyviin haasteisiin.

Kun organisaatio ei tue mallintamista eikä anna siihen tarvittavaa aikaa, työn-tekijät eivät voi kohdistaa sen hyödyntämiseen ja kehityksen seurantaan omia resurssejaan. Myöskään kiinnostus mallintamistyötä kohtaan ei pysy yllä tällai-sissa olosuhteissa.

KUVIO 17 Haasteet: organisaatio

Ohjelmistoarkkitehti H2 näki tilanteen kaikista lohduttomimpana. Hänen mu-kaansa isoissa organisaatioissa mallintamista ei ymmärretä, ei arvosteta eikä myöskään haluta hyödyntää. Tämä oli hänen mielestään todettavissa esimer-kiksi organisaation tarjoamien mallintamiskoulutusten vähäisyytenä.

Ei mallintamista saa lähtee opiskelemaan. Paljon tärkeempää on mennä suorittamaan joku Kubernetes- tai Docker-kurssi kuin se mallintamiskurssi.

Myös ohjelmistoarkkitehti H13 oli sitä mieltä, että koulutuksissa keskityttiin uusiin teknologioihin mallintamisen sijaan. Kun muilta haastateltavilta kysyt-tiin organisaation järjestämistä mallintamiskoulutuksista, ei heillekään ollut sellaisia tarjottu tai niistä oli jo aikaa. Osa kuitenkin lisäsi, että koulutusta var-masti saisi, jos itse olisi sen suhteen aktiivinen. Ohjelmistokehittäjä H8 mietti, että organisaatiossa ei todennäköisesti ollut edes ajateltu, että muutkin kuin arkkitehdit voisivat hyötyä mallintamiskursseista.

Ohjelmistoarkkitehti H5 kertoi mallintamisen olevan organisaatiossaan vähäistä ja epäili syyksi sitä, että asiaa ei ollut osattu edes ajatella hyötyjen nä-kökulmasta. Ratkaisujohtaja H3 ja pääarkkitehti H10 totesivat ohjelmistoarkki-tehdin H2 tavoin, että yrityksissä ei yleensä ajateltu pitkän tähtäimen hyötyjä, joita huolellisesta dokumentaatiosta malleineen seuraa.

…organisaatio suhtautuu tommosiin aika niinku sillei leväperäisesti, et se on sitte ehkä enemmän sen yksilön vastuulla, että miten se niinku suhtautuu siihen tilantee-seen. -- Yleensä se dokumentaatio on valitettavan paljon niinku PowerPointtia ja sit-ten sitä, että kyllä se koodi sen dokumentoi sen riittävän hyvin, että. (ohjelmistoark-kitehti H2)

Alalla vallitsevalla yleisellä asenneilmapiirillä voi olla merkittävä vaikutus or-ganisaatiossa ilmenevään mallintamisen arvostuksen puutteeseen. Negatiivisia asenteita mahdollisesti ruokkii myös jaottelu koodikeskeisiin ja mallintamista suosiviin ammattilaisiin (ks. esim. Badreddin ym., 2018). Jaottelu näkyi haasta-teltavienkin puheissa, kun mallintamista välillä kutsuttiin ”piirtelyksi”,

vasta-painona ”oikealle tekemiselle”. Haastateltavien esiin tuomat negatiiviset asen-teet vaihtelivat oman ja muiden käyttäytymisen välillä.

Edellisessä työpaikassa oli ihan osasto, missä ne teki ihan vaan kaavioo. -- Mut kyl myö vähän niitä mollattiin koko ajan, että ei tuo oo oikeeta työtä tommonen.

…mun koulutus oli ehkä siihen aikaan, että tota, se oli vielä niin kun niitä viimesiä aikoja, kun vielä uskottiin tällasiin, niin kun ehkä tietynlaisiin mallinnusmenetelmiin.

-– …sen jälkeen tuli kauhee niinku vastaisku, että mitään nyt ei saa mallintaa, että, että tota UML:ää kun joku mainitsi, niin aina tuli sata vitsiä siellä, hehehe UML:ää.. ...olemme edelleen hieman siinä tilanteessa, että se on sitte unohettu monet hyvät asiat, mitä on tehty.

Haastattelujen perusteella organisaatioissa ja projekteissa kaivattiin usein yksit-täisten henkilöiden merkittävää panosta, jotta asiat etenivät. Ohjelmistoarkki-tehti H5 oli sitä mieltä, että heidän organisaatiostaan puuttui mallintamisnäkö-kulmaa ajava osaaja, joka toisi mallintamiseen ja dokumentointiin kuuluvia käytänteitä muille tutuiksi. Ohjelmistokehittäjä H8 oli todennäköisesti omassa työyhteisössään tällainen henkilö, koska oli projektiin liittymisestään lähtien huolehtinut siitä, että kaavioita tuotettiin riittävästi. Ratkaisujohtaja H3 ja rat-kaisuarkkitehti H9 esittivät, että mallintamisen vähäisyyttä ja toimintaohjeiden puutteita korvaamaan tarvittiin yleensä yksittäisten henkilöiden ylimääräistä työpanosta (ks. 5.2.2 Mallien vähäisestä käytöstä johtuvat ongelmat).

…usein siinä tulee sit vastaan semmonen niinku mitä mää sanon hero effectiksi, että on niinku semmosia tiettyjä, tämmösiä henkilöityviä sankareita, jotka jossain hank-keessa, jotka on esimerkiksi ollut istumassa jossain workshopeissa ja niin edespäin, ja sit lähetään kovaa tekemään juttuja ja saahaan aluks tosi nopeesti paljon aikaseks.

(ratkaisujohtaja H3)

Se saatetaan sitten käytännössä kuroa sillei umpeen, että siellä on henkilöitä, jotka tekee sen toisella tavalla sen kokonaisuuden hallinnan sitten. Joko juoksemassa, juoksemalla eri tiimeissä ja keskustelemassa tai jotenkin muuten vastaavasti. (ratkai-suarkkitehti H9)

Neljä arkkitehtiä mainitsi haasteena organisaatioiden halun saada koko ajan nopeammin ja nopeammin toimivaa ohjelmistoa ulos (keskitytään lyhyen täh-täimen hyötyihin). Vaatimukset koettiin välillä hyvin kohtuuttomina, kun ta-voitteena kuitenkin oli laadukkaan ohjelmiston toimittaminen.

Siihen se nykyisin menee, et ei piirretä enää niin tarkkoja kuvia, pitäs vaan saadaan sitä koodia ulos mahollisimman paljon. Se on ihan yleinen joka puolella, kaikki yri-tykset yrittää mahollisimman kevyesti, mahollisimman tota tehokkaasti ja poistaa kaikki overheadit. Ihan pahimmillaan menny siihen, että testaustakaan ei juuri enää ole. Mikä on tosi huono juttu. Ne nähään noista miten huonoja nuo ohjelmistot ny-kyisin on. (ohjelmistoarkkitehti/-kehittäjä H1)

Kiirettä ja mallintamisen aliarvostamista ruokki haastateltavien mielestä kette-rän kehityksen yleistyminen ja sen ymmärtäminen väärin.

…on nähty, että kun tehdään ketterästi asioita, niin sillon ei tarvis mallintaa asioita, mikä ei ollu kyllä Scrumin ja agiilin, ketterän kehityksen mukaista alun perinkään, mutta sitä on käytetty sitten semmosena tekosyynä, minkä takia ei tarvii mallintaa ja dokumentoida asioita. (ratkaisuarkkitehti H9)

Me hyvin harvoin kehitämme mitään räjäyttävän todella uutta. Useimmitenhan IT:ssä tehdään asioita, tehdään nyt vaikka ne ostolaskut, niitä on kuule tehty kym-meniä vuosia ennenkin. -- ketteryys vetäs näistäkin kehitysjutuista, joissa se tiedon jakamisen takia riittävä mallintaminen on aina ollut tarpeen, niin vähän mentiin ehkä siinä yli. (projekti- ja palvelupäällikkö H4)

Mää uskon ainoostaan niinku arkkitehtuurilähtöiseen ohjelmistokehitykseen. Se on ainoo, minkä mää oon huomannu, että on 25 vuodessa tuottanu ees jollain lailla jär-kevää, koherenttia softaa. -- No, otetaan vaikka tää agile mikä on mun suosikki-inhokki nykyään on se, että mitään ei tartte dokumentoida ja mitään ei tartte niinku tehä muuta kuin vaan lätkitään koodia pinoon, niin. Mut eihän se niin mee. (ohjel-mistoarkkitehti H2)

Ohjelmistoarkkitehti H2 viittasi kirjallisuudessakin esitettyyn ongelmaan arkki-tehtuurin laiminlyönnistä ketterän kehityksen yhteydessä (ks. Abrahamsson ym., 2010; Babar, 2009). Ohjelmistoarkkitehdin H2 mielestä alaa vaivasi tällä hetkellä kaiken kaikkiaan huonot käytännöt. Myös ohjelmistoarkkitehti/-kehittäjä H1 koki organisaatioiden toimintaan vaikuttavat trendit ongelmallisi-na (keskitytään tyhjänpäiväisyyksiin hyvien käytäntöjen sijaan).

Ohjelmistotekniikka on vähän tämmönen niinku ööh, vähän niinku ois kiva olla vä-hän niinku tiedettä, mut ku ei oikein olla tiedettä, ni keksitään sitte jotain tyhjänpäi-väistä. (ohjelmistoarkkitehti H2)

…aina ku otetaan joku uus malli käyttöön, niin ensin sitä käy joku konsultti hehkut-tamassa ja sitten mennään ihan ettei tutkita kunnolla, että onko sitä järkevää käyttää.

(ohjelmistoarkkitehti/-kehittäjä H1)