Mallipohjainen tietojärjestelmäkehitys

Pääarkkitehti H10 ei luonnostelun ja dokumentaation lisäksi lukeutunut mui-den haastateltavien tavoin perinteisen mallintamisen hyödyntäjäksi. Pääarkki-tehdin H10 organisaatio H kehitti mallipohjaisen tietojärjestelmäkehityksen keinoin asiakaskohtaisia liiketoimintajärjestelmiä. Hän kutsui tapaa automati-soiduksi sovelluskehitykseksi. Organisaatio oli kehittänyt oman, korkean abst-raktiotason sovellusaluekohtaisen kielen ja koodia generoivan työkalun. Pää-arkkitehti H10 oli jo opiskeluaikoina kiinnostunut sovellusaluekohtaisesta mal-lintamisesta ja nykyään piti sitä ylivertaisena tapana kehittää ohjelmistoja. Hä-nen kokemuksensa mukaan mallipohjaisella ohjelmistokehityksellä oli useita etuja perinteiseen kehitykseen verrattuna, kuten tehokkuus- ja uudelleenkäytön hyödyt ja koodaajille mielenkiintoisemman työn tarjoaminen rutiinitöiden au-tomatisoinnin vuoksi. Asiakkaiden näkökulmasta hän sanoi näin:

…projekti/prosessitasolla niin löytyy tällasia asioita kuten asiakkaille, kun me pysty-tään nyt demonstroimaan niin kun järjestelmää sitä mukaa, kun me sitä määritellään,

niin ne on kokeneet sen sitouttavana ja innostavana ja erittäin miellyttävänä niin kun tapana määritellä järjestelmää.

Pääarkkitehdin H10 organisaation oma mallintamismenetelmä pureutui liike-toiminnan taustajärjestelmiin, mutta näiden ohessa he toimittivat myös perin-teisin menetelmin tuotettuja osajärjestelmiä, kuten verkkopalveluja. Myös au-tomaatiolla tuotettuihin järjestelmiin vaadittiin lisäksi räätälikoodin kirjoitta-mista. Toiminta vastasi Whittlen ym. (2013) näkemystä, jonka mukaan onnistu-neessa mallipohjaisessa kehittämisessä organisaatiot yhdistävät sitä joustavasti muihin menetelmiin. Haastattelu ei kuitenkaan tue Whittlen ym. (2013) tutki-mustulosta siitä, että koodigenerointi ei olisi mallipohjaisuudessa avainasemas-sa (ks. myös Mohagheghi ym., 2013). Pääarkkitehti H10 piti juuri koodi-generoinnin tarjoamia lyhyen tähtäimen hyötyjä niin merkittävinä, että malli-pohjaisuus oli hänen mielestään perinteistä ohjelmistokehitystä kannattavam-paa.

…ei siitä pelkästä mallista nyt niin paljon hyötyä ole. Mut sit kun sä yhdistät siihen sen, että sä saat siitä mallista tavaraa ulos, niin sit se alkaa kiinnostaa.

Näkemys vastaa mallipohjaisen kehittämisen puolestapuhujan Bran Selicin (2003) toteamusta siitä, että mallintamisen hyödyt tulisi nähdä nimenomaan koodigeneroinnin kautta pelkän dokumentaation sijaan. Whittlen ym. (2013) ja Mohagheghin ym. (2013) tutkimusten organisaatiot poikkeavat pääarkkitehdin H10 organisaatiosta H siten, että ne tuottivat ohjelmistoa lähinnä omiin tarpei-siinsa, eikä niiden toiminta perustunut mallipohjaisuuteen. Nämä tekijät voivat selittää näkemyseroja tehokkuuteen ja tuottavuuteen liittyen.

Myös UML:ää voidaan käyttää sovellusaluekohtaiseen automatisoituun tietojärjestelmäkehitykseen. Tällöin stereotyyppejä lisäämällä luodaan sovellus-aluekohtainen UML-profiili. Whittlen ym. (2013) tapaan pääarkkitehti H10 ei pitänyt tapaa optimaalisena.

…[UML] on niin yleiskieli, niin yleinen. -- …mä en oikeen oo, en oo ees ite keksiny miten sitä niin kun järkevästi pystys niin kun mallintaa tai sit se ois ihan järkyttävää niin kun stereotypioiden, stereotyyppien niin kun viljelyä joka paikkaan. Mut sit al-kaa herätä kysymys, että no, jos mulla nyt näitä stereotyyppejä on joka paikassa, niin miksen mää nyt vaan tekis omaa kieltä, jossa nää käsitteet on niin kun sitä, mitä mää haluan niitten olevan.

Pääarkkitehti H10 ei nähnyt UML:n viimeisimpien versioiden mukaista kehi-tystä mielekkäänä:

…ainakaan monimutkaisemmaks sitä ei kannata viedä tai sit se on kuollut kieli. Et tota noin niin, ehkä siitä kannattas yrittää kehittää jotakin, joku semmonen niinku profiili, joka olis niin kun käytännönläheinen. Hyväksyttäs se tosiasia, että ei, ei näitä piirtele niin kun tällä tasolla kukaan.

UML:n käyttö mallipohjaisessa kehittämisessä ei noussut esille muissa haastat-teluissa, vaikka mallipohjaisuutta muuten pohdittiinkin. Haastateltavat näkivät mallipohjaisessa kehittämisessä enemmän rajoitteita kuin hyötyjä. Haastatelta-vat mielsivät jo pelkän mallipohjaisen kehittämisen idean hyvin pitkälti toimi-mattomaksi ja vanhanaikaiseksi. Tuotepäällikön H11 kommentti oli hyvin ku-vaava:

Eikös se oo vähän semmosta vanhanaikasta, vähän vanhemman mallin tekemistä.

