Lean EA ja organisaation kehittämistoiminta

Lean EA -lähestymistapa yhdistää organisaation johtamisen, operatiivisen kehittämistoiminnan ja kokonaisarkkitehtuurin. Lean EA-lähestymistavassa hyödynnetään olemassa olevia menetelmiä ja välineitä sekä parhaita käytäntöjä (kuten muotoiluajattelua), mutta kokonaisuuden hallinnan kannalta tärkein on kokonaisarkkitehtuuri (KA).

Tärkeintä on liiketoiminnan kehittäminen asiakaslähtöisesti. Organisaation (liike)toiminnan johtaminen ja kehittäminen on keskeistä. Kokonaisarkkitehtuurin rooli ja merkitys on tukea edellisiä. Lean EA -lähestymistavassa kokonaisarkkitehtuuri on integroitu osaksi organisaation kehittämistoimintaa.

Huom! Tässä yhteydessä on kyse liiketoiminnan johtamisesta, ei ihmisten johtamisesta! Paino sanalla “toiminta“.

Lean

Mitä on Lean? Perusidea on maksimoida asiakasarvo ja minimoida arvoa tuottamaton hukka. Päämääränä on tuottaa asiakasarvoa keskittymällä prosessin läpivirtaukseen ja tehokkuuteen. On väärinkäsitys mieltää Lean soveltuvaksi vain valmistavan teollisuuden tuotannolliseen toimintaan, ja sen prosessien virtaviivaistamiseen. Lean soveltuu kaikille toimialoille, kaikenlaiseen liiketoimintaan ja julkishallintoon. Lean soveltuu, ei ainoastaan valmistavan teollisuuden, vaan kaikenlaisen toiminnan prosesseihin. Lean ei ole vain strategis-taktisen tason tai kustannusten vähentämisen ohjelma, vaan Lean on koko organisaatioon ja kaikille sen tasoille soveltuva tapa ajatella ja toimia. [Lean Enterprise Institute]

Lean -filosofia on toimintatapa (toimintastrategia) ja ajattelumalli, joka korostaa virtaustehokkuutta, ei resurssitehokkuutta. Leania voi soveltaa kaikenlaisten organisaatioiden johtamisessa, kehittämisessä ja operatiivisessa toiminnassa. Leanin periaatteet ovat hyvin yksinkertaiset, ja niitä voi soveltaa lähes kaikkeen. Kyse on toiminnan sujuvoittamisesta asiakasarvon tuottamiseksi.

Asiakasarvo tarkoittaa asiakkaan kokemaa arvoa organisaation tarjoamista palveluista tai tuotteista. Arvo voi olla esimerkiksi rahallista (kuten hyöty, voitto, säästö), laadullista (esim. tunne, etu, potentiaali, käytettävyys, ajan säästö, mukavuus, helppous) tai toiminnallista (apu, tuki, ohjaus, opastus, kontribuutio/osaaminen, ratkaisu jne.). Asiakasarvoa tuotetaan laadulla: arvoa syntyy laadulla ja laadusta. Kaikki toiminta organisaatiossa tulisi olla alisteista asiakasarvon tuottamiselle, joko suoraan tai välillisesti. Arvo on sitä josta asiakas olisi valmis maksamaan, siksi tulisikin aina kysyä “maksaisiko asiakas tästä?” kun jotain tehdään. Arvon muodostuminen alkaa asiakkaan tarpeesta, joka kohdistuu organisaatioon kysyntänä (demand), johon organisaatio pyrkii tarjoamaan asiakasta tyydyttävän toteutuksen. Lopputulos on sitä parempi, mitä paremmin organisaatiossa on ymmärretty asiakkaan tarve. Ja mitä laadukkaampi lopputulos, sitä parempi on asiakkaan kokema arvo.

Laatu on kaikkea sitä, minkä asiakas kokee täyttävän tarpeen. Laatuun sisältyy monia erilaisia asioita, kuten kyky tarjota parempi kokemus, parempaa ja nopeampaa palvelua sekä enemmän vaihtoehtoja.

Asiakaskeskeisyys on Leanin ydin: asiakkaan tarpeiden tyydyttäminen eli asiakasarvon tuottaminen on organisaation pääasiallinen tapa toimia. Tällöin keskitytään virtaustehokkuuteen asiakkaan näkökulmasta. Toissijaista on organisaation sisäinen resurssitehokkuus. Perinteisesti organisaatiot ovat resurssikeskeisiä: sisäinen resurssitehokkuus on ollut tavoite. Lean korostaa asiakaskeskeistä virtaustehokkuutta, eli asiakasarvon tuottamista laadukkaalla toiminnalla.

Asiakas -käsite ei kuitenkaan ole aina selkeä, vaikka arvon katsotaan määräytyvän aina asiakkaan näkökulmasta. Esim. kuka on julkishallinnon asiakas, kuka palokunnan? Jos asiakasta on vaikea tunnistaa, voidaan kiinnittää huomion tarpeisiin, joita organisaatio tyydyttää. Tällöin kysytään: mikä tarve tyydytetään? Näin selviää mistä palvelusta on kyse. Silloin prosessi määritellään alkavaksi sinä hetkenä, jona palvelutarve tunnistetaan, ja päättyväksi, kun tarve on tyydytetty.

