Zen ja kokonaisarkkitehtuurin mallintaminen

Katso myös:

• Liiketoiminnan kehittäminen ja kerrosnäkymä
• Kokonaisarkkitehtuuri ja liiketoiminnan kehittäminen
• ArchiMate käsikirja
• ArchiMate Cookbook

Johdanto

Ymmärtääksemme miksi kokonaisarkkitehtuurin (Enterprise Architecture, EA) mallintaminen on hyödyllistä, meidän tulee ymmärtää mitä on kokonaisarkkitehtuuri, ja miksi se on merkityksellinen. Kokonaisarkkitehtuuri, mitä se siis on? Tai paremminkin, mikä se on?

Kokonaisarkkitehtuuri ilmentää organisaatiota. Organisaatiolla on kokonaisarkkitehtuuri. Kokonaisarkkitehtuurissa on kyse organisaation toiminnasta ja rakenteesta kokonaisuutena, tämän kokonaisuuden ymmärtämisestä, ja sen monimutkaisuuden hallinnasta. Eli organisaatiosta kyse, ei mistään erillisestä asiasta.

Kun kokonaisuus ymmärretään, sitä voidaan kehittää. Kun tunnetaan mistä osista kokonaisuus muodostuu ja miten se toimii, sitä voidaan muuttaa, siihen voidaan lisätä osia, tai osia voidaan korvata tai poistaa, tai toimintaa voidaan tehostaa. Organisaation toiminta ja rakenne voidaan mallintaa. Tämä malli on kokonaisarkkitehtuuri. Kokonaisarkkitehtuurimalli on organisaation ns. digitaalisen kaksosen (DTO) runko. (DTO = organisaation digitaalinen kopio).

Kuvausvälineeseen mallinnettu kokonaisarkkitehtuuri on organisaation toiminnallisten ja rakenteellisten osien hallintajärjestelmä. Ne asiat, joita ei ole mallinnettu kuvausvälineeseen, ovat tämän ns. ‘kirjanpidon’ ulkopuolella, ja niiden riippuvuussuhteet, vaikutukset ja toiminnallisuudet ovat harmaata aluetta, jota ei tunneta.

Määritelmä: Kokonaisarkkitehtuuri on yhtenäinen periaatteiden, menetelmien ja mallien kokonaisuus, jota käytetään kun suunnitellaan ja toteutetaan organisaation rakennetta, liiketoimintaprosesseja, tietojärjestelmiä ja infrastruktuuria, sekä näihin liittyviä muutoksia. (Enterprise Architecture at Work, 4th edit., Lankhorst et. al, 2017.)

Määritelmiä on useita, ja monissa näkyy vahva IT painotus. Nykyisin painopiste on kuitenkin siirtynyt enemmän liiketoiminnan puolelle. Tällöin ensisijainen huomio kohdistuu mm. asiakaskokemukseen, palveluihin, palvelujohtamiseen, organisaation strategisiin tavoitteisiin ja arvovirtoihin. Näistä muotoillaan liiketoimintamalleja, joista johdetaan operatiivisia toimintamalleja. Eli nykyisin organisaation toiminnan kehittämisen lähtökohta on asiakas- ja liiketoimintalähtöisyys, joille alisteisia ovat kaikki muu.

Tässä kirjoituksessa keskitytään yksittäisen organisaation toiminnan ja rakenteen, eli kokonaisarkkitehtuurin, tarkasteluun, ja pyritään tekemään se järkiperäisesti, järjestelmällisesti ja johdonmukaisesti, mallintamisen avulla. Samat mallintamisen periaatteet pätevät myös, kun kyseessä on mikä tahansa yksittäistä organisaatiota laajempi yhteenliittymä, jolla on yhteiset tavoitteet, kuten esimerkiksi ekosysteemi. Kokonaisarkkitehtuurin mallintaminen on systemaattinen ja formaali lähestymistapa tarkastella organisaation toimintaa ja rakennetta. Mallintamisessa pyritään siis mahdollisimman tarkkaan esitystapaan, joka perustuu määriteltyjen elementtien ja yhteystyyppien käyttämiseen. On huomattava, että mallintamisella voidaan päästää jopa täsmällisyyteen, mutta kokonaisarkkitehtuurin mallintamisessa tärkeintä on ns. riittävä tarkkuus. Eli tarkkuus, jota pidetään tarkoituksenmukaisena kulloinkin käsillä olevan kehittämiskohteen kannalta.

Kokonaisarkkitehtuurin avulla hallitaan organisaation muodostamaa kokonaisuutta. Mikä se organisaation muodostama kokonaisuus sitten on? Se on niin ilmeinen ja päivänselvä, että juuri siksi sitä kannattaa hieman avata. Tarkastellaanpa siis itse organisaatiota…

1. Organisaatio

1.1. Organisaation toiminta ja rakenne

Organisaatio on sosio-teknis-ekonominen kokonaisuus, joka muodostuu toiminnallisista ja rakenteellisista osista. Rakenteellisia osia ovat esimerkiksi liiketoimintayksiköt, ryhmät, tiimit ja henkilöstö; tietojärjestelmät; tilat ja laitteet. Toiminnallisia osia ovat esimerkiksi strategiat, liiketoimintamallit, liiketoiminnan palvelut ja -prosessit sekä tietojärjestelmien tarjoamat sovelluspalvelut. Alla olevassa kuvassa on esitetty keskeisimpiä organisaatioon liittyviä toiminnallisia ja rakenteellisia osia.

Organisaatiolla on tarina jota se toteuttaa: sillä on olemassaolon tarkoitus (missio), näkemys siitä mihin se aikoo pyrkiä (visio), sekä tavoitteet ja toimenpiteet sinne pääsemiseksi (strategia). Kun on selvillä miksi organisaatio on olemassa, määritellään miten se toteuttaa tätä tehtäväänsä. Organisaation johto laatii a) liiketoimintamallin (Business Model), joka määrittelee miten organisaatio luo arvoa asiakkailleen, sekä b) toimintamallin (Operating Model) ja tarvittavat kyvykkyydet, eli kuinka organisaatio toimii käytännössä. Näihin ylätason määrittelyihin liittyvät kaikki organisaation konkreettiset asiat, kuten esimerkiksi: asiakkaille tarjottavat liiketoiminnan palvelut, liiketoiminnan prosessit joilla em. palveluita tuotetaan, organisaatioyksiköt, ryhmät ja tiimit, jotka toimivat prosesseissa, sekä kaikki tietojärjestelmät ja niiden tarjoamat palvelut, jotka tukevat liiketoiminnan prosesseja, sekä teknologiat, fyysiset tilat, verkot ja laitteet, kuten myös ulkoiset sidosryhmät ja muutostarpeet ja -vaikutukset. Kokonaisarkkitehtuuri on tätä kaikkea, sillä se on organisaation toiminnan ja rakenteen jäsennys.

Jos organisaation toiminnan ja rakenteen ymmärtäminen, sen monimutkaisuuden hallinta ja sen liiketoiminnan kehittäminen on tärkeätä, silloin kokonaisarkkitehtuuri on tärkeätä.

Tämä kaikki voidaan mallintaa mallinnuselementeillä (kuva alla), jotka vastaavat kaikkia näitä organisaation toiminnallisia ja rakenteellisia osia.

Organisaatio on systeemi, joka voidaan pilkkoa toiminnallisiin ja rakenteellisiin osiin, sekä näiden välisiin yhteyksiin. Kokonaisarkkitehtuurilla tarkoitetaan tätä toimintaa ja rakennetta, ja näiden toiminnallisten ja rakenteellisten osien välisiä yhteyksiä. Termi “arkkitehtuuri” mielletään tyypillisesti rakenteisiin liittyväksi. Termi “kokonaisarkkitehtuuri” tarkastelee tätä organisaation toiminnallisten ja rakenteellisten osien, sekä niiden välisten suhteiden muodostamaa arkkitehtuuria kokonaisuutena: systeemien muodostamana systeeminä. Tämä kokonaisuus on usein varsin laaja ja monimutkainen. Kokonaisarkkitehtuuria hyödynnetäänkin juuri laajan kokonaisuuden monimutkaisuuden hallinnassa. Mallintaminen on systemaattinen ja formaali tapa kuvata tämä monimutkainen kokonaisuus niin, että kaikki organisaation toiminnalliset ja rakenteelliset osat, sekä niiden väliset yhteydet kuvataan tarkasti määritellyn notaation avulla.

Kun organisaation toiminnan ja rakenteen ymmärtäminen, sen monimutkaisuuden hallinta ja sen liiketoiminnan kehittäminen on tärkeätä, silloin kokonaisarkkitehtuuri on tärkeätä. Kun kokonaisarkkitehtuuri on tärkeätä, silloin sen mallintaminen on tärkeätä ja hyödyllistä. Kokonaisarkkitehtuurin mallintaminen on järkevää tehdä systemaattisesti ja ammattimaisesti, standardipohjaisen mallinnuskielen avulla, asianmukaisella mallinnusvälineellä.

1.2 Organisaation ja sen kokonaisarkkitehtuurin kehittäminen

Organisaation kokonaisarkkitehtuurin mallintaminen on käytännöllisintä aloittaa rajatuista kehittämiskohteista, kuten uusista palveluista tai palvelukokonaisuuksista. Niiden osalta mallinnetaan kokonaisvaltaisesti kaikkia edellä esiteltyjä toiminnallisia ja rakenteellisia osia, ja niiden välisiä yhteyksiä. Laajempien kohdealueiden, kuten organisaatioyksikköjen kokonaisuuksia voidaan alkaa mallintamaan kartoittamalla ensin niiden elementtejä, ja sitten kytkemällä niitä yhteen.

Kartoittamisella tarkoitetaan tässä yhteydessä elementtiryhmien keskeisten elementtien tunnistamista ja kokoamista mallinnusvälineeseen. Elementtejä voidaan usein myös tuoda mallinnusvälineeseen ulkoisistä lähteistä mallinnusvälineiden tarjoamien ominaisuuksien avulla. Tällaisia “elementtikarttoja” ovat esimerkiksi seuraavat: palvelukartta, prosessikartta, järjestelmäkartta, teknologiakartta. Kun elementit on kartoitettu, niitä voidaan kytkeä yhteen. Elementeistä ja niiden yhteyksistä voidaan muodostaa erilaisia “näkymiä”, aina tarpeen mukaan, sopivalla tarkkuustasolla ja riittävällä laajuudella. Näkymiä voidaan laatia erityisillä kaaviotyypeillä, kuten kerrosnäkymä ja vuorovaikutusnäkymä (näistä tarkemmin jäljempänä). Mallinnusvälineen erityispiirre verrattuna ns. piirustusvälineisiin on, että samoja elementtejä käytetään eri kaavioissa kautta linjan. Kun elementtiä muutetaan, se muuttuu kaikissa kaavioissa joissa se esiintyy.

Kehittämiskohteella tarkoitetaan tässä yhteydessä rajattua muutoksen kohteena olevaa kokonaisuutta. Kehittämiskohde voi olla eri laajuinen kohdealue, jonka kehittäminen halutaan ymmärtää kokonaisuutena. Tyypillisesti kehittämiskohde on jokin uusi palvelu, mutta se voi olla myös esimerkiksi kokonainen palvelualue (palveluiden joukko), liiketoiminta-alue tai -yksikkö kokonaisuudessaan, tai oragnisaation tai sen osa-alueen digistrategia tms. Oleellista on, että arkkitehtuurin mallintamisen keinoin kehittämiskohdetta voidaan tarkastella kokonaisvaltaisesti, jolloin huomioidaan kaikki liiketoiminnan kannalta merkitykselliset elementit.

Näihin em. asioiden kuvaamiseen on valmiit kaaviotyypit, joiden avulla mallintaminen tapahtuu. Keskeisiä kaaviotyyppejä on itse asiassa vain muutama, joten mallintaminen niiden avulla on selkeätä ja systemaattista, ja lopulta varsin helppoa toteuttaa käytännössä. Kaaviotyypeistä tarkemmin jäljempänä.

