Kokonaisarkkitehtuurista ohjelmistoarkkitehtuuriin

Tuotteita vain tilauksesta. Just in time.

Tietohallinnoissa on ollut viime aikoina tapana selvittää ja kehittää kokonaisarkkitehtuuria. Valtiolla tätä vaatii  tietohallintolaki. Selvityksiin on yleensä tapana käyttää TOGAF-menetelmää tai sen suomalaista johdannaista, JHS-179-suositusta. Tulokset ovat olleet vaihtelevia. Joskus selvittelyn tulos on järjestelmäluettelo, joskus enemmän.

TOGAF-tyyppisissä selvityksissä on yksi perustavanlaatuinen vika. Ne eivät lisää ymmärrystä nopeasti eivätkä millään tavalla helpota siirtymää ohjelmistoarkkitehtuurin suunnitteluun, kun on tarpeen toteuttaa uusi ohjelmisto kokonaisuuden osaksi.  Ohjelmistoarkkitehtuurin suunnittelussa on olennaista ymmärtää kokonaisuus helposti ja riittävän yksiselitteisesti.

Tämän kirjoituksen tarkoituksena on hahmotella visuaalinen ja helppokäyttöinen menetelmä ohjelmistoarkkitehtuurityön aloittamiseksi kokonaisarkkitehtuurista lähtien. Aivan aluksi on kuitenkin ymmärrettävä, miksi joskus on tarpeen tehdä tai teettää uusi ohjelmisto.

Miksi uusi ohjelmisto?

Ohjelmisto – tai sovellus – on aina keino täyttää jokin nykyisten tai tulevien asiakkaiden tarve. Ohjelmisto luo asiakkaille arvoa. Asiakkaat ovat valmiit maksamaan arvosta, mikäli heidän ohjelmistosta saamansa hyöty on suurempi kuin ohjelmiston käytöstä syntyvät kustannukset. Kun asiakkaat ovat valmiita maksamaan, saa ohjelmiston tekijä ja omistaja tuloja. Julkishallinnossa arvo voi olla esimerkiksi parempi palvelu tai kulujen väheneminen, joskus jopa kunnan tai valtion tulojen kasvu.

Arvon tuottaminen asiakkaille on siis olennaista. Se onnistuu vain, jos tuntee asiakkaan ja hänen tarpeensa sekä ympäristön, jonka osaksi uusi ohjelmisto on suunniteltu. Jos ei tunne asiakkaan tarpeita, ei niitä voi täyttää eikä asiakas suostu maksamaan. Jos ei tunne ympäristöä, ohjelmiston toteuttaminen on hankalaa ja kallista. Ohjelmistosta voi tulla huono tai liian kallis.

Asiakkaiden tarpeiden löytämiseen ja ymmärtämiseen on olemassa monia tehokkaista menetelmiä: käyttäjäkertomukset (user stories), prototyypit ja vaikkapa lead user -menetelmä. Näistä ja niiden suhteista ohjelmistoarkkitehtuuriin kirjoitan myöhemmässä artikkelissa.

Kun asiakkaan tarpeet ovat tiedossa, seuraavaksi on selvitettävä ja ymmärrettävä, millaiseen liiketoiminnalliseen ja tekniseen ympäristöön uusi ohjelmisto on liittymässä. On ymmärrettävä mitä yritys tekee, miten se tehtävänsä tekee, keiden kanssa se tekee yhteistyötä ja miten. Lisäksi on ymmärrettävä mitä reunaehtoja jo olemassa olevat järjestelmät yhdessä organisaation osaamisen ja perinteiden kanssa asettavat uudelle ohjelmistolle.

Tätä työtä – ympäristöymmärryksen luomista – voisi vaikka kutsua ohjelmistoarkkitehtuurin ylätasoksi tai perustaksi. Työn tuloksen on oltava hyvin selkeä ja kaikkien osapuolten – myös muun kuin ohjelmistoteknisen koulutuksen saaneiden – ymmärrettävissä.

Yritys muuntaa raaka-aineet tuotteiksi

Uusi ohjelmisto on osa yrityksen tietojärjestelmäkokonaisuutta, jonka tarkoituksena on tuottaa asiakkaille arvoa. Siksi ymmärrystä luotaessa on lähdettävä liikkeelle yrityksen toiminnasta. Kullakin yrityksellä – tai isomman yrityksen osalla – on jokin pääasiallinen tehtävä. Jotkut yritykset tuottavat fyysisiä tuotteita, jotkut palveluita, jotkut informaatiota. Ylätasolla yritystä voi siis tarkastella mustana laatikkona, joka muokkaa syötteistä (raaka-aineista) valmiita tuotteita. Yksinkertaistettuna kuvana siis seuraavasti:

