Ennen kuin sukelletaan nykypäivän mallintamiseen, aloitetaan historiakatsauksella, sillä useimmat asiat ymmärtää paremmin, kun tietää niiden historian.
Entisaikaan suuri osa ohjelmistoista tehtiin ”käsin”. Eli ensin kirjoitettiin määritykset ja sitten joku koodasi ohjelmiston niiden mukaan. Määritysten perusteella suunniteltiin testitapaukset ja ohjelmisto hyväksyttiin käyttöön, kun testitapaukset oli onnistuneesti läpäisty. Määritykset olivat suurimmaksi osaksi word-dokumentteja, joten lähestymistapa oli työläs ja vei turhan paljon kalenteriaikaa. Hyvä määrittelijä osasi varmistaa, että määritys on ehyt, vaikkei se tekstidokumentin kanssa ollutkaan ihan helppoa. Sittemmin tekemistä on lähdetty ketteröittämään ja palastelemaan. Oikeutettu kritiikki nosti esille sen tosiasian, että kun ohjelmisto on viimein valmis, on se jo vanhentunut.
Tekstivoittoisista määrityksistä siirryttiin mallintamiseen jo parikymmentä vuotta sitten. Ensin mallinnuskieli oli UML. Kun UML oli hitti, kustakin notaation osasta oli kirjoitettu oma kirja, kirjailijoina ”three amigos” https://cs.smu.ca/~porter/csc/341/notes/uml.html . Elementtejä ei ollut kovinkaan paljoa, mutta kaikki me soveltajat pohdimme niiden käyttöä erittäin huolellisesti ja olipa aiheesta kirjoitettu artikkeleitakin. Meitä kutsuttiin systeemisuunnittelijoiksi. Olen siis tietyiltä osin jäävi sanomaan, onko mallintaminen vaikeaa. Itse olen tehnyt sitä kohta kolmekymmentä vuotta.
Nykyisin mallintaminen tarkoittaa useimmiten ArchiMate-kuvauskielen käyttämistä. Ennen ArchiMate-kuvauskieltä mallinnustavat vaihtelivat eri välineissä. Kokonaisarkkitehtuuriin oli kuitenkin vakiintunut ajatus, että on tarve kuvata prosesseja, tietoa, tietojärjestelmiä ja teknologioita. Yksityiskohtien määrä ja tulkinta vaihtelivat, mutta ”pihvi” oli pitkälti sama. ArchiMate standardoi tämän, poimi tietyt asiat UML:stä ja lisäsi uusia. Lopputuloksena saatiin hyvin laaja ja teknologiariippumaton kuvauskieli.
Jos hyppää matkaan vasta nyt, voi ArchiMate tuntua melkoiselta haasteelta. Laajan standardin lisäksi pitäisi hallita mallinnusväline ja oppia mitä se mystinen mallintaminen oikein on. Alussa onkin tyypillistä, että nämä uudet opeteltavat asiat vievät niin suuren osan huomiosta, että mallintaja unohtaa mitä olikaan mallintamassa. Myyntiprosessi alkaa tarjouspyynnöstä, etenee tarjouksen tekemiseen ja edelleen sopimukseen. Pankkien lainan myöntö taas alkaa lainahakemuksesta, etenee sen käsittelyyn ja siitä edelleen lainan myöntämiseen ja nostamiseen. Olen nähnyt, että kokematon mallintaja unohtaa noinkin yksinkertaiset asiat, kun on niin paljon uutta muistettavaa. Aluksi onkin riski, että mallinnuskieli ja väline vievät mallintajaa eikä toisin päin.
Kun mallintamiseen rutinoituu, auttaa mallinnuskieli selvittämään tarvittavat asiat. Sovitussa mallinnustavassa (kutsumme tätä mallinnuskäsikirjaksi) muistutetaan, että on syytä kuvata tarpeellisin osin kaikki arkkitehtuurinäkökulmat (toiminta, tieto, tietojärjestelmät ja teknologiat). Jos mallinnustapaa ei ole sovittu, tulee vastaan suunnitelmia, joissa katetaan ICT-asiat hyvinkin yksityiskohtaisesti, mutta ei sanallakaan mainita, mihin tätä uutta hienoa ratkaisua voisi käyttää. Toiminta siis puuttuu kuvauksesta ja useimmiten tiedotkin.
Vaikein asia jo kolmenkymmenen vuoden ajan on ollut sopivan "käsialan" valinta. Tehdäkö mallinnus karkeammin tai tarkemmin? Entä onko ns. abstrahointi hyvä juttu vai olisiko konkreettisempi lähestymistapa parempi? Paras tapa on kompromissi mainittujen ääripäiden välissä. Valitettavasti käsialaan ei ole valmista keittokirjaa, vaan kompromissi vaihtelee tilanteen mukaan. Netistä löytää joitain esimerkkejä, mutta tarve hyville esimerkeille on edelleen huutava. Mallinnustavan saa jalkautettua parhaiten oman organisaation sisällöllä tehtyjen esimerkkien avulla.
Entä miten tästä eteenpäin? Tekemällä oppii, niin me veteraanitkin olemme oppineet. Lisäksi vaaditaan kykyä kiteyttää asioita ja sinnikkyyttä iteroida lopputulosta, kunnes se on riittävän ehyt.