Kun organisaatio koostuu osista ja niiden välisistä suhteista, ja osien ja niiden välisten suhteiden kuvaaminen on mallintamisen tarkoitus, siksi organisaation toimintaa ja rakennetta on hyödyllistä tarkastella mallintamalla se.

2. Organisaation toiminnan ja rakenteen mallintaminen

2.1 Organisaation toiminnan ja rakenteen perusperiaate

Yksinkertaistettuna tyypillinen palveluorganisaatio toimii kokonaisarkkitehtuurin mallintamisen kannalta tarkasteltuna seuraavasti:

• Asiakkaille tarjotaan liiketoiminnan palveluita (ja tuotteita) – jotka palvelevat asiakkaita
• Liiketoiminnan palveluita tuotetaan prosesseilla – jotka toteuttavat palveluita
• Prosesseja tuetaan sovelluspalveluilla – jotka palvelevat liiketoiminnan prosesseja
• Prosesseihin osallistuu henkilöstöä
• Prosesseissa käytetään tietoja
• Sovelluspalveluita toteutetaan sovelluksilla – jotka toteuttavat sovelluspalveluita
• Sovellukset on toteutettu määrätyillä teknologioilla – jotka toteuttavat sovelluksia

Tästä on kysymys! Organisaatio toimii näin. Tämä kerrosmainen kaavio esittää organisaation toiminnallisten ja rakenteellisten osien luokat pinona, jotka on kytketty yhteen. Tämä on ns. kerroksellinen lähestymistapa, joka vastaa organisaatiota, ja joka on kokonaisarkkitehtuurin mallintamisen peruskaava. Mallintaminen perustuu näihin kerroksiin, ja näissä kerroksissa oleviin samankaltaisina toistuviin yksiköihin. Kerroksellisessa lähestymistavassa korostuu asiakaslähtöisyys ja palvelulähtöisyys, sekä näiden taustalla oleva liiketoimintalähtöisyys. Nämä ovat kaiken kehittämisen peruslähtökohdat organisaation toiminnan ja rakenteen kannalta.

HUOM! Organisaatio voi toimialasta riippuen tarjota asiakkailleen palveluita tai tuotteita, tai molempia. Sovellukset (eli järjestelmät) puolestaan tarjoavat palveluita toisilleen ja käyttäjilleen (rajapintojensa kautta).

2.2 Asiakaslähtöisyys + palvelulähtöisyys = liiketoimintalähtöisyys

“Asiakas, tai organisaation palveluiden käyttäjä, on oikeutus organisaation olemassaololle.
Asiakkaille tarjottavat palvelut (tai tuotteet) ovat syy, miksi organisaatio on olemassa.
Asiakas määrittelee, miten hyvin tai huonosti organisaatio kykenee tarjoamaan palveluita tai toimittamaan tuotteita. Organisaation toiminnan tehokkuus on yhdentekevää, jos se ei näy asiakkaalle esimerkiksi parempana laatuna, halvempina hintoina, nopeampana toimituksena tai paremman kokemuksen tai yhteisen hyvän muodossa.” [Järki töihin, Sami Paju, Tapani Riekki, Tuuma, 2019]

Kun avataan edellä kuvattua organisaation kerrosmaista yksinkertaistusta, voidaan elementit ryhmitellä toiminnallisiin ja rakenteellisiin (kuva alla). Samalla tunnistetaan muutama oleellinen elementti lisää. Toiminnallisia elementtejä ovat palvelut, sekä prosessit tai toiminnot. Rakenteellisia elementtejä ovat toimijat, rajapinnat, sovellukset ja teknologia-alustat. Informaatioelementtejä ovat käsitteet, tiedot (eli tietoelementit) ja artefaktit (eli ohjelmistotuotokset).

2.3 Toiminnan ja rakenteen perusyksikkö

Toiminnan ja rakenteen perusyksikkö (kuva alla) muodostuu sisäisestä- ja ulkoisesta-, sekä informaatio-osasta. Sisäinen osa koostuu rakenneosasta, sekä siihen liittyvästä toiminnallisuudesta, jotka yhdessä ovat perusyksikön varsinainen ydin. Ulkoinen osa koostuu palvelusta ja rajapinnasta. Palvelu kuvaa sitä toiminnallisuutta, jonka rakenneosa paljastaa eli tarjoaa ulospäin rajapinnan kautta. Toiminta (palvelu ja toiminnallisuus) on liiketoiminnan kannalta merkityksellinen. Rakenne (rajapinta ja rakenneosa) on konkreettinen entiteetti, kuten organisaatioyksikkö tai tietojärjestelmä, joka toteuttaa toiminnallisuuden.

Kärjistäen voi todeta että rakenneosat, kuten esimerkiksi määrätty organisaatioyksikkö tai järjestelmä, ovat resursseja (tuotannontekijöitä), jotka ovat vaihdettavissa jo korvattavissa, mutta niiden tarjoama toiminnallisuus ja palvelu ovat liiketoiminnan kannalta korvaamattomia. Tässä on havaittavissa analogia käsitteisiin kyvykkyys ja resurssi. Kyvykkyys on liiketoiminnan kannalta tärkeä “toiminnallisuus”, joka on merkityksellinen operatiivisen toiminnan kannalta. Resurssi on kyvykkyyden tuottamiseen osallistuva (tuotannon)tekijä. Kun toiminnallisten ja rakenteellisten asioiden liiketoiminnallinen merkitys liittyy strategisiin- ja liiketoimintamallin mukaisiin tavoitteisiin, tästä seuraa että kyvykkyydet eli “toiminta” on oleellista, mutta “rakenne” jolla toiminta saadaan aikaan on toisarvoista. Tässä mielessä on ymmärrettävää että haluttu toiminta pyritään saamaan aikaan mahdollisimman kustannustehokkaasti, ja vähäisillä rakenteellisilla kustannuksilla (kuten henkilöstö- ja IT-kustannuksilla).

Palvelu ja rajapinta ovat saman kolikon eri puolet: palvelu on toiminnallinen ja looginen, rajapinta on rakenteellinen ja konkreettinen. Näitä käytetään eri käyttötarkoituksissa, mutta molemmat kuvaavat rakenneosan ulospäin näkyvää toiminnallisuutta. Palvelulla voidaan mallintaa esimerkiksi sovelluksen käyttötapausta, ja rajapinnalla esimerkiksi käyttöliittymää (GUI, Graphical User Interface) tai sovellusrajapintaa (API, Application Programming Interface). Palvelulla voidaan mallintaa myös toimijan (=rakenneosa) tarjoamaa liiketoiminnan palvelua, joita tuotetaan prosessilla (=toiminnallisuus), ja joka tarjotaan kanavan (=rajapinta) kautta. Tällaisia kanavia ovat esimerkiksi sähköposti, puhelin, palvelutapaaminen/käynti, chat, internet jne.

Toiminnan ja rakenteen perusyksikössä voidaan tunnistaa luonnollisen kielen lauserakenne subjekti-predikaatti-objekti. Se pätee myös mallintamisen yhteydessä hyvänä muistisääntönä, kun tarkastellaan jonkin organisaatiossa esiintyvän entiteetin (kuten toimijan tai tietojärjestelmän) olemusta. Aktiivinen rakenne on subjekti, toiminta on predikaatti, ja passiivinen rakenne on objekti (kuva alla).

Tässä näkyy luonnollisen kielen lauserakenne: subjekti – predikaatti -objekti (tosin käänteinen sanajärjestys).

HUOM! ArchiMate -metamallin “Behavior” -aspektista käytetään tässä yhteydessä suomennosta “toiminta“. Voidaan käyttää myös suomennosta “käyttäytyminen“, mikä korostaisi tämän aspektin humaania puolta. Mutta tässä yhteydessä (ja kirjoituksessa) “toiminta” soveltuu paremmin organisaation kuvaamiseen: esimerkiksi liiketoiminta on vakiintunut termi. Vastaavasti sovellusten (eli järjestelmien) katsotaan tässä yhteydessä sisältävän ja tarjoavan “toiminnallisuutta” (jota voidaan mallintaa Function tai Process -elementeillä, kaikissa ns. “kerroksissa”).

2.4 Toiminta ja rakenne sekä kerroksellinen lähestymistapa

Toiminnan ja rakenteen perusyksikkö toistuu samanlaisena eri kerroksissa (kuva alla). Kerrokset ovat: liiketoimintakerros, sovelluskerros ja teknologiakerros. Kussakin kerroksessa esiintyy toiminnalliset ja rakenteelliset osat, sekä informaatioaspekti.

Liiketoimintakerroksen rakenteellisia osia eli toimijoita ovat esimerkiksi sisäiset organisaatiorakenteet kuten yksiköt, ryhmät ja tiimit, sekä erilaiset kanavat. Nämä osallistuvat liiketoimintaprosesseihin tai -toimintoihin, jotka ovat toiminnallisia osia. Lisäksi rakenneosia ovat ulkoiset toimijat kuten esimerkiksi asiakkaat, kumppanit ja sidosryhmät. Informaatiota ovat ne liiketoiminnan kannalta merkitykselliset käsitteet, joita käsitellään prosesseissa tai joita liikutellaan toimijoiden välillä.

Sovelluskerroksen rakenteellisia osia ovat sovellukset (eli järjestelmät) ja niiden tarjoamat rajapinnat. Toiminnallisia osia ovat sovellusten sisältämät prosessit ja toiminnot, joista osa tarjotaan palveluina ulospäin. Palveluita käytetään rajapintojen kautta, jotka puolestaan ovat sovellusten rakenteellisia osia. Sovelluskerroksen informaatioaspektia edustavat tietoelementit, joita sovellukset käsittelevät ja vaihtavat keskenään. Tietoelementit ovat konkreettisia ilmentymiä liiketoiminnan käsitteistä.

Informaatioarkkitehtuurin eli tietoarkkitehtuurin kannalta liiketoiminnan konseptien käsitemallinnus tarkentuu loogisessa tietomallinnuksessa, jossa mallinetaan organisaation varsinainen tieto. Tässä mielessä tietoarkkitehtuuri on horisontaalisia kerroksia läpileikkaava vertikaalinen aspekti, joka on mukana kaikessa.

Teknologiakerroksen entiteeteissä toistuvat niin ikään kaikki samat toiminnan ja rakenteen perusyksikön osat. Teknologiakerros edustaa konkreettisia teknologia-alustoja, ohjelmistoja, laitteita, tiloja ja tietoverkkoja, joiden ajoympäristöissä liiketoiminnan loogiset sovellukset ovat asennettuina. Teknologiakerroksen rooli ja merkitys kokonaisuuden kannalta vaihtelee. Nykyisin hankitaan yhä enenevässä määrin pilvipalveluina erilaisia liiketoiminnan tarvitsemia ratkaisuja, jolloin pilvipalvelun sisäinen teknologia on tilaavan organisaation liiketoiminnan kannalta toisarvoista.

3. Organisaation toiminnan ja rakenteen mallintaminen

3.1 Kokonaisarkkitehtuurin mallintamisen kattavin notaatio – ArchiMate

Organisaation toimintaa ja rakennetta voidaan tarkastella systemaattisesti mallintamisen keinoin. Open Groupin ArchiMate -notaatio (linkki) tarjoaa kattavimman joukon elementtejä, joiden avulla voidaan mallintaa kokonaisvaltaisesti organisaation toimintaa ja rakennetta, sekä näihin oleellisesti liittyviä asioita. Keskeisimmät ArchiMate-elementit (ydinelementit) on esitetty kuvassa alla kerroksittain.

ArchiMaten ydinelementtien väliset yhteystyypit on esitetty alla olevassa kuvassa. Paljon ArchiMate malleja ja esimerkkejä löytyy mm. ArchiMate käsikirjasta (linkki), sekä EA ja ArchiMate aiheisesta blogistani (linkki).

Kerrosmainen lähestymistapa perustuu ArchiMate -viitekehyksen kerroksiin (Business-, Application ja Technology Layer) (kuva alla). On huomattava, että ArchiMate -viitekehys jaottelee sisältöelementit paitsi kerroksiin, myös aspeketeihin (linkki). On siis mahdollista muodostaa organisaation arkkitehtuurin sisältökehikko joko a) kerroksellisesti tai b) aspekti-pohjaisesti – ilman kerroksia!