Ohjelmistoarkkitehtuuri alkaa tästä

Yritys siis saa syötteitä toimittajilta, tekee syötteille jonkin muunnoksen tai yhdistelyn ja toimittaa tuloksen asiakkaille. Tuotteet siis virtaavat yrityksen läpi kuvassa vasemmalta oikealle.

Tilaukset sen sijaan virtaavat oikealta vasemmalle. Asiakkaat tekevät tilauksia. Niiden perusteella yritys itse tekee tilauksia omille toimittajilleen.

Tuotteita vain tilauksesta. Just in time.
Tuotteita vain tilauksesta. Just in time.

Raha yhdistää osapuolet

Tuotevirran ja tilausvirran lisäksi yrityksen läpi virtaa muutakin. Erityisesti yrityksen läpi virtaa rahaa. Raha jakautuu yrityksen sisällä useaan eri osaan. Näiden mallintamiseksi kuvaan on lisättävä kaksi osapuolta: henkilöstö ja johto sekä valtio. Henkilöstö operoi yritystä, laatii suunnitelmat, valvoo tuotantoa jne. Vastineeksi henkilöstö saa palkkaa. Johto – johon kuuluvaksi ajattelemme myös omistajat –  ja valtio haluavat yrityksestä tietoa ja rahaa, omistajat osinkonsa ja valtio veronsa. Johto haluaa lisäksi erilaista raportointia, jotta johto voisi johtaa yritystä kulloisenkin tilanteen vaatimalla tavalla.

Kuvan muodossa tilanne on nyt tällainen:

 

Raha yhdistää osapuolet
Raha yhdistää osapuolet

Tätä kaaviota käyttäen yrityksen toimintaan on helppoa pureutua yhä syvemmälle. Kaavion avulla on suoraviivaista keskustella eri järjestelmistä ja niiden välisistä tietovirroista, tiedon omistajuudesta sekä järjestelmien muodostamista osakokonaisuuksista.

Tarkastelkaamme kaaviota käyttäen ja täydentäen kuvitteellista konepajayritystä. Yritys tuottaa fyysisiä tuotteita tehtaassaan. Yrityksen tuotantoa – niin valmistusta, tilauksia kuin toimituksia – hallitsee jokin ERP-järjestelmä. ERP saa tuotanto-ohjeet CAD-järjestelmältä ja tilaukset asiakkaan tilausjärjestelmältä.

Toimittajien käytössä on järjestelmä, josta he voivat nähdä tilaukset. Henkilöstön käytössä on työajanseuranta, palkkajärjestelmä ja koko joukko tuotannonsuunnitteluun liittyviä järjestelmiä.

Kuvana tämän voi esittää seuraavalla tavalla:

Ohjelmistojen lisääminen kuvaan lisää ymmärrystä
Ohjelmistojen lisääminen kuvaan lisää ymmärrystä

Miten jatkaa eteenpäin?

Kuvaan voi vähitellen lisätä yhä enemmän järjestelmiä. Kuvan avulla on kenen tahansa mahdollista ymmärtää, mihin kohtaan uusi järjestelmä on tulossa, millaisia tietovirtoja järjestelmän läpi on syytä kulkea ja mihin muuhun uusi järjestelmä vaikuttaa. Mitä keskemmällä kuvaa järjestelmä on, sitä laajempi sen vaikutus yleensä on.

On huomattava, että mikään kuva ei lisää ymmärrystä yhtä paljon kuin kuvan rakentaminen yhdessä keskustellen. Siksi kuva itsenään ei ole arvokas, ainoastaan kuvan kautta keskustelu on. Dokumentaatio ilman yhteistä työtä ja dialogia on arvotonta.

———

*Julkishallinnossa ja suuremmissa yrityksissä uudet järjestelmät voivat jäädä tuotantoon vaikka ne eivät tuottaisikaan asiakasarvoa.

(Tämä on ensimmäinen osa ohjelmistoarkkitehtuuria käsittelevää artikkelisarjaa. Seuraavissa artikkeleissa käsittelen muun muassa käyttöliittymien merkitystä ohjelmistoarkkitehtuuria suunniteltaessa ja ohjelmistoarkkitehtuurin suunnitteluun Codentossa kehitettyä “Lean SW architecture canvas” -työkalua).

Tämän artikkelin on kirjoittanut Matti Kinnunen ja sitä ovat sittemmin muokanneet muut Codenton työntekijät.

Vastaa

Sähköpostiosoitettasi ei julkaista. Pakolliset kentät on merkitty *