Virtaustehokkuus kohdistaa huomion organisaatiossa jalostettavaan yksikköön. Valmistavassa teollisuudessa yksikkö on fyysinen tuote, jota jalostetaan tuotantolinjalla erilaisilla materiaaleilla. Palvelualoilla yksikkö on useimmiten asiakas, jonka tarpeita täytetään erilaisin toiminnoin. Virtaustehokkuudessa päähuomio on yksikössä, joka ”virtaa” organisaation läpi. Tätä yksikköä sanotaan virtausyksiköksi. Virtaustehokkuutta voidaan mitata. Virtaus alkaa tarpeen tunnistamisesta ja päättyy siihen, kun tarve on tyydytetty.

Virtausyksikkö voi olla materiaalia, informaatiota tai ihmisiä. Palveluliiketoiminnassa (sektorista tai toimialasta riippumatta) virtausyksikkönä voi olla ihminen, joka saa arvoa organisaation palveluista. On huomattava, että vaikka organisaatiossa on tarjolla myös – tai ainoastaan – tuotteita, nekin voidaan nähdä vain koostettuina konfiguraatioina, jolloin lopulta on kyse palveluista. Organisaation kehitystoiminnassa “liukuhihna” on esimerkiksi kehittämisen arvoketju, jossa virtausyksikkönä on kehittämiskohde, eli asiakaslähtöinen kehittämistarve.

Palvelulähtöisyys: “Start thinking every organization is a service organization. Everything we do in business should be considered as a service .” [ITIL4]

Prosessi on virtaustehokkuuden perusta. On tärkeää ymmärtää, miten organisaation prosessit toimivat, sillä virtaustehokkuus syntyy niissä. Kaikilla organisaatioilla on prosesseja. Virtaustehokkuuden maksimoimisessa pyritään minimoimaan turhaa työtä eli hukkaa ja erilaisia häiriöitä (kuten häiriökysyntää, jota syntyy, kun asioita ei tehdä kerralla kuntoon). Virtaustehokkuuden luomisessa keskitytään siihen organisaation liukuhihnamaiseen prosessiin virtausyksikön näkökulmasta.

Arvoa muodostuu, kun virtausyksikölle tapahtuu jotain ja kun se etenee (ja jalostuu) prosessin aikana. Arvoa tuottavat toiminnot ovat niitä, joiden aikana virtausyksikkö jalostuu jollain tavalla. Vastaavasti toiminto on arvoa tuottamaton, jos virtausyksikkö ei sen aikana jalostu.

Hukat ja häiriöt aiheuttavat tehottomuutta ja virtaustehokkuuden heikkenemistä, joten niiden syntymistä tulisi ennalta ehkäistä. Tyypillisiä hukan ja häiriöiden syitä ovat: 1) odottelu (asioiden valmistuminen tai ihmisten kiinni saaminen kestää), 2) tarpeeton tavaroiden tai informaation siirtely, 3) ylikäsittely (ylisuunnittelu, liian tarkka ja yksityiskohtainen työ, usein arvosana 8 riittää ja 80% valmis on ok), 4) tarpeettomat varastot (ei tehdä asioita varastoon turhaan tai liian aikaisin), 5) tarpeeton liike (ihmiset, esineet, asiat), 6) virheellinen palvelu tai tuote (virheiden korjaus maksaa aikaa, rahaa ja sitoo henkilöitä), 7) ylituotanto (tehdään yli tarpeen, mikä on pahinta hukkaa; tulisi tehdä oikea-aikaisesti, just in time, ja vain tarpeeseen, eli riittävästi, just enough ja aina ensin MVP, Minimum Viable Product, eli pienin mahdollinen toimiva ratkaisu) ja 8) osaamisen käyttämättä jättäminen (ei luoteta ihmisiin, mikä on usein seurausta johtamisen ongelmista).

Visualisoininti on Leanissa keskeistä: kaikki asiat pyritään tekemään näkyviksi: tehtävät, tuotokset, suunnitelmat, toteumat jne. Mielellään yhdellä silmäyksellä (kuvauksissa suositaan ns. one-pagereitä kuten Business Model Canvas, BMC). Työn näkyväksi tekeminen tarkoittaa erilaisten visualisointien hyödyntämistä osana työn ohjausta ja viestintää. Esimerkiksi Kanban-taulu (sähköinen tai fyysinen) on tyypillinen väline tehtävien hallintaan ja edistymisen (=työn virtauksen) seurantaan.

Jatkuva parantaminen (Kaizen) on Leanin perustavanlaatuinen ominaispiirre, jolla pyritään kaikessa toiminnassa jatkuvasti suoriutumaan paremmin, nopeammin ja kustannustehokkaammin. Jatkuvasti pyritään opettelemaan ja oppimaan parempia työn tekemisen tapoja, paremman asiakasymmärryksen ja -kokemuksen aikaansaamista, parempien lopputulosten tuottamista jne. Ennen kaikkea pyritään laadun parantamiseen – kaikessa tekemisessä. Tavoitteena on työn laatu, ts. asioiden tekeminen laadukkaasti, joka taas tuottaa asiakkaalle arvoa. Jatkuvasti pyritään tekemään asioita järkevämmin. Pyritään tekemään oikeita asioita, ja asioita oikein ja oikea-aikaisesti. Siksi edistymistä kannattaa mitata ja seurata, jotta tapahtuu oppimista. Jatkuvassa parantamisessa voidaan hyödyntää erialisia menetelmiä. Eräs tällainen on PDCA (Plan, Do, Check, Act), eli suunnittele, tee, tarkista, muuta -sykli (Deming, W. E., 1993), jonka mukaisesti toimintaa voidaan jatkuvasti parantaa.

Lähteet: [1] Tätä on LEAN, Modig M., Åhlström P., 2013, [2] Arjen Lean, Määttä E., Määttä K., 2021

Yleisiä Lean EA -periaatteita ja tavoitteita

