Hyvää arkkitehtuuria tarvitaan

Tarkoitukseni tässä blogissa on kertoa arkkitehtuurista ja arkkitehtuurityöstä. En käsittele arkkitehtuurityön hallinnointia, vaatimusten hallintaa tai projektien hallintaa. Ne ovat tärkeitä  asioita, mutta niistä kertokoon joku muu. Keskityn nyt siihen, mitä hyvään arkkitehtuuriin kuuluu ja miten hyvää arkkitehtuuria tehdään. Kirjoitukseni perustuu siihen oppiin, jonka olen  saanut useista arkkitehtuurihankkeista toimiessani itseäni kokeneempien ja viisaampien arkkitehtien kanssa. Mainitsen heistä nimeltä kaksi, jotta kunnia menee oikeaan osoitteeseen: Kalevi Kontinen ja Tapio Ypyä. Mahdollisen kritiikin tästä kirjoituksesta otan kyllä täysin omalle kontolleni.

Arkkitehtuurilla tarkoitan tässä yhteydessä tietojärjestelmiin ja prosesseihin liittyvää arkkitehtuuria, jonka avulla muutetaan yrityksen tai jonkin muun yhteisön todellisuutta halutunlaiseksi. Kokemusteni mukaan sellaisilla muutoshankkeilla on suurempi todennäköisyys onnistua, joissa arkkitehtuurityö on tehty kunnolla. Ja vastaavasti epäonnistumisien takana usein on ammattimaisen jäsennyksen puute. Suosittelen, että luet tämän blogin ennenkuin alat suuremmassa määrin investoida uusiin tietojärjestelmiin – olipa sitten kysymys valtakunnallisesta potilastietojärjestelmästä, kansallisesta palveluväylästä tai ehkä vähän pienemmän mittakaavan hankkeesta yrityksessäsi.

Arkkitehtuuri syntyy mallintamalla

Arkkitehtuurityössä on kysymys todellisuuden mallintamisesta.  Esko Valtaoja aloittaa kirjansa ”Kaiken Käsikirja” toteamuksella ”On ihan mahdollista, että todellisuus on olemassa”. Tämä on viisaasti sanottu, koska kukaan ei toistaiseksi ole pystynyt todistamaan todellisuuden olemassaoloa. Lähden tässä kirjoituksessani kuitenkin olettamuksesta, että on olemassa sellainen käsite kuin todellisuus ja voin jatkaa tarinaani. Asian tosin tekee vaikeammaksi se, että arkkitehdille ei suinkaan riitä mallintaa todellisuutta sellaisena kuin se on nyt, vaan tarkoitus on kuvata todellisuutta sellaisena kuin sen halutaan olevan tulevaisuudessa. Arkkitehtuuria tarvitaan juuri tämän muutoksen toteuttamiseksi. Lähtökohdat arkkitehtuurityölle eli muutokselle asetetut tavoitteet ovat malleja nekin, joten voidaan perustellusti sanoa, että kysymys arkkitehtuurityössä on muunnoksesta, jolla liiketoimintaa kuvaavat mallit käännetään prosessiarkkitehtuuriksi, informaatiomalleiksi, sovellusarkkitehtuuriksi ja lopulta teknisiksi kuvauksiksi ja toimintaohjeiksi muutoksen toteuttamiseksi. Tärkeää on joka tapauksessa huomata, että malli on eri asia kuin todellisuus. Mallia ei pidä sortua kuvittelemaan todellisuudeksi.

