Tekesin ohjelm

an katsauksen nim

i0

00

|2010

Tekes | Ohjelm

an katsaus

Marraskuu 2010

ISSN 1797-7339

ISBN 978-952-457-513-3

Tekes – teknologian ja innovaatioiden kehittämiskeskus

vaihde 010 191 480asiakasneuvonta info@tekes.fikirjaamo kirjaamo@tekes.fi

Kyllikinportti 2, Länsi-Pasila, PL 6900101 Helsinkiwww.tekes.fi

Lisätiedot

Risto Setälä

Tekes

risto.setala@tekes.fi

Tero Kulha

Eeranka Oy

tero.kulha@eeranka.fi

Yritysarkkitehtuurin ja tiedolla johtamisen käytännöt

– haastattelututkimus suomalaisissa suuryrityksissä

Tero Kulha

Tekes | Tekes Review

Teke

sin

kat

sau

s 2

77/2

010

Tekesin ohjelm

an katsauksen nim

i0

00

|2010

Tekes | Ohjelm

an katsausTekesin oh

jelman katsau

ksen nimi

00

0|20

10Tekes | O

hjelman katsaus

Tekesin ohjelm

an katsauksen nim

i0

00

|2010

Tekes | Ohjelm

an katsaus

10

3

Tero Kulha, Eeranka Oy

Yritysarkkitehtuurin ja tiedolla johtamisen käytännöt

– haastattelututkimus suomalaisissa suuryrityksissä

Tekesin katsaus 277/2010Helsinki 2010

4

Tekes – rahoitusta ja asiantuntemusta

Tekes on tutkimus- ja kehitystyön ja innovaatiotoiminnan rahoittaja ja asiantuntija. Tekesin toiminta auttaa yrityksiä, tutkimuslaitoksia, yliopistoja ja korkeakouluja luomaan uutta tietoa ja osaamista ja lisäämään verkostoitumista. Tekes jakaa rahoituksellaan teollisuuden ja palvelualojen tutkimus- ja kehitystyön riskejä. Toiminnallaan Tekes vaikuttaa liiketoiminnan kehittymiseen, elinkeinoelämän uudistumiseen, kansantalouden kasvuun, työllisyyden vahvistumiseen ja yhteiskunnan hyvinvointiin. Tekesillä on vuosittain käytettävissä avustuksina ja lainoina lähes 600 miljoonaa euroa tutkimus- ja kehitysprojektien rahoitukseen.

Tekesin ohjelmat verkostoitumisen foorumeita

Tekesin ohjelmat tarjoavat yrityksille, yliopistoille, korkeakouluille ja tutkimuslaitoksille verkottumis-mahdollisuuksia, apua kansainvälistymiseen ja liiketoimintaosaamisen kehittämiseen sekä rahoitusta ohjelman aihepiiriin kuuluville tutkimus- ja kehitysprojekteille. Seminaarit, workshopit, ulkomaille suuntautuvat tutustumismatkat, koulutusohjelmat, uutiskirjeet ja muut julkaisut ovat ohjelmien keskeistä antia.

Copyright Tekes 2010. Kaikki oikeudet pidätetään. Tämä julkaisu sisältää tekijänoikeudella suojattua aineistoa, jonka tekijänoikeus kuuluu Tekesille tai kolmansille osapuolille. Aineistoa ei saa käyttää kaupallisiin tarkoituksiin. Julkaisun sisältö on tekijöiden näkemys, eikä edusta Tekesin virallista kantaa. Tekes ei vastaa mistään aineiston käytön mahdollisesti aiheuttamista vahingoista. Lainattaessa on lähde mainittava.

ISSN 1797-7339ISBN 978-952-513-3

Kannen kuva: Kari LehkonenTaitto: DTPage Oy

5

Esipuhe

Informaation merkitys organisaatioiden toiminnassa ja niiden johtamisessa on koko ajan lisääntymässä. Tietotekniikan käyttöönotolla ja kehittämisellä on merkittäviä vaikutuksia organisaatioiden tuottavuuteen ja kilpailukykyyn. Parhaimmillaan tietotekniikka toimii yritysten strategisen ketteryyden mahdollistajana. Liiketoiminnan tarpeet korostuvat tie-totekniikkaratkaisujen suunnittelussa. Kuitenkin asiat etenevät usein vielä liian teknispai-notteisesti. Tietotekniikan ja liiketoiminnan johtaminen hyvässä yhteistyössä vaatii uu-denlaista osaamista ja näkemystä eikä vastakkainasettelua.

Tekes ja Eeranka Oy toteuttivat kesän aikana tutkimuksen, jossa selvitettiin yritysark-kitehtuurin ja tiedolla johtamisen käytäntöjä suurissa suomalaisissa yrityksissä. Kvalitatii-vinen tutkimus toteutettiin haastattelemalla 25, pääasiassa suuren yrityksen edustajia.

Yritysarkkitehtuurilla tarkoitetaan toimintaprosessien ja niitä tukevien tietoteknisten ratkaisujen kokonaisvaltaista suunnittelua. Yritysarkkitehtuurin neljä tyypillistä pääaluet-ta ovat: liiketoiminta/prosessit, tieto/informaatio, järjestelmät/sovellukset sekä teknolo-gia (IT-infrastruktuuri).

Yritysarkkitehtuurityön kypsyys korreloi selvästi sen kanssa, kuinka tietointensiivisel-lä toimialalla organisaatio toimii. Finanssialan organisaatiot ovat tässä toiminnassa pisim-mällä. Vain neljän organisaation kohdalla ei ollut käytännössä lainkaan järjestäytynyttä yritysarkkitehtuuritoimintaa. Toisaalta suuri joukko organisaatioita oli vasta aloittamassa järjestäytynyttä yritysarkkitehtuuritoimintaansa.

Yritysarkkitehtuurityö on edelleen vahvasti tietohallintovetoista – kaikissa tutkituis-sa organisaatioissa siitä vastaavat tahot kuuluivat johonkin tietohallintotoiminnon yksik-köön. Pisimmällä ollaankin teknisen arkkitehtuurin alueella, kun taas tietoarkkitehtuuriin liittyvä problematiikka nähdään selkeästi suurimpana ongelmana. Systemaattisten arkki-tehtuuriviitekehysten vähäisyys oli myös odottamaton tulos.

Tiedolla johtamisen alueella mielenkiintoinen – ja myös huolestuttava – löydös oli se, että organisaation ulkopuolisen ja sisäisen tiedon prosessit ovat tyypillisesti hyvin eril-lään toisistaan. Tutkituissa organisaatioissa tietohallinnon rooli ulkoisen tiedon proses-soinnissa vaihteli vähäisestä olemattomaan, ja vain muutamassa tapauksessa ulkoista ja sisäistä tietoa yhdistettiin systemaattisesti mm. strategisen suunnittelun tueksi.

6

Sisältö

Esipuhe ................................................................................................................................................................................5

1 Johdanto .................................................................................................................................................................7Tutkimuksen tausta ja tavoitteet ................................................................................................................8Yritysarkkitehtuuri ja tiedolla johtaminen Tekesin näkökulmasta .........................................8

2 Keskeiset tutkimuslöydökset .................................................................................................................9Arkkitehtuurityön vetovastuu on selkeästi tietohallinnolla.......................................................9Viitekehysten käyttö yllättävän vähäistä ................................................................................................9Tietoarkkitehtuurin problematiikka.......................................................................................................10Organisaation ulkopuolisen tiedon ja sisäisen tiedon yhdistely on vähäistä ja sattumanvaraista. .....................................................................................................................10Arkkitehtuurityön hyödyt ............................................................................................................................11Yksityiskohtaiset käytännöt ........................................................................................................................11

3 Yritysarkkitehtuurin kypsyysmalli ja suomalaisten organisaatioiden sijoittuminen sen eri tasoille. ..............................................................................................................12

4 Yhteenveto arkkitehtuurityön hyvistä käytännöistä ja sudenkuopista............16Arkkitehtuurin rakenne .................................................................................................................................16Roolitus ...................................................................................................................................................................16Liiketoiminnan rooli yritysarkkitehtuurityössä ................................................................................17Tietoarkkitehtuuri .............................................................................................................................................18Ulkoisen ja sisäisen tiedon prosessointi..............................................................................................18Riskit ..........................................................................................................................................................................18

5 Johtopäätökset ja suosituksia arkkitehtuuritoiminnan kehittämiseksi. ..........19Johtopäätökset ..................................................................................................................................................19Suosituksia arkkitehtuuritoiminnan kehittämiseksi .....................................................................19Suosituksia Tekesin rooliksi arkkitehtuurivalmiuksien ja tiedolla johtamisen edistämiseksi. .........................................................................................................20Lopuksi ....................................................................................................................................................................20

Liite 1 ..................................................................................................................................................................................21Kolme lähestymistapaa arkkitehtuurityöhön ..................................................................................21Vallitsevat arkkitehtuurikäytännöt tutkituissa organisaatioissa: prosessit, viitekehykset ja päätöksentekomallit ...................................................................................................21 Resurssointi .....................................................................................................................................................21 Prosessi ..............................................................................................................................................................22 Viitekehys .........................................................................................................................................................22 Arkkitehtuurin hallinta .............................................................................................................................23 Liiketoiminnan rooli arkkitehtuurityössä ......................................................................................23

Tekesin katsauksia ...................................................................................................................................................24

7

Tiedolla johtaminen on julkisuudessa käytetty uudehko termi, jolla viitataan informaation lisääntyneeseen merki-tykseen yhä useamman organisaation toiminnassa ja sen johtamisessa. Tie-don määrän ja merkityksen kasvu on kiistatonta ja organisaatiot panostavat tuntuvia summia tietotekniikkaansa hallitakseen informaatiotulvaa.

Samaan aikaan moni organisaa-tio kuitenkin tuskailee laadukkaan in-formaation puutetta. Osa tärkeästä tiedosta, esimerkiksi organisaation ul-kopuolinen tieto, jää liian vähälle huo-miolle. Tietojärjestelmien sisältämästä datasta ei osata jalostaa hyödyllistä informaatiota. Pahimmillaan kallis ja jäykkä tietotekninen ”kone” estää or-ganisaatiota tekemästä strategisia va-lintoja, joita se haluaisi tehdä. Tiedolla

johtamisen potentiaalia ei pystytä hyö-dyntämään.