Mikä on Lean EA? Lean EA on Lean-periaatteisiin pohjautuva kehittämisen toimintamalli, johon integroitu EA-toiminta. Siksi nimi Lean EA. Tarkemmin täällä: Lean EA – toimintamalli ja viitekehys.

Yleiset Lean EA-periaatteet periytyvät Lean-filosofiasta, joka perustuu tuotannollisen toiminnan tehostamiseen: asiakasarvoa tuottavan toiminnan maksimointiin ja arvoa tuottamattoman toiminnan minimointiin. Lean EA:ssa kohteena ensisijaisena kohteena on organisaation kehittämistoiminnan tehostaminen, jota toimintaa kokonaisarkkitehtuuri tukee. Kehittämistoiminta on pääroolissa, kokonaisarkkitehtuuri on sivuroolissa. Mutta Lean EA:ssa kokonaisarkkitehtuurin rooli ja merkitys on keskeistä, sillä sen avulla tuetaan ja mahdollistetaan tehokas kehittämistoiminta. Käytännössä kokonaisarkkitehtuuri on integroitu osaksi kehittämistoimintaa, jonka kautta sen arvoa mitataan (kuten kaikkien muidenkin toimintojen).

Lean EA-lähestymistavalla tavoitellaan mm. seuraavia asioita:

#	Tavoite
1	Organisaation toiminnan ja rakenteen hallinnan parantaminen, sekä johtamisen ja kehittämistoiminnan tukeminen nopeammin, oikea-aikaisemmin, laadukkaammin ja tehokkaammin
2	Kehittämistoiminnan virtaustehokkuuden parantaminen
3	Kehittämistoimintaa tukevan resurssitehokkuuden parantaminen
4	Asiakasarvoa tuottavan ja mahdollistavan toiminnan maksimointi
5	Tarpeettoman, turhan, asiakasarvoa tuottamattoman toiminnan minimointi
6	Kehittämistoiminnassa huomioidaan liiketoiminta ja IT sekä ihmiset, kokonaisvaltaisesti

Periaatteista on luettavissa kokonaisarkkitehtuurin roolin ja merkityksen korostuminen. Periaate 1: “organisaation toiminta ja rakenne” tarkoittaa kokonaisuuden hallintaa, eli kokonaisarkkitehtuuria. Kokonaisarkkitehtuurin arvo ja hyöty liittyvät sen avulla saavutettavaan parempaan tietoon organisaatiosta. Tämä on tärkeätä aina kun organisaation kohdistuu muutoksia. Ja organisaatioon kohdistuu aina muutoksia. Muutos on jatkuvaa.

Lean EA:ssa fokus on “oikeiden” asioiden tekemisessä. Päähuomio on liiketoiminnan ja erityisesti asiakkaan tarpeissa. Samalla huomioidaan ihmiset: asiakkaat ja työntekijät. Molempien ryhmien tyytyväisyys on tavoite, ja samalla itse itseään ruokkiva myönteinen kehityskulku. Asiakastyytyväisyys on seurausta laadukkaista palveluista ja tuotteista, jotka taas ovat seurausta henkilöstötyytyväisyydestä, joka on hyvällä tasolla, jos on poistettu työskentelyn haittatekijät ja parannettu työn tekemisen tapoja. IT:n rooli on tukea liiketoimintaa: IT on keino, harvemmin itsetarkoitus.

Lean EA-toimintamallin periaatteita

Kehittämistoiminta organisoidaan kehittämisen arvoketjuksi (kuva alla), jonka alkuvaiheessa moniammatillinen ryhmä eri osaamisprofiilien ihmisiä yhdessä käsittelee liiketoiminnan tarpeita, ja lopulta hyväksyy soveltuvimmat kehitysportfolioon. Kehitysportfoliossa kehittämiskohteita arvioidaan, ne priorisoidaan ja resursoidaan. Tämän jälkeen ne etenevät kehittämisvaiheeseen, jossa tehdään tarvittavat muutostoimenpiteet jotka kohdistuvat organisaatioon (kunkin yksittäisen kehittämiskohteen osalta). Käytännössä kyse voi olla esim. prosessimuutoksesta, uuden järjestelmän toteuttamisesta tai hankinnasta (build or buy). Lopulta valmiit asiat siirtyvät osaksi organisaation operatiivista toimintaa, jossa IT-palveluita hallitaan palvelutuotannon prosesseilla ja menetelmillä (kuten ITIL4).

Kuvassa alla on havainnollistettu Lean EA -kehittämismalli, joka on organisaation kehittämistoiminnan ylätason malli. Sen avulla määritellään se kehittämistoiminta, jonka avulla on tarkoitus suunnitella ja toteuttaa arvoa tuottavia palveluita ja/tai tuotteita, sekä ylippätään muutoksia, jotka kohdistuvat organisaation operatiiviseen toimintaan. Kehittämismallissa tarkoiroitus on aikaansa tehokas virtaus “tarpeesta toteutukseksi” (Demand to Production, tai Idea to Production).

Lean EA-toimintamallin periaatteita:

#	Periaate	Kuvaus
1	Organisaation kehittämistoiminta organisoidaan kehittämisen arvoketjuun, jonka vaiheisiin kytketään tarvittavat kyvykkyydet	Tunnistetaan MITÄ organisaation kehittämistoimintaan liittyviä kyvykkyyksiä tarvitaan. Määritellään kehittämisen arvoketju ja sen vaiheet – ne määrittelevät MIKSI mitäkin kyvykkyyksiä tarvitaan.
2	Kaikki kehittämistarpeet käsitellään keskitetyn tarpeiden käsittelyn (Demand Management) kautta	Tarpeiden käsittely (Demand Management) on kehittämistoiminnan kyvykkyys (=toimija/toiminto), käytännössä moniammatillinen tiimi/ryhmä, joka vastaanottaa ja käsittelee ideat ja kehittämistarpeet.
3	Kokonaisarkkitehtuurin hallinta integroidaan osaksi organisaation kehittämistoimintaa ja kehittämisen arvoketjua	Kokonaisarkkitehtuurin arvo ja merkitys on johtamisen sekä kehittämistoiminnan tukeminen. Tässä roolissa kokonaisarkkitehtuuri on näkyvää, vaikuttavaa ja merkityksellistä.
4	Keskitytään asiakasarvoa tuottavan toiminnan maksimointiin ja arvoa tuottamattoman toiminnan minimointiin	Kaikessa toiminnassa määritellään tavoitteet ja lopputulokset jotka halutaan saada aikaan. Kiinnitetään huomioita että työn tekemisen tavat ovat mielekkäitä.

Lean EA:ssa kyse ei ole varsinaisesti ketteryydestä (agile), ei Agile EA:sta eli ketterästä kokonaisarkkitehtuurista, tai ketteryyden skaalaamisesta organisaatiotasolle – tästä on kyse korkeintaan toissijaisesti. Ketteryys on perimmältään ohjelmistokehityksen organisoinnin menetelmä tiimitasolla. Ja vaikka ketteryyden hyviä käytäntöjä on otettu käyttöön kaiken tyyppisissä tiimeissä, on ketteryyden skaalaaminen jo työläämpää toteuttaa organisaatiotasolla, tästä kertoo mm. SAFe-mallin epäonnistuneet kokeilut ja siihen kohdistuva kritiikki (esim. linkki, linkki, linkki). Organisaatio voi olla Lean (vrt. Lean Enterprise), mutta voiko organisaatio olla ketterä? Esim. Spotify Tribe-model (ns. heimomalli, linkki, linkki ja YouTube video) soveltuu organisaatioihin joissa painopiste on puhtaasti ohjelmistokehityksessä, eli ns. ohjelmistotuotannossa. Mutta tilanne on toinen jos painopiste on liiketoiminnassa ja palvelukehityksessä: silloin ohjelmistoja saatetaan pääasiallisesti hankkia vaikkapa pilvipalveluina, sen sijaan että niitä teetettäisiin alihankkijalla, tai tehtäisiin itse omalla henkilöstöllä. (Pilvipalvelut ovat vallitseva suuntaus maailmanlaajuisesti). Jos ohjelmistojen kehitys ei ole organisaation liiketoimintaa, ketterät menetelmät ja viitekehykset (kuten Scrum tai SAFe) eivät välttämättä ole tarkoituksenmukaisia. Mutta vastaavasti Lean-filosofia toimii useimmissa organsaatioissa, useimmilla toimialoilla. Lean-filosofia keskittyy koko tuotantoketjuun ja sen virtaviivaistamiseen, ja Lean EA aivan erityisesti tämän tuotantoketjun alkupäähän: liiketoimintatarpeiden käsittelyyn. Liiketoimintatarpeet ovat kaiken kehittämisen syy, ja liiketoimintaa tukevat lopputulokset ovat seuraus. Kaikki ”muu” tällä välillä on vain keinovalikoimaa, joilla asiakasarvoa tuottavia muutoksia voidaan toteuttaa (läpiviedä). Lean EA keskittyy koko arvoketjuun, jolla asiakasarvoa tuotetaan – eli organisaation kehittämistoimintaan ja sen toimintamallin. Tätä toimintamallia tukee käytännönläheinen ja konkreettinen Lean EA -viitekehys.

Lean EA -viitekehys ja arkkitehtuurisisältö

Organisaation arkkitehtuurisisällön hallinnassa kannattaa hyödyntää asianmukaista mallinnusvälinettä. Sen avulla kaikki elementit voidaan pitää järjestyksessä, ja kaavioita voidaan laatia soveltuvalla yleisellä mallinnuskielellä, standardinotaatiolla kuten ArchiMate, ja kaikki kaaviot pysyvät hallinnassa kuvausvälineen kuvauskannassa (repositoriossa). Tämän kuvauskannan sisältörakenne kannattaa muotoilla arkkitehtuurisisällön hallintaa tukevaksi.

Lean EA -lähestymistavan mukaisessa arkkitehtuurityössä hyödynnetään Lean EA-viitekehystä (LEAF) arkkitehtuurisisällön hallinnassa. Sen visuaalinen ilme ja sisällön hakemistorakenne tukee tehokasta arkkitehtuurisisällön tuottamista ja hallintaa. Viitekehyksen avulla arkkitehtuurityö ja arkkitehtuurisisällön hallinta onnistuu paremmin, nopeammin ja helpommin: tehdään oikeanlaisia kuvia, oikealla tavalla, oikea-aikaisesti, oikeaan paikkaan säilytettäväksi ja jaettavaksi. Viitekehys ohjaa ja tukee kokonaisarkkitehtuurin hallintaa osana organisaation kehittämistoimintaa.

Arkkitehtuurisisältö koostuu kahdenlaisesta sisällöstä: 1) kartoista (Maps) ja 2) näkymistä (Views). Näitä laaditaan kaikista kehittämiskohteista tarvelähtöisesti, kun on tarvetta kuvata jotakin käsillä olevaa muutosta.

