Alati kiihtyvän teknologisen kehityksen rinnalla tarve kokonaisuuksien hallinnalle on korostunut entisestään. Toiminnallisten ja teknisten asioiden ja näiden välisten riippuvuuksien hallintaan yritysarkkitehtuurin (Enterprise Architecture, EA) työkalut ovat oikein hyödynnettyinä hyvä apuväline. 

EA-työkalujen kirjo on laaja. Yhdessä päässä on ilmainen avoimen lähdekoodin piirto-ohjelma, jonka yksittäinen arkkitehti ottaa käyttöön samana iltapäivänä. Toisessa päässä on koko organisaation kattava pilvialusta, jonka käyttöönotto kestää kuukausia ja jonka vuosihinta nousee kymmeniin tuhansiin. 

Kun tällaista valikoimaa katsoo, mieleen nousee helposti kysymys siitä, mikä työkaluista on paras. Se on harhaanjohtava kysymys, sillä yhtä parasta EA-työkalua ei ole. Oikea valinta riippuu siitä, missä organisaatio on, mihin se työkalua tarvitsee ja minne se on menossa. 

Kokemukseni mukaan organisaatiot valitsevat työkalun usein, joskaan ei aina, sen ominaisuuksien perusteella. Järjestys menee silloin väärin päin. Ensin pitäisi miettiä, mihin työkalua on tarkoitus käyttää, ja hankkia se vasta sen jälkeen. 

Kun valinta lähtee käyttötarkoituksesta, työkalua on luontevaa katsoa osana organisaation omaa matkaa. Olennaista on, mitä siltä tarvitaan nyt ja miten tarve muuttuu, kun arkkitehtuurityö kypsyy. 

Miten lähteä liikkeelle EA-työkalun valinnassa? 

Useimmissa organisaatioissa arkkitehtuurityö alkaa pienesti. Vastuu on yhdellä tai muutamalla ihmisellä, ja tärkeintä on saada perusasiat näkyviin: mitä järjestelmiä on, miten ne kytkeytyvät toisiinsa ja mitä liiketoimintaa ne tukevat. 

Tässä vaiheessa työkalulta halutaan selkeää mallinnusta ja matalaa aloituskynnystä. Useimmat työkalut tukevat ArchiMatea, joka on kokonaisarkkitehtuurin kuvaamiseen kehitetty standardoitu mallinnuskieli. Moni tukee myös prosessien kuvaamisen BPMN:ää tai järjestelmäsuunnittelun UML:ää sekä menetelmäkehyksiä kuten laajalti käytettyä TOGAFia. 

Avoimen lähdekoodin Archi on tästä hyvä esimerkki. Se on ilmainen työpöytäsovellus, tukee ArchiMatea ja tallentaa mallin paikalliseen tiedostoon. Tällainen kevyt työkalu sopii yhdelle arkkitehdille, pienelle tiimille, konsultille tai oppilaitokselle, mutta suuren organisaation yhteiskäyttöön sitä ei ole rakennettu. 

Olen havainnut, että kevyt työkalu riittää alkuvaiheessa yllättävän pitkälle. Aloittelevan toiminnan todelliseen tarpeeseen se vastaa hyvin, eikä siitä makseta kyvykkyyksistä, joita ei vielä käytetä. 

Kevyellä työkalulla on silti rajansa, ja ne tulevat vastaan jo perusasiassa. Pelkkä piirtäminen kertoo, miltä asiat näyttävät, mutta ei paljon enempää. Malli muuttuu aidosti arvokkaaksi vasta, kun siihen liitetään tietoa, jonka varassa voidaan tehdä päätelmiä. Tämä havainto kantaa läpi koko matkan. 

Kun arkkitehtuurityön kypsyystaso organisaatiossa kasvaa ja työhön tulee mukaan useampia ihmisiä ja mallintamisesta tulee jatkuvaa, paikallinen tiedosto käy ahtaaksi. Tarvitaan yhteistä tietovarastoa eli repositoryä, johon mallit kootaan keskitetysti, sekä versiohallintaa ja mahdollisuutta jakaa näkymiä muillekin kuin mallintajille. 

Tähän vaiheeseen asettuvat tiimitason työkalut. Esimerkiksi Sparx Enterprise Architect tarjoaa jaetun mallin, jonka voi tallentaa myös tietokantapohjaisesti, ja se tunnetaan laajasta notaatiotuestaan UML:stä BPMN:ään ja SysML:ään. Kotimaisista vaihtoehdoista Arter ARC ja QPR EnterpriseArchitect tuovat mukaan suomalaiselle julkishallinnolle suunnattuja mallipohjia, jotka pohjautuvat julkisen hallinnon suosituksiin ja tiedonhallintalain velvoitteisiin. 

