ArchiMate elementit jaotellaan kerroksiin ja näitä leikkaaviin aspekteihin.

Kerrokset (horisontaalit) ovat: liiketoiminta, sovellukset ja teknolgiat, sekä siihen sisältyvä fyysisten elementtien kerros. Kerrokset voidaan erottaa toisistaan väreillä seuraavasti: keltainen (liiketoimintakerros), turkoosin sininen (sovelluskerros) ja vihreä (teknologiakerros).

Aspektit (vertikaalit) ovat: passivinen rakenne, toiminta eli käyttäytyminen (behavior), sekä aktiivinen rakenne.

Kuvassa alla ArchiMate spesifikaation esittelemä framework.

Kuva: ArchiMate Core Framework.

Kolme kerrosta, kolme aspektia (3×3). Oleellista ArchiMatessa on, että sen avulla voidaan erottaa toisistaan toiminta ja rakenne, mikä auttaa organisaation kuvaamisessa.

Peruselementit – ydinelementtien osajoukko

ArchiMatessa on elementtejä yhteensä melko paljon, kuutisenkymmentä kappaletta… mutta tämä osajoukko elementeistä (15 kpl) riittää useimpiin tarpeisiin (kuva alla). Tässä yhteydessä tätä ArchiMate-elementtien osajoukkoa kutsutaan peruselementeiksi. Kyseessä on ArchiMate-ydinelementtien osajoukko. ArchiMate ydinelementit ovat ArchiMate Core Frameworkin kerrosten ja aspektien muodostama elementtijoukko, joka on esitelty kokonaisuudessaan ArchiMate-spesifikaatiossa.

Kuva: ArchiMate peruselementit.

ArchiMatessa on paljon yhteystyyppejä, joilla kuvataan elementtien välisiä suhteita. Mutta sama mikä pätee elementteihin, pätee myös yhteystyyppeihin: vain pienehkö osajoukko riittää useimpiin käyttötarpeisiin.

Toimintaa eli käyttäytymistä kuvataan kaikissa kerroksissa paitsi prosessielementeillä, myös toiminto (Function) -elementeillä.
Prosessi ja toiminto -elementtejä käytetään kuvaamaan eri tyyppistä toimintaa.

Kerrokset kytkeytyvät yhteen palveluiden ja rajapintojen kautta.

ArchiMate peruselementit video: linkki

ArchiMate perusrakenne

ArchiMaten peruselementtien ydinjoukko on esitetty kuvassa alla. Tämä ArchiMate elementtien ydin koostuu aktiivisesta rakenteesta, toiminnasta ja passiivisesta rakenteesta. Tämän perusrakenne on ArchiMate-notaation ydin, joka toistuu samanlaisena kaikissa kerroksissa. Nämä samat perusrakenteen elementit erotetaan eri kerrosten vastaavista elementeistä symboleilla ja väreillä.

Kuva: ArchiMate perusrakenne.

ArchiMate -notaation rakenne koostuu puhutun kielen kaltaisista osista:

  • Aktiivinen rakenne on subjekti, aktiivinen toimija, aktori.
  • Toiminta on predikaatti, joka kuvaa tekemistä, toiminnallisuutta eli käyttäytymistä (behavior).
  • Passiivinen rakenne, objekti, toiminnan kohde, on organisaatiossa tyypillisesti tietoa eli infromaatiota eri muodoissa.

Toiminta edellyttää aina suorittava toimijan, aktorin. Nämä toimijat, eli aktiiviset rakenneosat, ovat esim. Tietojärjestelmiä tai organisatorisia toimijoita kuten organisaatio itse tai jokin sen osa, kuten yksikkö, ryhmä, tiimi. Itse toimintaa kuvataan prosessi- tai toiminto -elementeillä, ja toiminta kohdistuu informaatioon.

ArchiMate ytimessä on lisäksi kaksi ulottuvuutta: 1) sisäinen ja 2) ulkoinen.

Kuva: ArchiMate ytimen ulottuvuudet: sisäinen ja ulkoinen.

Toiminta tarjotaan ulospäin muille toimijoille palvelun tai rajapinnan kautta. Palvelu ja rajapinta ovat saman kolikon kaksi eri puolta: toinen kuvaa toimintaa, toinen rakennetta. Rajapinta on konkreettinen, rakenteellinen ilmentymä palvelusta. Palvelu määrittelee toiminnallisuuden, rajapinta on esimerkiksi käyttöliittymä tai kanava.