ArchiMate kerrokset vastaavat TOGAF ADM (Architecture Development Method) -menetelmän vaiheita (B. Business Architecture, C. Information Systems Architecture ja D. Technology Architecture).

3.2 Mallintaminen

Mallintaminen on hyödyllinen apuväline, kun organisaation toimintaan ja rakenteeseen kohdistuu muutoksia. Kun suunnitellaan uusia palveluita tai muutetaan nykyisiä, ne aina liitetään osaksi olemassa olevaa kokonaisuutta. Mallintamisen avulla muutosvaikutuksia voidaan tunnistaa tehokkaasti. Mallintaminen auttaa eri sidosryhmiä ymmärtämään kehittämiskohdetta ja arvioimaan sen muutosvaikutuksia paremmin. Mallintamisessa hyödyllisintä on itse mallinnusprosessi, jonka aikana yhdessä tarkastellaan kehittämiskohdetta, ja pyritään löytämään kaikki siihen liittyvät oleelliset asiat, ja jaetaan yhteinen käsitys kokonaisuudesta. Mallintamisen arvo on siinä, että sen avulla tulee kysytyksi oikeita kysymyksiä ja kuvatuksi organisaatiota systemaattisesti ja ammattimaisesti – näin saavutetaan parempaa laatua lopputulosten muodossa kaikilla organisaation kehittämistoiminnan tasoilla.

Mallintamisessa hyödyllisintä on itse mallinnusprosessi, jonka aikana yhdessä tarkastellaan kehittämiskohdetta, ja pyritään löytämään kaikki siihen liittyvät oleelliset asiat, ja jaetaan yhteinen käsitys kokonaisuudesta, ja tehdään se näkyväksi sekä arvioitavaksi – visualisoimalla se.

Kehittämiskohteiden läpivienti on se varsinainen ”pihvi”. Mallintaminen on vain keino tukea varsinaista kehittämistyötä, kuvaamalla kehittämiskohdetta. Mutta mallintaminen on keino tehdä kuvaaminen ammattimaisesti, ja saada aikaan laadukkaita tuotoksia. Mallintaminen on erinomainen tapa löytää kehittämiskohteesta juuri se oleellinen, ja tehdä se näkyväksi. Kun tämä näkemys on yhdessä jaettu, on kehittämiskohdetta helpompi kehittää.

Mallintamisessa on kyse organisaation toiminnan ja rakenteen ymmärtämisestä, ja nimenomaan kokonaisuuden ymmärtämisestä, sekä sen monimutkaisuuden hallinnasta. Mallintamisessa tunnistetaan ja visualisoidaan organisaation rakenteelliset osat, ja niihin liittyvä toiminta, sekä näiden toiminnallisten ja rakenteellisten osien väliset relaatiot eli suhteet. Suhteet voivat olla rakenteellisia, riippuvuutta ilmaisevia, tai dynamiikkaa kuvaavia.

Kun organisaation toiminnalliset ja rakenteelliset osat, sekä niiden väliset yhteydet on mallinnettu, kokonaisuus on tehty näkyväksi, sitä voidaan ymmärtää, ja kun voidaan ymmärtää, voidaan kehittää. Mallinnettujen yhteyksien, eli “kytkentöjen”, avulla voidaan myös jäljittää mikä vaikuttaa mihinkin. Näistä organisaation toiminnallisista ja rakenteellisista osista, sekä niiden välisistä suhteista muodostuu kokonaisuuden arkkitehtuuri. Eli kokonaisarkkitehtuuri.

Mallintaminen on tehokkainta, kun käytössä on asianmukainen mallinnusväline, joka tukee standardinotaatioita (kuten ArchiMate, BPMN ja UML), ja joka tarjoaa keskitetyn kuvauskannan (repositorion) mallinnuselementeille, sekä kaavioiden julkaisumahdollisuuden.

Voidaan todeta, että ArchiMate tarjoaa ainoastaan mallinnusnotaation, eli yhteiset merkintätavat kaikille mallintajille. Haaste onkin siinä, miten ArchiMate:a käytetään järkevästi. Usein mallinnuksessa lopputuloksena syntyviä ArchiMate-malleja tärkeämpää onkin itse mallinnusprosessi, sillä se pakottaa mallintajan ajattelemaan systemaattisesti ja miettimään mallinnettavan ongelman kaikkia puolia, sekä mahdollistaa ennen toteutusta tapahtuvan eri suunnitteluratkaisujen keskinäisen vertailun.

[Sovitettu kontekstiin; M. Luukkainen, H. Laine, Tietojenkäsittelytieteen laitos Helsingin Yliopisto, 2010.]

Mallinnuksessa ideana on tehdä abstraktio jostain tarkastelun alla olevasta kehittämiskohteesta. Abstraktiolla tarkoitetaan yksinkertaistettua mallia, joka kuitenkin sisältää riittävän määrän kiinnostavia yksityiskohtia. Mallinnusta on siis hyvin monen tasoista, ylimalkaisista luonnoksista aina hyvinkin detaljoituun mallinnukseen asti. Mallinnusta tehdään myös monesta eri näkökulmasta. ArchiMate:n erilaiset kaaviotyypit tarjoavat kukin mahdollisuuden hieman erilaiseen näkökulman esilletuomiseen. Yhdellä kaaviotyypillä ei pystytä todennäköisesti mallintamaan tiettyä kohdetta tyhjentävästi vaan on käytettävä useita eri näkökulmia tarjoavia kaavioita. Voidaan esim. kuvata sovelluksen sisäisten rakenneosien (osajärjestelmien, moduulien) staattista luonnetta rakennekaaviolla (komponenttikaaviolla). Näin ei kuitenkaan saada vielä minkäänlaista kuvaa siitä, miten ja missä roolissa sovellus toimii osana kokonaisarkkitehtuuria, eli tarvitaan lisäksi esim. sovellusten vuorovaikutuskaaviota (sovellusintegraatiot) kuvaamaan sovellusten välistä yhteistoimintaa.

Mallinnuksen detaljirikkauden ja näkökulmien lisäksi mallinnuksen luonteeseen vaikuttaa myös se, missä kehittämisporisessin vaiheessa mallinnus tapahtuu. Vaatimusmäärittelyn aikana kuvataan ongelman kohdealueen (problem domain) käsitteitä ja niiden suhteita ylätason käsitemallikaavioilla. Siirryttäessä suunnitteluvaiheeseen, aiemmin tehdyt kaaviot tarkentuvat. Siirryttäessä vaatimusmäärittelystä suunnitteluun, kaavioista tulee konkreettisempia, eli niiden abstraktiotaso laskee. Kaaviot siis tarkentuvat ja muuttuvat toteutusläheisemmäksi siirryttäessä määrittelystä suunnitteluun.

[Sovitettu kontekstiin; M. Luukkainen, H. Laine, Tietojenkäsittelytieteen laitos Helsingin Yliopisto, 2010.]

Mallinnusvälineen käyttäminen ja mallintaminen ovat taitoja, jotka edellyttävät paneutumista ja osaamista paitsi organisaation toiminnasta, myös taiteellista silmää ja ihmissuhdetaitoja. Mallinnustyö onkin arkkitehtuurityötä, josta noin 80% on kommunikointia ja tiedonkeruuta, ja 20% puhdasta mallintamista. Mallintaminen itse on tarkkuutta ja kärsivällisyyttä vaativaa, ja edellyttää määrätynlaista asennetta.

Mallintaminen on paras tapa oppia mallintamista ja saada arkkitehtuurin tuotoksia aikaan. Mallintamista ei opi kursseilla vaan tekemällä. Päivittäin. Edes vähän kerralla. Silloin siitä muodostuu rutiini, joka alkaa palkitsemaan tekijäänsä kiihtyvällä vauhdilla! Kun keskittyy tekemiseen, taitojen oppiminen kehittyy. “Käytännön tekeminen opettaa”.

“Mallintaminen on helppoa, jos on oikea asenne.
Mutta oikean asenteen omaksuminen on vaikeaa.”
Oikean asenteen oppii tekemällä.

Tekeminen on ylivoimaisesti paras tapa saada asioita aikaan! [Anssi Tuulenmäki]

3.3 Mallinnusväline

Mallinnusväline on organisaation toiminnallisten ja rakenteellisten osien, sekä näiden välisten yhteyksien hallintajärjestelmä. Mallinnusväline on myös organisaation kokonaisarkkitehtuurin ja kehittämiskohteiden käsittelyn ja visualisoinnin väline, eli kuvausväline. Samalla se on myös johtamisen ja kehittämisen sekä operatiivisen toiminnan tukijärjestelmä. Ammattimainen väline mahdollistaa systemaattisen kehittämisen.

Tyypillisesti mallinnusvälineet tarjoavat elementtien kuvauskannan (repositorion) ja kaavioiden julkaisumahdollisuuden. Usein mallinnusväline mahdollistaa myös erilaiset analyysit kuvauskannan dataan perustuen. Tärkeimpänä ominaisuutenaan mallinnusvälineet tarjoavat tuen standardinotaatioille, joista kattavin, monipuolisin ja ilamisuvoimaisin on ArchiMate. Se on vakiinnuttanut paikkansa merkittävimpänä kokonaisarkkitehtuurin mallinnuskielenä. ArchiMatea tukee useat eri mallinnusvälineet (linkki), joista osa on Open Groupin sertifioimia (linkki).

Mallinnusvälineistä moderneimmat tukevat paitsi standardinotaatioita kuten ArchiMate, myös Open Groupin ArchiMate-mallien siirtoformaattia, ArchiMate Model Exchange File Format (linkki). Sen avulla ArchiMate-malleja voidaan siirtää eri välineiden välillä. Mallinnusvälineet tarjoavat tyypillisesti myös jonkinlaisen skriptikielen, jonka avulla voidaan laatia esimerkiksi automatisoituja rutiineja vaikkapa repositorion elementtien käsittelyyn (muunnokset, import / export, relaatioiden luonti jne.). Mallinnusvälineissä on vaihteleva määrä mallinnustyötä helpottavia ja tehostavia ominaisuuksia, kuten sallittujen relaatioiden validointi, näkymien generointi, elementtien relaatioiden ja niiden kautta kytkettyjen elementtien automaattinen visualisointi, raporttien genereointi (eri formaatteihin kuten esim. Word, Powerpoint, pdf, HTML) jne.

Taitava mallintaja saa mallinnusvälineellä aikaan mitä vaan halutaan.
Taitamaton mallintaja saa mallinnusvälinellä aikaan mitä vaan, paitsi sitä mitä halutaan.
”A fool with a tool is still a fool”.

Mallinnusväline on kokonaisarkkitehtuurin kuvausväline ja -hallintajärjestelmä

Ammattimaisessa käytössä ja systemaattisessa kokonaisarkkitehtuurin mallintamsessa mallinnusväline on organisaation kokonaisarkkitehtuurin hallintakyvykkyyden / -toiminnon (Enterprise Architecture Management, EAM) pääasiallinen tukiväline. Valittu mallinnusväline on kokonaisarkkitehtuurin ensisijainen kuvausväline, ja organisaation toiminnallisten ja rakenteellisten osien, sekä niiden välisien yhteyksien ylläpitojärjestelmä. Tässä mielessä mallinnusväline on kokonaisarkkitehtuurin hallintajärjestelmä (EA tool).

Mallinnusväline on organisaation digitaalisen kaksosen (DTO) hallintajärjestelmä

Sen lisäksi että kokonaisarkkitehtuurin mallinnusvälineessä on tietoa kaikista organisaation toiminnallisista ja rakenteellisista osista, siihen voidaan yhä enenevässä määrin integroida lähes reaaliaikaista tietoa organisaation prosesseista ja muista organisaation järjestelmistä, kuten esimerkiksi konfiguraation hallintajärjestelmä (Configuration Management DataBase, CMDB). Tällöin on luontevaa ajatella että, kokonaisarkkitehtuurin mallinnusväline on organisaation digitaalisen kaksosen (Digital Twin of an Organization, DTO, tai Enterprise Digital Twin) hallintajärjestelmä. DTO on Gartnerin 2017 lanseeraama käsite, jolla tarkoitetaan organisaation digitaalista versiota, jonka avulla organisaation toimintaa voidaan esimerkiksi monitoroida, simuloida ja hallita.