#	Periaate	Kuvaus
1	Arkkitehtuurisisältöä tehdään vain riittävästi (just enough)	Vältetään ylisuunnittelua ja turhan tarkkaa etukäteissuunnittelua (Big Design Up Front, BDUF). Aloitetaan ylätasolta, karkeasti, yksinkertaistaen. Edetään tarkemmalla tasolle vain kun se on perusteltua kehittämiskohteen ymmärtämiseksi tarkemmalla tasolla.
2	Arkkitehtuurisisältöä laaditaan vain tarpeeseen (just-in-time)	Mitään ei tehdä varastoon varmuuden vuoksi (just in case). Asioita kuvataan oikea-aikaisesti. Arkkitehtuurikaavioita tehdään kehittämiskohteiden yhteydessä tapauskohtaisesti. Kuvausvälineen kuvauskannan arkkitehtuurisisältö kasvaa pieni pala kerrallaan, pikku hiljaa, osana päivittäistä kehittämistoimintaa. Ei suurissa ryppäissä pitkäkestoisen kuvaustyön tuloksena
3	Arkkitehtuurisisältöä hallitaan (luodaan, käsitellään ja julkaistaan) kuvausvälineessä ja siellä olevassa viitekehyksessä	Arkkitehtuurisisältöä kannattaa hallita kuvausvälineessä, jossa kaavioden laatiminen on helpooa (standardinotaatioilla), ja jossa arkkitehtuurisisältö säilyy laadukkaana ja koherenttina kokonaisuutena kuvausvälineen kuvauskannassa (repositoriossa). Kuvaamisen tukena hyödynnetään viitekehystä, joka ohjaa arkkitehtuurisisällön hallintaa.
4	Arkkitehtuurisisällön hallinnan tulee olla yksinkertaista ja helppoa	Kaavioiden tekemisen tulee olla helppoa, kaavioiden löytämisen ja jakamisen tulee olla helppoa, kaavioiden ymmärtämisen tulee olla helppoa. Kuvausvälineen käyttämiskynnyksen tulee olla matala: väline tulee olla helposti ja nopeasti käytettävissä, ja sillä tulee voida tuottaa kaaviota helposti ja nopeasti.
5	Arkkitehtuurituotosten tulee olla yksinkertaisia ymmärtää ja helppoja tehdä	Kaavioiden tulee olla mieluummin yksinkertaisia kuin monimutkaisia. Tällä on merkitystä mm. ymmärrettävyyden ja ylläpidettävyyden kannalta. Kaavioiden tulisi olla houkuttelevia ja ennen kaikkea hyödyllisiä. Kaaviota tulee olla helppo ymmärtää ja helppo tehdä. Vähennetään, ei lisätä asioita, sillä usein “oleellinen on jo silmien edessä” – se tulee vain löytää. Voiko vaativa asia kuten (kokonais)arkkitehtuuri olla yksinkertaista ja helppoa, ja pitääkö sen edes olla? Kyllä. Vain yksinkertaiset ja helposti toteutettavat asiat toimivat. Muista: KISS-sääntö (Keep It Simple, Stupid), ja vähemmän on enemmän (Less is More) jne.
6	Yleiskuva karkealla tasolla riittää useimmiten	Arkkitehtuurin tuotoksissa (kaavioissa) yksityiskohtiin ei kannata uppoutua – varsinkaan liian aikaisin. Vältetään turhaa monimutkaisuuttaa – siitä seuraa vain monitulkintaisuutta. Yleiskuva (Overview), konteksti kehittämiskohteesta riittää usein, ensimmäinen (joskus ainoa) kaavio voi olla jokin Kerrosnäkymän (Layered View) sovellutus. Kuvaaminen kannattaa aloittaa luonnostelulla heti alussa nopeasti, yhdessä, ja katsoa mihin se johtaa. Kuvan tärkein tehtävä on viestiä ymmärrettävästi. Useimmat ihmiset hahmottavat asioita visuaalisesti.
7	Arkkitehtuurin kaaviotyypit ja niissä käytettävät elementit on sovittava	Kuvauksia on helpompaa laatia, kun arkkitehtuurituotokset perustuvat sovittuihin kaaviotyyppeihin, mallinnuselementteihin ja niiden välisiin yhteystyyppeihin. Kaaviotyypit määritellään metamallissa ja viitekehyksessä. Kaaviotyypeistä tehdään malleja ja esimerkkejä. Paras tapa oppia on kuitenkin tekeminen, ja varsinkin yhdessä tekeminen. Mallintamisen vinkeistä ja sudenkuopista keskusteleminen kannattaa tehdä käytännön työssä konkreettisten kuvaustarpeiden yhteydessä. (HUOM! Kaaviotyypit, mallit ja esimerkit sekä metamalli ovat valmiina LEAF-viitekehyksessä, joka on vapaasti hyödynnettävissä).
8	Arkkitehtuurikuvaukset laaditaan standardinotaatioilla	Standardinotaation käyttäminen auttaa pidemmän päälle, koska kaaviot ovat noudattavat samoja periatteita, elementtejä ja yhteystyyppejä. Kaavioiden ymmärrettävyys ja hyödynettävyys paranee jatkuvasti käytön myötä. Vastaavasti henkilösidonnaisten ja tapauskohtaisten (ad hoc) kuvaustapojen merkitys vähenee. Tärkeimpänä notaationa käytetään ArchiMate -notaatiota, muita soveltuvia ovat BPMN ja UML.
9	Arkkitehtuurisisällössä ei erotella näkökulmia tai kerroksia	Ns. perinteisiä kokonaisarkkitehtuurin näkökulmia (domaineja) toiminta, tieto, järjestelmä, teknologia ei erotella toisistaan, niitä ei käsitellä erikseen erillisinä sisälöllisina osa-alueina, vaan niitä kaikkia tarkastellaan yhtenä kokonaisuutena, kokonaisvaltaisesti, yhdessä. Vastaavasti, kehittämiskohdetta ei tarkastella kerroksellisesti (liiketoiminta, järjestelmät, teknologiat), vaan kehittämiskohdetta tarkasteellaan kokonaisuutena, johon kuuluvat kaikki kerrokset ja näkökulmat. Muussa tapauksessa kokonaisuuden hallinta siiloutuu – sekä sisällöllisesti että työn tekemisen ja työnjaon tasolla. Yhteistyö ja yhdessä tekeminen on sekä kokonaisuuden kannalta että yksittäisten lopputulosten kannalta ensiarvoisen tärkeätä!
10	Arkkitehtuurisisältöä hallitaan kokonaisuutena – osakokonaisuus (segmentti) kerrallaan	Arkkitehtuurisisältö on kokonaisuus, jossa kaikki vaikuttaa kaikkeen – ei itsenäisten ja erillisten asioiden kokoelma. Siksi arkkitehtuurin sisältöä tulee tarkastella ja tuottaa kokonaisvaltaisesti: samanaikaisesti huomioidaan kaikki aspektit, kerrokset, osa-alueet ja näkökulmat – osa-alue (segmentti) kerrallaan. Tällöin organisaation kokonaisukuva (kokonaisarkkitehtuuri) kasvaa jatkuvasti, samanaikaisesti, osakokonaisuus (segmentti) kerrallaan. Kussakin osakokonaisuudessa huomioidaan kaikki siihen vaikuttavat asiat. Tyypillinen kuvaus on kerrosnäkymä, jonka avulla voidaan hahmottaa koko kehittämiskohde eli kehitettävä osakokonaisuus (segmentti).
11	Kehittämiskohteita kuvataan kokonaisvaltaisesti – osakokonaisuus (segmentti) kerrallaan	Yksittäisiä kehittämiskohteita kuvattaessa huomioidaan kaikki oleelliset asiat samalla kertaa, kokonaisuutena. Ei erotella kerroksia eikä ns. näkökulmia (business-, application-, technology layers) toisistaan. Kuvaamisessa hyödynnetään sovittuja kaaviotyyppejä, jolloin kehittämiskohteiden käsittely jatkuvasti helpottuu, kun asioita jäsennellään samalla tutulla tavalla. Kuvausten laatiminen helpottuu ja nopeutuu jatkuvasti, samoin kuvausten ymmärtäminen ja hyödynnettävyys paranee kun niitä opitaan “lukemaan”.
12	Nykytilaa ja tavoitetilaa kuvataan erikseen vain tarvittaessa	Tapauskohtaisesti ratkaistaan kuvataanko nykytilaa, tavoitetilaa vai näiden yhdistelmää: tilannekuvaa (jossa voidaan mm. värein korostaa nykyisiä ja suunniteltuja asioita). – Useinkaan ei ole mahdollista ylläpitää erikseen laajoja kuvauksia sekä nykytilasta että tavoitetilasta. – Lean EA -lähestymistavassa arkkitehtuuria kuvataan aina vain sen verran kun sitä on tarvetta ymmärtää, olipa kyse nyky- tai tavoitetilasta. Kahden kaavion ylläpitämisen sijaan yksi tilannekuva usein riittää samasta asiasta…