Tällaisen kehityksen muuttaminen edellyttää organisaatioiden omistajilta ja johtoryhmiltä uutta, edistyksellistä ajattelua: toisaalta tiedon hallinnan johtamista irrallaan tietotekniikasta sekä toisaalta prosessien ja tietotekniikan ko-konaisvaltaista kehittämistä, mitä kutsu-taan yleisesti yritysarkkitehtuuriksi.

Tekemässämme tutkimuksessa nousi esiin aiheellinen kysymys: ”Teem-mekö parempaa businesstä, jos meillä on olemassa systemaattinen yritysark-kitehtuuri?” Yritysarkkitehtuurilta, ku-ten kaikilta muiltakin kehityskohteilta, pitää edellyttää konkreettisia hyötyjä. Jos näitä ei löydy, voi yritysarkkitehtuu-ritoiminnan oikeutetusti jättää hieman vähemmälle huomiolle.

Mutta yritysarkkitehtuuriin on myös toinen näkökulma: Kirjassaan ’Enterprise Architecture as Strategy’ Jeanne Ross, Pe-ter Weill ja David Robertson määrittele-vät yritysarkkitehtuuritoiminnan tavoit-teeksi luoda rakenne, jota he kutsuvat nimellä ’Foundation for Business Execu-tion’. Käytännössä tämä tarkoittaa orga-nisaation prosesseista ja järjestelmistä koostuvaa operatiivista konetta, jonka tehokkuus, virheettömyys ja joustavuus ovat elinehto menestyvälle organisaa-tiolle. Tällaisen koneen olemassa olon ja rakentamisperiaatteiden tulee olla organisaation johdon ja omistajien ai-tona intressinä.

Yritysarkkitehtuuri – jota julkinen sektori kutsuu kokonaisarkkitehtuurik-si – on tässä tutkimuksessa määritelty suoraviivaisesti: toimintaprosessien ja

1Johdanto

Yritysarkkitehtuuri on prosessien jatietotekniikan kokonaisvaltaista suunnittelua

Business- taiprosessi-

arkkitehtuuri

Tekninenarkkitehtuuri

Liiketoiminnan vahva panos

Tietohallinnon vahva panos

Informaatio-arkkitehtuuri

Järjestelmä-arkkitehtuuri

8

niitä tukevien tietoteknisten ratkaisu-jen kokonaisvaltainen suunnittelu.

Edellisen sivun kuva havainnollis-taa yritysarkkitehtuurin tyypilliset pää-alueet.

Tähän raporttiin on koottu Tekesin ohjaaman yritysarkkitehtuuritutkimuk-sen tulokset. Tutkimus osoittaa, että or-ganisaatioilla on vielä paljon mahdolli-suuksia parantaa oman tietopääoman-sa hyödyntämistä. Tutkimus kuvaa suomalaisten suuryritysten yritysarkki-tehtuurikäytäntöjä ja antaa esimerkke-jä, joiden avulla muutkin organisaatiot voivat rakentaa omaa yritysarkkiteh-tuuriaan ja edetä omassa organisaati-ossaan kohti tiedolla johtamista.

Tutkimuksen tausta ja tavoitteet

Tutkimuksen lähtöhypoteesi oli seu-raava: voidakseen pysyä kilpailukykyi-senä ympäristössä, jossa tiedon mää-rä ja merkitys kasvavat nopeasti ja jos-sa tietotekniset ympäristöt muuttuvat hyvin monimutkaisiksi kokonaisuuksik-si, yritysten täytyy kiinnittää kasvavassa määrin huomiota yritysarkkitehtuuritoi-mintaansa.

Hypoteesin testaamiseksi teimme kvalitatiivisen tutkimuksen suomalais-ten suuryritysten käytännöistä koskien yritysarkkitehtuuria, tiedolla johtamis-ta ja organisaatioiden ulkoisen tiedon hyväksikäyttöä. Tarkoituksena on ollut kartoittaa yritysarkkitehtuurin nykyti-lannetta, löytää alueen parhaita käytän-töjä ja kehittämiskohteita.

Tutkimus toteutettiin kesällä 2010 haastattelemalla 25 suuren organisaa-tion edustajia. Haastateltavista 18 oli tietohallintojohtajia, 13 (pää-)arkkiteh-teja ja 3 muita asiantuntijoita. Kaikissa tapauksissa haastateltavilla oli selkeä käsitys yritysarkkitehtuurin sisällöstä ja

sen tilasta omassa organisaatiossa. Läpikäydyistä organisaatioista

19 oli suuria pörssiyrityksiä tai niiden divisioonia ja 6 muuta oli suuria yk-sityisoikeudellisia organisaatioita tai osuuskuntia. Haastatelluista organisaa-tioista vain yksi edusti julkista sektoria. Keskittyminen yrityksiin oli tietoinen päätös mm. siksi, että julkisen sektorin arkkitehtuurityötä on selvitelty laajasti mm. Jyväskylän Yliopiston kokonaisark-kitehtuurihankkeessa.

Tutkimus on luonteeltaan selkeästi kvalitatiivinen. Kerätystä aineistosta on tehty kevyttä tilastointia, mutta tutki-musmetodiikka ei ole ”tieteellisen tark-ka”. Otoksen koon takia tutkimuksesta pystyy kuitenkin tekemään melko pitä-viä johtopäätöksiä ja näin ollen se vas-taa tutkimukselle asetettuja tavoitteita.

Tutkimuksen ohjauksesta ovat vas-tanneet Raine Hermans ja Risto Setälä Tekesistä ja sen käytännön toteutukses-ta Tero Kulha Eeranka Oy:sta.

no on tuotekehityksessä, prosessien ke-hittämisessä ja innovaatioissa. Tieto on jo monilla toimialoilla tärkein tuotan-nontekijä ja yhä useammin myös kes-keinen tuotteen tai palvelun kompo-nentti.

Jos organisaation käytössä oleva tieto on laadultaan huonoa tai se on heikosti yhdistettävissä päätöksenteon tueksi, tiedolla johtaminen ei toteudu parhaalla mahdollisella tavalla. Syynä voi usein olla puutteellinen arkkiteh-tuurityö. Organisaation yksittäisiin pe-rusjärjestelmiin kerätään järjestelmäl-lisesti tietoa ja niistä tuotetaan onnis-tuneesti säännöllisiä perusraportteja. Mutta kun käsitellään strategisia kysy-myksiä ja ”isoa kuvaa” joudutaan usein kertakäyttöselvitysten, tietojen manu-aalisen yhdistelyn ja epätäsmällisten tietomääritysten labyrinttiin. Tiedon hyödyntäminen on tehotonta.

Arkkitehtuurityöllä ei välttämättä suoraan paranneta yrityksen inno-vointikykyä tai tuotekehityksen tehok-kuutta. Välillinen vaikutus on kuitenkin olemassa. Systemaattisella yritysarkki-tehtuurilla pystytään parantamaan tie-don hyödyntämistä ja tiedolla johta-mista. Hyvän arkkitehtuurityön avulla tietoteknisestä ympäristöstä saadaan tehokas ja toimintavarma, jolloin or-ganisaation ajasta pienempi osuus menee perusjärjestelmien ylläpitoon ja korjailuun ja vastaavasta suurempi osuus innovointiin ja kilpailukyvyn pa-rantamiseen.

Lähtöhypoteesi: Kasvava tiedon merkitys +

kompleksinen tietotekninen ympäristö ¢ suuri

tarve systemaattiselle yritysarkkitehtuurille.

Yritysarkkitehtuuri ja tiedolla johtaminen Tekesin näkökulmasta

Tutkimuksen valmistelun yhteydessä käydyissä keskusteluissa kävi ilmi, että Tekes oli omissa kehitysohjelmissaan usein törmännyt tiedolla johtamisen merkityksen kasvuun. Kokonaisvaltai-sen tiedon hallinnan tarve näkyy siis jo-pa sellaisissa hankkeissa, joissa pääpai-

Kun käsitellään strategisia kysymyksiä joudutaan usein

kertakäyttöselvitysten, tietojen manuaalisen yhdistelyn ja

epätäsmällisten tietomääritysten labyrinttiin.

9

Kaikissa organisaatioissa on liiketoimin-taprosesseja ja niitä tukevia tietojärjes-telmiä ja niiden muodostama niin sa-nottu de facto -yritysarkkitehtuuri. Yri-tysarkkitehtuuritoiminnasta voidaan kuitenkin puhua oikeastaan vasta sil-loin, kun tuota prosessien ja tietojärjes-telmien yhdistelmää kehitetään koko-naisvaltaisesti ja systemaattisesti.

Yritysarkkitehtuuri käsitteenä oli kaikissa haastatelluissa organisaatioissa tuttu ja suurimmassa osassa systemaat-tista arkkitehtuurityötä myös tehtiin. Vain neljässä organisaatiossa arkkiteh-tuurityötä ei tehty systemaattisesti ja niissäkin syy ko. toiminnan vähäisyy-teen oli varsin perusteltu: yrityksen pie-nempi koko, rooli osana isompaa yritys-tä tai organisaation historia.

Monissa organisaatioissa yritys-arkkitehtuuri on noussut voimakkaasti agendalle vasta vähän aikaa sitten. Noin puolessa haastatelluista yrityksistä yritysarkkitehtuurityötä on tehty vasta alle kaksi vuotta.

Arkkitehtuurityön vetovastuu on selkeästi tietohallinnolla

Tutkimuksen aikana tuli selvästi ilmi, et-tä yritysarkkitehtuurityö on edelleen hyvin vahvasti tietohallintofunktion vastuulla. Kaikissa haastatelluissa orga-nisaatioissa mahdollinen pääarkkitehti ja/tai arkkitehtitiimi sijaitsi organisato-risesti jossain IT-yksikössä. Liiketoimin-

tayksiköiden määrämuotoinen osallis-tuminen systemaattiseen arkkitehtuu-rityöhön oli joitain poikkeuksia lukuun ottamatta hyvin vähäistä.

Liiketoiminta ja IT tekevät hyvää yhteistyötä valtaosassa haastatelluista organisaatioista, mutta kokonaisvaltai-selle yritysarkkitehtuurin kehittämiselle ei tunnu ainakaan vielä olevan ”imua” liiketoiminnan tai ylimmän johdon suunnalta. Monissa organisaatioissa yri-tysarkkitehtuurin tavoitteet ja merkitys ymmärretään hyvin organisaatioiden johtoryhmässä, mutta käytännön ve-tovastuu on poikkeuksetta tietohallin-tofunktiolla. Tämä näkökulma saattoi korostua tutkimuksessa siksi, että haas-tateltavina oli pääasiassa tietohallinnon henkilöitä.