Välinepuolella DTO-konseptiin liitetään usein ns. process mining eli prosessien louhinta- ja suorituskyvyn analysointivälineet (kuten esimerkiksi QPR Process Analyzer, linkki), mutta DTO-konsepti on laajempi kokonaisuus kuin mitä pelkästään prosessien suorituskyvyn analysointi käsittää. Kun prosesseista saatava suorituskykytieto yhdistetään tietoihin organisaation muista tietolähteistä, sekä perustietoihin organisaation toiminnallisista ja rakenteellisista osista, ja niihin liittyvistä tilatiedoista, voidaan puhua täysiverisestä DTO-hallintajärjestelmästä. Kattavimmillaan DTO käsittää mm. organisaation kaikki liiketoiminnan palvelut ja -prosessit, toimijat, järjestelmät, IT-palvelut sekä tilat ja laitteet, jotka kaikki liittyvät toisiinsa, ja joiden muodostama kokonaisuus on konkreettisen organisaation digitaalinen kaksonen. Mitä reaaliaikaisemman näkymän DTO tarjoaa organisaation tilasta, sitä paremmin se on hyödynnettävissä eri tasoisiin toimenpiteisiin (strategisiin, taktisiin ja operatiivisiin). Parhaimmillaan DTO mahdollistaa nopean ja ajantaisaisen palautesilmukan avulla operatiivisten toimenpiteiden hallinnan OODA-silmukan mukaisesti (OODA-loop, Observe-Orient-Decide-Act, linkki).

Modernien kokonaisarkkitehtuurin kuvausvälineiden ja DTO-ratkaisujen (esim. Mavim, Orbus iServer) käyttöliittymät tarjoavat helppokäyttöisiä ja ymmärrettäviä näkymiä (dashboardeja) organisaatiosta eri käyttäjäryhmille (johto, liiketoiminnan kehittäjät, päälliköt, arkkitehdit, kehitystiimit, palvelunhallinta jne.). DTO-järjestelmät integroituvat moniin organisaation järjestelmiin kerätäkseen tietoa, jota yhdistellään ja jalostetaan. Näin DTO tarjoaa lähes reaaliaikaisen tilannekuvan organisaation toiminnasta ja rakenteesta. Epäilemättä osa kokonaisarkkitehtuurin mallinnusvälineistä tullee kasvamaan, laajenemaan, konsolidoitumaan, tai vähintään integroitumaan tiiviimmin muiden erikoistuneiden välineiden kanssa (esim. CMDB, BI, BI/A, BAM, BPM, portfolion hallinta jne.). Joka tapauksessa kokonaisarkkitehtuurin hallinta (EAM) on osa DTO-konseptia. Voidaan ajatella myös että DTO on kokonaisarkkitehtuurin (EA) kehittymisen seuraava aste. Osa kokonaisarkkitehtuurin mallinnusvälineistä kytkeytyy jo nyt mm. gaafitietokantoihin (Graph Database), ja muihin tiedon yhdistelyn välineisiin, sekä ‘korkeamman visuaalisen käyttäjäkokemuksen’ tarjoaviin käyttöliittymiin.

3.4 Mallintamisen kaaviotyypit

Kun organisaation toimintaa ja rakennetta mallinnetaan, se voidaan tehdä käyttäen määrättyjä kaavioityyppejä. Kaaviotyyppi on esimääritelty “suunnittelumalli”, jossa määrätyillä elementeillä ja yhteystyypeillä voidaan mallintaa kehittämiskohdetta määrätystä näkökulmasta (viewpoint).

Organisaatiossa käytettävät kaaviotyypit on määritelty valmiiksi, jotta mallintaminen olisi helpompaa ja arkkitehtuurituotokset olisivat yhteismitallisia. Kun organisaatiossa käytetään samoja kaaviotyyppejä, saadaan organisaation kokonaisarkkitehtuurin sisältö pysymään mahdollisimman koherenttina, yhdenmukaisena ja johdonmukaisena. Siksi onkin tärkeätä, että organisaatiossa sovitaan mitä kaaviotyyppejä käytetään.

Tässä esitettävät kaaviotyypit ovat valikoituneet eri lähteistä (artikkelit, seminaarit) ja vuosien arkkitehtuurityön kokemusten perusteella eri organisaatiosta. Nämä keskeisimmät kaaviotyypit ja niistä versioidut sovellutukset riittävät useimpiin mallinnustarpeisiin. Näiden kaaviotyyppien avulla voidaan kuvata kaikki oleelliset asiat määrätyn kehittämiskohteen kuvaamiseksi ymmärrettävällä tavalla.

Keskeiset kaaviotyypit ovat: 1) Tavoitteet -näkymä, 2) Kerrosnäkymä, 3) Vuorovaikutusnäkymä eli integraationäkymä (toimijoiden-, prosessien- ja sovellusten vuorovaikutus), 4) Käsitemalli ja 5) Teknologia-alusta (kuva alla).

3.4.1 Tavoitteet-näkymä

Tavoitteet -näkymän (Motivation View, Goals View) avulla voidaan kiteyttää yhteen näkymään kehittämiskohteen tarve: mikä on se lisäarvo joka tämän kehittämiskohteen avulla saavutetaan (alustava ”business case”). Tavoitteet -näkymän avulla vastataan kysymyksiin: kenelle, miksi, mitä. Kaiken kehittämisen perustana tulisi aina olla selkeä käsitys miksi muutos tarvitaan. Tämän kaaviotyypin avulla on mahdollista analysoida, ennen kuin tehdään yhtään mitään, seuraavia asioita:

• Kenelle kehittämiskohde on tarkoitettu, mitkä sidosryhmät ovat kiinnostuneita tästä kehittämistarpeesta tai muutoksesta, tai joilla on ylipäätään jokin intressi tähän kehittämiskohteeseen liittyen, eli mitä sidosryhmiä se koskee? Sidosryhmiä ovat esimerkiksi asiakkaat, sisäiset tai ulkoiset toimijat.
• Miksi kehittämiskohde tarvitaan, mitkä ovat sen ajurit eli taustavaikuttimet, mitkä ovat varsinaiset ongelmat tai juurisyyt. On erittäin tärkeätä analysoida miksi kehittämistarve on merkityksellinen, miksi tarvitaan muutos nykyiseen asiantilaan?
• Mitä ovat ne tavoitteet, joita kehittämistarpeeseen liittyy. Ne on syytä määritellä sanamuodoiltaan selkeästi ohjaaviksi, kohti konkretiaa pyrkiviksi, sisällyttämällä tavoitteeseen laadullisen määreen. Esimerkiksi “asiakastyytyväisyyden parantaminen”, “hakemuskäsittelyn nopeuttaminen”, “manuaalityön vähentäminen” jne.
• Mitä halutaan saada aikaan, mitkä ovat konkreettiset lopputulokset? Tavoitteille voidaan tunnistaa mitattavissa olevia lopputuloksia, kuten esim. “asiakastyytyväisyyden parantaminen 20%”. Lopputuloksen arvon mitta on viime kädessä se, miten hyvin se käyttäjää tyydyttää, eli mikä on asiakkaan kokema tyytyväisyys.
• Miten tavoitteisiin päästään, voidaan tunnistaa mallintamalla kehittämiskohteeseen liittyvät periaatteet ja rajoitteet sekä kehittämisvaatimukset. Niistä voidaan tunnistaa millä konkreettisilla toimenpiteillä tavoitteiden mukaisiin lopputuloksiin päästään, sekä mitä kyvykkyyksiä organisaation tulee omata, ja millä resursseilla kyvykkyydet toteutuvat.

Tavoitteet-näkymä on apuväline kehittämistarpeen analysointiin, jossa pyritään tunnistamaan todellinen tarve, sen juurisyyt, konkreettiset tavoitteet, lopputulokset ja toimenpiteet. Konkretia lisääntyy siirryttäessä alaspäin, kun tarkennetaan tavoitetta, lopputuloksisiksi, ja edelleen konkreettisiksi toimenpiteiksi.

Tällaisella yhden sivun tiivistyksellä havainnollistetaan kehittämistarpeen juurisyyt, tavoitteet, periaatteet ja rajaukset sekä kehittämisvaatimukset. Kaaviotyypillä saadaan aikaan yksinkertainen rautalankamalli kehittämistarpeesta, kaiken tekemisen pohjaksi. Tässä mielessä Tavoitteet -näkymät ovat erittäin hyödyllisiä jokaisen kehittämiskohteen osalta, sillä niiden avulla tehdään näkyväksi ja arvioitavaksi ennen kaikkea MIKSI kyseinen kehittämiskohde on merkityksellinen, ja mikä on sen tuottama lisäarvo.

HUOM! Tavoitteet -näkymä soveltuu strategiatyön tueksi, kun halutaan tarkasti osoittaa miten strategisista tavoitteista johdetaan mittattavissa olevia lopputuloksia, edelleen toimenpiteitä ja kyvykkyyksiä. Tavoitteet -näkymän avulla voidaan visualisoida strategia, ja tuoda se kiinteäksi osaksi organisaation toiminnan ja rakenteen kehittämistä. Osaksi kokonaisarkkitehtuuria. Tavoitteet -näkymän avulla voidaan myös tunnistaa tarvittavat kyvykkyydet, kun halutaan kuvata tavoitetilaa.

3.4.2 Kerrosnäkymä

Kerrosnäkymällä (Layered View) voidaan esittää kehittämiskohteen kokonaiskuva, konteksti / toimintaympäristö, joka on kehittämiskohteen kannalta kiinnostava ja merkityksellinen. Kerrosnäkymän avulla voidaan tunnistaa ja kuvata kehittämiskohteen toiminnan ja rakenteen tärkeimmät osatekijät, sekä näiden väliset riippuvuudet. Tällaisia osatekijeitä ovat esimerkiksi seuraavat: asiakkaat, joille tarjotaan, liiketoiminnan palveluita, joita tuotetaan määrätyillä liiketoimintaprosesseilla, joita tuetaan sovelluspalveluilla, joita tarjoavat määrätyt sovellukset, jotka on toteutettu määrätyillä teknologiapalveluilla ja -alustoilla.

Kerrosnäkymissä voidaan hyödyntää kaikkien ArchiMate kerrosten (Biz, App, Tech) elementtejä, ja kerrosnäkymän avulla näitä eri kerrosten elementtejä kytketään toisiinsa. Kerrosnäkymä on kenties hyödyllisin ja informatiivisin kaaviotyyppi, sillä kerrosnäkymän avulla visualisoidaan eri kerrosten elementtien väliset suhteet. Näin voidaan esittää samassa kaaviossa elementtien välisiä rakenteellisia- ja dynaamisia suhteita, sekä riippuvuussuhteita. Näiden osoittaminen onkin eräs arkkitehtuurin tärkeimmistä ominaispiirteistä.

Katso “Kerrosnäkymä” video.

3.4.3 Vuorovaikutusnäkymä

Vuorovaikutusnäkymä (Cooperation View) eli integraationäkymä kuvaa tietovirtoja toimijoiden, prosessien tai sovellusten välillä. Eli mitä tietoa siirtyy ja mihin suuntaan. Vuorovaikutusnäkymiä on kolmea eri tyyppiä (kuva alla), joita voidaan myös yhdistellä mikäli tarkoituksenmukaista. Esimerkiksi sovellusten vuorovaikutusnäkymässä voidaan esittää myös toimijoita.

3.4.4 Käsitemalli

Käsitemalli (Conceptual Data Model) kuvaa kehittämiskohteen tai kohdealueen liiketoiminnan käsitteitä ja niiden välisiä suhteita. Käsitemallin pohjalta voidaan laatia myös sovellustason tietomalli.

3.4.5 Teknologia-alusta