Lean EA ja arkkitehtuurityö

Tärkeintä on liiketoiminnan kehittäminen asiakaslähtöisesti. Organisaation (liike)toiminnan johtaminen ja kehittäminen on keskeistä. Kokonaisarkkitehtuurin rooli ja merkitys on tukea edellisiä. Siksi kokonaisarkkitehtuuri tulee integroida osaksi organisaation kehittämistoimintaa. Ei ole mielekästä toteuttaa kokonaisarkkitehtuuria erillisenä asiana. Kokonaisarkkitehtuurin tulee tuottaa näkyviä tuloksia ja vaikuttaa. Tämä onnistuu siten että arkkitehdit osallistuvat kehittämistoimenpiteisiin jokapäiväisessä käytännön työssä yhdessä muiden kehittämisroolien kanssa.

Lean EA -tapa tehdä arkkitehtuuria ei erottele arkkitehtuurin tasoja kuten kokonaisarkkitehtuuri tai ratkaisuarkkitehtuuri. Kyse on lopulta vain arkkitehtuurista. Tässä mielessä arkkitehtuuriosaaminen käsittää kaikki arkkitehtuurityön osaamiset, kuten kuvaamis- ja mallinnusosaamisen. Arkkitehtuurissa on perimmältään kysymys kokonaisuuksien (isojen tai pienien) hallinnasta, erityisesti silloin, kun tähän kokonaisuuteen kohdistuu muutoksia. Tällöin tämän kokonaisuuden ymmärtäminen suhteessa muuhun organisaation (tai sen ulkopuoliseen) toimintaan ja rakenteeseen on oleellista. Arkkitehtuuri kuin arkkitehtuurityökin on kokonaisvaltaista toiminnan ja rakenteen hallintaa, ja tämä osaaminen on skaalattavissa eri laajuisten kokonaisuuksien hallintaan. Kokonaisarkkitehtuurin tasolta ratkaisuarkkitehtuurin tasolle.