ArchiMate ydin toistuu samanlaisena kaikissa kerroksissa. Kun oivaltaa tämän peruskaavan, on ArchiMate mallinnus lopulta erittäin helppoa ja loogista.

Perusrakenne eri kerroksissa

Liiketoimintakerroksen perusrakenne

Kuva: Liiketoimintakerroksen perusrakenne.

Sovelluskerroksen perusrakenne

Kuva: Sovelluskerroksen perusrakenne.

Sovelluskerroksen toiminta (Behavior) = sovelluksen toiminnallisuus; “mitä tietojen käsittelyn toimenpiteitä sovellus tekee”.

  • Ulkoinen: Sovelluspalvelu (Application Services) ja/tai sovellusrajapinta (Application Interface) = toiminnallisuus, jonka sovellus tarjoaa ulospäin; mitä sovelluksella voidaan tehdä, mihin sitä käytetään.
    • Huom! Kaikki toiminnallisuudet eivät näy ulospäin. Mutta ne jotka näkyvät, ovat pääasiallinen syy miksi sovellus on olemassa.
  • Sisäinen: Sovellusprosessi (Application Process) ja/tai sovellustoiminto (Application Function) = toiminnallisuus, jonka sovellus toteuttaa sisäisesti; mitä sovellus tekee, mitä tietoja se käsittelee.
    • Huom! Sovellus toteuttaa toiminnallisuuksia, joista osa tarjotaan ulospäin, ja osa on täysin sisäisiä eivätkä näy ulospäin: sovellus hakee tietoja, käsittelee tietoja (yhdistelee, päivittää, lisää, muuttaa, poistaa – CRUD – Create, Read, Update, Delete jne.).

Teknologiakerroksen perusrakenne

Kuva: Teknologiakerroksen perusrakenne.

Peruselementtien käyttö – perusnäkymät

Näkymä = View, eli kaavio (Diagram), joka on laadittu määrätystä näkökulmasta (Viewpoint).

Liiketoimintakerroksen näkymiä

Elementit: toimija (Business Actor), liiketoiminnan palvelu (Business Service), liiketoimintaprosessi (Business Process) ja toiminto (Business Function), käsite (Business Object).

Kaikessa kehittämisessä on ensin syytä ymmärtää mikä on se toiminta, johon jokin muutos on suunnitteilla. Ensimmäinen tarkastelu voidaan tehdä tunnistamalla kaikki ne toimijat (Business Actor), jotka kyseiseen kokonaisuuteen liittyvät. Tämä voidaan kuvata toimijoiden vuorovaikutus -näkymän avulla.

Toimijoiden vuorovaikutus (Actor Cooperation)

Kuva: Toimijoiden vuorovaikutus.

Toimijoiden vuorovaikutus on hyödyllinen kuvaus, jos kehittämiskohde on vähänkin laajempi, ja jos siihen liittyy useita toimijoita. Silloin toimijoiden vuorovaikutus on epäilemättä se ensimmäinen kaavio, joka on syytä laatia.

Toimijoiden vuorovaikutuskaavion avulla voidaan tunnistaa tiedonvaihto eri osapuolten välillä. Kaavion avulla voidaan kuvata tietovirrat toimijoiden välillä: mitä tietoa siirtyy, ja mihin suuntaan.

Jos taas kehittämiskohde ei ole laaja-alainen, useita toimijoita käsittävä kokonaisuus, tämä kaavio ei ole tarpeellinen. Kannattaa kuvata vain asioita, joista on lisäarvoa kehittämiskohteen edistämisen kannalta.

Prosessi (Business Process)

Kehittämisen kannalta on ensiarvoisen tärkeätä tuntea se toiminta, johon kehittämiskohde liittyy. ArchiMate soveltuu ylätason toiminnan kuvaamiseen erityisen hyvin. ArchiMaten liiketoimintakerroksen elementtien avulla voidaan kuvata kehittämiskohteen toimintaa. Tässä keskeistä on itse toiminta, jota mallinnetaan joko a) liiketoimintaprosessi (Business Process) tai b) toiminto (Business Function) -elementeillä. Näihin kytketään toimijat, jotka suorittavat kyseistä toimintaa. Ja mikäli toiminta tarjotaan ulospäin, prosessielementti kytketään liiketoiminnan palveluun (Business Service), joka edelleen kytketään sitä käyttävään toimijaan (tyypillisesti asiakasroolissa olevaan toimijaan).