Teknologia-alusta (Technology- / Infrastructure View, Deploymenet Diagram) kuvaa sovelluksen ajoympäristön: alustaohjelmistot kuten käyttöjärjestelmän, laitteet kuten palvelimet jne. (kuva alla). Solmu on alustan rakenteellinen elementti, jonka sisään ohjelmistot voidaan sisällyttää (nesting) tilan säästämiseksi ja ymmärrettävyyden parantamiseksi. Tällöin teknologia-alusta esitetään ikään kuin pinona, ja se on visuaalisesti helpompi hahmottaa. Lisäksi tilaa säästyy, jos samalle kaaviolle tulee useita alustasolmuja, esimerkiksi eri palvelinkonfiguraatioille, klusterin solmuille tms.

3.5 Mallintamisen referenssimateriaalia

Esimerkkejä ja malleja eri kaaviotyypeistä löytyy mm. seuraavista linkeistä:

• ArchiMate käsikirja – malleja ja esimerkkejä suomeksi,
• ArchiMate Cookbook – paljon malleja ja esimerkkejä englanniksi,
• ArchiMate Examples – erittäin paljon ArchiMate mallintamisen suunnittelumalleja ja esimerkkejä.

Kirjallisuutta:

• Enterprise Architecture at Work, 4th Edition, Marc Lankhorst et al., Springer, 2017.
• Mastering ArchiMate, Edition III, Gerben Wierda, 2017. (1st edition 2012)
• Chess and the Art of Enterprise Architecture, Gerben Wierda, 2015.

4. Kokonaisarkkitehtuurin ongelma ja sen ratkaisu

4.1 Kokonaisarkkitehtuurin ongelma on kokonaisarkkitehtuuri

Useille organisaation sidosryhmille, kuten johdolle ja toiminnan kehittämiseen osallistuville kokonaisarkkitehtuuri on vaikea ymmärtää, sen välittömiä hyötyjä on vaikea nähdä, se on “erillinen kaikesta muusta”. Kokonaisarkkitehtuurin viitekehykset ovat laajoja ja vaikeaselkoisia, ja niiden perinteinen “näkökulmapohjaisuus” (neljä T:tä: Toiminta, Tieto, Tietojärjestelmä, Teknologia) johtaa siilomaiseen tarkasteluun. Se mikä joskus oli hyvä muistisääntö, ja auttoi kokonaisarkkitehtuurityön jäsentelyssä (nuo neljä T:tä), ei toimi käytännössä. Organisaatio (tai sen liiketoimintayksikkö, Business Domain) on kokonaisuus. Yksi konkreettinen ja koherentti reaalimaailman kokonaisuus. Ei neljä eri osakokonaisuutta. “Näkökulmapohjaisessa” organisaation tarkastelussa ei huomioida kahta asiaa: 1) kokonaisuutta ja 2) arkkitehtuuria. Wanha “näkökulmapohjaisuus” korostaa liikaa eri näkökulmien erityisyyttä ja erillisyyttä. Sen sijaan, organisaatiota tai sen osaa, tai yksittäistä kehittämiskohdetta, tulisi tarkastella yhtenä kokonaisuutena, jolloin huomioidaan kaikki oleelliset asiat, kerrokset ja näkökulmat, palvelut, prosessit, tiedot ja järjestelmät jne. – kokonaisvaltaisesti, samalla kertaa, kokonaisuuteen ei saa jäädä aukkoja.

Kokonaisarkkitehtuuritoiminto on usein ollut varsin erillinen kaikesta muusta kehittämistoiminnasta. On pidetty katselmointeja jälkikäteen, viisasteltu norsunluutornista, piirusteltu viikko- tai kuukausikaupalla kaavioita joita kukaan muu ei ymmärrä, tai edes halua nähdä. Kuvaukset ovat wanhentuneita jo valmistuessaan. Kokonaisarkkitehdit eivät ole osallistuneet päivittäiseen kehittämistoimintaan yhdessä muiden kanssa, vaan arkkitehdit ovat toimineet “irti arjesta”, pää pilvissä, omassa kuplassaan laajojen suunnitelmiensa parissa. Tällainen toiminta on usein koettu hyödyttömäksi, ja touhu on lopetettu kokonaan kun muiden kärsivällisyys on loppunut. Nykypäivän liiketoimintaympäristö on niin nopeatempoista, etteivät hitaat, raskaat, liian laajat ja liian tarkat suunnitelmat liian aikaisessa vaiheessa ole erityisen hyödyllisiä. Kokonaisarkkitehtuurin välineet, -menetelmät ja -viitekehykset ovat olleet vaikeita käyttää ja vaikeaselkoisia ymmärtää, myös arkkitehdeille itselleen. Joskus toimintaa on yritetty uudelleenkäynnistää, mutta jos keinot ovat olleet ne samat wanhat, on seurauksena ollut jälleen epäonnistuminen. Ei ihme jos organisaation johto on jossain määrin allergisoitunut koko asialle. Vaikka itse asia olisikin tärkeäksi koettu, on se pilattu tökeröllä toteutuksella. Tällainen “vanhoillisuus” ja “erillisyys” ovat näköluklmapohjaisuuden ohella ajaneet kokonaisarkkitehtuurin itse aiheutettuihin “eksistentialistisiin” ongelmiin.

Kokonaisarkkitehtuurin paradoksi: organisaatio on monimutkainen ja laaja-alainen asia ymmärtää, kehittää ja hallita. Kokonaisarkkitehtuuri auttaisi ymmärtämään, kehittämään ja hallitsemaan tätä organisaation kokonaisuutta ja sen monimutkaisuutta. Mutta kokonaisarkkitehtuuri itse on vaikea: kokonaisarkkitehtuurin menetelmät ja viitekehykset ovat liian monimutkaisia ja laajoja ymmärtää, ja niiden hyödyntäminen käytännössä ei usein onnistu. Organisaation muodostama kokonaisuus on laaja, kuvausten tekeminen ja ylläpito on työlästä. Eli kokonaisarkkitehtuurin ongelma on kokonaisarkkitehtuuri itse.

Siksi kokonaisarkkitehtuuri tulisi pelastaa siltä itseltään. Siksi kokonaisarkkitehtuuria tulisi muuttaa. Tässä muutoksessa kannattaa keskittyä kokonaisarkkitehtuurin rooliin ja merkitykseen organisaatiossa. Kokonaisarkkitehtuuri on yhtä tärkeätä kuin on organisaation toiminnan ja rakenteen kehittäminen, koska kyse on samasta asiasta. Kokonaisarkkitehuurista puhumisen sijaan kannattaa keskittää huomio “varsinaiseen pihviin eikä lautaseen”: varsinaisesti merkityksellistä on organisaation kehittämistoiminta, eli kehittämiskohteiden läpivienti. Kehittämistoiminnalla aikaansaadaan organisaation olemassaolon kannalta kaikkein tärkeintä: arvon tuottamista asiakkaille. Kokonaisarkkitehtuuri on ainoa(!) ja paras menetelmä, joka tukee organisaation kokonaisvaltaista toiminnan kehittämistä. Kokonaisarkkitehtuurilla on vakiintuneet, ammattimaiset ja systemaattiset menetelmänsä, joiden ytimessä on myös mallintaminen. Kokonaisarkkitehtuuriin liittyy valmiita malleja ja menetelmiä, viitekehyksiä ja standardeja mallinnuskieliä. Niistä pitää vain muotoilla organisaation tarpeisiin sopiva versio, joka on riittävän yksinkertainen, ymmärrettävä ja käytännönläheinen. Eikä sellaista tarvitse keksiä enää uudestaan. Eräs esimerkki esitellään seuraavissa kappaleissa: LeanEA.

Ongelman ratkaisu alkaa ongelman tunnistamisesta. Ei ole erillistä kokonaisarkkitehtuuria, jolla olisi arvoa sinällään. Kokonaisarkkitehtuuri on tärkeätä, koska organisaation toiminnan ja rakenteen ymmärtäminen ja kehittäminen on tärkeätä – kokonaisarkkitehtuuri ilmentää tätä. Kokonaisarkkitehtuurityötä ei kannata tehdä sen itsensä vuoksi, sitä kannattaa tehdä organisaation vuoksi. Kokonaisarkkitehtuurin ongelman ratkaisu on kokonaisarkkitehtuurin muutos: kokonaisarkkitehtuurin integroiminen osaksi kehittämistoimintaa. Muutos on välttämätön. Uusi ajanmukainen, Lean ja ketterä menetelmä ja toimintamalli tarvitaan. Uusi, modernisoitu ja helpompi viitekehys tarvitaan.

4.2 Kokonaisarkkitehtuurin ratkaisu on kokonaisarkkitehtuurin muutos

Kokonaisarkkitehtuurin muutos :

• Uudelleenorganisointi – kehittämistoiminnan uudelleen muotoilu, kokonaisarkkitehtuurin integrointi kehittämisen toimintamalliin
• Uusi viitekehys
• Uusi menetelmä – edelliset yhdessä

Yksinkertaista mutta helppoa. Valmis malli on olemassa: LeanEA (linkki). Pyörää ei tarvitse keksiä.

LeanEA = LeanEA-toimintamalli + LeanEA-viitekehys

LeanEA on organisaation kehittämisen toimintamalli ja sitä tukeva viitekehys.

LeanEA ja kokonaisarkkitehtuurin muutos:

• Arkkitehtuurityö integroidaan osaksi jokapäiväistä kehittämistoimintaa
• Reaktiivisesta moodista dynaamiseen ja proaktiiviseen
• Arkkitehtuuri osallistuu kehittämiskohteisiin heti alusta alkaen
• Arkkitehdit osallistuvat moniammatilliseen virtuaalitiimiin, joka käsittelee kaikki organisaation kehittämiskohteet
• Arkkitehtuurikuvauksia tehdään vain tarpeeseen ja vain riittävästi – niistä kehittämiskohteista jotka tulevat “tilauksesta” työn alle, sekä niistä jotka ovat kokonaisuuden kannalta tärkeimpiä (kaikkea ei kannata eikä tarvitsekaan aina kuvata)
• Kokonaisarkkitehtuurin sisältö kasvaa pikku hiljaa, ja konaiskuva täydentyy jatkuvasti
• Arkkitehtuurituotoksia tehdään mallinnusvälineellä, josta kuvaukset julkaistaan jatkuvasti
• Arkkitehtuurityö on näkyvää: kaikki tehtävät ovat Kanbanilla, ja kaikki tuotokset julkaisuportaalissa
• Arkkitehtuuri on vaikuttavaa, koska kaikkia kehittämiskohteita tarkastellaan kokonaisarkkitehtuurin tilannekuvaa vasten

LeanEA -toimintamalli:

• Organisaation arvoketjupohjainen kehittämisen toimintamalli, ja siihen integroitu arkkitehtuuritoiminto
• Keskittyminen asiakkaalle arvoa tuottavien lopputulosten tuottamiseen, jotka perustuvat liiketoimintalähtöisiin tarpeisiin

LeanEA-viitekehys:

• Kokonaisvaltainen, kerroksellinen, palvelulähtöinen
• Yksinkertainen, helppo omaksua ja käyttää, ohjeistettu ja heti valmis kuvausvälineessä – päivästä yksi alkaen

LeanEA tarkastelee organisaatiota ja sen kehittämiskohteita tarvelähtöisesti, asiakaslähtöisesti, palvelulähtöisesti, kokonaisvaltaisesti, kerroksellisesti. LeanEA keskittyy asiakkaalle arvoa tuottavien lopputulosten aikaansaamisen, ketterän ja virtaustehokkaan toimintamallin avulla

Oleellista LeanEA-mallissa on kokonaisarkkitehtuurin kannalta se, että se integroidaan osaksi päivittäistä toimintaa ja yhdessä tekemistä. Tällöin fokus on liiketoimintalähtöisten kehittämiskohteiden läpiviennissä, ja arvoa tuottavien tuotosten tuottamisesta (business driven outcomes). Tässä mielessä kokonaisarkkitehtuurityö on enemmänkin kuin shakkia, mahdollisimman hyvien siirtojen tekemistä jatkuvasti (kuten Gerben Wierda mainiossa kirjassaan ”Chess and the Art of Enterprise Architecture” osuvasti kuvaa, linkki).

