Netti on pullollaan erilaisia listauksia kokonaisarkkitehtuurivälineiden ominaisuuksista. Mukana on myös vertailuja ja kukin välinetoimittaja julkaisee Gartnerin nelikentistä ainakin sen, jossa oma tuote on positioitu yläkvartaaliin.
Omien kokemusteni mukaan on muutama asia, joita ei tule ajatelleeksi ja jotka hivenen yllättävät. Ainakin minut on aikoinaan yllätetty. Kokonaisarkkitehtuuri on paljon muutakin kuin välineen kanssa askartelua, mutta jos väline tökkii, aiheutuu siitä uskomattoman paljon vaivaa.
Tämän ei pitäisi tulla arkkitehdille yllätyksenä. Nimittäin sama koskee kaikkia yrityksen toimintoja. Kokonaisarkkitehtuuriväline on se väline, jolla tuotetaan arkkitehtuurikuvat ja niihin suoraan liittyvä tietosisältö. Monissa välineissä on lisäksi erilaisia julkaisutoimintoja, joilla saadaan sisältö luettavaksi nettiselaimen kautta. Paras lukukokemus saadaan, jos sisältö integroidaan jollain tavalla Intranettiin, SharePointtiin tai johonkin portaalinäkymään.
Yrityksellä voi olla muitakin mallinnusvälineitä, yksi prosessien kuvaamiseen ja toinen IT-puolen määrittelyihin ja suunnitteluun. Lisäksi on erinäisiä muita järjestelmiä, joissa on samaa tietoa kuin kokonaisarkkitehtuurissa; tyypillisimmillään tietoa organisaatiorakenteesta ja IT-järjestelmistä. Niinpä onkin päätettävä, mikä on eri järjestelmien välinen työnjako.
Kokonaisarkkitehtuurin yhteenvedot ovat ohuita ilman tiettyjä volyymi- ja kustannustietoja. Tuoterakenne ei ole kiinnostava, jos ei tiedetä tuotteiden volyymeita. Vastaavasti IT-järjestelmien kohdalla kiinnostavaa tietoa ovat mm. kustannukset. Tästä päästäänkin määrittelemään erilaisia tietovirtoja ja päivitysketjuja. Tietohan on luotettavinta silloin, kun master-data ketjut ovat kunnossa, eli tiedetään mihin tieto pitää päivittää ja miten se virtaa muihin järjestelmiin.
Mallinnusvälineiden alkutaipaleella ne olivat pitkälti yhden käyttäjän ympäristöjä ja pyörivät mallintajan omalla koneella. Käyttöoikeuksien hallintaa, kirjautumista jne. niihin on lisätty vasta myöhemmin. Varmaankin siinä vaiheessa, kun joku keksi, että eikös olisi kiva siirtää väline serverille ja mallintaa yhdessä. Nykyisinhän useimmat välineet saa jo pilvestäkin.
Vastaavasti välineiden alkutaipaleella mallintaja itse oli se koodari-nörtti, joka lennosta konfiguroi välineen omiin tarpeisiinsa. Työnjako, jossa system manager konfiguroi välineen, muutoksista mallinnustapaan sovitaan muutoksenhallintaprosessin kautta ja mallintaja ainoastaan tuottaa sisältöä, on varsin uutta ja ennenkuulumatonta.
Niinpä sen koommin välineen ominaisuuksissa kuin sen käyttöohjeissakaan ei useimmiten ole näitä asioita huomioitu riittävästi. Onhan se kaikille aika uutta ja muutaman mallintajan ympäristössä ei edes välttämätöntä.
Tässä kohtaa kannattaa kerrata mitä ensimmäisessä vinkissä kerrottiin. Kyse on siis järjestelmäkokonaisuudesta, joten myös integrointeja tarvitaan.
Väline kuin väline on yleensä riittävän kätevä erilaisten arkkitehtuurikuvien tuottamiseen. Joitain välineitä oppii käyttämään nopeammin ja toisten kanssa pitää panostaa hieman sen opetteluun. Välinevalinnassa välineen ominaisuuksien testaus keskittyy useimmiten piirrosominaisuuksiin. Onhan se silmiinpistävin piirre uudessa välineessä.
Välineistä saa tulostettua (tai julkaistua) erilaisia yhteenvetoja raportteina. Nämä raportit ovat nimenomaan niitä, jotka kiinnostavat suurta yleisöä. Esimerkiksi yhteenveto yrityksen tietojärjestelmien elinkaarista ja kustannuksista. Jos valmisraportit eivät ole soveltuvia tietosisällöltään, joudutaan raportteja räätälöimään. Jos yhteenveto kuin yhteenveto joudutaan räätälöimään, muodostuu työmäärä melkoiseksi. Kysehän ei ole pelkästä raportin toteutuksesta vaan jonkun on suunniteltava myös tietosisältö.
Vastaavasti integrointi muihin järjestelmiin harvoin menee kuin Strömsössä. Ensimmäisenä asiana tulee vastaan se, että vaikka toisessa järjestelmässä näyttäisi olevan samaa tietoa kuin kokonaisarkkitehtuurivälineessä, käsitteet eroavat merkittävästi.On vaikea uskoa ennen kuin näkee, kuinka monella eri tavalla voidaan ymmärtää ”mikä on yksi tietojärjestelmä”.
Määrältään kokonaisarkkitehtuurivälineen lukukäyttäjiä (useimmiten julkaisun kautta) pitäisi olla enemmän kuin sisällön tuottajia. Silloinhan arkkitehtuurin sisältöä myöskin hyödynnetään. Lukukäyttäjien huomioiminen sisältää varsin yksinkertaisia asioita. Löytääkö lukukäyttäjä haluamansa sisällön? Ymmärtääkö lukukäyttäjä sen? Joutuuko lukukäyttäjä kohtaamaan kovin monella eri tavalla kuvattua sisältöä? Pelkkä se, että yksi kuvaa pystyyn ja toinen vaakaan, voi olla ärsyttävää. Puhumattakaan muista visuaalisista tehosteista, joissa vain mielikuvitus on rajana.
Lukukäyttäjiä kannattaa kouluttaa jonkin verran. Sekä käytettyyn notaatioon että sisällön rakenteeseen. Kukin ymmärtää kuitenkin, että kouluttaminen pitää pitää kohtuudessa. Arkkitehtuurin sisältö ei saa olla niin kryptistä, että lukukäyttäjien perehdyttäminen muodostuu liian suureksi ponnistukseksi. Tässä toimii myös luonnonvalinta. Tietyn koulutusmäärän jälkeen kukaan ei enää halua osallistua.
Tässäkin kohdassa voi muistella ensimmäistä vinkkiä. Kyse on järjestelmäkokonaisuudesta, jossa kullakin järjestelmällä on oma luontevin käyttötarkoituksensa. Ei arkkitehtuurivälineessä itsessään tarvitse olla dashboardia, riittää että se löytyy jostain.
Ei myöskään ole realismia, että päätöksentekijä itse selailisi arkkitehtuurin kuvauskantaa ja tekisi tarvittavat analyysit itse. On kätevintä että arkkitehti on valmistellut esityksen johtoryhmälle. Esityksessä voi lisäksi käyttää erilaisia PowerPointin tehokeinoja esim. korostaa jotain asiaa vaikkapa punaisella nuolella. Näitä ominaisuuksia ei siis tarvita arkkitehtuurivälineessä.