Arkkitehtuurin ”IT-vetoisuuden” taustalla on hyvin ilmeisesti se histori-allinen ilmiö, että tietohallintoyksiköt ovat jo tottuneet tekemään eri asteista arkkitehtuurityötä tietoteknisen ympä-ristön hallitsemiseksi.

Toisaalta aito yritysarkkitehtuuri-työ, jossa huomioidaan myös organi-saation liiketoimintamallit, prosessit ja niiden vaatimat tiedot on paljon har-vinaisempaa ja samalla paljon haasta-vampaa.

Tällöin määrääviksi kyvykkyyksiksi valikoituvat teknisen näkemyksen si-jaan muu osaaminen: pitkäjänteisyys, kyky käyttää liiketoiminnalle tuttua terminologiaa sekä kyky identifioida ja

kvantifioida arkkitehtuurityön hyötyjä varsinaisella toiminnalle. Tämä edel-lyttää liiketoiminnankin täysipainoista osallistumista arkkitehtuurityöhön.

2Keskeiset tutkimuslöydökset

Kokonaisvaltaiselle yritys-arkkitehtuurin kehittämiselle on vasta harvoissa organisaatioissa aitoa kysyntää liiketoiminnan tai

ylimmän johdon suunnalta.

Viitekehysten käyttö yllättävän vähäistä

Tutkimuksessa yllätti tietynlainen syste-maattisuuden puute arkkitehtuuritoi-minnassa. Yritykset, joissa noudatettiin arkkitehtuuriprosessia olivat vähem-mistössä ja samoin arkkitehtuuriviite-kehysten käyttö oli yllättävän vähäistä. Vain kolmasosalla oli käytössään kun-nollinen kehikko tai looginen rakenne, johon arkkitehtuurikuvaukset ryhmitel-lään.

Suurin osa jakaa arkkitehtuuri-työnsä neljään eri alueeseen: proses-siarkkitehtuuriin, tietoarkkitehtuuriin, järjestelmäarkkitehtuuriin ja tekniseen arkkitehtuuriin, mutta noin karkean jaon ei voida vielä katsoa edustavan riittävän johdonmukaista viitekehystä. Viitekehyksen puute tekee arkkitehtuu-rityöstä helposti epämääräistä ja tem-poilevaa.

10

Tietoarkkitehtuurin problematiikka

Edellä mainituista arkkitehtuurialueista tekninen arkkitehtuuri on vakiintuneis-sa yrityksissä suhteellisen hyvässä kun-nossa ja järjestelmäarkkitehtuurikin on kohtalaisen helposti hallittavissa. Mo-nissa yrityksissä ollaan pitkällä proses-sien kuvaamisessa ja jopa prosessien mukaisessa toiminnassa. Tällä alueella tehdään monin paikoin hedelmällistä yhteistyötä liiketoiminnan ja tietohal-linnon kesken.

Lähes kaikki haastatellut henkilöt allekirjoittivat väitteen, että tietoarkki-tehtuurin alueella on arkkitehtuurityön suurimmat haasteet.

Vaikuttaa siltä kuin tietoarkkiteh-tuuriin liittyvät kysymykset olisivat ”pudonneet väliin”. Liiketoiminta jättää liian usein tietoarkkitehtuuriin liittyvät kysymykset tietohallinnon huoleksi ja tietohallinto keskittyy vieläkin liian usein tiedon sijasta tekniikkaan. Kun lisäksi tietoarkkitehtuuriin liittyvät kysy-mykset ovat usein melko käsitteellisiä ja niiden ratkaiseminen edellyttää pitkä-jänteisyyttä, ei ole yllätys, että ongelmia syntyy. Ongelmat näkyvät esimerkiksi tiedon huonona laatuna ja yhdistel-tävyytenä, mikä puolestaan edelleen hidastaa prosesseja ja tekee toiminnan ohjaamisesta sattumanvaraista.

Tutkituissa organisaatioissa oli vain muutama esimerkki, joissa tietoarkki-tehtuuri oli sille kuuluvassa asemassa. Oikeaoppisesti ajateltuna ensin pitää määrittää toimintaprosessit ja niissä tarvittavat tiedot ja vasta tämän jälkeen organisoida ne eri tietojärjestelmiin, jotka toteutetaan valituilla teknologi-oilla. Tutkimus osoittaa, että tämä on helpommin sanottu kuin tehty.

Organisaation ulkopuolisen tiedon ja sisäisen tiedon yhdistely on vähäistä ja sattumanvaraista

Tutkimuksessa selvitettiin myös ns. tie-dolla johtamisen -käsitteen yleisyyttä ja sisältöä. Erityisesti käytiin läpi orga-nisaatioiden käytäntöjä liittyen organi-saation ulkoisten tietojen (ns. business intelligence) -prosesseihin.

Yleisesti voidaan todeta, että tie-dolla johtaminen ei ainakaan vielä ole kovin yleisesti käytetty termi tai vaalittu aihe tutkituissa yrityksissä.

Tietoa käytetään tietysti jatkuvas-ti päätöksenteossa, mutta todellinen tiedolla johtaminen pitää sisällään pitkälle kehitetyn ja hienovaraisen ra-portointijärjestelmän ja sen tehokkaan hyödyntämisen. Tällaista järjestelmää tulee kehittää systemaattisesti ja siitä tulee saada hyvin ajantasaista tietoa organisaation johtamiseen. Yksittäisen tietotarpeiden täyttäminen ei riitä

Organisaatioiden business intelli-gence -prosessit vaikuttivat monessa tapauksessa melko vaatimattomilta ja/ hajanaisilta.

Ulkoinen business intelligen-ce -tieto on tyypillisesti vähemmän strukturoitua, mutta useammin tule-vaisuuteen suuntautuvaa kuin yrityk-sen sisäinen tieto. Ainakin strategisen suunnittelun näkökulmasta tällainen ulkopuolinen tieto (markkinatutkimus,

kilpailija-analyysit, ennakointi) on kiin-nostavampaa kuin organisaation pe-rinteisen raportointijärjestelmän tuot-tama tieto.

Haastatteluissa kävi ilmi, että yh-dessäkään haastatellussa organisaati-ossa tietohallinto ei ollut vastuussa ul-koisen tiedon hankinnasta, hallinnasta ja prosessoinnista. Niissä harvoissa tapauksissa, joissa IT-osastolla oli jokin rooli bi-prosessissa, vastuu rajoittui lähinnä tarvittavia työkalujen (esim. kollaboraatiotyökalut) toimittamiseen. Tällainen vastuunjako vaikuttaa siis hy-vin vakiintuneelta, mutta samalla herää kysymys, onko se perusteltua ainakaan silloin, jos halutaan edetä kohti tiedolla johtamista.

Voisi kärjistäen sanoa, että vaikka arvokkain tieto on strukturoimatonta ja/tai tulee organisaation ulkopuolel-ta, organisaatiot – ja varsinkin niiden IT-yksiköt – keskittyvät ”tuunaamaan” tietokantoja ja operatiivisia järjestel-miä. Tämä voi itse asiassa olla merkki huonosta arkkitehtuurisuunnittelusta, mistä syystä sisäinen tietojärjestelmä-kokonaisuus vaati suhteettoman paljon huomiota ja ylläpitoa.

Tietoarkkitehtuuriin liittyvät kysymykset ”putoavat

väliin”: liiketoiminta jättää ne tietohallinnon huoleksi ja

tietohallinto keskittyy liian usein tiedon sijasta tekniikkaan.

Strategisen suunnittelun näkökulmasta ulkopuolinen

tieto on kiinnostavampaa kuin organisaation perinteisen

raportointijärjestelmän tuottama tieto.

Hyvin mielenkiintoinen ja samalla huolestuttava havainto oli se, kuinka vähäistä on ulkoisen ja sisäisen tiedon keskinäinen prosessointi. Ainostaan parissa kolmessa organisaatiossa oli selviä merkkejä systemaattisesta

11

tavasta kahdesta eri suunnasta tulevan tiedon yhdistelyyn. Suomalaisilla orga-nisaatiolla tuntuu olevan vielä paljon parannettavaa ja paljon tekemistä mat-kalla kohti tiedolla johtamista, jolloin sisäistä ja ulkoista tietoa yhdistellään ja analysoidaan säännöllisesti osana pää-töksenteko- ja johtamisprosesseja.

Arkkitehtuurityön hyödyt

Yritysarkkitehtuurityön hyödyllisyys nähtiin ensisijaisesti siinä, että sen avul-la luodaan tietotekniselle kokonaisuu-delle liiketoimintaprosesseja tukeva ta-voitetila, jota kohti liiketoiminnan kehi-tysprojekteilla ja järjestelmäprojekteil-la edetään. Kun tällaisesta tavoitetilasta pystytään sopimaan, muokkaa se pro-jektisalkkua yhdensuuntaiseksi ja hillit-see projektikohtaista osaoptimointia.

Toinen keskeinen yritysarkkiteh-tuuritoiminnan hyöty on muutosten ai-heuttamien vaikutusten analysoinnin helpottuminen. Organisaatioiden toi-mintaympäristöissä tapahtuu jatkuvas-ti muutoksia, joista syntyy vastaavasti muutostarpeita liiketoimintaprosessei-hin ja niitä tukeviin tietojärjestelmiin ja -tekniikkaan. Selkeä kuva arkkitehtuurin nykytilasta ja eri komponenttien välisis-tä riippuvuuksista mahdollistaa muu-toksen vaikutusten nopean analyysin ja myös arvion siitä, kannattaako aiottua muutosta ollenkaan tehdä.

Kolmas arkkitehtuurityön hyöty on sen toimiminen yhteisenä toiminnan-kehittämisen käsitteistönä tai kielenä, joka on yleisesti hyväksytty organisaa-tion avainhenkilöiden keskuudessa. Tällöin yritysarkkitehtuurityö voi toimia yleisenä toiminnan kehittämisen kehik-kona ja se voidaan nähdä myös laadun parantamisen metodina.

Arkkitehtuurityön hyötynä nähtiin myös harmonisointi eri muodoissaan: prosesseissa, järjestelmissä, tiedossa ja tekniikassa. Harmonisoinnin nähtiin poikkeuksetta helpottavan kokonai-suuden hallinnointia ja alentavan kus-tannuksia.