Kun kokonaisarkkitehtuuria hyödynnetään välineenä organisaation strategisten tavoitteiden toteuttamiseen, silloin voidaan soveltaa ns. kyvykkyspohjaista suunnittelua (Capability-Based Planning, CBP). Tällöin strategisiin tavoitteisiin voidaan liittää lopputulokset, jotka halutaan saada aikaan, sekä toimenpiteet, joilla tavoitteiden mukaiset lopputulokset aiotaan toteuttaa, sekä kyvykkyydet joiden kautta konkretisoituu MITÄ organisaation tulee omata. Tällöin kokonaisarkkitehtuuri ja mallintaminen auttavat organisaation kannalta tärkeiden kyvykkyyksien tunnistamisessa. Kyvykkyydet ovat myös se liima, joka kytkee strategiset tavoitteet konkretiaan: organisaation toiminnallisiin ja rakenteellisiin osiin. Kyvykkyys on terminä toisinaan haastellinen ymmärtää, mutta voidaan ajatella että kyvykkyydet ovat “asoita”, joita organisaatiossa tulee olla kun se toteuttaa strategiaansa ja liiketoimintamalliaan operatiivisessa toiminnassaan. [Tässä kyvykkyys (Capability) kuten ArchiMate sen määrittelee: linkki. Ja CBP kuten Togaf sen määrittelee: linkki]

LeanEA:ssa kokonaisarkkitehtuuri ei ole erillistä, vaan se on osallistuvaa ja vaikuttavaa, eli erittäin hyödyllistä. Kokonaisarkkitehtuurityö on koko kehittämisen toimintamallin ytimessä, keskeisessä roolissa, jonka merkitys on osallistua kaikkien kehittämistarpeiden käsittelyyn heti alusta alkaen, heti kun ideat nousevat. Ja kun ideoita eli kehitystarpeita käsitellään, konseptoidaan, suunnitellaan, innovoidaan ja kokeillaan, kokonaisarkkitehtuuri on mukana. Kysymys on kehittämistyön ja sen tuotosten laadusta: se paranee kun kaikkia kehittämistarpeita tarkastellaan organisaation olemassa olevaa tilannekuivaa vasten – kokonaisarkkitehtuurin avulla. Myös tietoturva-asiat voidaan huomioida heti alusta alkaen. Palvelumuotoilua voidaan hyödyntää tukimenetelmänä, kun kehittämistapeita tarkastellaan asiakkaan ja palvelukokemuksen perspektiivistä. Kun kehittämiskohteet tai toimintamallimuutokset yms. etenevät toteutukseen tai vaikkapa hankintaan, ja edelleen tuotantoon (IT-palvelut palvelutuotantoon), kokonaisarkkitehtuuri on mukana jatkuvasti. Tuotannossa olevien IT-palveluiden ratkaisujen arkkitehtuurit löytyvät kokonaisarkkitehtuurin kuvausvälineestä. Näin kokonaisarkkitehtuuri on lakannut olemasta erillinen, eristäytynyt toiminto, nyt se on mukana kaikessa. LeanEA on keino toteuttaa kaikki tämä käytännössä, konkreettisesti.

4.2.1 LeanEA -toimintamalli

LeanEA toimintamallissa koko organisaation kehittämistoiminta muotoillaan virtaustehokkuuden maksimoimiseksi. Kehittämisen toimintamalli, ideasta-tuotantoon –prosessi, määritellään arvoketjuksi, joka muodostuu arvovirroista. Näitä ovat vaiheet: ideointi, kehittäminen ja palvelutuotanto. Tämä on analoginen BizDevOps -lähestymistavan kanssa. Näihin vaiheisin kytketään tarvittavat organisaation kyvyykkyydet, eli toimijat ja toiminnot. Kokonaisuus viritetään käsittelemään kehittämistarpeita, ratkaisemaan ja toteuttamaan niitä toimiviksi digitaalisiksi palveluiksi tai toiminitamalleiksi.
Kokonaisarkkitehtuuri ja mallintaminen ovat tämänkin toimintamalli-kokonaisuuden suunnittelun, kehittämisen ja ylläpidon apuväline.

LeanEA toimintamallissa kokonaisarkkitehtuurilla on huomattava rooli ja merkitys kahdessa arvovirrassa: 1) strategiasta-portfolioon (Strategy to Portfolio), ja 2) kehittämistarpeesta-portfolioon (Demand to Portfolio). Molemmat ovat ideasta-tuotantoon -prosessin (=arvoketjun) ensimmäisessä vaiheessa “Ideointi” (josta voidaan myös käyttää nimeä “suunnittelu”, mikä tosin korostaa vesiputousmaisuutta. Tarkoitus on kuitenkin hyödyntää moderneja käytäntöjä ja menetelmiä kuten kokeilua, innovointia ja palvelumuotoilua osana tarpeiden käsittelyä/ideointia, samalla kun huolehditaan virtaustehokkuudesta). Molemmissa em. arvovirroista (1 ja 2) kehittämiskohteet kytketään portfolion hallintaan, mitä LeanEA-viitekehys tukee osana ideasta-tuotantoon -prosessia. Kokonaisarkkitehtuurin tuotoksia hyödynnetään läpi koko ideasta-tuontantoon -prosessin, kuvauskannassa olevan kokonaisuuden tilannekuvan kautta. Kuvaukset täydentyvät ja tarkentuvat kun kehittämiskohde etenee prosessissa. Myös tuotannossa olevien IT-palvelujen kuvaukset löytyvät kuvauskannasta. Ja jos niihin kohdistuu muutostarpeita, niitä käsitellään prosessin mukaan kuten muitakin (kehittämis)tarpeita.

Eteneminen, kun LeanEA-toimintamalli implementoidaan organisaation:
1. Määritellään kehittämisen toimintamalli – ”ideasta-tuotantoon”
– Ensin ylätason arvovirta, johon kytketään organisaation kyvykkyydet
– Sitten tarkemman tason prosessi, toimintamallin kuvaus
2. Muodostetaan kehittämistarpeita käsittelevä moniammatillinen virtuaalitiimi (Demand Management Team)
– Tiimi käsittelee kaikki kehittämiskohteet kehittämismallin ideasta-tuotantoon prosessin alussa
3. Arkkitehtuuritoiminto liitetään osaksi moniammatillista virtuaalitiimiä
– Arkkitehtuuri on integroitu osaksi kehittämismallia
– Arkkitehdit mallintavat vain kehittämiskohteita, vain tarvelähtöisesti ja vain riittävästi
4. Kaikki kehittämiskohteet kuvataan mallinnusvälineeseen
– Mallinnusväline tukee kehittämismallia; kaikki kehittämiskohteet mallinnetaan, ja julkaistaan jatkuvasti, kaikille kehittämistoimintaan osallistuville nähtäväksi
– Ideointi, suunnittelu, kehittäminen ja valmiit ratkaisut ovat näkyvissä kaikille kaiken aikaa

Organisointi LeanEA-toimintamallissa on luonnollisesti organisaatiokohtainen. Alla olevassa kuvassa esimerkkitoteutuksen toimijoita ja rooleja. Keskeisin toimija on kehittämistarpeita käsittelevä virtuaalitiimi (kuvassa “Tarpeiden käsittelytiimi”, Demand Management Team).

Keskeisin rooli on Lean Manager, koko kehittämismallin operatiivista toimintaa käytännössä johtava rooli. Tämä rooli myös osallistuu koko kehittämismallin johtamiseen ja mallin itsensä kehittämiseen, suorituskyvyn mittaamiseen jne. Tämä rooli toimii myös kehittämistarpeita käsittelevän virtuaalitiimin (Demand Management Team) Scrum Master -tyyppisessä tehtävässä.

Tiimit. Kaikkien (!) tiimien tehtävät tulee olla läpinäkyviä, jotta tehtävien edistymistä voidaan seurata paremmin. Miksi? Jotta tiimin jäsenet kokevat tekevänsä mielekästä ja laadukasta työtä, ja saavuttavat hallinnan tunteen omaan työhönsä. Miten? Tehtävät ovat avoimella Kanban-taululla (sähköisellä), palaverikäytänöt perustuvat tyypillisiin ketterien menetelmien käytäntöjen sovellutuksiin (kuten esimerkiksi daily-, bi-weekly-, weekly-palaverit). Yleisesti ottaen voidaan todeta, että jos jonkin tiimin tai ryhmän toiminta ei ole selkeästi tavoitteellista ja konkreettisia lopputuloksia tuottavaa, sellainen tiimi on tarpeeton. Kaikessa toiminnassa huomioidaan asiakkaalle tuotettava (lisä)arvo: jos toiminnasta ei ole asiakashyötyä, suoraan tai välillisesti, toiminta on hyödytöntä. Kun tiimin toiminta on tavoitteellista, ja tavoitteet on tehty näkyviksi, päivittäinen toiminta on mielekästä ja palkitsevaa tiimin jäsenille.

Tiimien toiminnan ja tehtävien näkyvyyden ja seurannan lisäämisen tarkoitus ei ole kontrollin lisääminen, vaan tiimin jäsenten päivittäisen tekemisen laadun parantaminen. Sekä toiminnallisesti että lopputulosten muodossa. Varmistetaan että tehdään oikeita asioita, ja asioita oikein. Jotta käytetään resursseja hyödyllisiin ja arvoa tuottaviin asioihin. Näin tiimin jäsenet voivat keskittyä tärkeisiin asioihin, ja kaikki epämääräinen tekeminen väistyy. Näkyvyys lisää myös hallinnan tuntua omasta työstä: nähdään mitä tulisi tehdä milloinkin, ja kuinka paljon eri asioihin on arvokasta käyttää aikaa ja energiaa. Tavoitteena on pyrkiä suunnitelmalliseen proaktiiviseen toimintaan, reaktiivisen sekoilun sijaan. Näin päästään tilanteeseen, jossa päähuomio ei ole ongelmien ratkaisemissa, vai asioiden tekemisestä niin, ettei ongelmia synny!

Kehittämistapeita käsittelevä virtuaalitiimi käsittelee kaikki kehittämistarpeet. Tiimi koostuu mm. seuraavista rooleista: asiakasvastaava, palvelumuotoilija, arkkitehti, tuoteomistaja. Virtuaalitiimin toimintaa fasilitoi Lean Manager, tai vastaava rooli, joka vetää palaverit ja toimii Scrum Master –tyyppisenä roolina. Jokaisen kehittämiskohteen etenemisestä vastaa rooli, joka omistaa kehittämiskohteen. Se voi olla esim. kehittämistarpeen tuonut asiakasvastaava, tai kehitysvastaava, tai tuoteomistaja, organisaation roolinimikkeistä riippuen.

Kehittämistarpeita käsittelevä tiimi organisoituu moniammatillisena virtuaalitiiminä. Osallistujina esimerkiksi seuraavia rooleja: asiakasvastaavat, arkkitehdit, tekniset asiantuntijat + muut tarvittavat asiantuntijat. Tiimi kokoontuu Scrum-palaverikäytäntöjä soveltaen viikkopalavereissa, ja järjestää demot, katselmoinnit sekä retrospektiivit yms. sovitun sprintin pituuden mukaan. Tiimi tuottaa konsepteja kehitysportfolioon. Tiimin tehtävät hallitaan Kanbanilla (esimerkki kuvassa alla), jota käydään viikottaisissa palavereissa läpi. Kehittämistarpeet tuodaan ensin idebacklogiin, josta ne otetaan käsittelyyn. Kehittämistarpeet voivat olla esimerkiksi asiakas- tai liiketoimintalähtöisiä, strategialähtöisiä tai teknologialähtöisiä. Ideoista valmistellaan konsepteja, joista valitut etenevät kehittämisvaiheeseen, ja lopulta tuotantoon.

Arkkitehtitiimin arkkitehdit osallistuvat kehittämiskohteiden läpivientiin heti alusta alkaen. Arkkitehdit vastaavat kehittämiskohteiden kuvauksista, ja siitä, että tarjolla on tilannekuva organisaation toiminnasta ja rakenteesta, jonka osaksi kehittämiskohteet tulevat. Arkkitehtitiimi toimii kuten mikä tahansa ketterä kehitystiimi, ketterän tiimin käytäntöineen: backlog, Kanban, viikkopalaverit jne. (kuva alla). Arkkitehtitiimi voi olla myös virtuaalinen, organisaatiosta riippuen.