Lean EA-lähestymistavassa kokonaisarkkitehtuuria ja kokonaisarkkitehtuurityötä ei jaotella sisällöllisiin osa-alueisiin, eli ns. perinteisiin näkökulmiin (domaineihin) toiminta, tieto, järjestelmä ja teknologia, vaan näitä tarkastellaan aina kokonaisuutena – yksi kehittämiskohde eli osakokonaisuus (segmentti) kerrallaan. Tällöin kaikki asiat huomioidaan samalla kertaa, riippumatta siitä mihin ns. kerrokseen tai näkökulmaan ne kuuluvat. Näin ei synny sisäistä siiloutumista eri arkkitehtuurin sisällöllisiin osa-alueisiin tai kerroksiin. Tässä on iso ero ns. perinteiseen kokonaisarkkitehtuurityöhön nähden, jossa arkkitehtuurityö jakaantuu osa-alueittain vastuisiin ja osaamisiin. Lean EA-lähestymistavassa arkkitehtuuri on kokonaisuus, ei kokoelma erillisiä asioita. Tässä kokonaisuudessa arkkitehtuuriosaamisen ja sen kehittämisen tulisi keskittyä arkkitehtuurikilta -tyyppiseen viiteryhmään, johon arkkitehdit kuulusivat ja jonka kautta he saisivat vertaistukea – kokemuksesta ja osaamisesta riippumatta.

Arkkitehtuurityön periaatteita:

#	Periaate	Kuvaus
1	Arkkitehtuurityön tulee olla tavoitteellista	Kaikella toiminnalla tulee olla selkeästi määritellyt tavoitteet. Ellei näin ole, toiminta on tarpeetonta puuhastelua. Arkkitehtuurityön tavoitteet on sovittava arkkitehtuurityöhön osallistuvien kesken, ja nämä tavoitteet tulee hyväksyttää arkkitehtuurityön omistavalla taholla. Ellei tavoitteita ole määritelty, toiminnan kypsyyttä ei voida mitata, ja toimintaa ei voi kehittää.
3	Arkkitehtuurityö on näkyvää	Kaikki tehtävät näkyvät Kanban-taululla. Tehtävien tulee liittyä joko a) tavoitteisiin tai b) kehittämistoimintaan. Kaikki muut tehtävät ja niiden työmäärät näkyvät myös, joten niiden järkevyyttä ja arvoa voidaan arvioida myös. Tavoitteena on keskittyä tavoitteellisen ja arvoa tuottavan työn maksimointiin, ja minimoida muun työn määrää.
4	Arkkitehtuurityötä ohjataan ja seurataan	Arkkitehtuurityö on luonteeltaan ensisijaisesti jatkuvaa (ei time-boxed), jolloin työnohjauksen menetelmäksi soveltuu Kanban-ohjaus ja soveltuva sähköinen Kanban-taulu (esim. Trello, Teams). Tehtäviä seurataan esim. viikkopalavereissa (1-2krt/vko a 15-45min).
5	Arkkitehtuuritehtävät on johdettu organisaation kehittämistoiminnasta	Kaikki arkkitehtuuritehtävät tulee voida kytkeä johonkin liiketoimintalähtöiseen kehittämiskohteeseen. Arkkitehtuurityötä tehdään ensisijaisesti kehittämiskohteiden yhteydessä.
6	Arkkitehtuurityötä tehdään vain kun sille on “tilaus”	Arkkitehtuurityötä tehdään vain kun se tuottaa liiketoiminnan johtamista, kehittämistä tai operatiivista toimintaa tukevia tuotoksia (business-driven outcomes). Kaikille arkkitehtuuritehtäville tulee olla omistaja, eli taho, jolla on intressi jonkin arkkitehtuurityön tai -tehtävän aikaansaamiseksi. Esim. omistajalla voi olla kehittämistarve, johon liittyy arkkitehtuuria.
7	Arkkitehtuurityötä tehdään yhteistyössä eri roolien ja osaamisprofiilien kanssa	Arkkitehtuuria ei tehdä sen itsensä vuoksi (sillä ei ole itseisarvoa sellaisenaan), vaan arkkitehtuuria tehdään osana muuta kehittämistoimintaa, yhteistyössä muiden kanssa, tarvelähtöisesti, jolloin arkkitehtuuri liittyy ja/tai tukee jotakin kehittämiskohdetta. Yhteistyötä pyritään tekemään mm. palvelumuotoilijoiden kanssa, heidän menetelmiään ja välineitään hyödyntäen
8	Arkkitehtuurityötä tehdään kokonaisvaltaisesti	Huomioidaan samalla kertaa kaikki arkkitehtuurin osa-alueet (perinteiset toiminta, tieto, järjestelmä ja teknologia) ja tasot (KA, ratkaisuarkkitehtuuri) sekä kerrokset (Business, Application, Technology), lisäksi myös tietoturva ja tietosuoja-asiat, sekä riskit. Tämä kannustaa yhteistyöhön eri arkkitehtuurin osaamisalueiden väliseen yhteistyöhön ja pakottaa ajattelemaan kokonaisvaltaisesti. Arkkitehtuurityötä (kuten ei arkkitehtuurisisältöäkään) ei erotella sisällöllisiin tai osaamisiin perustuviin jaotteluihin (kuten toiminta-arkkitehtuuri tai tietoarkkitehtuuri tai järjestelmäarkkitehtuuri tai teknologia-arkkitehtuuri tai tietoturva-arkkitehtuuri), koska se johtaa siiloutumiseen ja lyhytnäköiseen osa-optimointiin ja kapea-alaiseen, rajoittuneeseen tarkasteluun ja sen mukaisiin lopputuloksiin.
9	Arkkitehtuurityö ei ole erillistä	Arkkitehtuurityön tulee olla integroitu osaksi organisaation kehittämistoimintaa. Itse asiassa tämä on kokonaisarkkitehtuurin elinehto. Kokonaisarkkitehtuurilla ei ole itseiasarvoa, se ei sinällään kiinnosta ketään, vaikka se on tärkeätä. Mutta kun kyse on kehittämistoiminnasta, kokonaisarkkitehtuuri on sen ytimessä. Voidaankin todeta että “lopetetaan puhuminen kokonaisarkkitehtuurista, ja aletaan puhumaan liiketoiminta-arvon ja asiakasarvon tuottamisesta eli kehittämistoiminnasta”. Se koskettaa ja kiinnostaa kaikkia, ja varsinkin organisaation johtoa. Joten: kun puhutaan kokonaisvaltaisesta organisaation kehittämistoiminnasta, kyse on organisaation toiminnasta ja rakenteesta, eli itse asiassa kokonaisarkkitehtuurista.