Vaikka läpikäytyjen organisaatioi-den tietointensiivisyydessä (=kuinka olennainen osa tuotteita ja toimintaa tieto on) oli eroja, niin tietojärjestelmi-en liiketoimintakriittisyydestä vallitsi haastateltavien keskuudessa selkeä yksimielisyys. Kaikissa organisaatioissa tunnistettiin prosessien ja tietoteknis-ten resurssien ”kohtalonyhteys” eli se, että suurta osaa prosesseja ei voi pyö-rittää (ainakaan hyväksyttävällä tehok-kuudella) ilman tietojärjestelmää. Koska prosessin käytännön suorittaminen on koodattu tietojärjestelmän logiikaksi, prosesseja ei ole mielekästä edes kehit-tää irrallaan tietojärjestelmästä. Ja tämä johtaa edelleen systemaattisen yritys-arkkitehtuurin tarpeeseen.

Selkeä kuva arkkitehtuurin nykytilasta mahdollistaa

vaikutusten analyysin ja arvion siitä, kannattaako aiottua

muutosta ollenkaan tehdä.

Yksityiskohtaiset käytännöt

Tutkimuksen liitteessä on kuvattu tar-kemmalla tasolla, kuinka yleisesti haas-tatelluissa organisaatioissa ovat käytös-sä arkkitehtuurityön keskeiset elemen-tit, kuten mm. pääarkkitehdin rooli, sys-temaattinen arkkitehtuuriprosessi tai viitekehys.

Samoin liitteessä on kuvattu yritys-ten kolme peruslähestymistapaa yritys-arkkitehtuurityöhön.

12

Kirjassaan ’Enterprise Architecture as Strategy’ Jeanne Ross ja kumppanit esittelevät neljä kypsyysvaihetta, joiden kautta organisaatiot tyypillisesti etene-vät niiden yritysarkkitehtuurimaturee-tin kasvaessa. Vaiheet näkyvät yllä ole-vassa kuvassa.

Karkeasti arvioiden haastatelluis-ta organisaatioista seitsemän on en-simmäisessä vaiheessa tai vasta pyr-kimässä kakkostasolle. Kakkostasolla on toiset seitsemän organisaatiota ja

kolmostasolla yksitoista, joista vasta 2–3 on matkalla kohti ylintä tasoa.

Tutkimuksessa luotiin oma kyp-syysmalli organisaatioiden yritysark-kitehtuurivalmiuksille kuvaamaan sitä, kuinka valmiita organisaatiot ovat systemaattiseen arkkitehtuurityöhön. Kypsyysmalli ottaa huomioon edellises-sä kappaleessa esitellyt yritysarkkiteh-tuurityön peruselementit: työn resur-soinnin, prosessit, viitekehyksen, hallin-tamallin, liiketoiminnan osallistumisen

yritysarkkitehtuurityöhön sekä arkki-tehtuuritoiminnan ajallisen keston. Näi-den kriteerien perusteella läpikäydyt organisaatiot on sijoitettu yhdeksän-portaiselle arkkitehtuurin kypsyysastei-kolle.

Luotu kypsyysmalli ei ole tieteelli-sen tarkka, vaan suhteellinen eli sellai-nen, jossa läpikäydyt organisaatiot on asetettu karkeaan järjestykseen arkki-tehtuurikäytäntöjensä perusteella.

3Yritysarkkitehtuurin kypsyysmalli ja suomalaisten organisaatioiden sijoittuminen sen eri tasoille

Yritysarkkitehtuurin neljäkypsyysvaihetta

Business silos

Standardizedtechnology

Optimizedcore

Businessmodularity

13

Arkkitehtuurin kypsyystason avulla tehtiin kolme vertailevaa analyysiä, joista voi tehdä kiinnostavia päätelmiä. Ensim-mäisessä analyysissä kypsyystasoa verrat-tiin organisaation toimialan tietointensii-visyyteen jolloin saatiin seuraava kuva:

Kuvassa arkkitehtuurin kypsyys kasvaa vasemmalta oikealle. Tasolla yksi olevilla organisaatioilla on käytän-nössä vain de facto arkkitehtuuri eikä sitä kehitetä erillisenä toimintona. Ta-solla viisi oleva yritys tekisi yritysarkki-tehtuurityötä hyvin systemaattisesti ja

niin, että liiketoiminta osallistuisi siihen hyvin kokonaisvaltaisesti. Tälle tasolle ei nykyisellään yllä yksikään haastatelluis-ta organisaatioista.

Pystyakselilla on toimialan tietoin-tensiivisyys siten, että ylimpänä on toi-miala, jossa koko tuote on pelkkää tie-toa ja alimmalla tasolla toimiala, jossa tiedon merkitys tuotannontekijänä on vielä sekundäärinen. Huom! Toimialat ovat esimerkin omaisia, eivätkä kaikilta osin viittaa tutkimuksen kohteina ollei-den organisaatioiden toimialoihin.

Arkkitehtuurin kypsyyden voi sanoa korreloivan toimialan tietointen iivisyyden kanssa melko hyvin. Muutama organisaa-tio poikkeaa pääsäännöstä kuitenkin mel-ko paljon. Lähimpänä oikeaa alakulmaa olevilla yrityksillä on suhteellisen hyvät arkkitehtuurivalmiudet, vaikka ne eivät toimikaan erityisen tietointensiivisillä aloil-la. Lähimpänä vasenta yläkulmaa olevat organisaatiot taas toimivat hyvin tietoin-tensiivisillä aloilla, mutta niiden yritysark-kitehtuurityön systemaattisuus ei ole vielä kovin korkealla tasolla.

Arkkitehtuurin kypsyys jatietointensiivisyys

ADHOC

Käynnis-tymässä

Frameworkja prosessit

Vakiintuneetkäytännöt

BusinessInvolvement

5

4

3

2

1

1 2 3 4 5

Inte

nsi

ivis

yys

Esimerkki-toimiala

Analyytikkotalo

Mediatalo

Finanssiyritys

Telco

Kauppa,Erikoisteollisuus

Konepajateollisuus

Prosessiteollisuus

Ravintola

Maansiirto

Arkkitehtuurin kypsyys

1

2

3

4

5 6

7

8

9

10

21

2223

24

25

11

12

13

14

15

16

17

18

1920

14

Toisessa vaiheessa arkkitehtuuri-kypsyyttä verrattiin organisaation komp-leksisuuteen. Tuloksena saatiin alla ole-va kaavio.

Kompleksisuus määriteltiin kolmen osion summana: • organisatorinen kompleksisuus,

joka kuvaa sitä, miten stabiili yri-tyksen organisaatio on. Esimerkik-si vast’ikään tehdyt suuret fuusiot lisäävät tämän elementin komp-leksisuutta.

• tietojärjestelmien kompleksisuus. Organisaatio, jossa on käytössä laaja ja vakiintunut toiminnanoh-

jausjärjestelmä (ERP) on tästä nä-kökulmasta vähemmän komplek-sinen kuin organisaatio, jossa on satoja erilaisia järjestelmiä ja nii-den joukossa useita ERP’ejä.

• prosessien ja tai businessmallien kompleksisuus. Tästä osiosta kor-keat pisteet saa organisaatio, jolla on useita erilaisia liiketoimintamal-leja ja/tai prosesseja.

Kustakin osiosta organisaatio saat-toi saada 0–3 pistettä, joiden summa-na saatiin kymmenportainen asteikko (0–9).

Kuviossa näkyy kolme organisaa-tiota, jotka ovat lähempänä oikeaa ala-kulmaa kuin pääjoukko. Nämä voivat katsoa olevansa nykyisillä arkkitehtuu-rikäytännöillään melkoisen turvassa suhteessa organisaation kompleksisuu-teen. Sitä vastoin vasemmalla ylhäällä erottuvat kolme organisaatiota ovat tilanteessa, jossa organisaatio on yritys-arkkitehtuurimielessä hyvin komplek-sinen, mutta organisaatiot ovat arkki-tehtuurikäytännöissään suhteellisen al-haisella tasolla. Näissä organisaatioissa tilaus arkkitehtuurityön tehostamiselle on ilmeinen.

Arkkitehtuurin kypsyys jakompleksisuus

ADHOC

Käynnisty-mässä

Frameworkja prosessit

Vakiintuneetkäytännöt

BusinessInvolvement

9

7

5

3

1

1 2 3 4 5

Esimerkki

Fuusioita, hajanainensovellussalkku,erilaisiaansaintamalleja

Uudistettu tai laajaorganisaatio, useitajärjestelmiä,rajallinen määräansaintamalleja

Yhtenäinenorganisaatio,vahva ERP, harvojaansaintamalleja

Ko

mp

lek

sisu

us

Arkkitehtuurin kypsyys

1 2 34

5

6

7

8

9

10

2122

23

24

25

11

12

13

14

15

16

1718

19

20

15

Viimeisessä analyysissä nämä kaksi aiempaa analyysiä yhdistettiin, jolloin saatiin suure ympäristön haasteellisuus ja seuraavan kaltainen kuva.

Haasteellisuus määriteltiin tie-tointensiivisyyden ja kompleksisuuden

summana niin, että tietointensiivisyyden arvo kerrottiin kahdella (jotta kompleksi-suus ei korostuisi liikaa).

Tässä analyysissä hajonta on jo selvästi suurempaa kuin kahdessa ai-emmassa. Mitä kauempana yritys on

yläpuolella diagonaalia, joka leikkaa kaavion vasemmasta alakulmasta oi-keaan yläkulmaan, sitä tärkeämpää sen olisi panostaa yritysarkkitehtuurival-miuksiinsa.

Arkkitehtuurin kypsyys ja yleishaastavuus

1 2 3 4 5

Esimerkki

Tietointensiivinenja kompleksinen

Tiedon merkityspienempi, selkeäorganisaatio jarajallinen määräansaintamalleja

Ha

ast

av

uu

s

Arkkitehtuurin kypsyys

ADHOC

Käynnis-tymässä

Frameworkja prosessit

Vakiintuneetkäytännöt

BusinessInvolvement

15

13

11

9

7

1

2

3

6

23

7

8

9

21

22

25

1112

13

14

15

18

19

20

10

1617

4

5

24

16