On jokseenkin itsestään selvää – joskin tämäkin totuus joskus unohtuu, että arkkitehdin tulisi tuntea se todellisuus, jota hän on mallintamassa. On myös tärkeää tuntea ja määritellä näkökulmat ja reunaehdot arkkitehtuurityölle. Arkkitehtuurin tarkoituksena ei ole kuvata valittua todellisuutta kaikista näkökulmista, vaan ainoastaan niistä, jotka ovat tärkeitä tavoitellun muutoksen toteuttamisessa. Yksi määritelmä arkkitehtuurille onkin, että ”arkkitehtuuri tarkoittaa sitä 20 %:a asioista, joilla on todellista merkitystä”. Tämä on hyvä määritelmä. Täytyy vain löytää ne 20%. Arkkitehtuurityölle on siis aina tarpeen määritellä rajaus (scope). Kun rajaus on määritelty, arkkitehdin pitäisi pystyä kattamaan tämä ongelma-alue mahdollisimman täydellisesti. Arkkitehtuuriin ei saisi jäädä rajauksen sisälle mustia aukkoja. Tiukka rajaus tuottaa paremman lopputuloksen kuin kovin laaja tai varsinkin löysä rajaus.

Liiketoimintalähtöinen arkkitehtuuri

Liiketoimintalähtöisen arkkitehtuurin rooli on varsin yksinkertainen: Sen tulee jäsentää ja muuntaa liiketoimintatarve konkreettisiksi arkkitehtuurimalleiksi, joilla voidaan ohjata yhtä tai useampaa muutoshanketta. Olen esittänyt tämän idean alla olevassa kuvassa.

Jotta arkkitehti pystyy tämän konversion tekemään, hänen on syvällisesti ymmärrettävä, mitä muutosta liiketoiminnassa tavoitellaan sekä millaisia reunaehtoja ja tosiasioiden tuomia rajoituksia tavoitteisiin liittyy. Arkkitehdin on pystyttävä tunnistamaan arkkitehtuurin kannalta kriittiset asiat. Kysymys ei siis ole välttämättä tekijöistä, jotka vaativat toteutusvaiheessa eniten töitä, vaan tekijöistä, jotka työmäärältään saattavat olla pieniäkin, mutta voivat tunnistamattomina tuhota koko hankkeen.

Arkkitehtuurityö on varsinkin ongelman ja tavoitteiden ymmärtämisvaiheessa hyvin intensiivistä ja vuorovaikutteista yhteistyötä liiketoiminnasta vastaavien ja liiketoiminnassa mukana olevien kanssa. On ehdottoman tärkeää, että kommunikointikanavat ovat suorat ilman välikäsiä. Usein käy lisäksi niin, että arkkitehtuurityö myös selventää ja konkretisoi alkuperäisiä liiketoimintatarpeita, mikä on kaikille eduksi. Suositukseni on, että kannattaa valjastaa muutama pätevä arkkitehti jäsentämään liiketoimintaongelmaa tai muutostarvetta välittömästi kun tällainen tarve nousee esille. Sen jälkeen kun arkkitehdit ovat analysoineet liiketoimintamuutoksen vaikutukset prosesseihin, tietojärjestelmiin ja jopa organisaaatioon, on huomattavan paljon helpompi käynnistää hanke tai hankkeita muutosta toteuttamaan. Arkkitehtuurityön käynnistäminen on hallinnollisesti kevyt operaatio ja koko työ voidaan useimmiten vallan hyvin hoitaa linja-organisaation ohjauksessa. Ei siis ole mitään tarvetta heti lähteä pystyttämään isoa projektia. Missään nimessä ei pidä lähteä ratkaisemaan arkkitehtoonista pulmaa projektihallinnan keinoin, vaikka sellainen lähestymistapa saattaa luoda illuusion siitä, että asiat ovat hallinnassa.