Kuva: Ylätason prosessi.

Prosessien vuorovaikutus (Process Cooperation)

Organisaation toimintaa voidaan kuvata yhdistämällä toiminto- ja prosessielementtejä. Alla olevassa mallissa on kuvattu prosessien vuorovaikutus yli toimintorajojen.

Kuva: Prosessien vuorovaikutus yli toimintojen (Business Functions).

Sovelluskerroksen näkymiä

Elementit: sovellus/järjestelmä (Application Component), sovelluspalvelu (Application Service), sovellusrajapinta (Application Interface), sovellusprosessi (Application Process), sovellustoiminto (Application Function), tietoelementti (Data Object).

Sovellusten vuorovaikutus (Application Cooperation)

Kun kehittämiskohteeseen liittyy useita tietojärjestelmiä, on tätä kokonaisuuttaa hyödyllistä kuvata sovellusten vuorovaiktusnäkymän avulla. Siinä kuvataan tietovirtoja sovellusten välillä: mitä tietoa siirtyy, ja mihin suuntaan. Samalla tunnistetaan ns. integraatiopisteet, joita voidaan kuvata myöhemmin tarkemmin. Tarkempi ratkaisuarkkitehtuurisuunnittelu voi tämentää esimerkiksi konkreettiset rajapinnat, joita integraatioiden toteutuksessa käytetään, sekä integraatiomekanismit kuten esimerkiksi ftp-siirto, pyyntö-vastaus -rajapintakutsu jne.

Kuva: Sovellusten vuorovaikutus. (Toimijoita voidaan käyttää osoittamaan organisaatiorajoja.)

Organisaation kokonaisarkkitehtuurin (Enterprise Architecture) ja liiketoiminta-arkkitehtuurin (Business Architecture) kannalta on merkityksellistä tietää miksi jokin järjestelmä on olemassa, eli mitä toiminnallisuuksia se tarjoaa ulospäin ja mitä tietoa se vaihtaa muiden järjestelmkien kanssa. Kokonaisarkkitehtuurin tai liiketoiminnan kannalta ei oleellista tuntea millainen on järjestelmän sisäinen arkkitehtuuri (looginen tai fyysinen). Mutta järjestelmän sisäinen toiminta ja rakenne on merkityksellistä ratkaisuarkkitehtuurin (Solution Architecture) näkökulmasta. Nämä asiat voidaan tarvittaessa kokonaisarkkitehtuurivälineessä, tai vaihtoehtoisesti jossain toisessa välineessä joka on käytännöllisempi esim. ketterän kehitystiimin kannalta.

Sovellusrakenne (Application Structure)

Sovelluksen sisäinen looginen rakenne on ratkaisuarkkitehtuurin (Solution Architecture) kuvaus. Sovellusrakenne kuvaa järjestelmän sisäiset osajärjestelmät (sub-systems) eli moduulit / osakomponentit, sekä näiden tarjoamat ja käyttämät rajapinnat.

Teknologiakerroksen näkymiä

Elementit: solmu (Node), järjestelmäohjelmisto (System Software), teknologiapalvelu (Technology Service), teknologiarajapinta (Technology Interface), teknologiaprosessi (Technology Process), teknologiatoiminto (Technology Function), artefakti (Artifact), laite (Device), tietoliikenneverkko (Communication Network).

Teknologia-alusta (Technology Platform)

Järjestelmän tekninen totetus voidaan kuvata teknologia-alusta -näkymän avulla. Teknisiä asioita ovat mm. järjestelmän toteutukseen liittyvät ohjelmistot, palvelimet ja muut laitteet kuten verkkokomponentit sekä tietoliikenneverkot. Edelleen voidaan kuvata järjestelmän asennukseen ja ajoympäristöön liittyviä tuotantoympäristön asioita kuten klusterointia, replikointia, palomuureja, verkkosegmenttejä jne., mikä milloinkin on tarkoituksenmukaista. Tällöin teknologia-alustojen kuvaukset laaditaan kertaalleen, ja niihin viitataan muissa kaavioissa. Kaikki (!) järjestelmän tekniseen ratkaisuun liittyvät asiat voidaan kuvata tämän näkymän avulla.

Kuva: Teknologia-alusta.