Tässä kappaleessa esitellään tutkimuk-sen aikana esiin tulleita hyviä yritysark-kitehtuurikäytäntöjä. Ne eivät ole pa-remmuusjärjestyksessä, eivätkä ne kaik-ki ole sovellettavissa kaikissa organisaa-tioissa, mutta toisaalta ne voivat antaa ideoita oman arkkitehtuurityön kehit-tämiseen.

Arkkitehtuurin rakenne

Liitteessä on esitelty organisaatioiden kolme erilaista lähestymistapaa arkki-tehtuurityöhön. Niin sanotun ToBe-ark-kitehtuurivision luominen voisi tapah-tua joko ns. greenfielding tai referenssi-arkkitehtuurin hankkimisen avulla. Eräs pääarkkitehdeista oli toiminut mukana laajassa projektissa, jossa ison yrityksen yhtä toimialaa suunniteltiin ”puhtaal-ta pöydältä”, ilman vallitsevien nykypro-sessien ja järjestelmien painolastia. Täl-löin voitiin aidosti miettiä kyseisen lii-ketoiminnan kokonaisoptimointia sekä prosessien ja järjestelmien saumatonta yhteispeliä.

Tavoitemalli voidaan myös luoda hankkimalla esimerkiksi alaa tuntevalta konsulttitalolta toimialakohtainen refe-renssiarkkitehtuuri, jota voidaan pitää toimialan kokonaisvaltaisena parhaana käytäntönä. Jos malli hankitaan, kan-nattaa aluksi kuitenkin huolella miettiä,

onko siinä osia (prosesseja), joita halli-tusti muuttamalla voidaan saada kilpai-luetua suhteessa alan muihin toimijoi-hin.

Tutkimuksessa tuli esille muutamia yritysarkkitehtuuriin liittyviä laadullisia määreitä. Näistä kannattaa nostaa esille ymmärrettävyys, hallittavuus ja ”kestävyys” (englanninkieliset termit: understandable, manageable ja sustai-nable). Nämä kaikki ovat tärkeitä mää-reitä laadukkaalle yritysarkkitehtuurille. Kokonaisuus ei saa olla niin kryptinen, että vaadittaisiin erikoisosaamista, jotta ymmärtäisi sen sisältöä ja hyötyjä. Toi-saalta arkkitehtuuri ei saa olla niin mo-nimutkainen, että sen kehittäminen ja hyödyntäminen muuttuvat painolastik-si. Viimeisen määreen voisi tulkita siten, että hyvä arkkitehtuuri on henkilöriip-pumaton. Tämä vaatimus on läheisessä yhteydessä kahteen edelliseen ja aset-taa korkeat vaatimukset arkkitehtuurin johdonmukaisuudelle ja dokumentoin-nin tasolle.

Tunnetun ja paljon sovelletun Togaf-viitekehyksen monista hyvistä käytännöistä nousi esiin suositus etsiä organisaatiosta uudelleen käytettäviä elementtejä. Tätä ohjenuoraa voi nou-dattaa itse asiassa missä tahansa arkki-tehtuurityön vaiheessa. Kun organisaa-tiossa opitaan vaalimaan elementtien

(ohjelmistokomponenttien, prosessien, teknologian jne.) uudelleenkäyttöä – niin kehittämisessä kuin käyttämisessä – luodaan perustaa kustannussääs-töille, ympäristön harmonisoinnille ja toiminnan modulaarisuudelle. Viime mainittu on tärkeää mm. toiminnan joustavuuden kannalta.

4Yhteenveto arkkitehtuurityön hyvistä käytännöistä ja sudenkuopista

Hyvä arkkitehtuuri on henkilöriippumaton.

Roolitus

Eräs parhaista haastatteluissa kuulluis-ta yksittäisistä kommenteista oli tä-mä: ”Pääarkkitehdin roolin pitää ol-la leadership-rooli, ei asiantuntijaroo-li”. Leadership-rooli merkitsee sitä, et-tä paitsi ymmärtää aidosti organisaati-on varsinaisen toiminnan tavoitteita, pi-tää myös toimia aloitteellisesti (johdan-nossa mainitun) operatiivisen koneen rakentamisessa. Tämä edellyttää arkki-tehtuuriprosessin ja -elementtien hal-litsemisen lisäksi suhdetoimintakykyä, vaikutuskykyä ja usein jopa diplomaat-tista painostusta.

Toinen mielenkiintoinen ajatus liit-tyen arkkitehtuurirooleihin oli analogia lainsäätäjiin ja poliiseihin. Arkkiteh-tuuria voisi verrata lakiin, koska sekin

17

sisältää sääntöjä ja periaatteita, joita tulee noudattaa. Kuten laeilla, arkkiteh-tuurillakin on niiden säätäjiä ja valvojia. Lain tapauksessa nämä ovat eri rooleja ja ne vaativat erilaista osaamista. Vaikka hyvänä käytäntönä voidaan pitää ark-kitehtien tiivistä yhteistyötä projektien kanssa, kannattaa harkita, tulisiko nämä kaksi roolia antaa eri henkilöiden tai ryhmien tehtäväksi.

Liiketoiminnan rooli yritysarkkitehtuurityössä

Yritysarkkitehtuurin tekeminen pelkäs-tään tietohallinnon voimin muuttuu sitä vähemmän mielekkääksi, mitä pidem-mälle arkkitehtuurin kypsyysmalleissa edetään. Vaikka tietohallintoihmisillä on usein erinomaiset valmiudet johtaa yri-tysarkkitehtuuritoimintaa, on tuossa toi-minnassa viime kädessä kyse siitä, kuin-ka organisaatio tekee businessta ja to-teuttaa missiotaan ja vastuu siitä kuuluu organisaation ylimmälle johdolle.

Mitä sitten pitäisi tehdä, jotta yritysarkkitehtuuri ei rajoittuisi tieto-hallintoihmisten teknispainotteiseksi suunnitteluksi? Tämä kysymys kirvoitti tutkimuksen aikana paljon keskustelua ja joukon hyviä ideoita:

On ensisijaisen tärkeää, että yritys-arkkitehtuurissa käytetään liiketoimin-taan läheisesti liittyviä käsitteitä ja ter-minologiaa eikä IT-jargonia. Tämä antaa arkkitehtuurityölle liiketoimintaihmisten keskuudessa uskottavuutta ja madaltaa heidän osallistumiskynnystä.

Toinen tärkeä ajatus on suunnata arkkitehtuuritoimintaa niin, että sillä pyritään ratkaisemaan olemassa oleva, konkreettinen liiketoimintaongelma tai -tarve. Mitä tämä tarkoittaa käytännös-sä? Sen sijaan, että luodaan pelkästään

ylätason periaatteita esimerkiksi tiedon omistajuudesta tai teknologiavalinnois-ta, voidaan etsiä ajankohtaisia liiketoi-mintatarpeita ja suunnata arkkitehtuu-rityötä niiden ratkaisemiseksi.

Liiketoimintatarpeita voi ryhmitel-lä esimerkiksi seuraavan jaon mukaises-ti: tuottojen lisääminen (top line impro-vement), kustannustehokkuus (bottom line improvement), riskien hallinta (risk management) tai ketteryyden paranta-minen (agility).

Tarpeet voisivat olla seuraavia: • Top line: Halutaan kehittää eri tuot-

teiden ristiin myyntiä olemassa oleville asiakkaille. Vaikutus arkki-tehtuuriin: täytyy parantaa tieto-mallia, jotta mahdollistetaan asia-kastietojen (ja mahdollisesti tuo-tetietojen) parempi yhdisteltävyys.

• Bottom line: Halutaan pienentää organisaation kiinteitä kuluja. Vai-kutus arkkitehtuuriin: harmonisoi-daan palvelinalustoja ja jätetään tiettyjä teknologiasukupolvia vä-liin.

• Risks: Halutaan parantaa liiketoi-minnan jatkuvuutta poikkeustilan-teissa. Vaikutus arkkitehtuuriin: tu-lee olla selvä kuva teknisen ympä-ristön riippuvuuksista, esimerkiksi siitä, mitkä prosessit käyttävät mi-täkin järjestelmiä.

• Agility: Valitaan strategiaksi laajen-tua yritysostoin. Vaikutus arkkiteh-tuuriin: mietitään, miten nykyark-kitehtuurin eri osia pitäisi muut-taa, jotta ostettavien yritysten in-tegrointi nopeutuisi ja helpottuisi.

Edellä mainitut arkkitehtuuritoimenpi-teet ovat joka tapauksessa tarpeellisia ja oikean suuntaisia askeleita kohti ko-

konaisuutta. Jos niitä tehdään ratkai-semalla samaan aikaan päivän poltta-va business tarve, on ylimmällä johdol-la aito kiinnostus asiaan.

Viimeinen liiketoimintayhteis-työhön liittyvä hyvä käytäntö koskee myös ketteryyttä. Tietohallintofunktio käy monesti keskustelua liiketoiminnan kanssa hengessä: ”kertokaa, mitä aiotte tehdä, niin rakennamme teille tarvit-tavan IT-kokonaisuuden tai teknisen arkkitehtuurin”. Lähestymistapa on siis hyvin deterministinen. Liiketoiminta ajattelee sen sijaan opportunistisesti tyyliin: mitä uusia tilaisuuksia businek-sen tekoon avautuu ja ovatko ne pii-levän riskinoton arvoisia. Jos arkkiteh-tuuri suunnitellaan pelkästään oppor-tunistisesta lähtökohdasta, tarvittaisiin arkkitehtuuri, jota voisi soveltaa mille tahansa toimialalle, mikä on tietysti utopistinen ajatus.

Olennaista olisi käydä liiketoimin-nan kanssa syvällistä ja aitoa keskus-telua siitä, minkä asioiden (prosessien, tietojen, verkkojen jne.) pitää olla jous-tavia eli helposti muutettavissa. Kun keskustelu on käyty, on arkkitehtuuri-vastuullisilla selvä käsitys liiketoimin-nan odotuksista ja vastaavasti liiketoi-minnalla realistinen käsitys arkkitehtuu-rin asettamista reunaehdoista. Tällöin arkkitehtuurityötä päästään tekemään oikealla tasolla ja oikeilla odotuksilla.

Tietohallinto ajattelee usein deterministisesti, kun taas liiketoiminta tyypillisesti

opportunistisesti: mitä uusia tilaisuuksia busineksen tekoon

avautuu ja ovatko ne riskin arvoisia?

18

Tietoarkkitehtuuri