Arkkitehtuurityön alkuvaiheessa liiketoimintatarpeen ymmärryksen on siis siirryttävä tarpeen omistajalta arkkitehdille. Muuten arkkitehti ei pysty kääntämään ongelmaa arkkitehtuuriratkaisuksi. Kuinka tämä ymmärryksen siirto tapahtuu? Kaikki lailliset keinot ovat sallittuja. Keskustelu on ihan hyvä työväline, piirtäminen vielä parempi, tarinat voivat auttaa paljon. Lopulta kysymys on todellisuuden mallintamisesta – tässä tapauksessa liiketoimintatarpeen omistajan näkökulmasta. Moniriviset vaatimustaulukot kelpaavat tukimateriaaliksi, mutta ainoaksi tarvemäärittelyksi ne ovat huonoja – varsinkin, jos ne on tehty periaatteella ”mitä enemmän vaatimuksia ja mitä yksityiskohtaisempia ne ovat, sen parempi”. Näillä vaatimuslistoilla on taipumus kuvata listan kirjoittajan ratkaisuja johonkin ongelmaan, joka ongelma jää kertomatta. Arkkitehtuurityö kannattaa jättää arkkitehdeille.

Arkkitehtuurin osa-alueet

Oheisessa kuvassa olen esittänyt arkkitehtuurimallit, jotka ovat osoittautuneet hyödyllisiksi arkkitehtuurin kuvaamisessa.

Prosessimalli, informaatiomalli, sovellusarkkitehtuuri sekä tekninen arkkitehtuuri ovat kukin omia kokonaisuuksiaan. Ne kuvaavat todellisuutta omista lähtökohdistaan. Prosesseilla kuvataan tekemisen rakenteita, informaatiomalleilla kuvataan käsitteitä ja niiden välisiä suhteita, sovellusarkkitehtuuri kertoo järjestelmien rooleista ja keskinäisistä vuorovaikutuksista erilaisten käyttötapausten toteuttamisessa. Tekninen arkkitehtuuri sitoo loogisen sovellusarkkitehtuurin ja loogisen informaatiomallin teknologiaan eli niihin palvelimiin ja tietokantoihin, jotka pyörivät joko omissa tai vaikkapa pilvipalvelujen tarjoajien konehuoneissa.

Näille malleille on olemassa omat kuvauskielensä, joita arkkitehdin on syytä käyttää arkkitehtuurin kuvaamisessa. Uuden kielen kehittäminen ei ole helppoa, joten kannattaa pitäytyä niissä kielissä, jotka on aikojen saatossa kehitetty mallien kuvaamiseksi ja joita oletusarvoisesti moni muukin voi ymmärtää. Mutta kieli on kuitenkin vain kieli. Jos osaat hyvin englannin kieltä, ei se tarkoita, että kaikki mitä englanniksi ilmaiset on nerokasta. Mutta yhteinen kieli antaa joka tapauksessa mahdollisuuden kommunikoida omia ajatuksia muille – tässä tapauksessa englantia ymmärtäville. Formaaleilla kuvauskielillä on lisäksi se etu, että ne helpommin paljastavat oman ajattelun virheet. PowerPointeilla on paljon helpompi huijata sekä itseään että muita. Mutta arkkitehtuurin tarkoituksena ei ole huijata vaan kuvata todellisuutta.

Mistä malleista aloittaa arkkitehtuurityö? Tähän ei ole aivan yksioikoista vastausta. Se on kuitenkin selvää, että teknistä arkkitehtuuria kannattaa miettiä vasta sitten kun käsitteelliset ja loogiset mallit alkavat olla paikoillaan. Samoin sovellusarkkitehtuuriin ei pidä tarttua ensimmäisenä, vaikka nämä arkkitehtuurit usein eniten kiinnostavatkin varsinkin tietotekniikkaihmisiä. Suosittelen siis, että arkkitehtuurin mallintaminen kannattaa aloittaa prosesseista ja tietomalleista yhtäaikaisesti ja iteratiivisesti. Muutoshankkeissa on usein kysymys siitä, että nimenomaan liiketoimintaprosesseja halutaan muuttaa, jolloin ne on syytä kuvata. Mutta liiketoimintaprosessin kuvaaminen ei onnistu elleivät käsitteet ole selvät ja silloin luiskahdetaan välittömästi tietomallinnuksen puolelle. Alec Sharp on kirjoittanut paljon liiketoimintaprosesseista mm. kolumnisarjassaan ”A Practitioner’s Perspective”. Yksi hänen viesteistään on, että yhteiset käsitteet täytyy määritellä ja sopia heti hankkeen alkumetreillä. Kannattaa tutustua Sharpin teräviin kirjoituksiin.