Teknologia-alusta on konfiguraatio, jota voidaan “monistaa” eri ratkaisuissa. Organisaation teknologia-alustat kuvataan kertaalleen, jolloin niiden päivitykset voidaan helpommin hallita teknisten asiantuntijoiden toimesta. Näin liiketoiminnan järjestelmien kuvauksissa voidaan vain viitata näihin alustakaavioihin, ilman että teknisistö ratkaisuista tarvitsee laatia useita kaavioita, jokaiseen käyttökohteeseen erikseen.

Teknisten ratkaisujen hallinta organisaation kokonaisarkkitehtuurissa muuttuu. Nykyisellä pilvipalveluiden aikakaudella teknologioiden ja teknisten ratkaisujen merkitys vähenee, kun järjestelmiä hankitaan pilvipalveluina enenevässä määrin. Mutta aina silloin kun järjestelmä toteutetaan itse, on hyödyllistä kuvata sen teknologiaratkaisu tarkasti, jo pelkästään jatkuvan ylläpidollisen jatkokehityksen vuoksi. Myös DevOps -kulttuurissa kehitystiimin kannattaa kuvata järjestelmän tekninen ratkaisu, jotta sen ominaisuuksien jatkuva kehittäminen ja tuotannollinen opertointi olisi mahdollsimman hyvin dokumentoitu. Lisäksi, mikäli organisaatiossa halutaan hallita ns. teknologiasalkkua (teknologioita), on syytä kytkeä järjestelmät ja teknologiat yhteen.

Kerrokset ylittäviä liiketoiminta-arkkitehtuurin näkymiä

ArchiMate peruselementeillä voidaan liiketoiminta-arkkitehtuurin näkymiä, jotka ylittävät ArchiMaten kerrokset. Liiketoiminta-arkkitehtuurilla tarkoitetaan tässä yhteydessä kaikkea sitä, mikä on merkityksellistä liiketoiminnan kehittämisen ja operatiivisen toiminnan kannalta. Tällöin kuvataan kaikki toiminnalliset ja rakenteelliset asiat joiden ymmärtämisellä on vaikutusta liiketoimintaan (sis. kaikki osatekijät joilla on ns. business relevanssia).

Kerrosnäkymä (Layered View)

Kerrosnäkymä on monipuolisin kaaviotyyppi, sillä sen avulla voidaan yhdistellä kaikkien kerrosten kaikkia elementtejä. Mutta ennen kaikkea, kerrosnäkymän avulla voidaan kuvata kehittämiskohteesta kaikki oleellinen liiketoiminnan näkökulmasta: mikä on se liiketoiminta johon kehittämiskohde liittyy – olipa kysessä liiketoimintaan kohdistuva muutos tai IT-muutos.

Kuva: Kerrosnäkymä (Layered View).

Yleiskuva (Overview)

Yleiskuva / Yleisnäkymä (Overview), on ns. yhdistelmänäkymä, joka perustuu ns. kerrosnäkymään (Layered View), mutta laajentaa sitä tarvittavin osin. Tarkoituksena on aikaansaada kehittämiskohteesta yleisnäkymä, kokonaiskuva, jossa voidaan esittää kaikki oleelliset asiat yhdessä näkymässä – myös tietovirrat. Kuvaan on lisätty asioita kuten tietovirtoja prosessien ja sovellusten välillä, jolloin niitä varten ei tarvitse laatia erillisiä kaavioita.

Kuva: Yleiskuva (Overview).

Yleiskuvan avulla voidaan kuvata kehittämiskohteen liiketoiminta-arkkitehtuuri, jossa on kuvattu toimijoiden toimintaa, järjestelmien käyttöä toiminnan tukena, sekä tietojen vaihtoa prosessien, järjestelmien ja/tai toimijoiden välillä.

Yleiskuva (Overview) on yhdistelmä kerrosnäkymästä (Layered View) ja vuorovaikutusnäkymästä (Cooperation View).

Alla olevassa esimerkissä on kuvattu ylätasolla ns. Tilauksesta toimitukseen (Order to Cash) päästä-päähän -prosessi (Tilaus-Myynti, Tuotanto, Toimitus). Se ylittää yksikkörajoja ja käsittää useiden järjestelmien (kuten CRM ja ERP) hyödyntämistä, sekä niiden välistä tietojen vaihtoa. Tämän kuva avulla voidaan esittää yhdessä kuvassa koko kehittämiskohteen muodostama kokonaisuus.

Kuva: Yleiskuva (Overview), jonka avulla voidaan yhdessä kuvassa esittää kehittämiskohteen konteksti (toimintaympäristö).