Tietoarkkitehtuuri on useimmilla haas-tatelluista organisaatioista kenties sel-kein arkkitehtuurin ongelma-alue. Tie-toarkkitehtuuriin kuuluvat muun mu-assa tietojen mallinnukseen ja perustie-tojen hallintaan (Master Data Manage-ment) liittyvät kysymykset.

Moni organisaatio lähestyy ongel-maa myös järjestelmäpohjaisesti niin, että ne soveltavat niitä tietomalleja, joita valittavat järjestelmät käyttävät. Tämä voi olla toimiva ratkaisu, mikäli organisaatiossa on pieni määrä vahvoja ydinjärjestelmiä, mutta muussa tapauk-sessa voidaan joutua valtavaan integ-rointisuohon, jos eri tietomalliin perus-tuvia järjestelmiä halutaan yhdistellä.

Eräs haastatelluista organisaatiois-ta, jolla oli käytössä laaja, keskitetty ERP-järjestelmä piti kuitenkin yllä keskeisten tietojen osalta omaa erillistä tietomal-lia, joka oli ”virallinen” tietomalli. Toinen organisaatio oli saanut operatiivisen raportoinnin hyvin vahvalle pohjalle niin ikään itsenäistä tietomallia sovel-tamalla.

Eräs haastatelluista oli rajannut tie-tohallinnon ja liiketoiminnan vastuut tietojen osalta periaatteelle ”IT vastaa datasta ja liiketoiminta informaatiosta”.

Yksi tutkituista organisaatioista pyrki tunnistamaan ja kartoittamaan, mikä organisaatiossa oleva tieto on todella arvokasta. Tällaisen harjoituk-sen tuloksista voidaan johtaa useitakin tarvittavia toimenpiteitä arkkitehtuurin kehittämiselle.

Ulkoisen ja sisäisen tiedon prosessointi

Vain muutamalla haastatelluista organi-saatioista on tehty toimenpiteitä orga-nisaation ulkopuolisen tiedon ja sisäi-sen tiedon yhdistelemiseksi. Paras käy-täntö tässä tuntuu olevan pieni tiimi, joka toimii näiden kahden tiedon sol-mukohtana. Tiimissä voisi olla analyyti-kon, informaatikon ja controllerin roo-leissa toimivia henkilöitä. Tiimin tehtä-vänä on, paitsi yhdistää erityyppistä tie-toa päätöksentekoa varten mielekkääl-lä tavalla, myös kehittää tiedon hyödyn-tämisen osaamista ja prosesseja.

Riskit

Haastatteluissa nousi esille joukko yri-tysarkkitehtuuriin liittyviä riskejä tai ”huonoja käytäntöjä”.

Selvästi yleisimpänä riskinä pidet-tiin arkkitehtuurityön eristämistä tai eristäytymistä omaksi saarekkeekseen ilman kontakteja varsinaiseen kehitys-toimintaan. Jos tämä riski toteutuu, arkkitehtuurityöstä tulee vain tarpeet-tomia hallintokuluja organisaatiolle. Yritysarkkitehtuurityö ei saa olla itse-tarkoituksellista, vaan sitä pitää voida soveltaa kehittämistyöhön.

Toinen mielenkiintoinen näkö-kulma riskeihin liittyi nykyisin melko suuressa muodissa oleviin ketteriin ke-hitysmenetelmiin (esim. Scrum). Niiden ydinajatus on edetä vahvasti iteroiden ja niin, että kukin pienehkö iteraatio to-teuttaa täysin valmiin lopputuotoksen, esimerkiksi ohjelmistokomponentin.

Vaikka ketterillä menetelmillä on varmasti hyvät puolensa, ne asettavat suuria haasteita arkkitehtuurityölle ja arkkitehtuurin soveltamiselle. Mikäli arkkitehtuuri on epäselvä tai sen so-veltamisprosessi ontuu, ketterät me-netelmät lisäävät hajanaisuutta ja osa-optimointia. Niiden perusfilosofiaan ei kuulu erityisen kokonaisvaltainen suunnittelu. Toisaalta taas vahvan ark-kitehtuurin omaavissa organisaatioissa pystytään tarkkaan määrittämään ne rajat joita kunkin yksittäisen projektin tulee toteuttaa. Tällöin lähestymista-pa on kokonaisuutta optimoiva, mikä edellyttää proaktiivista suunnittelua.

Mikäli arkkitehtuuri on epäselvä tai sen soveltamisprosessi ontuu,

ketterät menetelmät lisäävät hajanaisuutta ja osaoptimointia.

19

Johtopäätökset

Suomalaiset organisaatiot voisivat ol-la paljon tehokkaampia ja kilpailukykyi-sempiä, jos ne osaisivat nykyistä parem-min hyödyntää saatavilla olevaa tietoa. Ongelmana on vähäinen panostus ul-koisen tiedon prosesseihin, sisäisen tie-don vaatimaton käyttö johtuen tiedon huonosta laadusta ja yhdisteltävyydes-tä sekä ulkoisen ja sisäisen tiedon yh-distelyn puute.

Yritysarkkitehtuuri on prosessi, jota kehittämällä yritykset voivat parantaa toimintaprosessiensa ja tietoteknisten resurssiensa kokonaisvaltaista suun-nittelua. Systemaattisen arkkitehtuurin käyttöönotolla organisaatiot voivat ra-kentaa tehokkaan, toimintavarman ja joustavan ”operatiivisen koneen” ydin-toimintansa tueksi. Johdonmukainen arkkitehtuuri parantaa yrityksen sisällä syntyvän tiedon laatua ja hyödynnet-tävyyttä. Ulkoisen ja sisäisen tiedon yh-distelyä voidaan tehostaa olennaisesti pienillä prosessimuutoksilla.

Yritysarkkitehtuurityö on luonteel-taan jatkuvaa toiminnan parantamis-ta, minkä pitäisi olla organisaatioiden tehtävänä joka tapauksessa. Yritysark-kitehtuurityön avulla voidaan luoda organisaatiolle yhteinen tahtotila siitä, mitä edellä mainittu operatiivinen ko-ne edellyttää prosesseilta, tiedoilta ja

tietotekniikalta. Yhteinen tahtotila aut-taa kehitysprojektien suuntaamisessa ja johtaa kohti kustannustehokasta ja toimintavarmaa operatiivista ympäris-töä. Se parantaa selvästi myös tietojen hyväksikäyttöä ja vapauttaa resursseja tuotekehitykseen ja innovointiin. Toi-miva yritysarkkitehtuuri tekee tiedolla johtamisen mahdolliseksi.

Yritysarkkitehtuuritoiminnan ”kil-pailijoiksi” voidaan laskea muut laajat liiketoiminnan kehitysmetodit. Sitä voi-daan pitää yksinkertaisesti laadukkaan toiminnan kehittämisenä tai laaduk-kaana liikkeenjohtona. Yritysarkkiteh-tuuri erikoisominaisuus moneen muu-hun malliin verrattuna on sen tietojär-jestelmien ja –tekniikan huomioon ot-taminen. Yritysarkkitehtuuritoiminnan merkitys korostuu silloin, kun tieto on organisaatiolle tärkeä tuotantotekijä.

siaikaisesti keskittymään kyseiseen teh-tävään, saadaan helposti aikaan tun-tuvia tuloksia. Pääarkkitehdin kannat-taa lisäksi kerätä ympärilleen verkosto, jonka avulla hän kehittää vastuualuet-taan. Yritysarkkitehtuurikäytännöt kyp-syvät harvoin, jos niitä tehdään sivutoi-misesti.

Yritysarkkitehtuuri kannattaa mieltää toisaalta kehitysprosessina ja toisaalta rakenteellisena kokonaisuu-tena malleja, periaatteita, standardeja ja suosituksia. Arkkitehtuuritoiminnon pitäisi olla iteratiivista ja lähes jatkuvaa. Tästä syystä kannattaa alussa käyttää aikaa yritysarkkitehtuurin perusteiden kuntoon saattamiseen. Organisaation sisällä kannattaa luoda yhteinen näke-mys seuraavista asioista: • miten organisaatiossamme arkki-

tehtuurityötä tehdään (prosessi) • mitä tuloksia arkkitehtuurityöstä

odotetaan (tuotokset ja hyödyt) • miten ne organisoidaan (viite-

kehys) ja • miten tuloksia hallitaan

(governance).

Näiden perusteiden linjaaminen edes karkealla tasolla antaa huomattavan paljon ryhtiä yritysarkkitehtuurityölle.

Riippumatta siitä, millaisen lähes-tymistavan arkkitehtuurin kehittämi-seen valitsee, kannattaa työ aloittaa ja

5Johtopäätökset ja suosituksia

arkkitehtuuritoiminnan kehittämiseksi

Ongelmana on ulkoisen ja sisäisen tiedon yhdistelyn puute.

Suosituksia arkkitehtuuri-toiminnan kehittämiseksi

Kun organisaatio päättää tosissaan pa-nostaa yritysarkkitehtuurinsa paranta-miseen, kannattaa sen nimetä toimin-non johtoon päätoiminen pääarkki-tehti. Kun edes yksi henkilö pystyy täy-

20

tehdä organisaation eri toimintojen yhteistyönä, ei vain IT-yksikön harjoi-tuksena. Liiketoiminnan ja tietohal-linnon preferenssit saattavat poiketa toisistaan periaatteellisella tasolla. Tie-tohallinto saattaa suosia ensisijaisesti suorituskykyisiä ja hyvin luotettavia teknisiä ratkaisuja, kun taas liiketoimin-tayksiköiden tavoitteena olisi saada rat-kaisu tarpeeseen nopeasti ja edullisesti. Nämä kaksi lähestymistapaa pitää pysy-tä sovittamaan yhteen myös niin, että ne ovat kokonaisarkkitehtuurin kannal-ta perusteltuja.

Yritysarkkitehtuuria tulee soveltaa aitoon ja ajankohtaiseen liiketoimin-nan tarpeeseen. Tällöin arkkitehtuuri-työstä saadaan nopeasti konkreettisia hyötyjä.

Seuraavassa on lueteltu tapoja, mi-ten Tekes voisi näitä valmiuksia verkos-tossaan edistää: • Yritysarkkitehtuurin merkityksen

nostaminen esille eri yhteyksis-sä (Tekesin ohjelmat ja aktivointi-hankkeet).