EA-työkalu johtamisen välineenä  

Kun toiminta kehittyy edelleen, kasvavat myös odotukset työkalulle. Kyvykkyydet ja kypsyys eivät ole erillisiä asioita, vaan ne kulkevat yhdessä. Kypsässä organisaatiossa arkkitehtuuri on osa johtamista, ja silloin malli halutaan rikastaa tiedolla, jota voidaan oikeasti hyödyntää. 

Käytännössä malliin liitetään esimerkiksi sovellusten kustannukset, riskit, omistajat ja elinkaaritieto. Tällaisen tiedon varassa kokonaisuudesta voidaan tehdä vaikutus- ja riippuvuusanalyysejä. Ardoq nojaa graafitietokantaan, joka tukee juuri riippuvuuksien analysointia, ja useat alustat tarjoavat sovellusportfolion hallintaa eli järjestelmällistä tapaa seurata, mihin sovelluksia käytetään ja mitkä niistä kannattaa säilyttää, korvata tai poistaa. 

Minun mielestäni yksi painavimmista valintatekijöistä on julkaisutarve. Se, keiden pitää pystyä katsomaan mallia, vaikuttaa työkaluvalintaan paljon. Mitä laajemmalle joukolle tieto pitää jakaa, sitä vahvempi peruste on julkaisualustalle ja sen koontinäkymille eli dashboardeille, jotka kokoavat olennaisen sidosryhmille ilman mallinnustyökalun opettelua. 

Juuri julkaisukerros erottaa monet organisaatiotason alustat kevyemmistä välineistä. Bizzdesign Enterprise Studio julkaisualustanaan Horizzon sekä SAP LeanIXin mukautettavat dashboardit ovat tästä esimerkkejä, kun taas kevyemmät työkalut tyytyvät usein dokumentti- tai HTML-vientiin. 

Samaan kypsään vaiheeseen kuuluvat automaatiot. Mallin muokkausta ja rikastusta sekä näkymien muodostusta voidaan automatisoida, kevyimmillään skriptaamalla, kuten Archin jArchi-skriptauksella. Laajamittainen automaattinen datan tuonti ja näkymien generointi on kuitenkin tyypillisesti järeämpien alustojen, kuten Bizzdesignin, piirre. 

Mittakaava ja kustannus kulkevat näiden kyvykkyyksien mukana. Ilmainen Archi toimii yhden henkilön välineenä, edullisempi Sparx tarjoaa kunnollisen mallinnuksen ja yhteistyön kohtuuhintaan, ja sen lisenssit ovat poikkeuksellisesti julkisesti hinnoiteltuja muutamiin satoihin dollareihin. Myös Arter ARC on julkisesti hinnoiteltu, kuukausihinta alkaa muutamista sadoista euroista, ja palvelu on hostattu Suomessa. 

Organisaatiotason alustat kuten SAP LeanIX, MEGA HOPEX, Avolution ABACUS ja Orbus kokoavat datan rikastuksen, analytiikan, dashboardit, automaatiot ja integraatiot saman katon alle. Niiden hinnoittelu on useimmiten tarjouspohjaista, ja SAP LeanIX hinnoittelee poikkeuksellisesti hallittavien sovellusten määrän eikä käyttäjien mukaan. Kokonaiskustannus ei rajoitu lisenssiin, sillä käyttöönotto, integraatiot ja koulutus muodostavat oman osuutensa. 

Käytännön johtopäätös on selvä. Kallis ja järeä alusta tuottaa arvoa vasta, kun organisaatiolla on kypsyyttä ja ylläpidettävää dataa, joten sen hankinta kannattaa ajoittaa siihen vaiheeseen eikä varmuuden vuoksi etukäteen. 

Data ja integraatiot osana EA-mallia 

Mitä pidemmälle matkalla edetään, sitä keskeisemmäksi nousee data. Malli on lopulta juuri niin arvokas kuin sen sisältämä tieto, ja luotettavat analyysit edellyttävät yhteyksiä järjestelmiin, joissa ajantasainen tieto jo on. 

