Enterprise-arkkitehti
Tämän päivän enterprise-arkkitehdin on päihitettävä edeltäjänsä viestinnässä ja liiketoimintayhteistyössä

Enterprise-arkkitehdin on osattava esitellä ja perustella mallinnukset ja niistä tekemänsä analyysit siten, että ne ovat helposti liiketoimintajohdon omaksuttavissa ja aidosti hyödynnettävissä päätöksenteon tukena. Taitava arkkitehti tuo konkreettisia ehdotuksia toiminnan kehittämiseksi, liiketoimintajohdon omalla kielellä.

The Open Groupin blogeista löytyy Terry Blevinsin ajatuksia herättävä kirjoitus “The Future Enterprise Architect“. Siinä Terry kuvailee osuvasti yleistä liiketoimintajohdon ja enterprise-arkkitehtuurin välistä kuilua ja tarjoaa myös paremman version näiden yhteistyöstä. Suomennan tässä “Enterprise Architecture” -termin enterprise-arkkitehtuuriksi, jolla tarkoitetaan yrityksen kokonaisrakennetta aina strategioista liiketoimintaprosessien ja henkilöroolien kautta tietojärjestelmiin ja infraan.

Terry havainnollistaa asiaa kuvaamalla kirjoituksessaan kaksi henkilöä, Lorettan ja Archien. Loretta on liiketoimintajohtaja, joka vastaa alueensa tuloksesta ja kehittämisestä. Hän laatii strategioita, liiketoiminnan kehittämissuunnitelmia, budjetteja ja näiden mukaisesti kehittää omaa liiketoiminta-aluettaan. Tavoitteena hänellä on tyytyväinen asiakas ja hyvä taloudellinen tulos. Lorettan apuna on joukko sisäisiä ja ulkoisia konsultteja ja palveluntarjoajia, mutta hänen on vaikea löytää itselleen vieraan teknisen kommunikaation seasta sellaisia asiantuntijoita, joihin hän uskaltaisi aidosti luottaa.

Archie on samaisen yrityksen enterprise-arkkitehti. Archie tuntee mallintamismenetelmät ja hänen työhönsä kuuluu ylläpitää nyky- ja tavoitetilan mukaisia arkkitehtuurimalleja soveltuvin työkaluin. Archie laatii toiminnallisia ja ei-toiminnallisia vaatimuksia sekä muuntaa liiketoiminnan strategioita teknisiksi suuntaviivoiksi ja periaatteiksi. Mallintamisen avulla Archie näkee yrityksen liiketoiminta- ja IT-ympäristön rakenteet sekä näiden keskinäiset riippuvuussuhteet ja potentiaaliset kehityskohteet.

Terryn kertomuksessa Lorettan ja Archien välillä on kuilu. Loretta hädin tuskin tietää, että yrityksellä on enterprise-arkkitehti, eikä hän siis ole koskaan käyttänyt apunaan Archien osaamista. Lorettan ensimmäinen ajatus yhteistyöstä on, että mihin Archieta tässä oikein tarvitaan: onko hän vain ylimääräinen byrokraattinen kerros ja kehittämisen hidaste? Archie taas tuntee, että hänellä voisi olla paljon annettavaa liiketoimintajohdolle, jos hän vain pääsisi esittämään asiansa ja tekemään aitoa yhteistyötä. Hän kokee osaavansa ja ymmärtävänsä sellaisia asioita, joita muut eivät tunnu arjessa huomaavan ja toivoo, että muutkin hyödyntäisivät hänen työnsä tuloksia päätöksenteossa. Kommunikaatiokuilu estää kuitenkin yhteistyön.

Liiketoimintajohdon ja enterprise-arkkitehdin väliin ei pitäisi tarvita erillistä tulkkia

Lorettan ja Archien kertomukset kuulostavat hyvin tutuilta. Enterprise-arkkitehdin työn hyödyntäminen jää yrityksissä usein puolitiehen. Yrityksen prosessit ja tietojärjestelmät voidaan mallintaa hyvinkin tarkasti nyky- ja tavoitetiloissa, mutta mallintamisesta saatua informaatiota ei käytetä silti liiketoimintajohdon päätöksenteon tukena.

Terry kuvailee kertomuksessaan myös Archien parannetun version, Archie II:n, jota pidetään yrityksessään luotettuna, eri osapuolten tarpeita ymmärtävänä neuvonantajana. Hän tarjoaa päätöksenteon tueksi suosituksia ja perusteluja eri vaihtoehdoille. Oman toimintansa hän osaa mitoittaa niin, että hän kerää juuri sopivan määrän informaatiota, jotta voi menestyksekkäästi tukea yrityksen kehittämistä juuri silloin, kun sitä tarvitaan.

Archie II -mallin mukaista enterprise-arkkitehtuurin ja muun organisaation välistä suhdetta näkee harvoin, vaikka tällainen suhde olisi yrityksen edun mukaista ja siksi tavoittelemisen arvoista. Firmalle voisi olla suurta arvoa toiminnolla, joka systemaattisesti analysoi yrityksen rakenteen ja toiminnan nyky- sekä tavoitetilan, joka näkee eri tekijöiden väliset riippuvuussuhteet ja tuottaa vielä suosituksia ja analyyseja päätöksenteon seurauksista.