Arkkitehtuurityön vaiheet

Arkkitehtuurin tekeminen voidaan jakaa seuraaviin vaiheisiin:

1. Ongelman löytäminen
2. Faktojen löytäminen
3. Ratkaisun löytäminen
4. Toimenpiteiden löytäminen
5. Hyväksynnän löytäminen ja
6. Jatkuvuuden löytäminen

On varmasti mahdollista hahmottaa arkkitehtuurin tekeminen jollakin toisella tavalla, mutta edellä kuvattu vaiheistus on joka tapauksessa osoittautunut hyödylliseksi ja käyttökelpoiseksi, kun lisäksi muistaa, että tosielämässä vaiheet ovat iteratiivisia ja ainakin osittain päällekkäisiä.

Ongelman löytäminen ja faktojen löytäminen ovat erityisen tärkeitä. Olen edellä jo kertonut siitä kuinka arkkitehdin tulee ymmärtää liiketoimintaongelma ja siihen liittyvät reunaehdot. Tästä on kysymys. Arkkitehdin ei pidä lähteä ratkomaan väärää ongelmaa väärien olettamusten varassa. Näissä vaiheissa tarvitaan tiivistä kommunikointia liiketoimintatarpeen omistajan kanssa sekä paljon jalkatyötä faktojen selvittämiseksi. Tiedontulva on usein sen verran suurta, että arkkitehti voi hyvinkin tuntea konsulttiahdistusta, mutta tästä ei pidä huolestua. Se kuuluu asiaan. Päinvastoin, jos alkuvaiheessa kaikki tuntuu kovin suoraviivaiselta, olet todennäköisesti unohtanut jotain ja silloin kannattaa hetkeksi huolestua. Valkotaulu ja tussit ovat hyödyllisiä työvälineitä tässä vaiheessa, samoin kamera kuvien tallentamiseen. Käyttötapauksia kannattaa kirjoittaa ja ei-toiminnalliset vaatimukset dokumentoida myös.

Vähitellen alat siirtyä ratkaisun löytämiseen. Tämä vaihe tarkoittaa vapaata ideointia, innovointia ja formaalimpaa mallintamista. Edelleen valkotaulu on kova työväline. Miellekarttoja (mind map) kannattaa hyödyntää sekä mallintamisvälineitä varsinkin siinä vaiheessa, kun ajatuksesi alkavat konkretisoitua. Hyvä työkalu omien ajatusten vapauttamiseen ja ratkaisuvaihtoehtojen pohtimiseen on ns. ”äärimmäisyyksiin venyttelyn” periaate. Älä heti etsi kultaista keskitietä, vaan astu rohkeasti äärimmäisyydestä toiseen, koska sellainen ajattelu saattaa paljastaa jotain oleellista optimointitehtävästä.

Kun arkkitehtuurimalli alkaa olla valmiiina, sitä tulisi verrata olemassa oleviin prosesseihin, informaatiomalleihin ja järjestelmiin sekä analysoida tarvittavat muutokset toteutushankkeiden lähtökohdaksi. Tätä vaihetta kutsutaan toimenpiteiden löytämiseksi viitekehyksessämme.

Arkkitehtuurissa on siis kysymys mallintamisesta. Arkkitehdin ajattelutyön pitäisi kulminoitua näihin malleihin. Mutta harvoin mallit ovat itsestäänselviä sellaisenaan edes muille arkkitehdeille. Sen vuoksi mallit tarvitsevat tuekseen selittävää tekstiä eli arkkitehtuurista on tarpeen kirjoittaa dokumentti. Korostan kuitenkin, että oleellista on malli. Kun se on valmis, arkkitehtuuridokumentin kirjoittaminen on suoraviivaista ja käy nopeasti. Ja tietenkin on tarpeen tehdä erikseen esitysmateriaali. Sitä tarvitaan arkkitehtuurityön seuraavissa vaiheissa eli hyväksynnän ja jatkuvuuden löytämisessä.