Tärkein näistä on usein yhteys konfiguraationhallintatietokantaan eli CMDB:hen (configuration management database), jollainen on esimerkiksi ServiceNow. CMDB kuvaa todellista, ajantasaista IT-ympäristöä konfiguraatioyksikkötasolla: mitä palvelimia, sovelluksia ja palveluita on käytössä juuri nyt ja miten ne liittyvät toisiinsa. EA-malli taas kuvaa rakenteita, riippuvuuksia ja muutossuunnittelua abstraktimmalla tasolla ja ulottuu myös liiketoimintaan ja strategiaan. 

Minun mielestäni EA-mallia ja CMDB:tä ei pidä sekoittaa keskenään, mutta parhaimmillaan ne täydentävät toisiaan. Koska CMDB sisältää ajantasaisen kuvan teknisestä ympäristöstä, se voi toimia yhtenä datalähteenä EA-mallin rikastukselle. Kun konfiguraatioyksiköt kytketään arkkitehtuurimalliin, analyysit nojaavat todellisuuteen eivätkä vanhentuneeseen tilannekuvaan. 

Valmis kahdensuuntainen ServiceNow-integraatio löytyy useilta organisaatiotason alustoilta, kuten Avolution ABACUSilta, Bizzdesignilta, MEGA HOPEXilta ja SAP LeanIXiltä. Kevyemmissä työkaluissa vastaava yhteys puuttuu tai nojaa manuaaliseen tuontiin, joten integraatioiden tarve kasvaa samaa tahtia datan hyödyntämisen kanssa. 

Raja EA:n ja CMDB:n välillä on myös hämärtymässä. Osa CMDB-alustoista on tuonut mukaan EA-hallinnan ominaisuuksia, ja esimerkiksi ServiceNow tarjoaa yhteisen tietomallin (Common Service Data Model, CSDM) ja sen päälle sovellusportfolion hallinnan, business capability -hallinnan sekä arkkitehtuurin mallinnusta ja visualisointia. Vaikka tuotteet lähentyvät toisiaan, EA-mallin ja CMDB:n perustarkoitus pysyy erilaisena, mikä tekee oman tarpeen tunnistamisesta tärkeämpää kuin tuoteryhmien rajoista. 

Tekoäly EA-työkaluissa 

Tekoäly on tulossa osaksi EA-työkaluja, ja se näkyy jo monen toimittajan tuotteissa. Käytännön sovelluksia ovat mallinnuksen avustus, luonnollisen kielen kyselyt malliin, generatiivinen dokumentointi ja datan automaattinen rikastus. 

Osa toiminnallisuudesta on jo saatavilla. SAP LeanIXin Joule-avustaja on yleisesti käytössä, Bizzdesign tarjoaa muun muassa BPMN-avustajan ja generatiivista dokumentointia, Sparxiin voi kytkeä konfiguroitavan kielimallin, ja Avolution ABACUSin Ask ABACUS hyödyntää koneoppimista ennakoivassa analytiikassa. 

Näkemykseni mukaan tekoäly EA-työkaluissa on lupaavaa mutta keskeneräistä. Tilanne muistuttaa geneerisen tekoälyn hyödyntämistä organisaatioissa muutenkin: potentiaalia on, mutta moni ominaisuus on vielä kypsymässä. 

Keskeneräisyys on syy erottaa jo tuotteistettu toiminnallisuus tiekartan lupauksista ja tarkistaa, mihin lisenssitasoon kukin ominaisuus kuuluu. Suunta on silti selvä, sillä tekoäly madaltaa mallinnuksen kynnystä ja voi ajan myötä vaikuttaa siihen, missä vaiheessa eri kyvykkyyksiä kannattaa hankkia. 

Yhteenveto 

EA-työkalun valinta on sovittamista organisaation tilanteeseen, ei paremmuuskilpailun ratkaisemista. Kun arkkitehtuurityö kypsyy aloittelevasta kehittyväksi ja edelleen kypsäksi, myös tarpeet kasvavat mallinnuksesta datan rikastukseen, julkaisuun ja automaatioihin. 

Kolme asiaa kannattaa pitää mielessä. Parasta yleispätevää työkalua ei ole. Liikkeelle pääsee kevyellä välineellä, ja järeämpään siirrytään, kun kypsyys ja todellinen tarve sitä vaativat. Ja ratkaisevaa on tunnistaa oma käyttötarkoitus, ei vertailla ominaisuuslistoja. 

Seuraava taulukko kokoaa kypsyyden, kyvykkyyksien ja kustannuksen yhteyden pelkistetysti.