Arkkitehtuuria kuvataan tarvelähtöisesti (on-demand, just in time) ja vain riittävästi (just enough) kokonaisarkkitehtuurin kuvausvälineen kuvauskantaan (repositorioon), jossa oleva kokonaisarkkitehtuurin arkkitehtuurisisältö kasvaa pikku hiljaa. Tarkoitus on välttää turhaa etukäteissuunnittelua (Big Design Up Front, BDUF) ja varastoon tekemistä (just in case). Ajan myötä kokonaisarkkitehtuurin tilannekuva (architeture landscape) täydentyy, ja se kattaa päivä päivältä yhä enemmän organisaation toiminnasta ja rakenteesta. LeanEA:n periaatteiden mukaan, sisältöä syntyy jatkuvasti kun laaditaan kaavioita nykytilaan, tavoitetilaan tai niiden yhdistelmiin liittyen. Ketterässä arkkitehtuurityössä ei ole tarkoitus tehdä pitkiä ja massiivisia viikkojen tai kuukausien kuvausponnisteluja, vaan tuottaa nopeasti näkyviä tuotoksia julkaistavaksi kuvausvälineen portaalissa.

Kokonaisarkkitehtuurin tilannekuva on kuvausvälineen kuvauskannassa (repositoriossa) oleva organisaation toiminnallisten ja rakenteellisten elementtien, sekä niiden välisten yhteyksien muodostama kokonaisuus. Arkkitehtien tehtävänä on ylläpitää tilannekuvaa. Se täydentyy jatkuvasti, ja kaikki kuvaukset myös julkaistaan jatkuvasti kuvausvälineen portaalissa, kaikille kehittämistoimintaan osallistuville tai siitä kiinnostuneille organisaation eri rooleissa toimiville. Kuvauksia, eli arkkitehtuurituotoksia, syntyy pääsääntöisesti ideasta-tuotantoon -prosessin kautta, sitä mukaa kun kehittämistarpeita käsitellään. Osasta niistä muodostuu kehittämiskohteita, joista syntyy ratkaisuja tuotantoon (tehdään itse tai hankitaan). Kuvauksia tehdään vain tarvelähtöisesti (just in time), ei varastoon (just in case), ja vain riittävästi (just enough) – Lean-filosofian periaatteiden mukaisesti.

On nopeampaa, helpompaa ja hyödyllisempää ylläpitää yhtä tilannekuvaa, kuin erillisiä nyky- ja tavoitetiloja. Ensinnäkin: nykytilan kattava kuvaaminen koko organisaatiosta on työläs harjoitus, ja nykytilan kuvauksen ylläpitäminen ajan tasalla vaatii jatkuvaa työtä. Jos sen lisäksi laaditaan erillinen tavoitetilan kuvaus, on arkkitehdeilla ylläpidettävänään kaksi eri mallia. Liiketoimintaympäristön muutosnopeus lisääntyy jatkuvasti, maali liikkuu, ja tavoitetila elää. Tavoitetila toteutuu harvoin, jos silloinkaan, sellaisena kuin se alunperin suunniteltiin. Mitä pidemmälle katsotaaneteenpäin tulevaisuuteen, sitä enemmän epävarmuustekijöitä esiintyy. Joten tavoitetilaa tulee jatkuvasti päivittää, kuten nykytilaa. Siksipä, sen sijaan että laaditaan erillisiä nyky- ja tavoitilan kuvauksia, on mielekästä kuvata tarvelähtöisesti jokin rajattu kokonaisuus (kehittämiskohde, kohdealue jne.) silloin, kun se tulee ajankohtaiseksi ideasta-tuotantoon -prosessin kautta. Tällöin analysoidaan nykytilaa sen verran kuin katsotaan tarkoituksenmukaiseksi, ja samalla tunnistetaan muutoskohteet jotka kohdistuvat tähän samaan kokonaisuuteen. Näin voidaan kuvata saman aikaisesti, samassa kuvassa, sekä olemassa oleva nykyinen tilanne ja siihen liittyvät tavoitteena olevat muutokset.

Mallintamisen avulla nykyiset elementit ja tunnistetut uudet elementit voidaan erottaa esimerkiksi väreillä toisistaan, jos ne esiintyvät samassa kaaviossa. Ketterä, kevyt, nopea ja kaikkein hyödyllisin tapa kuvata kokonaisarkkitehturia on yhdistää tilannekuva -mallintamisessa nykyisyys ja tulevaisuus. Tilannekuva = nykytila + tavoitetila. Mikään ei estä tekemästä erillisiä nyky- ja tavoitetilakuvauksia. Mutta tilannekuva on aina “näkymä” organisaatioon, tai johonkin sen rajattuun osa-alueeseen, olipa kyseessä a) nykyinen tai b) tavoitteena oleva uusi asiantila, tai c) näiden yhdistelmä.

Innovointitiimi osallistuu tarpeen mukaan kehittämiskohteiden innovointikokeiluihin, kun haluitaan saada nopeita kokeiluja tai  protoja aikaan klehittämiskohteista, tai kun halutaan kokeilla aivan uusia ideoita joilla olisi hyödyntämispotentiaalia.

Ketterät kehitystiimit kehittävät kehittämiskohteista valmiita palveluita tuotantoon. Kehittämisvaiheessa tehdään myös esimerkiksi hankintaa, toimintamallin muutoksia, kokeiluja ja pienkehitystä.

Lähtökohtaisesti kaikkien tiimien tulisi organisoitua ja perustua ketterien menetelmien (Scrum) käytäntöjen mukaisesti. Kehittämisen työjonojen tulisi olla läpinäkyviä, esimerkiksi sähköistä Kanban-taulua hyödyntäen. Sovitulla frekvenssillä toistuvat palaverikäytännöt (daily scrums) ja niihin liittyvät rituaalit (demot, retrospektiivit, suunnittelut) tulisi olla organisaatiossa laajasti käytössä. Ketterät kehitystiimit organisoituvat nykyisin tuote-käsitteen ympärille enimmäkseen (aikaisemmin kehittäminen “projektoitiin” projektiksi useimmiten). Kehitystiimi kehittää tuotetta, jonka liiketoiminnan vastaavuudesta huolehtii liiketoiminnan edustajana tuoteomistaja (Product Owner) -rooli. Muut kehitystiimin roolit ovat tyypillisesti Scrum-menetelmän mukaisia (kuten Scrum Master).

Kaikki kehittämistoiminta on kuitenkin lähtökohtaisesti organisoitu ketterän kehittämisen ja itseohjautuvien tiimien muotoon, jolloin kehittämisen etenemistä seurataan ja tuotoksia demotaan ketterien käytäntöjen mukaisesti. Palveluiden hallintatiimi ja esim. palvelupäälliköt hallinnoivat palveluita tuotannossa.

Koko kehittämisten toimintamallia, eli ideasta-tuotantoon prosessia, kehittää ja ohjaa erityinen kehittämisen ohjausryhmä, johon osallistuu Lean Managerin ja valittujen roolien lisäksi myös organisaation johdon edustus.

4.2.2 LeanEA viitekehys

Lean EA-viitekehys (kuva alla) tarjoaa uuden tavan tehdä kokonaisarkkitehtuuria. Oleellista viitekehyksessä on, että se yhdistää kokonaisarkkitehtuurin kuvaamisen ja mallintamisen (taso-2) organisaation kehittämismalliin (taso-1), ja tukee näin organisaation liiketoimintalähtöistä kehittämistoimintaa käytännönläheisesti ja konkreettisesti.

Lähtökohtaisesti LeanEA-viitekehyksen etusivun kehittämismalli (taso-1) perustuu tyypilliseen PLAN-BUILD-RUN –lähestymistapaan, johon ideasta-tuotantoon arvoketju pohjautuu. LeanEA-viitekehyksen päähuomio onkin asiakkaalle tuotettavan arvon tuottamisessa (value delivery chain). Tapauskohtaisesti LeanEA-viitekehyksen etusivun (tason-1) kehittämisen toimintamalli muotoillaan organisaation kehittämisen toimintamallia vastaavaksi. Vaihtoehtoisesti kehittämismalli voi perustua esimerkiksi SAFe:n tai IT4IT:n kaltaiseen arvoketjuun, kohdeorganisaation kehittämistoiminnan luonteesta riippuen. Kehittämisen toimintamalli kannattaa muotoilla arvovirraksi (vrt. SAFe Development Value Stream), jotta kehittämistoimintaan liittyvät kyvykkyydet ja niitä vastaavat toimijat voidaan tunnistaa ja kytkeä arvovirtaan (kts. “Value Stream Modelling“). Varsinaiset organisaation operatiiviset arvovirrat (vrt. SAFe Operational Value Streams) puolestaan kuvataan tason-1 yläosaan yhdessä liiketoimintamallin kanssa. Näiden operatiivisten arvovirtojen avulla voidaan kuvata liiketoimintalähtöisesti mm. miten organisaatio tuottaa arvoa asiakkaalle. Yläosassa “Johtaminen” kuvataan myös organisaation kyvykkyydet (kyvykkyyskartta). Kyvykkyydet voidaan johtaa strategisten tavoitteiden päättelyketjun seurauksena (“Tavoitteet-näkymä”), ja kyvykkyydet voidaan kytkeä arvovirtoihin kuvaaman liiketoimintamallia (Business Model). Arvovirtaa vastaava tarkemman tason toimintamalli (Operating Model) kuvataan prosessina LeanEA-viitekehyksen sisältöalueelle (taso-2).

LeanEA-viitekehyksen etusivu (taso-1) on siis näkymä organisaation johtamiseen ja liiketoiminnan kehittämiseen, kun taas kehyksen alasivut (taso-2) ovat näkymiä organisaation osa-alueisiin (domain). Osa-alueet voivat perustua, organisaation toimialasta ja toiminnan luonteesta riippuen, joko tyypillisiin organisatioyksiköihin, liiketoiminta- tai palvelualueisiin, operatiivisiin arvovirtoihin yms.

Valmis, kuvausvälineeseen implementoitavissa oleva LeanEA-mallipohja voidaan ottaa käyttöön nopeasti ja helposti. Lean ja ketterä tapa tehdä kokonaisarkkitehtuuria voidaan aloittaa heti päivästä yksi alkaen. LeanEA-viitekehys sisältää susoiteltavat kaaviotyypit, sekä niihin liittyvät esimerkit ja ohjeistuksen. LeanEA-viitekehys on ArchiMate 3 yhteensopiva. Itse asiassa, LeanEA-viitekehyksen kokonaisarkkitehtuurin sisältönäkymä (taso-2) perustuu ArchiMate -viitekehykseen.

Alla olevassa kuvassa on esitetty LeanEA-viitekehyksen tasot tarkemmin.

Alla olevassa kuvassa on esitetty kaavioiden sijoittelu LeanEA-viitekehyksen tasolle kaksi (2).

LeanEA-viitekehys on yhteensopiva muiden viitekehyksien (kuten esimerkiksi JHS179, ArchiMate 3, Togaf 9.x, IT4IT, SAFE, ITIL 4 jne.) kanssa.

Edellä mainittujen viitekehyksien lisäksi LeanEa-viitekehys mukautuu esim. DevOps –tyyppiseen kehittämiseen. LeanEA-viitekehyksen etusivun (taso-1) rakenne vastaa ns. BizDevOps -lähestymistapa.

LeanEA-viitekehys referenssitoteutuksia: Vantaan kaupunki (2017), Kela (2018).

Tarkemmin Lean EA:sta täällä: linkki.

5. Kokonaisarkkitehtuurin mallintaminen käytännössä

5.1 Miksi kokonaisarkkitehtuurin mallintamista?

Miksi tehdä kokonaisarkkitehtuurin mallintamista? Miksi vaivautua?
Silloin, kun:

• halutaan ymmärtää kehittämiskohteen tai kohdealueen kokonaisuutta ja hallita sen monimutkaisuutta
• kyseessä ovat uudet kehittämiskohteet, muutokset organisaation toimintaan ja rakenteeseen
• käsillä on uusi ja tuntematon asia, on luonnollista, että järkevintä mitä voidaan tehdä on suunnitella se huolella
• kehittämiskohde on tärkeä liiketoiminnan kannalta tai asiakaskäyttäytymisen kannalta
• halutaan ymmärtää liiketoiminta johon kehittämiskohde liittyy
• kehittämiskohteen toiminta on monimutkaista
• kehittämiskohde on laaja-alainen
• kehittämiskohteeseen liittyy paljon osapuolia: toimijoita, prosesseja, järjestelmiä, ja paljon integraatioita eli riippuvuuksia

Kysymys on siitä, että on tarve ymmärtää kehittämiskohteen tai muutoksen osalta, miksi se tarvitaan, mitä se käsittää ja mihin se liittyy – eli mihin se vaikuttaa. Kysymys on lopulta laadusta: sitä laadukkaampia ja asiakkaalle eniten arvoa tuottavia lopputuloksia saadaan aikaan, mitä paremmin tunnetaan ja suunnitellaan kehittämiskohteen toiminnalliset ja rakenteelliset osat sekä niiden väliset suhteet.

5.2 Miten kokonaisarkkitehtuuria mallinnetaan?

• Aloitetaan tavoitteiden mallintamisesta, miksi kehittämiskohde tarvitaan, mitä sillä tavoitellaan ja halutaan aikaansaada?
• Kuvataan konteksti, kehittämiskohteen kokonaisuus kerrosnäkymällä
• Kuvataan informaatio (käsitemalli ja/tai tietomalli)
• Kuvataan integraatiot tarpeen mukaan (toimijoiden, prosessien tai sovellusten välillä)

5.3 Kokonaisarkkitehtuurin mallintamisen periaatteet

Kokonaisvaltaisuus

• Huomioidaan kaikki kehittämiskohteeseen vaikuttavat osatekijät (holistinen lähestymistapa)
• Kuvataan liiketoimintaa, sovelluksia ja teknolgiaa – kokonaisuutena, tarkoituksenmukaisesti soveltaen

Kuvataan vain tarpeeseen (just in time)

• Kuvauksia tehdään kehittämiskohteita varten, sitä mukaa kun niitä virtaa kehitystarpeina sisään (On-demand) – kehittämisen toimintamallin ideasta-tuotantoon -prosessiin
• Arkkitehtuurityö on integroitu kehittämismalliin, tekeminen on läpinäkyvää, kaikki tuotokset julkaistaan jatkuvasti, mallinnusta tehdään vain kehittämiskohtesiin, ei varastoon

Kuvataan vain riittävästi (just enough)

• Kuvataan tarkoituksenmukaisesti, tapauskohtaisesti arvioiden, mikä on oleellista juuri tässä vaiheessa, mikä on kuvauksen MVP (Minimum Viable Product) taso, eli millä päästään eteenpäin. Tai MVA (Minimum Viable Architecture), jos halutaan korostaa arkkitehtuurin osuutta kehittämiskohteessa.
• Tarkennetaan ja täydennetään myöhemmin – kuvaukset täydentyvät välineessä – Tilannekuva elää

Mallinnetaan niin vähän kuin mahdollista, mutta niin paljon kun tarvitaan (as little as possible but as much as needed) [Marc Lankhorst]

• Ei lisätä liikaa yksityiskohtia – ellei se ole välttämätöntä (KISS, Keep It Simple, Stupid! – Yksinkertaisuus!)

• Mallin ylläpito on helpompaa ja malli on hyödyllisempi kun sisältöä on vähemmän ja se on ymmärrettävää (Less Is More! – Vähemmän on enemmän!)

5.4 Arkkitehtuurituotokset ja laatu

Tavoitteena ovat laadukkaat arkkitehtuurituotokset. Laadukkan arkkitehtuurituotoksen piirteitä ovat:

• Asiakasarvo, asiakkaalle tuotettava hyöty on tärkeintä, kaikki muu on sille alisteista
• Oleellisen tunnistaminen
• Riittävä tarkkuus ja laajuus
• Selkeys, ymmärrettävyys
• Vaikuttavuus, hyödynnettävyys (kaavioilla on arvoa jos niistä on hyötyä käytännössä)
• Johdonmukaisuus
• Kokonaisvaltaisuus
• Kerroksellisuus
• Standardinmukaisuus

Mallintaminen nostaa arkkitehtuurityön lopputulosten laatua.

Asiakkaan kokemassa arvossa on kyse laadusta: laadukkaampi lopputulos on arvokkaampi. Mitä laadukkaampi lopputulos, sitä tyytyväisempi asiakas. Asiakas päättää onko lopputulos laadukas. Asiakkaasta on siis syytä pitää huolta.

Noin yleisesti ottaen, laatua on vaikea määritellä. Sitä joko on tai ei ole. Tiedämme kyllä milloin sitä on, ja milloin ei. Tiedämme mikä on laadukas lopputulos, mikä ei. Laadun arvostaminen on kuitenkin se syy, miksi asioita kannattaa tehdä hyvin, kuten mallintamista.

Arkkitehtuurin mallintamisessa lähes aina on hyödyllisintä itse mallinnusprosessi, jonka aikana yhdessä tarkastellaan kehittämiskohdetta, ja pyritään löytämään kaikki siihen liittyvät oleelliset seikat. Mallintaminen on erinomainen tapa löytää juuri se oleellinen, ja tehdä se näkyväksi. Kun tämä näkemys on yhdessä jaettu, on kehittämiskohdetta helpompi kehittää. Mallintaminen nostaa arkkitehtuurityön lopputulosten laatua, ja sitä kautta asiakas- ja liiketoimintalähtöisten kehittämiskohteiden laatua.

Mallintamisessa hyödyllisintä on itse mallinnusprosessi, jonka aikana yhdessä tarkastellaan kehittämiskohdetta, ja pyritään löytämään kaikki siihen liittyvät oleelliset asiat – samalla kun visualisoidaan.

Mallintaminen on erinomainen tapa löytää kehittämiskohteesta juuri se oleellinen, ja tehdä se näkyväksi.
Kun tämä näkemys on yhdessä jaettu, on kehittämiskohdetta helpompi kehittää.

5.5. Kokonaisarkkitehtuurin mallintamisen kokonaisvaltainen ajattelu

Kokonaisvaltainen ajattelu on yhdistelmä seuraavista:

• Tavoitelähtöisyys ja arvon tuottaminen asiakkaalle kaiken tekemisen ytimessä
• Holistinen lähestymistapa (huomioidaan liiketoiminta sekä tiedot ja järjestelmät kokonaisuutena)
• Tarkastellaan kokonaisuutta systeeminä – systeemiajattelu
• Kerrosmainen lähestymistapa
• Palvelupohjainen lähestymistapa – asiakaslähtöisyys
• Arvovirta-ajattelu
• Kyvykkyyspohjainen suunnittelu
• Lean-ajattelu

Holistinen lähestymistapa, huomioidaan kaikki osat ja tasot kokonaisuutena, jossa kaikki vaikuttaa kaikkeen: ”kokonaisuus on enemmän kuin osiensa summa”. Tarkastellaan kokonaisuutta systeeminä, organisaatio on systeemien systeemi – systeemiajatelu. Ja jos tarkastellaankin jotakin kokonaisuuden osaa, kuten organisaation yksikköä, silloinkin sitä tarkastellaan kokonaisarkkitehtuurin kaikki kerrokset huomioiden: liiketoiminta-, sovellukset ja teknologiat.

Kerrosmainen lähestymistapa, huomioidaan kokonaisvaltaisesti kehittämiskohteen liiketoiminta, sovellukset ja teknologia, mahdollisuuksien mukaan.

Palvelupohjainen lähestymistapa, korostaa asiakaslähtöisyyttä, mitä asiakas tarvitsee, mikä tuottaa asiakkaalle arvoa, selviää kun aloitetaan palvelusta ja palvelukokemuksesta asiakkaan lähtökohdista. Tässä hyödynnetään muotoiluajattelua.

Tavoitelähtöisyys, aloitetaan aina kysymällä miksi? Mitä tavoitellaan, mitkä halutaan saada aikaan, eli mitkä ovat lopputulokset? Ja miten ne saavutetaan? Eli tavoitteiden jälkeen pyritään tunnistamaan konkreettiset toimenpiteet.

Tunnistetaan kunkin liiketoimintamallin arvovirta: miten asiakasarvoa tuotetaan organisaatiotasolla, mitä kyvykkyyksiä arvon tuottamiseen osallistuu ja millä panoksella? Eli tunnistetaan mitä kyvykkyyksiä organisaatio tarvitsee, toteuttaakseen tavoitteiden ja arvovirran mukaiset lopputolokset. (Huom! Operatiivisten arvovirtojen lisäksi organisaatiolla on kehittämisen arvovirtoja.)

Kaikessa tekemisessä pyritään noudattamaan Lean-filosofiaa ja ketterien menetelmien periaatteita. Tällaisia ovat esimerkiksi keskittyminen kehittämistoiminnan virtausnopeuteen ja läpinäkyvyyteen kaikessa toiminnassa.

Kokonaisarkkitehtuuri ja organisaatiokulttuuri

Kokonaisarkkitehtuuri on organisaation ”kova” puoli, mekanistinen ja tekninen luonteeltaan. Kulttuuri on organisaation pehmeä puoli, organisaatioyksiköiden ja niissä toimivien henkilöiden vuorovaikutussuhteet ovat merkittävä onnistumisten ja epäonnistumisten lähde. Kyse on saman kokonaisuuden eri puolista, jotka molemmat tulee huomioida, jotta toiminta olisi mahdollisimman tehokasta, ja joissain organisaatioissa voitaisiin edetä kohti Leaniä organisaatiota. Kun mallinnetaan ja tehdään kokonaisarkkitehtuurityötä, tulee huomioida työntekijöiden näkökulma, eli ns. työntekijäkokemus. Sen tulee olla kehittämisen toimintamallia tukeva, jotta organisaation kulttuuri ei olisi kehittämisen toimintamallin hidaste, vaan kiihdytin.

6. Lopuksi

• Organisaatiolla on aina kokonaisarkkitehtuuri
• Kokonaisarkkitehtuuri ilmentää organisaatiota
• Kokonaisarkkitehtuurissa on kyse organisaation toiminnasta ja rakenteesta, sekä tämän monimutkaisen kokonaisuuden ymmärtämisestä, kehittämisestä ja hallinnasta
• Toiminta ja rakenne voidaan mallintaa
• Malli on kokonaisarkkitehtuuri
• Kokonaisarkkitehtuurimalli on organisaation “digitaalisen kaksosen” perusta.

Kun halutaan ymmärtää kokonaisuutta ja hallita sen monimutkaisuutta

Kokonaisarkkitehtuurin mallintamisessa on kyse organisaation toiminnallisten ja rakenteellisten osien, sekä näiden välisten yhteyksien kuvaamisesta. Mallinnettu kokonaisarkkitehtuuri tukee organisaation johtamista, kehittämistä ja päätöksentekoa.

Entä se Zen tässä yhteydessä? Zen on se oikea asenne. Ammatillinen suhtautuminen mallintamiseen. “Mallintaminen on helppoa, jos on oikea asenne. Mutta oikean asenteen omaksuminen on vaikeaa.” (Robert M. Pirsigiä mukaillen). Kun mallintaa usein ja paljon, mallintaminen muuttuu koko ajan helpommaksi, ja sen myötä hyödyllisemmäksi apuvälineeksi. Mallintamista voi tällöin hyödyntää kaikkien(!) kehittämiskohteiden yhteydessä.

Mallintamista on turha yrittää selittää kaikille, koska kaikki eivät sitä tule koskaan ymmärtämään.
Sitten on joukko ihmisiä, joille sitä kannattaa yrittää selittää, jotta he ymmärtäisivät.
Sitten on joitakin ihmisiä, jotka ymmärtävät selittämättäkin.

_________________________________________________________________________________________________________________

– Eero Hosiaisluoma