Kuulen tämän kysymyksen usein koskien kokonaisarkkitehtuurin nykytilan kuvauksia. Asiassa on puolensa ja puolensa, kuten kaikissa asioissa. Kuvauksia on ylläpidettävä. Jos ne eivät ole ajan tasalla, ei niillä tee mitään. Siinä mielessä on parempi valinta ylläpitää niitä kuin jättää ylläpitämättä, vaikka ylläpitäjä vähän oikaisisi joissain asioissa. Jos kuvauksia on sorkkimassa useampi kokki, on riski, että joku kokeista sotkee niitä. Tällöin tehdyt analyysit menevät rikki eli analyyseissa näkyvät yhteenvedot alkavat näyttää vähintäänkin kummallisilta. Toisaalta, jos kuvauksiin saa koskea vain yksi henkilö, on hän väistämättä pullonkaula ja kuvausten ylläpito tökkii kiireisinä aikoina. Mikä olisi siis sopiva kompromissi?
Kokonaisarkkitehtuuri ei saisi olla ”niin hienoa”, ettei siihen uskalla koskea. Toisaalta sen on oltava ”riittävän hienoa”, jotta se on pitkäikäistä ja yhteenvedot pysyvät laadukkaina. Eli arkkitehtuurisisältö, johon ne perustuvat on oikein.
Mitä riittävä oikeellisuus tarkoittaa? Nykytilan kuvausten osalta on tärkeintä, että ne kuvaavat todellisuutta. Lisäksi kokonaisarkkitehtuurissa on elementtejä, jotka potentiaalisesti puuroutuvat, jos ei pidä varaansa. Prosessit ja palvelut ovat kuuluisa parivaljakko. Prosesseilla kuvataan, miten joku asia tehdään. Jos tekemisen tapa muuttuu, muuttuvat prosessitkin. Palvelu taas on sellainen, jonka organisaatio tarjoaa asiakkailleen. Tietojärjestelmät ja teknologiat on toinen pari. Erityisesti integraatioalusta ja muut tekniset komponentit luetellaan helposti tietojärjestelmälistauksessa. Edellä mainitut esimerkit voivat tuntua lapsellisilta, kukapa tuota eroa ei ymmärtäisi? Käytännössä vastaani ei ole tullut yhtäkään organisaatiota, jossa ero olisi selkeä. Suuri osa sisällöstä toki on oikein, mutta mukana on riittävä määrä rajatapauksia tai selvästi virheellisiä tulkintoja. Tässä tarkoitan riittävää määrää sotkemaan yhteenvedot.
Miten arkkitehtuurin tekijöille ja ylläpitäjille saadaan riittävä ymmärrys kokonaisarkkitehtuurista? Kaikkien ei luonnollisestikaan tarvitse olla sertifioituneita mallinnusfriikkejä. Koulutus tuunataan kohderyhmän tarpeisiin ja siinä huomioidaan osallistujien taustat. Jos kokonaisarkkitehtuurin perussisällöt (palvelut, prosessit, tiedot, tietojärjestelmät, teknologiat) on tehty, valmista sisältöä käytetään koulutuksessa esimerkkinä. Esimerkki, joka on tehty organisaation omalla sisällöllä, on tehokkain tapa kouluttaa ja jalkauttaa arkkitehtuuria. Myös arkkitehtuurin ylläpitäjät koulutetaan. ”Käypä tuolla päivittämässä tietojärjestelmien tiedot” ei ole riittävä perehdytys mihinkään tehtävään.
Mallinnustapa on suunniteltava ”riittävän oikein”. Oikeellisuus tarkoittaa asioita, jotka toimivat käytännössä unohtamatta teoriaa. Parhaissa esimerkeissä teoria ja käytäntö kohtaavat. Esimerkiksi tietojärjestelmien attribuuteiksi (lisätietokenttä, joka liitetään kuhunkin tietojärjestelmään) laitetaan ne asiat, joita ylläpidetään useimmin ja joiden sisältö on kaikille selkeä. Tällaisia tietoja on esimerkiksi ”tietojärjestelmän omistaja”, ”pääkäyttäjä”, ”käyttöönottopäivämäärä”. Liiketoimintakriittisyys taas saadaan selville tietojärjestelmään liittyvien prosessien ja palveluiden kautta, se ei ole tietojärjestelmän tieto. Tietojärjestelmä, joka tukee liiketoimintakriittistä palvelua, on liiketoimintakriittinen. Tarkasteluun voidaan ottaa mukaan myös ne prosessin askeleet, joiden on oltava käytettävissä 24/7 ilman katkoja. Kyllä, tällä analyysilla voi saada kiitettävät pisteet myös excel-taulukoille. Se ei ole arkkitehtuurianalyysin vika.
Kaikki edellä mainittu saattaa olla helposti hyväksyttävää, mutta entäs sitten? Tiivistän tähän loppuun vielä parhaat vinkit, jos ne edellä puuroutuvat muun tekstin sekaan. Eli käytännön selviytymiskeinoja on:
Kiinnostuitko? Jatkokeskustelut Coalan Kokonaisarkkitehtuurin Starttipaketti-kurssilla 12.12.2019, vielä ehtii ilmoittautua!