Terminologiaa:

Termi	Kuvaus
Kehittämistarve (tarve)	Liiketoimintaan liittyvä muutostarve. Esim. asiakkaan “ongelma” joka tulisi ratkaista (Huom! Erotetaan todelliset tarpeet haluista), jokin puuttuva osa kokonaisuudesta jolla parannetaan toimintaa. Kehittämistarpeen tulee olla asiakaslähtöinen ja sen tulee olla liiketoiminnallisesti perusteltavissa. Kehittämistarpeen tulee suoraan tai välillisesti tukea asiakasarvoa tuottavaa toimintaa. Kehittämistarpeen taustatekijät, juurisyyt eli ajurit on syytä selvittää samalla kun selvitetään konkreettiset tavoitteet ja lopputulokset, jotka halutaan saada aikaan (muutoksella, eli kehittämiskohteella).
Kehittämiskohde (muutos)	Organisaation toimintaan ja/tai rakenteeseen kohdistuva muutos, joka on lähtöisin jostakin kehittämistarpeesta. Kehittämiskohteella toteutetaan muutos, joka voi olla esim. olemassa olevan toiminnallisen ja/tai rakenteellisen asian korjaus tai parannus, tai se voi olla täysin uuden asian toteuttaminen tai hankkiminen (build or buy).
Kehittäminen	Toimintaa (vrt. “kehitys” on seurausta toiminnasta. Siksi “kehittämistarve, “kehittämiskohde” jne., ei “kehitystarve” tai “kehityskohde”). Kehittäminen (Development) toteuttaa jonkin asian. Tätä edeltää tyypillisesti kehittämisen suunnittelu / muotoilu (Design).
Lean	Kokonaisvaltainen tuotannollisen toiminnan tehostamisen filosofia, joka pyrkii hukan (Muda), eli arvoa tuottamattoman toiminnan, minimoimiseen tai poistamiseen. Tavoitteena on ensisijaisesti virtaustehokkuus ja asiakkaalle tuotettavan arvon maksimointi, eli asiakaskokemukseen keskittyminen. Toissijaisena tavoitteena organisaation sisäisen resurssitehokkuuden parantaminen, jolla tuetaan ja mahdollistetaan asiakasarvoa tuottava toiminta.
Lean EA	Lean EA yhdistää organisaation kehittämistoiminnan ja kokonaisarkkitehtuurin. Lean EA on lähestymistapa, joka tukee liiketoiminnan kokonaisvaltaista kehittämistä. Lean EA lähestymistapa konkretisoituu menetelmänä, joka käsittää kehittämisen toimintamallin (kehittämismallin) ja viitekehyksen. Lean EA-lähestymistavan kohteena on organisaation kokonaisvaltainen toiminnan ja rakenteen kehittäminen, ja tässä kokonaisarkkitehtuurilla on tärkeä rooli ja merkitys. Lean on tuotannollisen toiminnan tehostamisen filosofia, vastaavasti Lean EA on organisaation kehittämistoiminnan tehostamisen lähestymistapa. Lean EA ei ole kokonaisarkkitehtuurin tuottamisen menetelmä perinteisessä mielessä. Päinvastoin, Lean EA on organisaation kokonaisvaltaisen kehittämisen lähestymistapa, jota kokonaisarkkitehtuuri tukee. Lean EA:ssa kokonaisarkkitehtuuri on integroitu osaksi kehittämistoimintaa, joka on se varsinainen, organisaation kannalta merkityksellinen asia. Kokonaisarkkitehtuuri arvo on tukea varsinaista asiakasarvoa tuottavaa kehittämistoimintaa. Kokonaisarkkitehtuurin tukena hyödynnetään muita menetelmiä kuten esim. palvelumuotoilua. Lean EA:ssa kokonaisarkkitehtuuria on yksinkertaistettu, siitä on riisuttu pois vaikeiksi ja raskaiksi osoittautuneita asioita. Lean EA on siis uusi tapa tehdä kokonaisarkkitehtuuria osana muuta kehittämistoimintaa, kevyemmin, nopeammin ja tehokkaammin. Lean EA-viitekehys tukee kehittämistoimintaa, ja tarjoaa yksinkertaisen arkkitehtuurisisällön kehikon, sekä valmiita malleja ja esimerkkejä. Lean EA on käytännönläheinen, helpommin lähestyttävä, ymmärrettävä ja konkreettinen. Lean EA:ssa kokonaisarkkitehtuuri on kiinteä osa päivittäistä kehittämistoimintaa, osallistuvaa yhdessä tekemistä. Kokonaisarkkitehtuuri ei ole erillinen, etäinen ja epäselvä. Lean EA:ssa kokonaisarkkitehtuuri on hyödyllinen ja vaikuttava osa kehittämistoimintaa.

Lisätietoja Lean EA-lähestymistavasta mm. täällä: linkki.