Mielenkiintoinen kysymys, johon Terrynkään artikkeli ei anna suoraa vastausta, on se, miten tällainen toiminto saadaan aikaiseksi. Miten Lorettan ja Archien välinen suhde saadaan muutettua Archie II -mallin mukaiseksi yhteistyöksi?

Arkkitehti etsii mallinnuksella syy-seuraussuhteita ja tuo tietoa liiketoimintajohdolle

Toimivan enterprise-arkkitehtuurin hallinnan rakentaminen vaatii eri osapuolten sitoutumista, kuten mikä tahansa muukin yhteistyö. Omasta mielestäni Lorettan tulisi yksinkertaisesti antaa Archielle mahdollisuus. Artikkelin kuvaama Archie on hyödyntämistään odottava ansiokas työkalu ja osaaja. Työnsä perusteella hän näkee asioita ja syy-seuraussuhteita, joita on ilman systemaattista mallintamista hankala nähdä. Lorettan pitäisi uskaltaa hyödyntää tätä palvelua ja pitää Archie ajan tasalla suunnitelmista. Yksinkertaiset kysymykset, kuten “mitä mieltä olet tällaisesta hankkeesta”, saattavat tuoda esiin yllättäviäkin asioita. Archien taas pitäisi selvittää, mitä Loretta oikeasti tarvitsee. Huippuunsa viimeistellyt suunnitelmat tai monimutkaiset mallit eivät ehkä ole tarpeen. Pitää tehdä se, mikä on perusteltavissa ja riittää kyseiseen tilanteeseen.

Archien pitäisi puhua sellaista kieltä, jota Loretta ymmärtää. Hänen pitäisi esittää asiat selvästi ja yksinkertaisesti sekä osallistua aktiivisesti kehityshankkeisiin. Archien osalta on tärkeää muistaa, että enterprise-arkkitehdin työssä kokonaisuuden hallinnan ohella yhtä tärkeää on se, että havainnot saadaan vietyä niille, jotka tietoa tarvitsevat.

Keskitytään oleelliseen

Olen työskennellyt paljon mallinnuksen ja mallinnustyökalujen kanssa. Olen kehittänyt mallinnusmenetelmiä ja tehnyt varsinaista mallinnustyötä. Terryn kertomuksen opetukset vahvistavat paria itsekin huomaamaani enterprise-arkkitehtuurin mallinnukseen liittyvää seikkaa.

Ensinnäkin on harkittava, mikä on riittävä määrä mallintamista ja mikä on aidosti oleellista: mitä mallinnetaan, millä tarkkuustasolla, millaisia malleja tarvitaan sekä miten muutostilanteen mallinnus hoidetaan? Toiseksi, mallinnustyökaluilla tuotetut, esimerkiksi ArchiMate-notaation mukaiset kaaviot eivät välttämättä ole juuri niitä, joita kannattaa esitellä liiketoiminnan päättäjille. Kuten aiemmin on todettu, mallin sisältö ei ole asian ydin, vaan se informaatio, joka mallin perusteella voidaan havaita. Jotta havainnot tulisivat huomioiduiksi liiketoiminnan päätöksissä, on ne syytä esittää kohderyhmälle kuulijan termein.

Markku Ryynänen

Markku on Reflectorin EA- ja ratkaisuarkkitehti, joka on tottunut toimimaan yhteistyössä sekä asiakkaan liiketoiminnan että IT:n edustajien kanssa. Markulla on runsaasti kokemusta erityisesti finanssialalta.

Tarvitsetko arkkitehtuuritukea yritykseesi? Saat meiltä nopeallakin aikataululla osaajia avuksesi. Ota yhteyttä ja kysy lisää: markku.ryynanen@reflector.fi.

LinkedIn

Reflector on ICT-talo, jonka ykköstehtävä on auttaa asiakkaitamme liiketoiminnan isoissa ja pienissä muutoshankkeissa. Ketterästi ja riippumattomasti.

Jaa artikkeli

Voisit pitää myös näistä:

Vaatimusmäärittely

Onko vaatimusmäärittelylle paikkaa SAFe-junassa?

Joskus IT-ammattilaisten kahviautomaattikeskusteluja kuunnellessa syntyy vaikutelma, että ketteryys, Scrum esimerkkinä, kadottaa tarpeen perinteiseen järjestelmäkehitykseen kuuluvalle vaatimusmäärittelylle ja kattavalle toiminnalliselle määrittelylle. Kun keskusteluun tuodaan

Lue lisää
Kokonaisarkkitehtuuri Reflector

Ota yhteyttä, mietitään yhdessä juuri teille parhaat ratkaisut

Täytä tiedot ja siirry lataamaan tutkimus

Kokonaisarkkitehtuuri Reflector

Get in touch!