TOGAF® – nämä asiat sinun tulee tietää kokonaisarkkitehtuurin viitekehyksestä

TOGAF-viitekehyksen avulla rakennat organisaatiolle oman arkkitehtuuriviitekehyksen

TOGAF on kansainvälinen The Open Groupin ylläpitämä kokonaisarkkitehtuurin viitekehys. Itse viitekehystekstiä voi lukea netistä The Open Groupin sivuilta veloituksetta, mutta siitä on myös saatavilla sertifikaattikursseja henkilöille.

Organisaatio, jossa halutaan ottaa käyttöön TOGAF-viitekehys, voi omavalintaisesti joko sertifioida arkkitehtuuritiimin jäseniä tai tutustua omatoimisesti viitekehykseen ja lähteä soveltamaan TOGAF:ia parhaaksi katsomallaan tavalla. 

TOGAF tarjoaa parhaita parhaita käytänteitä organisaation arkkitehtuuritoiminnolle, mutta viitekehystä ei ole tarkoitus hyödyntää sellaisenaan

Yksi keskeinen ajatus TOGAF:ssa on Tailored Architecture Framework, eli organisaation itse tuottama soveltava arkkitehtuurin viitekehys. 

TOGAF:ia siis ei ole tarkoitus hyödyntää sellaisenaan, eikä viitekehyksen pointti sinällään ole tehdä organisaatiosta TOGAF:in mukaista, vaan ainoastaan tarjota parhaita käytäntöjä siitä, millainen organisaation arkkitehtuuritoiminto voisi olla.

TOGAF on siis tarkoituksella suunniteltu melko ylätasoiseksi ja joustavaksi, jotta sitä voidaan muokata helposti organisaation omiin tapoihin.

Arkkitehtuurin viitekehyksen muokkaus ja hyödyntäminen on yksi osa TOGAF:ia. Tämän lisäksi muita osia voi ryhmitellä useilla eri tavoilla. Tässä yksi ryhmittely:

1️⃣ Miten arkkitehtuuritoiminto perustetaan, eli ”Architecture Capability and Governance”
2️⃣ Mitä arkkitehtuuritoiminto tekee, eli ”Architecture Development Method”
3️⃣ Millaisia kuvauksia arkkitehtuurityössä tuotetaan, eli ”Architecture Content Framework”
4️⃣ Miten erilaisia kuvauksia organisoidaan, eli ”Enterprise Continuum”
5️⃣ Millaisia metodeja tai valmissisältöjä työnteossa voi käyttää, eli ”Guidelines and Techniques” 

Tutustutaan seuraavaksi yllä oleviin aihealueisiin tarkemmin, ja katsotaan millaisia asioita kunkin aihealueen alta löydät TOGAF-viitekehyksestä.

Lue tämä ennen kuin tutustut itsenäisesti TOGAF-viitekehykseen

TOGAF-viitekehyksen rakenteesta on  hyvä tietää jonkin verran kokonaisuutena, jos sitä haluaa itsenäisesti lukea. Kokonaisarkkitehtuurin viitekehys on parhaimmillaan, kun hyödynnät sen tarjoamaa teoriaa käytäntöön soveltaen.  

Jos siis tämän lyhyen esittely pohjalta kiinnostuit lukemaan enemmän jostakin alla mainitusta osa-alueesta, löydät todennäköisesti helposti TOGAF-viitekehystekstistä vastaavan kohdan, jossa aiheesta kerrotaan tarkemmin. 

1️⃣ Architecture Capability and Governance

Architecture Capability and Governance kertoo siitä, miten arkkitehtuuritoiminto perustetaan ja miten sitä organisoidaan. Se ottaa kantaa esimerkiksi arkkitehtuuritoiminnon sisäisiin rooleihin, tai arkkitehtuuritoiminnon suhteeseen muihin kehitysviitekehyksiin.

TOGAF on viitekehys pääasiassa tavoitetilojen suunnitteluun, mutta esimerkiksi COBIT ottaa enemmän kantaa asioiden valvontaan ja hallintaan.

Osiossa esitellään myös esimerkiksi Architecture Board -organisaatiorakennetta ja arkkitehtuurinmukaisuuden arviointia (Compliance review).

2️⃣ Architecture Development Method 

Architecture Development Method käytetään usein lyhennettä ADM – kertoo siitä, miten arkkitehtuurityötä tehdään.

Se esittelee ehkäpä TOGAF-viitekehyksen tunnetuimman kuvan, eli arkkitehtuurin kehitysmentelmän. Ympyrän, jossa on Preliminary-vaihe, jota seuraa A-H -vaiheet ja Requirements Management. Näiden vaiheiden kautta organisaatio voi suorittaa arkkitehtuurin kehittämistä, eli tavoitteenasetantaa, nykytilan ja tavoitetilan kuvauksia ja toimeenpanon suunnittelua järkevästi suunnitellun vaiheistuksen avulla. Standardissa kuvataan jokaisen vaiheen inputeja, työvaiheita ja lopputulosta.

ADM-ympyrä on tarkoitettu karkeaksi yleismalliksi, jolla useita TOGAF:n liittyviä kehitystarpeita voidaan toteuttaa. Jotain tiettyä hyvin rajattua kehitysprojektia voidaan tehdä ADM:n avulla, mutta myös esimerkiksi arkkitehtuuritoiminto yleisesti voidaan organisoida sen ympärille. Ympyrää ei ole tehty täydellisesti seurattavaksi, vaan sitä voidaan jälleen kerran muokata organisaation omaan käyttöön.