Yleiskuvassa yhdistyy kaikki oleellinen: riippuvuudet ja tietovirrat. Yleiskuva on yksinkertaisin ja helpoin tapa kuvata kokonaisuus yhdessä kuvassa, kun se on pieni tai keskisuuri. Yleiskuva on hyödyllinen, jotta ainakin edes yksi kuva tulisi tehdyksi kehittämiskohteesta. Jos kokonaisuus on laaja, ja siitä on vaarassa tulla liian monimutkainen ymmärtää ja ylläpitää, se kannattaa pilkkoa erilllisiin kaavioihin kuten esim. kerrosnäkymä, sovellusten vuorovaikutus, käsitemalli.

Käsitemalli auttaa ymmärtämään kehittämiskohdetta: mistä puhutaan kun tästä puhutaan. Käsitemalli auttaa hahmottamaan kehittämiskohteen tietoja.

Vuorovaikutusnäkymä (Cooperation View) eli Tietovirtanäkymä (Data Flow View)

Vuorovaikutusnäkymä (Cooperation View) eli tietovirtanäkymä (Data Flow View) on näkymä, jossa kuvataan tietovirtoja toimijoiden, prosessien ja sovellusten välillä. Päähuomio on tietovirroissa. Tietovirtoja voidaan kuvata sekä rakenteellisten (active structure) että toiminnallisten (behavioral) elementtien välillä.

Versio 1

Kuva: Kerroksellinen tietovirtanäkymä – yleiskuva. Tietovirtayhteyksien (Flow) labelissa mainittu informaatiokäsitteen (Business Object) / tietoelementin (Data Object) nimi.

Versio 2

Kuva: Kerroksellinen tietovirtanäkymä – yleiskuva. Tietovirroissa esiintyy informaatiokäsitteet (Business Objects) elementteinä. (Ne voidaan korvata tietoelementeillä (Data Objects), mikäli tietoryhmät on tunnistettu ja tietorakenteet määritelty.)

Tarkoituksena on saada aikaan kokonaiskuva kehittämiskohteen tietovirroista, eli tiedonvaihdosta, yhteen kaavioon. Mikäli kehittämiskohde on laaja ja kaaviosta uhkaa tulla liian monimutkainen, kannattaa silloin tehdä erilliset kaaviot elementtityypeittäin (toimjoiden vuorovaikutus, prosessien vuorovaikutus ja sovellusten vuorovaikutus). Vuorovaikutusnäkymä voidaan kuvata myös kerrosmaisesti, kuten alla olevassa esimerkissä on tehty.

Kuva: Vuorovaikutusnäkymä (Cooperation View), jonka avulla voidaan esittää keskeiset tietovirrat yhdessä kuvassa.

Toimijoiden ja sovellusten vuorovaikutuksia voidaan yhdistellä samaan kaavioon jo senkin vuoksi, että molemmat elementit ovat ns. rakenteellisia elementtejä. Tämä on käytännöllistä kun toiminnan luonne on tietointensiivistä, ts. kun tiedon rooli ja merkitys on organisaation toiminnassa keskeistä.

Vuorovaikutusnäkymässä voidaan tarvittaessa käyttää sovelluskomponenttien (Application Component) sisällä joko sovellusprosessi- (Application Process) tai sovellustoimintoelemettejä (Application Function), kuten kuvassa alla. Tällöin pyritään siihen, että tietovirtoja kuvataan toiminnallisten (behavioral) elementtien välillä, jota toimintaa rakenteellliset (active structure) elementit “suorittavat”.

Kuva: Vuorovaikutusnäkymässä voidaan käyttää sovelluksen sisäisiä toiminnallisia elementtejä (Application Function ja Application Process).

Ylimmällä tasolla tietovirrat kohdistuvat rakenteelliseen elementtiin (Business Actor tai Application Component). Sen sisäistä toimintaa voidaan tarvittaessa avata, jolloin tietovirtojen kohdistumista voidaan tarkentaa, ja kytkeä ne toiminnallisiin elementteihin (Business Process, Business Function, Application Process, Appplication Function).

ArchiMate yhteystyypit

Alla olevassa kuvassa on esitetty kaikki ArchiMate -yhteystyypit elementtien välillä.

Huom! Vain osajoukko yhteystyypeistä riittää useimpiin käyttötarkoituksiin:

  • toteuttaa (realization),
  • palvelee (serving),
  • tietovirta (flow).
Kuva: ArchiMate yhteystyypit.

– Eero Hosiaisluoma