• Kevyiden ja pragmaattisten arkki-tehtuurimenetelmien kehityksen tukeminen ja käyttöönoton edis-täminen.

• Hyvien käytäntöjen levittäminen erilaisissa yritysverkostoissa.

• Verkostojen tai ohjelmien sisäisen arkkitehtuurityön katalysointi, mi-käli siihen on tarvetta. Tämä työ on arvokasta varsinkin silloin, jos ver-kostossa ei ole muuta toimijaa, jo-ka luontevasti voisi ottaa vastuun tarvittavista arkkitehtuurilinjauk-sista.

• Yritysarkkitehtuurien kehittämis-työn rahoittaminen erikoistapauk-sissa.

Nykyisellään Tekesin oman toiminnan lisäksi voi kokonaisarkkitehtuurin liitty-viä kehityskokonaisuuksia olla mukana strategisen huippuosaamisen keskitty-mien (SHOK) ohjelmissa. Tieto- ja vies-tintäteollisuuden tutkimus Oy (Tivit Oy) on käynnistänyt useita ohjelmia, joissa arkkitehtuurikysymykset ovat tärkeässä osassa kokonaisuuden kannalta (kts. li-sää - ICT SHOK - www.tivit.fi).

Lopuksi

Tiedon määrän ja merkityksen kasvu or-ganisaatioissa on huomattavaa ja ylei-sesti tunnustettua. Tiedon käsittelyä varten rakennetut järjestelmät ja muu tietotekniikka muodostavat usein hy-vin monimutkaisen kokonaisuuden, jonka hallinta aiheuttaa ylettömän pal-jon vaivaa ja kustannuksia. Samaan ai-kaan tiedon hyödynnettävyydessä on paljon puutteita ja liiketoiminnan halu-amat muutokset ovat hitaita toteuttaa. Organisaatiot ovat jääneet tietojärjes-telmiensä panttivangeiksi.

Systemaattisen yritysarkkitehtuu-rityön avulla prosessien ja tietoteknis-ten resurssien kokonaisuutta voidaan parantaa ja siten saada organisaation tietopääoma paremmin hyödynnettyä.

Ja vastauksena tämän raportin alussa olleeseen kysymykseen (teem-mekö parempaa businesstä, jos meillä on olemassa systemaattinen yritys-arkkitehtuuri?): todennäköisesti kyllä. Ainakin hyvä arkkitehtuurityö luo sille erinomaiset edellytykset.

Tietohallinnon preferenssi: suorituskykyinen ja

hyvin luotettava ratkaisu. Liiketoimintayksiköiden

preferenssi: ratkaisu tarpeeseen nopeasti ja edullisesti.

Suosituksia Tekesin rooliksi arkkitehtuurivalmiuksien ja tiedolla johtamisen edistämiseksi.

Jokainen organisaatio on viime kädes-sä itse vastuussa siitä, millaista sen yri-tysarkkitehtuuritoiminta on. Tekes toi-mii tyypillisesti laajassa verkostossa, jos-sa sen intressinä voi olla yritysarkkiteh-tuurikäytäntöjen ja ennen kaikkea tie-don hyödyntämisen parantaminen.

Organisaatiot ovat jääneet tietojärjestelmiensä

panttivangeiksi.

21

Kolme lähestymistapaa arkkitehtuurityöhön

Tutkituissa organisaatioissa voitiin erot-taa kolme erilaista lähestymistapaa ark-kitehtuurityöhön, joita kutsutaan tässä nimillä AsIs-metodi, Ahead-metodi ja ToBe-metodi. • AsIs-metodia noudattavat yrityk-

set pyrkivät olemaan hyvin selvil-lä nykyisistä arkkitehtuurielemen-teistä ja niiden välisistä riippu-vuuksista. Arkkitehtuuria kehite-tään lähinnä projektien mukana.

• Ahead-metodia soveltavat organi-saatiot pyrkivät rakentamaan ark-kitehtuuria proaktiivisesti niin, et-tä tarpeelliset linjaukset ovat ole-massa ennen niitä soveltavia pro-jekteja.

• ToBe-metodia soveltavat organi-saatiot luovat arkkitehtuurista vi-sion tai ideaalimallin, jota kohti ne etenevät projektien avulla.

Vaikka rajanveto tässäkin on vaikeaa ja moni tekee työtä noiden metodien yh-distelmällä, niin karkeasti voidaan sa-noa neljän organisaation suosivan AsIs-metodia, kahdeksan käyttävän pääasi-assa Ahead-metodia ja yhdeksän ToBe-metodia (neljä organisaatiota ei sijoitu selkeästi mihinkään vaihtoehtoon).

Mikään näistä metodeista ei ole yksiselitteisesti toisia parempi, vaan kussakin lähestymistavassa voidaan nähdä hyviä ja huonoja puolia. Näiden yhteenveto on esitetty seuraavassa tau-lukossa:

Vallitsevat arkkitehtuuri-käytännöt tutkituissa organisaatioissa: prosessit, viitekehykset ja päätöksen-tekomallit

Systemaattinen yritysarkkitehtuurityö sisältää tiettyjä peruselementtejä. Tällai-sia ovat oikea resurssointi, arkkitehtuu-rin luonti- ja soveltamisprosessi, jonkin-lainen arkkitehtuurin viitekehys, hallin-tamalli (governance) ja tapa tehdä yh-teistyötä liiketoiminnan kanssa. Näiden olemassaoloa kysyttiin kaikissa haastat-teluissa.

Resurssointi

Tutkituista organisaatioista yli puolel-la (15 kpl) oli nimetty pääarkkitehti tai henkilö, joka oli vastuussa yritysarkki-tehtuuritoiminnasta. Näiden henkilöi-den nimitys saattoi vaihdella, mutta rooli oli selkeä ja vastuualueena arkki-tehtuuri kokonaisuudessaan. Osa näistä henkilöistä toimi samalla arkkitehtuuri-tiimin vetäjänä.

Heitä kaikkia voi luonnehtia to-dellisiksi yritysarkkitehtuuriammat-tilaisiksi, joilla on tehtävän edellyttä-mää kokemusta, näkemystä ja muita

Liite 1

METODI EDUT RAJOITTEET

AsIs Luo vahvan perustan joka ta-pauksessa tietoteknisen ym-päristön hallinnalle ja arkkiteh-tuurityölle.Suoraviivainen tapa aloittaa arkkitehtuurityö

Ei anna suuntaa tai maalia, jota kohti or-ganisaation pitäisi edetä.Liiketoimintahyödyt saattavat jäädä vä-häisiksi, mikäli takerrutaan liiaksi yksityis-kohtaisen nykytilan kuvaamiseen (toisaal-ta niinkin voi löytyä säästöpotentiaalia)

Ahead Nopeuttaa projekteja, joiden ei tarvitse päättää kaikkea itse.Vahvistaa arkkitehtuurikulttuu-ria, koska edellyttää proaktiivis-ta arkkitehtuurityötä.

Vaatii kurinalaisuutta, että projektit nou-dattavat arkkitehtuuria, varsinkin, jos oh-jeet eivät muodosta ehyttä ja riittävän kattavaa kokonaisuutta.

ToBe Luo maalin, jota kohti kehitys-toiminnan tulisi edetä.Toimii pohjana gap-analyysille, jonka pohjalle voi luoda kehi-tysprojektisalkun.

Voi olla liian kaukana, jotta olisi sopivan konkreettinen maali.Sisältää usein oletuksen, että arkkitehtuu-rin voi luoda puhtaalta pöydältä, vaikka tämä on vain äärimmäinen erikoistapaus.Vaatii organisaatiolta tiettyä arkkitehtuu-rikypsyyttä, jotta visiota ei pidetä haihat-teluna.

Liite

1

22

ominaisuuksia. Keskusteluissa tuli hyvin esille pääarkkitehdin roolin vaativuus: riittävän teknisen ymmärryksen lisäksi pitää olla liiketoimintaymmärrystä, dip-lomaatin taitoja, vahvaa konseptuaalis-ta ajattelukykyä, johtajaominaisuuksia sekä aloitekykyä, järjestelmällisyyttä ja pitkäjänteisyyttä. Ei siis mikään vähä-pätöinen yhdistelmä. Kuitenkin nämä kaikki ominaisuudet löytyvät kaikilta tavatuilta pääarkkitehdeilta ainakin jos-sain muodossa.

Seitsemässä organisaatiossa löytyy sivutoimisia arkkitehteja tai johonkin tiettyyn alueeseen keskittyneitä arkki-tehteja (esim. tekninen arkkitehti).

Kuudessa organisaatiossa löytyi myös yhtenäinen arkkitehtuuritiimi, kymmenessä organisaatiossa arkkiteh-tuuria tehtiin verkostossa tai useam-man kuin yhden arkkitehdin voimin. Arkkitehtuuriresurssien määrä korreloi vahvasti organisaation koon ja tietoin-tensiivisyyden kanssa. On huomattava, että monissa järjestelmäprojekteissa tehdään arkkitehtuurityötä ja on mah-dotonta vetää tarkkaa rajaa systeemi-arkkitehtuurityön ja yritysarkkitehtuu-rityön välille. Tässä tutkimuksessa ark-kitehtiresursseina pidettiin henkilöitä, jotka tekevät arkkitehtuurityötä (lähes) päätyönään.

Prosessi

Arkkitehtuuriprosessi voidaan jakaa karkeasti ottaen kahteen osaan: arkki-tehtuurin luomiseen ja arkkitehtuurin soveltamiseen. Ensin mainittuun voi-daan lukea esimerkiksi erilaisten poli-tiikkojen, periaatteiden ja mallien pro-aktiivinen luominen. Jälkimmäiseen taas niiden soveltaminen kehityspro-jekteissa.

Systemaattinen arkkitehtuurin luontiprosessi löytyy vain noin viidel-tä organisaatiolta. Lisäksi 2-3 on luo-massa arkkitehtuurin ensimmäistä tai seuraavaa versiota projektina. Jonkin-laista erikseen tehtyä arkkitehtuurin kehittämistä löytyy noin kymmeneltä organisaatiolta, loput kehittävät arkki-tehtuuriaan ”linjatyönä” tai se muodos-tuu projekteissa tehtävien päätösten summana.