Liiketoimintavastuulliset ovat olleet mukana arkkitehtuurityössä alusta alkaen ja toivon mukaan hyvä kommunikointi on jatkunut koko mallinnustyön ajan. Keskeisten arkkitehtuurilöydösten ja toimenpidesuositusten ei pitäisi tulla heille yllätyksenä. Hyväksynnän saaminen arkkitehtuurityölle pitäisi siis olla lähes pelkkä muodollisuus, mutta tarpeellinen siitä huolimatta.

Jatkuvuuden löytäminen on viimeinen vaihe arkkitehtuuriprosessissa. Siinä on kysymys tietämyksen ja kokemuksen siirtämisestä toteutushankkeista vastaaville. Jos arkkitehtuurityö liittyy jo käynnistettyyn toteutusprojektiin, on tietenkin luonnollista, että ainakin projektin pääsuunnitelija on mukana arkkitehtuurityössä, jolloin hän pystyy jatkamaan yksityiskohtaista suunnittelua ilman tietokatkoksia. Mutta hyvä arkkitehtuuri palvelee myös hankkeita, jotka käynnistyvät vasta joskus myöhemmin tulevaisuudessa. Arkkitehtuurin pääperiaatteet tulisi sen vuoksi pystyä kommunikoimaan laajemmin sekä arkkitehtiyhteisöön että liiketoiminnasta vastaavien keskuuteen. Hyvästä esitysmateriaalista on silloin apua, mutta älä koskaan luota pelkästään materiaaliin. Henkilökohtaista kanssakäymistä tarvitaan, jos haluat viestisi kunnolla perille. Mutta kannattaa miettiä myös kommunikoinnin ajoitusta. Ihmiset ovat motivoituneita syvällisempään opastukseen, jos aiheeseen liittyvä ongelma on ajankohtainen. Muulloin yleisluonteinen esitys arkkitehtuurista on riittävä.

Mallintaminen on arkkitehtuurityön ydintä. Ensiksi liiketoimintatarpeista johdetaan käsitteelliset ja loogiset mallit. Sen jälkeen loogiset mallit muunnetaan fyysisiksi. Nämä prosessit eivät ole deterministisiä, vaan vaativat luovuutta ja jopa innovaatioita. Jos arkkitehdit onnistuvat näissä muunnoksissa, on olemassa hyvät edellytykset, että tietojärjestelmät ja prosessimuutokset toteutuvat jotakuinkin suoraviivaisesti vähemmin ongelmin ja lopulta vastaavat alkuperäiseen liiketoimintatarpeeseen odotusten mukaisesti.

Heikki Melama

Kirjoittajalla on monipuolista kokemusta yrityselämän eri osa-alueilta myynnin ja markkinoinnin, tuotekehityksen, tuotannon ja ICT:n parissa. Hänen kiinnostuksensa on viime vuosina kohdistunut erityisesti arkkitehtuurityöhön ja arkkitehtuurin merkitykseen yrityksen johtamisessa ja muutoshankkeissa.

PS. Englanninkielinen versio blogikirjoituksesta löytyy täältä.

Lue myös Heikin kirjoitus ”Arkkitehtuuri ja digitalisaatio”

Arkkitehtuurin osaajayritykset

Arkkitehtuuritoteutukset

Arkkitehtuuriin liittyvät julkaisut

ite wikin yrityshaku

ite wikin referenssihaku

ite wikin julkaisuhaku

Kirjoitus Digitalisaation roolista strategiatyössä

Liiketoiminnan Digitalisoinnin opas