Mulla on semmonen mielipide siitä ehkä. Vesi-, vesiputoukseen liittyvää. -- …saman kommentin oon kyllä kuullut muiltakin, että se saattaa olla vähän vanhemman liiton juttuja.

Koodigeneroinnin nykytilasta kysyttäessä moni haastateltava vastasi, että sitä hyödynnettiin heidän organisaatioissaan vain vähän tai ei ollenkaan, tai että ei ollut asiasta aivan varma. Monella haastateltavalla oli kuitenkin aiempaa ko-kemusta koodigeneroinnista, johon liittyvät epäonnistumiset vaikuttivat heidän mielipiteisiinsä mallipohjaisesta kehittämisestä. Koodigeneroinnin käyttö näh-tiin myös täysin vastakkaisena toimintana tehokkaalle ja taidokkaalle koodaa-miselle, joten mallipohjaiseen kehittämiseen voidaan epäillä liittyvän negatiivi-sia asenteita, ainakin koodikeskeisimpien ammattilaisten joukossa.

…sitä käytiin ehkä sillon alussa, kun ei ollut vielä paljon kokemusta, mutta sen jäl-keen niin tota en mää käytä sitä, nopeempi tehä käsin ite se koodi, ku tietää mitä te-kee. (ohjelmistoarkkitehti/-kehittäjä H1)

Joskus sitä [koodigenerointia] on kokeiltu 2000-luvun alussa, mutta aina se jotenkin mätti. Ei se toiminut. (sovellusarkkitehti H12)

Ratkaisuarkkitehti H9 oli sitä mieltä, että vaikka ajatus on mielenkiintoinen, ei mallipohjainen kehittäminen yksinkertaisesti toimi. Hän selitti, että onnistumi-nen vaatisi hyvin tarkkaa mallintamista ja toisaalta myös käsin koodaamista rinnalla, joten kustannustehokkuus ei olisi halutulla tasolla. Merkittävänä es-teenä hän näki parin muun haastateltavan lisäksi myös koodigenerointia teke-vien työkalujen riittämättömyyden. Osa haastateltavista ei kuitenkaan tuntunut olevan aiheesta kiinnostuneita, vaikka teknologia sen mahdollistaisikin, mikä vastaa Whittlen ym. (2013) havaintoa koodiguruista ja eri teknologioita testaile-vista, mallipohjaisuutta vastustavista ammattilaisista.

Ei mua varmaan mikään, mikään saa kiinnostumaan. Mä oon valinnu tämän polun, niin mä meen tällä. (sovellusarkkitehti H12)

…mää oon sen verran vanhan liiton koodari, ni en mää käytä semmosia… (ohjelmis-toarkkitehti/-kehittäjä H1)

Haastateltavista moni lisäsi, että kiinnostuksen ja soveltuvan työkalutuen puut-teesta huolimatta suhtautuu avoimin mielin koodigeneroinnin ja mallipohjai-suuden tarjoamiin mahdollisuuksiin. Ohjelmistokehittäjä H8 ja

ohjelmistoarkki-tehti H13 totesivat, että mallipohjaisuus todennäköisesti sopii moneen tarkoi-tukseen, mutta pitivät perinteistä tapaa helpompana ja sillä tuotetun koodin elinkaarta pidempänä. Ainoastaan tuotepäällikkö/sovellusarkkitehti H7 osoitti pääarkkitehdin H10 lisäksi selkeästi kiinnostusta mallipohjaista kehittämistä kohtaan ja näki vaihtoehdot luovina rajoittavien sijaan, yhdistäen ne ketteryy-teen. Hän oli kiinnostunut etenkin ratkaisujen vaivattomasta demoilusta. Kui-tenkaan edes hän ei uskonut, että teknologia tällä hetkellä taipuisi tehtävään halutulla tavalla.

Pääarkkitehti H10 ymmärsi mallipohjaisuuteen kohdistetun kritiikin, kos-ka toiminta vaati onnistuakseen paljon osaamista ja investointeja sekä sitoutu-mista valittuun linjaan.

…siis kyl sen saa toimimaan, mutta se on, se ei oo ihan halpaa ja et se vaatii ihan oi-keesti investointeja ensinnäkin ihan puhtaasti teknologiaan, se vaatii sitoutumista eli käytännössä suomeksi tarkoittaa, että rahaa sen jatkuvaan kehittämiseen, eteenpäin viemiseen, se vaatii sitä, että sulla on ikään kuin kokemusta tarpeeks siitä niinku on-gelma-alueesta, että sä voit ylipäänsä päättämään itsesi kanssa sen, että mitä kannat-taa mallinkannat-taa ja mitä ei kannata mallinkannat-taa.

Taulukossa 10 on esitetty haastatteluissa mainitut hyödyt, haasteet ja ongelmat mallipohjaiseen kehittämiseen liittyen.

TAULUKKO 10 Mallipohjaiseen kehittämiseen liittyvät hyödyt ja haasteet

Hyödyt Esiintyvyys Haasteet Esiintyvyys

Ratkaisujen protoilu aikaisessa vaiheessa 2 Ei kiinnosta 3

Koodaajalle mielekkäämpi työ 1 Ei toimi 3

Tehokkuushyödyt (koodi, dokumentointi) 1 Koodaaminen kannattavampaa (helppous,

Uudelleenkäytön hyödyt 1 pidempi elinkaari)

Yksinkertaisuus, korkea abstraktiotaso 1 Työkalut eivät tue 3

Vaatii osaamista 3

Vanhanaikaista 3

Ei kustannustehokasta 2

Vaati sitoutumista 2

Liian rajoittavaa 1

Vaatii investointeja 1

Vaatii notaation tarkkaa noudattamista 1 3