Vain kuudella organisaatiolla on määrämuotoinen arkkitehtuurin so-veltamisprosessi. Tällä tarkoitetaan sitä, että projektinhallintamenetelmässä on kohdat, joissa suunniteltavan ratkaisun riittävä arkkitehtuurinmukaisuus var-mistetaan. Ääritapauksessa arkkiteh-tuurivastaavilla voi olla veto-oikeus tar-kastuspisteen läpäisyyn ja projektia ei päästetä eteenpäin ennen arkkitehtuu-rin edellyttämiä muutoksia tai eksplisiit-tistä päätöstä muutoksesta.

Käytännössä kaikilla muillakin or-ganisaatioilla on projektinhallintame-netelmässään kohta, joissa tarkastetaan ratkaisun sopivuus arkkitehtuuriin - jos sellainen on - tai muihin periaatteisiin. Tarkastusten systemaattisuudessa on kuitenkin suuria eroja. Useimmissa ta-pauksissa arkkitehtuurityötä tekevät henkilöt tekevät yhteistyötä projektien kanssa ja ohjaavat heitä kohti yhtenäis-tä toimintatapaa.

Positiivinen uutinen on se, että KAIKKI haastatellut organisaatiot il-moittivat, että heillä on käytössä mää-rämuotoinen projektinhallintamenetel-mä. Niiden käytännön soveltamisessa oli toki eroja. Tätä voi pitää jopa yllättä-vänä löydöksenä ja se luo ilman muu-ta tärkeän välineen arkkitehtuurin so-veltamiselle. Täytyy kuitenkin muistaa,

että arkkitehtuurin soveltaminen riip-puu paljon myös siitä, millaista arkki-tehtuurityötä historiassa on tehty: jos ”arkkitehtuuri” on joukko epämääräisiä linjauksia eri puolilla organisaatiota, on selvää, että niiden ohjaava vaikutus on hyvin rajallinen.

Viitekehys

Viitekehyksellä (framework) tarkoi te-taan yksinkertaisemmillaan arkkiteh-tuuri(dokumentaatio)n rakennetta. Yri-tysarkkitehtuuria ei voi kuvata yhdellä tai edes muutamalla dokumentilla, vaan siinä on potentiaalisesti satoja tai jopa tuhansia erilaisia dokumentteja.

Tutkimuksissa yllätti viitekehysten käytön vähyys. Vain kahdeksalla on käytössään selkeä viitekehys antamas-sa ryhtiä arkkitehtuurityölle ja jäsentä-mässä sen tuloksia järjestelmälliseksi kokonaisuudeksi. Edistyksellisimmät organisaatiot käyttävät viitekehystä myös määrittämään arkkitehtuurityön tuotoksia ja niiden tuottamisen vas-tuuta.

Puoli tusinaa muuta soveltaa arkki-tehtuuriproblematiikan jakoa eri koko-naisuuksiin tai domaineihin (tyypillisim-min prosessi-, informaatio-, applikaa-tio- ja tekninen arkkitehtuuri). Tämän kaltainen jako on kuitenkin riittämätön rakenne yhtään laajemman dokumen-taation organisoimiseksi.

Eräs selitys viitekehysten suh-teellisen vähäiselle käytölle saattaa olla niiden jäykkyys ja muodollisuus. Useimmat mallit ovat luoteeltaan hy-vin kokonaisvaltaisia ja perusteellisia ja siten liian raskaita sovellettavaksi edes suurissa organisaatioissa. Ne sisältävät myös turhan usein implisiittisen ajatuk-sen siitä, että arkkitehtuuria päästään

Liite

1

23

kehittämään puhtaalta pöydältä. Tämä on tietysti vain harvinainen erikoisti-lanne – normaalisti arkkitehtuurityötä tehdään vuosikausia jatkunee kaaok-sen selvittämiseksi kovassa kiireessä ja poliittisten näkökulmien paineessa.

Arkkitehtuurin hallinta

Governancella eli hallintamallilla tarkoi-tetaan yritysarkkitehtuurin yhteydessä sitä, miten ja kenen toimesta arkkiteh-tuuri hyväksytään ja virallistetaan. Hy-vään governanceen kuuluu myös mää-ritelmä siitä, miten käsitellään mahdol-liset tarpeet poiketa hyväksytystä arkki-tehtuurista.

Kolmanneksella vastaajista oma arkkitehtuurihallintamallinsa eli omia foorumeita tai prosesseja nimenomaan arkkitehtuurikysymysten käsittelyyn. Kolmetoista organisaatiota ottaa kan-taa arkkitehtuurikysymyksiin normaalin IT Governancen keinoin. Osassa näistä organisaatioista arkkitehtuuri on kui-tenkin hajanainen tai jopa de facto -ti-lassa.

Liiketoiminnan rooli arkkitehtuurityössä

Vain kolme organisaatiota haastatel-luista on saanut liiketoiminnan edusta-

jat osallistumaan systemaattiseen ark-kitehtuurityöhön. Tältä osin tulee kui-tenkin huomata, että raja systemaatti-sen osallistumisen ja muuten tiiviin yh-teistyön välillä on hämärä. Jonkinlaise-na indikaattorina voidaan kuitenkin pi-tää sitä, kuinka hyvin liiketoiminnan ke-hittämisestä vastaavat avainhenkilöt hahmottavat liiketoimintamallien, pro-sessien ja järjestelmien yhteyden ja ke-hittävät näitä kokonaisvaltaisesti. Tä-mä havainto osoittaa kuitenkin selväs-ti, miten yritysarkkitehtuurityön paino-piste on vielä turhan paljon tietohallin-non puolella.

Liite

1

24

Tekesin katsauksia

277/2010 Yritysarkkitehtuurin ja tiedolla johtamisen käytännöt – haastattelututkimus suomalaisissa suuryrityksissä. Tero Kulha, Eeranka Oy. 23 s.

276/2010 BioRefine Yearbook 2010. Tuula Mäkinen, Eija Alakangas and Marjo Kauppi (eds.) 188 p.

275/2010 ROADMAP for Communication Technologies, Services and Business Models 2010, 2015 and Beyond. Pekka Ruuska, Jukka Mäkelä, Marko Jurvansuu, Jyrki Huusko and Petteri Mannersalo. 47 p.

274/2010 Business Dynamics and Scenarios of Change. Petri Ahokangas, Miikka Blomster, Lauri Haapanen, Matti Leppäniemi, Vesa Puhakka, Veikko Seppänen, Juhani Warsta. 66 p.

273/2010 Kehityspolku ohjelmistoalan liiketoimintaan Oulun seudulla.

272/2010 The Future of Service Business Innovation. 75 p.

271/2010 Automaatio liiketoimintaprosessien tukena. Jean-Peter Ylén, Olli Ventä, Teemu Tommila, Jari Lappalainen, Juhani Hirvonen, Tommi Karhela, Matti Paljakka, Hannu Lehtinen, Juhani Heilala, Janne Peltonen, Timo Malm, Janne Valkonen, Paavo Voho. 111 s.

270/2010 Aineeton pääoma ja tuotto-odotukset. Tempo Economics Oy.

269/2010 Löystymätön ruuvi – merkittäviä kotimaisia metsä- ja metallisektoreiden innovaatioita 60 vuoden ajalta. Juha Oksanen, Nina Rilla, Pekka Pesonen ja Eija Ahola. 47 s.

268/2010 Puhtaasti asiakkaalle – suomalaisen kemianteollisuuden menestyksen tekijät globaalissa kilpailussa. Marjo Mäenpää, Jani Saarinen, Peter Sikow ja Pekka Pesonen. 51 s.

267/2010 Silicon Valley Journey – Experiences of Finnish IT Startups from Dot-Com Boom to 2010. Raija Rapo & Marita Seulamo-Vargas. 175 p.

266/2010 Kemian osaamisen kartoitus. 48 s.

265/2009 Palvelujen kansainvälistymisen muodot ja polut – Selvitys liike-elämän asiantuntijapalvelujen kansainvälistymisestä ja sen merkityksestä yritysten kasvulle. Marja Toivonen, Irma Patala, Pekka Lith, Tiina Tuominen ja Anssi Smedlund. 76 s.

264/2009 BioRefine Programme 2007–2012. Yearbook 2009.

263/2009 Itseuudistumisen kapasiteetti ja alueelliset innovaatiopolitiikat. Markku Sotarauta (toim.). 139 s.

262/2009 Drive for Future Software Leverage. The Role, Importance, and Future Challenges of Software Competences in Finland. Mikael von Hertzen, Jyrki Laine, Sami Kangasharju, Juhani Timonen and Maarit Santala. 93 p.

261/2009 REACH-palveluiden markkinaselvitys. Piia Pessala, Tiina Pursula, Ylva Gilbert, Xiaona Tang. 48 s.

260/2009 Yhteiseltä areenalta globaaleille markkinoille – Pohjois-Pohjanmaan, Kainuun ja Lapin innovaatioympäristön toimintamalli. Tommi Ranta ja Anssi Uitto. 42 s.

259/2009 Technology Transfer of Research Results Protected by Intellectual Property: Finland and China. Rainer Oesch. 28 p.

258/2009 Ruoripotkurilaitteiden liiketoiminta Suomessa. 33 s.

257/2009 Globaalit arvoverkostot. HM&V Research Oy. 122 s.

Julkaisujen tilaukset Tekesistä: www.tekes.fi/julkaisut

Tekesin ohjelm

an katsauksen nim

i0

00

|2010

Tekes | Ohjelm

an katsaus

Marraskuu 2010

ISSN 1797-7339

ISBN 978-952-457-513-3

Tekes – teknologian ja innovaatioiden kehittämiskeskus

vaihde 010 191 480asiakasneuvonta info@tekes.fikirjaamo kirjaamo@tekes.fi

Kyllikinportti 2, Länsi-Pasila, PL 6900101 Helsinkiwww.tekes.fi

Lisätiedot

Risto Setälä

Tekes

risto.setala@tekes.fi

Tero Kulha

Eeranka Oy

tero.kulha@eeranka.fi

Yritysarkkitehtuurin ja tiedolla johtamisen käytännöt

– haastattelututkimus suomalaisissa suuryrityksissä

Tero Kulha

Tekes | Tekes Review

Teke

sin

kat

sau

s 2

77/2

010

Tekesin ohjelm

an katsauksen nim

i0

00

|2010

Tekes | Ohjelm

an katsausTekesin oh

jelman katsau

ksen nimi

00

0|20

10Tekes | O

hjelman katsaus

Tekesin ohjelm

an katsauksen nim

i0

00

|2010

Tekes | Ohjelm

an katsaus