Myös kotimainen julkisen sektorin JHS 179 -suositus sisältää muokatun version tästä ympyrästä, joka tosin TOGAF:sta poiketen korostaa hieman vähemmän nykytilan ja tavoitetilan laatimista seuraavia vaiheita, eli esimerkiksi muutoshallintaa.

3️⃣ Architecture Content Framework

Architecture Content Framework ottaa kantaa siihen, millaisia Artefakteja arkkitehtuurityön pitäisi tuottaa. Artefaktit ovat siis erilaisia arkkitehtuurin tekemiä tuotoksia, jotka ovat yleensä osa jotain Deliverablea, eli jotain toteutettavaa lopputuotetta. Artefaktit ovat muodoltaan yleensä luetteloita, tekstejä, kaavioita tai matriiseja.

Eli esimerkiksi ARC-ohjelmistossa oleva tietojärjestelmäsalkku tai prosessikartta olisivat kummatkin Artefakteja, ja sitten vaikkapa tietyt tiedonhallintalaissa määritellyt Artefaktit voisivat tuottaa Deliverablen “Tiedonhallintamalli”. Content Framework käytännössä ottaa kantaa siihen, millaisia Artefakteja ja millaisia Deliverableja ADM-ympyrän eri vaiheissa saatettaisiin haluta tuottaa.

JHS 179 -viitekehyksen listaus periaatteellisia, käsitteellisiä, loogisia, fyysisiä ja toimeenpanoon liittyvistä kuvauksista on hieman vastaava. Myös Arterilla on oma vastaavanlainen kuva, Arter Framework, jossa on listattu ja ryhmitelty Arterin ARC-ohjelmistoon laadittavaksi suositeltavat Artefaktit.

4️⃣ Enterprise Continuum

Enterprise Continuum on luokittelu, joka auttaa ymmärtämään eri tasoisten arkkitehtuurikuvausten suhdetta toisiinsa. Sisällöllisesti se on osa Content Frameworkia, mutta olen itse yleensä nostanut sen omaksi aihealuekokonaisuudekseen.

Continuumin perusidea on se, että on olemassa arkkitehtuurikuvauksia ja ratkaisukuvauksia. Arkkitehtuurikuvauksilla tarkoitetaan korkean tason toimittajariippumattomia peruskuvauksia siitä, miten organisaatio toimii, eli esimerkiksi ”vastaanotossa meillä on käytössä varaustietojärjestelmä”. Varaustietojärjestelmä ei ota kantaa toimittajaan, vaan järjestelmän toiminnallisuuteen. Näistä arkkitehtuurikuvauksista sitten erotellaan ratkaisukuvaukset, jotka kertovat tarkemmin (yleensä perustuen esimerkiksi jonkin hankkeen/projektin tarpeisiin), että miten asiat todellisuudessa tai teknisesti toimivat.

Tämä on Continuumin ns. pystyakseli. Sitten on vielä vaaka-akseli, jossa tarkastellaan sitä, että onko arkkitehtuurikuvaus tai ratkaisukuvaus osa organisaation omaa arkkitehtuuria vai osa esimerkiksi alakohtaista viitearkkitehtuuria. Tästä esimerkkinä vaikkapa juuri laadittu hyvinvointialueiden viiterakkitehtuuri. Se linjaa yleisellä tasolla, miltä hyvinvointialueen pitäisi näyttää, mutta ei ole kuitenkaan kuvaus minkään yksittäisen hyvinvointialueen toiminnasta tarkalla tasolla.

Sitä pitää siis tarpeen vaatiessa tarkentaa organisaation omaksi kuvaukseksi, ja organisaation oma kuvaus ei saisi olla ristiriidassa ylemmän tason viitekuvan kanssa.

5️⃣ Guidelines and Techniques

Guidelines and Techniques sisältää vaihtelevan joukon erilaisia tekniikoita ja valmissisältöjä, joilla arkkitehtuurityötä voidaan tehdä.

Kaksi keskeistä nostoa ovat esimerkiksi GAP-analyysin malli, jolla voidaan arvioida nykytilan ja tavoitetilan eroavaisuuksia ja esimerkiksi arkkitehtuuriperiaatteet, jossa on hyödyllinen valmislistaus arkkitehtuurityöhön liittyviä periaatteita.

Periaatteita on ryhmitelty eri tavalla, ja joitakin osa-alueita ovat esimerkiksi toiminnan tarpeiden huomioiminen, tietoturva tai ketterä kehittäminen. 

Säästä aikaa – näillä vinkeillä selvität tuottaako TOGAF-viitekehys hyötyä organisaatiollenne

Lukuvinkkimme TOGAF-viitekehyksen osalta:

• tutustu ensimmäiseksi ADM-syklin perusteisiin,
• ja tämän jälkeen esimerkiksi Artefaktien ja Deliverablejen listaan
• sekä TOGAF-viitekehyksen valmiisiin arkkitehtuuriperiaatteisiin.

Tällä järjestyksellä säästyt isolta luku-urakalta ja ymmärrät millaista konkreettista hyötyä TOGAF-viitekehys tarjoaisi teidän organisaatioonne arkkitehuurityöhön. 

Kiinnostaako kokonaisarkkitehtuuri? Suosittelen sinulle näitä sisältöjä:

👉 Kokonaisarkkitehtuurin pikaopas | ladattava materiaali
👉 Kokonaisarkkitehtuurin hyödyt organisaatiolle – Kaikki kokonaisarkkitehtuurista | blogi
👉 Loppu huonoille päätöksille kokonaisarkkitehtuurin avulla – näin aloitat | blogi