ArchiMate®-kaavioita on tullut tehtyä paljonkin. Mutta aina välillä tulee mallinnustilanteita, joissa ns. peruskaavioilla ei pärjää mitenkään. Sen sijaan joutuu miettimään, mitä elementtejä ja yhteyksiä ylipäätään käyttäisi. Ja tyypillisesti lopputuloksen pitäisi kuitenkin olla niin selkeä, että lukija ymmärtäisi, vaikkei ArchiMatea® syvällisesti tuntisikaan.
Tässä blogissa kerron casesta, jossa jouduin miettimään, miten ja millä elementeillä mallintaisi asiakirjoihin liittyviä metatietoja.
Erilaisissa asiankäsittelyprosesseissa syntyy ja päivitetään asiakirjoja. Asiakirjoihin liittyy metatietoja, joista jotkut ovat pakollisia ja jotkut valinnaisia. On myös tilanteita, joissa EI saa käyttää tiettyjä metatietoja. Ja kuvauksen pitäisi tietysti olla selkeä ja ymmärrettävä. Miten siis lähestyä?
Perustana normi prosessikuvaus
Prosessi ja sen vaiheet: ok, siihen löytyy ihan normielementit ArchiMatesta®.
Asiakirja: juu, käytetään liiketoimintakerroksen esitys-elementtiä (representation).
Samassa prosessin vaiheessa voi syntyä useita asiakirjoja, tai syntyä uusia ja päivittyä olemassa olevia.
Kuva 1: Päästä-päähän prosessi ja sen asiakirjat peruskuvauksena
Todellisessa casessa yhteen prosessin vaiheeseen saattoi liittyä 13 asiakirjaa ja koko päästä-päähän prosessiin jopa 21, jolloin pääsy-nuolien (access) määrä on huima, jos ne liitetään jokaiseen asiakirjaan erikseen.
Haaste 1: Kuinka ratkaista nuolihässäkkä niin, että kuvasta tulee helppo lukea?
Ratkaisu: Ryhmitellään asiakirjat ja kiinnitetään pääsy-nuoli prosessin vaiheesta kyseiseen ryhmään – ei siis jokaiseen asiakirjaan erikseen. Yhteen ryhmään laitettiin keskenään samankaltaiset asiakirjat. Vastaavaa ryhmittelyä kannattaa käyttää myös muissa vastaavissa tilanteissa.
Kuva 2: Ratkaisu nuolihässäkälle
Tämä ratkaisu ei toimi, jos olisi haluttu myös analysoida mallista, missä kaikkialla tiettyä asiakirjaa käytetään. Onneksi kyseisessä casessa master-tietolähde oli massiivinen excel, josta näitä erilaisia tilanteita saatiin esiin suodattamalla. Eli mallissa riitti kuvaaminen.
Yllä olevasta kuvasta myös näkyy, että useassa prosessivaiheessa käsiteltävä asiakirja oli selkeintä jättää ryhmän ulkopuolelle, jotta ei tulisi pääsy-nuolia ryhmän sisään.
Metatietojen kuvaaminen
Entäs ne metatiedot? Onneksi tässä tapauksessa erityisesti kiinnostava asiakirjaan liitettävä metatieto oli mahdollista kuvata toiminnan palvelulla. Sillä itse asiassa kuvattiin, mihin toiminnan palvelun toteuttamiseen kyseinen prosessin vaihe ja asiakirja liittyivät. Niinpä prosessin vaihe toteuttaa (realize) kyseistä toiminnan palvelua.
Kuva 3. Asiakirjojen palvelu-metatiedon kuvaaminen
Ja samoin kuin asiakirjojen tapauksessa, mikäli prosessivaihe toteutti useita palveluita, ne kannatti ryhmitellä.
Haaste 2: Palvelun kirjaaminen asiakirjaan voi olla pakollista, vapaaehtoista tai sitä ei saa kirjata. Miten ihmeessä tuon saisi kuvattua?
Ratkaisu: Ns. liikennevalojen käyttö olisi luonnollinen lähestymistapa: punainen = ei saa, vihreä = juu, pitää ja keltainen = jos haluaa. En kuitenkaan halunnut lähteä muuttamaan ArchiMaten® värejä – esityksen väri on vaaleankeltainen. Vaan entäpä jos vaihtaisin elementin reunaviivan värin? Toimii! Tosin ohuen reunaviivan erottuvuus voi olla vähän huono… Välinekohtaisesti viivaa saattaa pystyä paksuntamaan – tai sitten ei.
Usein usealla asiakirjalla oli palvelun kirjaamiseen samanlainen pakollisuus – laitetaanpas nämä siis ryhmään, ja sen sisuksen väriä kyllä voi vaihtaa. Niinpä sitten kaavioista löytyi pakollisen palvelu-metatiedon asiakirjojen vihreitä ryhmittelyitä, ’ei saa käyttää’ -metatiedon punaisia ryhmittelyitä jne.
Kuva 4. Asiakirjojen metatiedon pakollisuuden kuvaaminen
Haaste 3: Joskus olikin tilanne, että kaikki muut palvelut voi kuvata metatiedoksi PAITSI se ja se.
Ratkaisu: Käytetään rajoitus- eli constraint-elementtiä ja nimetään se kielteisen ehdon mukaisesti. Jos rajoituksia oli useita, jokaisesta tehtiin oma elementtinsä. Nimittäin joskus sama rajoitus koski useampaa asiakirjaa. Rajoitus-elementti kiinnitettiin asiakirjaan yhteydellä eli assosiaatiolla.
Lukijan opastukseksi alkuun lisättiin lukuohjeet ja jokaiseen kuvaan nuo värikoodit.
Kuva 5: Lopputulos asiakirjojen metatietojen kuvaamisesta
Yleistä uusien kuvaustapojen työstämisestä
Eihän nuo kuvatut haasteet kerralla esiin tulleet. Eivätkä ratkaisutkaan hihasta pudistamalla. Kyllä noihin meni useampia iterointikierroksia: tein ehdotuksen, jota käytiin yhdessä läpi ja todettiin, mikä toimii ja mikä ei. Jos kuvaustapa ei toiminut, niin takaisin mietintämyssy päähän ja kokeilemaan. En kuitenkaan halunnut tehdä ratkaisuja, jotka ovat syntaksin vastaisia. Iteroiden löytyi sopiva kuvaustapa ja sitten vain sitä soveltamaan kautta linjan mallinnettaviin kohteisiin.