Vaatimusmäärittely
Sujuva ja helppo arkkitehtuurimallinnus

Minulla oli viime vuoden loppupuolella kunnia päästä kehittämään erään asiakkaamme tietojärjestelmäarkkitehtuurin mallinnustapaa. Avaan kirjoituksessani mitä tehtiin ja miksi, sekä mitä hyötyä tehdystä työstä oli.

Asiakkaalla oli jo käytössä riittävät työkalut mallinnukseen, mutta mallinnusta oli tehty eri aikoina ja eri henkilöiden toimesta, vaihtelevalla tavalla ja tarkkuudella. Erilaisia arkkitehtuurikuvia oli olemassa ja joitain asioita oli kuvattu myös muualle kuin käytössä olevaan mallinnustyökaluun.

Tällainen tilanne on asiakaskunnassamme melko yleinen. Jos jokin mallinnustyökalu on jo käytössä, sitä saatetaan käyttää lähinnä irrallisten kaavioiden piirustustyökaluna. Systemaattista, tietyn sovitun mallin mukaista ja ehjän kokonaisuuden muodostavaa arkkitehtuurimallinnusta näkee harvemmin. Tätä lähdimme kyseisessä casessa kehittämään.

Usein ajatellaan, että systemaattisen mallinnuksen kehittäminen on kallista, hankalaa ja aikaa vievää työtä, jonka hyödyt jäävät vähäisiksi verrattuna kustannuksiin. Tässä työssä jätimme yleiset ennakkoluulot huomiotta. Otimme kunnianhimoisen lähestymistavan: annoimme yhdelle konsultille eli minulle 15 htp aikaa kehittää yhdessä yhden asiakkaan oman osaavan henkilön kanssa toimiva ja asiakkaan oman henkilöstön jatkossa itse ylläpitämä mallinnuksen perusrakenne niin, että sitä voitiin välittömästi alkaa hyödyntämään. Koska mikään osapuoli ei pystynyt keskittymään pelkästään tähän työhön, kalenteriaikaa työlle annettiin 2-3 kk.

Alkuperäinen tavoite oli kehittää nimenomaan arkkitehtuurin mallinnustapa eikä niinkään tuottaa sisältöä malliin. Suunnitelma oli selkeä. Ensin käydään läpi nykytila ja selkeytetään tavoitetila. Tästä työstä tuloksena on joukko kehitystarpeita, jotka toimivat lähtökohtana iteratiiviselle, itsenäisen työn ja työpajojen avulla laadittavalle uudelle mallinnustavalle. Viimeistelyn ja dokumentoinnin jälkeen asiakkaan käyttöön luovutetaan työn lopputulos: ohje siitä, miten mallinnusta jatkossa kannattaa tehdä.

Automaatiosta avaintekijä mallin sisällön luomiseen

Työtä tehdessä työn sisältö kuitenkin lähti elämään. Näinhän usein käy, sillä vasta työtä tehdessä selviää tarkemmin se, mikä on asiakkaalle hyödyllisintä ja mihin kannattaa keskittyä. Tässä tapauksessa alkuperäinen tavoite eli mallinnustavan kehittäminen, oli toki tarpeellinen, mutta asiaa haluttiin viedä vieläkin konkreettisemmaksi. Malliin luotiin uuden rakenteen mukaista sisältöä sekä kehitettiin mallinnustyökaluun tarvittavat menetelmät, joiden avulla sisältöä voi tarkastella.

Automaatiosta tuli avaintekijä mallin sisällön ja sen esittämistavan luomisessa. Asiakkaalla oli olemassa valmista aineistoa eri työkaluissa: mallinnustyökalussa, Excel-taulukoissa jne. Sen sijaan, että olisi otettu muutama esimerkkitapaus vanhoista lähteistä ja luotu näitä vastaava sisältö malliin käsipelillä, rakennettiin tarvittavat skriptit aineistojen massakäsittelyyn: uuteen rakenteeseen muuntamiseen, malliin tuomiseen, aineistojen sisältämien elementtien keskinäiseen linkittämiseen sekä myös tarvittavien kaavioiden luontiin. Näin saatiin sekä materiaalia mallin rakenteen toimivuuden todistamiseen että myös todellisuutta vastaava lähtötilanne malliin.

Mallinnustavan käytön ja jatkokehittämisen osaaminen siirrettiin asiakkaalle

1) Alkuperäisen suunnitelman mukainen mallin rakenne suunniteltiin ja kuvattiin.
2) Malliin tuotiin pohjaksi uuden mallinnustavan mukaiseksi muunnettua sisältöä.
3) Mallinnustyökaluun rakennettiin automaation avulla päivitettäviä kaavioita.

Vaikka työn laajuus kasvoikin, arvioitu työmäärä piti kutinsa. Tilannetta helpotti se, että mallinnustavan pohjaksi valittiin kummallekin osapuolelle entuudestaan tuttu ja maailmalla paljon käytetty ArchiMate-mallinnusnotaatio. Mallinnustyökaluna asiakas käyttää Sparx Systems:n Enterprise Architect -työkalua, joka tukee hyvin useamman henkilön yhtäaikaista käyttöä ja johon on helppo rakentaa skriptejä mallin automaattiseen käsittelyyn.

Omien sanojensa mukaan asiakas oli tehtyyn työhön hyvin tyytyväinen. Lopputulokset suhteessa kustannuksiin todettiin hyviksi. Työn lopputulosten hyödyntämiseen ja jatkokehittämiseen tarvittava osaaminen siirrettiin työn aikana asiakkaan omalle henkilöstölle, joten ulkopuolisen konsultin käyttö ei jatkossa ole välttämätöntä. Toki autamme, jos tulevaisuudessa siihen tulee tarvetta.

Markku Ryynänen

Markku on erityisesti finanssisektorilla toiminut EA- ja ratkaisuarkkitehti, joka on tottunut toimimaan yhteistyössä sekä asiakkaan liiketoiminnan että IT:n edustajien kanssa. Markku työskentelee mielellään kokonaisarkkitehtuurien ja liiketoimintaprosessien parissa edistämässä IT:n keinoin liiketoiminnan tavoitteita.

LinkedIn

Reflector on ICT-talo, jonka ykköstehtävä on auttaa asiakkaitamme liiketoiminnan isoissa ja pienissä muutoshankkeissa. Ketterästi ja riippumattomasti.

Jaa artikkeli

Voisit pitää myös näistä:

Vaatimusmäärittely

Onko vaatimusmäärittelylle paikkaa SAFe-junassa?

Joskus IT-ammattilaisten kahviautomaattikeskusteluja kuunnellessa syntyy vaikutelma, että ketteryys, Scrum esimerkkinä, kadottaa tarpeen perinteiseen järjestelmäkehitykseen kuuluvalle vaatimusmäärittelylle ja kattavalle toiminnalliselle määrittelylle. Kun keskusteluun tuodaan

Lue lisää
Kokonaisarkkitehtuuri Reflector

Ota yhteyttä, mietitään yhdessä juuri teille parhaat ratkaisut

Täytä tiedot ja siirry lataamaan tutkimus

Kokonaisarkkitehtuuri Reflector

Get in touch!