Arkkitehtuurikaavioiden laatimisen taito

Jossain vaiheessa jokaisessa ohjelmistoprojektissa, jossa olemme mukana, saattaa tulla tarve luoda arkkitehtuurikaavioita. Riippumatta siitä, seuraammeko virallista arkkitehtuurimallia (esim. Kruchten 4+1, Rozanski & Woods jne.) vai emme, on tarve dokumentoida joitakin sovelluksen osia luomalla kaavioita. Ohjelmistoarkkitehtuurissa tällaisia kaavioita luodaan näkemysten mukaisesti, jotka liittyvät tiettyyn näkökulmaan, joka voi olla osa mallia, mutta tässä artikkelissa pitäydyn mieluummin termissä arkkitehtuurikaavio enkä ole kovinkaan muodollinen; kaikkia muita näkökohtia ei ole tarkoitus käsitellä tässä.

Kokemukseni perusteella ohjelmistoarkkitehtina ja teknisenä kouluttajana on havaittavissa, että arkkitehtuurikaavioiden luomisessa on paljon eroavaisuuksia projektien välillä ja myös projektiryhmän sisällä kehittäjien välillä. Olen nähnyt paljon ongelmia, jotka liittyvät epäjohdonmukaisuuteen, hajanaisuuteen ja renderöidyn tiedon rakeisuuteen sekä kaavioiden ulkoasuun. Verrattuna arkkitehtuurimalliin, jonka on oltava muodollinen ja standardoitu, kaaviot eivät välttämättä ole formalisoituja tai noudata tiettyä standardia.

Kaavioiden on kuitenkin oltava itseään kuvaavia, johdonmukaisia, riittävän tarkkoja ja yhteydessä koodiin. Siksi on tärkeää, että jokainen arkkitehti tai ohjelmistosuunnittelija tukeutuu useisiin ohjeisiin luodessaan arkkitehtuurikaavioita, koska ne ovat yhteinen perusta sovelluksen arkkitehtuurin viestinnälle ajan mittaan (esim. rakenne, elementit, suhteet, ominaisuudet, periaatteet) ja eri sidosryhmien välillä, joilla on erilainen tekninen tausta ja erilaiset huolenaiheet.

Yleisiä sudenkuoppia arkkitehtuurikaavioita suunniteltaessa

Valmis ennen kuin menen syvemmälle mahdollisiin ongelmiin, haluaisin analogian englantilaiseen sanontaan, joka sanoo, että ”kuva kertoo enemmän kuin tuhannen sanan arvosta”. Tämän wiki-selityksen mukaan ”se viittaa käsitykseen, että monimutkainen ajatus voidaan välittää yhdellä ainoalla still-kuvalla tai että kuva jostakin asiasta välittää sen merkityksen tai olemuksen tehokkaammin kuin kuvaus”. Sama käsite pätee arkkitehtuurikaavioon: jos se herättää enemmän kysymyksiä kuin vastauksia, kaaviota ei ole luotu hyvin. Älä anna arkkitehtuurikaavion vaatia tuhansia sanoja tai selvennyksiä!

Esimerkki huonosta arkkitehtuurikaaviosta. Se kärsii useimmista alla kuvatuista ongelmista

Kierretään nyt läpi luettelo sudenkuopista, jotka saattavat haitata arkkitehtuurikaavioiden asianmukaista luomista.

Mitä laatikko tai muoto tarkoittaa?

• Minkä tahansa laatikon tai muodon käyttäminen, jota ei ole dokumentoitu kunnolla, saattaa aiheuttaa useita tulkintoja. Se saatetaan liittää joko tietoon, koodinippuun tai prosessiin. Jo pelkkä laatikko kaaviossa saattaa herättää useita epäilyjä, ja on erittäin tärkeää välttää ne lisäämällä nimenomaisesti laatikon tai muodon merkitystä koskevia yksityiskohtia kaavioluetteloon.

Mitä muodon eri reunat edustavat?

• Jokainen muodon reuna (esim. katkoviivainen, katkoviivainen, katkoviivainen, pistekatkoviivainen, jne…………………………………………………….. Viittaako tietty reuna tiettyyn komponenttityyppiin (esim. katkoviiva viittaa konttiin, mikropalveluun, kerrokseen jne.) vai onko se vain suunnittelijan mieltymys runsaaseen ulkoasuun? Vältä tällainen sekaannus antamalla legendakaaviossa tarkat tiedot, kun valitset useita tai epätyypillisiä reunoja.

Mitä viiva tai nuoli tarkoittaa?

• Viiva tai nuoli voidaan tulkita joko tietovirraksi (esim. tieto kulkee järjestelmästä A järjestelmään B) tai elementtien väliseksi suhteeksi (esim. komponentti A on riippuvainen komponentista B). Useimmissa tapauksissa nuolten esittämät suhteet tai tietovirrat eivät konvergoi samansuuntaisesti, ja on tärkeää kirjoittaa tämä eksplisiittisesti kaavion legendaan.

Mikä on viivan tai nuolen osoittama kommunikaatio-/assosiaatiotyyppi?

• Sitäkin huolimatta, että viiva viittaa tietovirtaan tai osatekijöiden väliseen suhteeseen, kyseisen viivan tai nuolen osoittama kommunikaatiotyyppi (esim. tietovirran tapauksessa) tai assosiointityyppi (esim. relaatiokohtaisen suhteen tapauksessa) on eriteltävä yksityiskohtaisesti. Jos viiva edustaa esimerkiksi tietovirtaa, tiedonsiirto voi olla synkronista tai asynkronista, mutta jos viiva viittaa suhteeseen, se voidaan esittää riippuvuutena, perintönä, toteutuksena jne. Kaikkien näiden yksityiskohtien on oltava esillä kaavion legendassa.

Mitä tuo väri tarkoittaa?

• ”Perrot”-polikloorikaavio (esim. laatikoiden ja viivojen useita värejä) ilman asianmukaista dokumentoitua tarkoitusta saattaa herättää useita kysymyksiä (esim. miksi jotkin laatikot ovat vihreitä ja toiset punaisia? Miksi jotkin viivat ovat mustia ja toiset sinisiä?). Värimaailmalla ei ole kaaviossa niin suurta merkitystä, eikä runsas värimäärän käyttö tuo liikaa lisäsisältöä tai arvokasta tietoa. Kaavio voi olla itsestään selvä ja hyvin suunniteltu myös pelkkiä mustavalkoisia värejä käyttämällä, ellei ole olemassa tiukkoja rajoitteita, joiden mukaan joitakin kaavion osia on korostettava käyttämällä erottuvia värejä. Joka tapauksessa on aina parempi pitäytyä yksinkertaisuudessa käytettyjen värien suhteen, mutta jos näin ei ole, älä unohda eritellä valintaa.

Diagrammin elementtien tai erillisten olioiden välisten suhteiden puuttuminen

• Elementtien tai erillisten olioiden välisten suhteiden puuttuminen kaaviosta voi olla vihje puutteellisuudesta. Sekä rakenteellisesta että käyttäytymisen näkökulmasta jokaisen elementin tai entiteetin tulisi tukeutua / sillä tulisi olla suhde (esitetty viivalla tai nuolella) toiseen järjestelmän osaan, jota edustaa jokin toinen elementti.

Hämärtävät/dokumentoimattomat lyhenteet tai liian epämääräiset/yleisluonteiset termit

• Käyttäessä elementin merkintää kaaviossa suositellaan, ettei käytetä mitään harhaanjohtavaa tai dokumentoimatonta lyhennettä, joka saattaisi aiheuttaa hämmennystä. Pelkkä kirjainsarja (esim. TFH, RBPM) ei merkitse mitään ilman asianmukaista selitystä kaavion elementissä tai vielä paremmin kaavion legendassa (esim. TFH – ticket feed handler, RBPM – rates business process manager).

• Toinen kaavioelementtien nimeämiselle ominainen piirre liittyy erittäin epämääräisiin tai yleisluonteisiin termeihin (esim. liiketoimintalogiikka, integraatiologiikka), jotka eivät tuota liikaa arvokasta informaatiota, koska niiden nimet eivät ole kunnolla itseään kuvaavia. Tämä ongelma saattaa esiintyä myös kooditasolla, ja ehdotus olisikin, että käytettäisiin aina itseään selittäviä ja vihjailevia nimiä noudattamalla puhtaan koodin periaatteita.

Teknologioiden, viitekehysten, ohjelmointi- tai skriptikielten, IDE:n tai kehitysmetodologian korostaminen kaavioissa

• Arkkitehtuurisuunnittelu ei liity millään tavalla mihinkään tekniikkaan, viitekehykseen, ohjelmointi- tai skriptikieleen, IDE:hen tai kehittämismetodologiaan, eikä se ole pohjimmiltaan siihen sidoksissa tai perustuva. Kaikki nämä tulevat prosessin myöhemmässä vaiheessa auttamaan arkkitehtuurin rakentamisessa, mutta ne eivät ole keskeinen asia. Niitä ei pitäisi sisällyttää kaavioihin, vaan ne pitäisi mainita arkkitehtuurin kuvauksessa, mukaan lukien perustelut niiden valintaan.

Sekoitetaan ajoaikaisia ja staattisia elementtejä samassa kaaviossa

• Ajoaikaisia elementtejä (esim. säikeitä, prosesseja, virtuaalikoneita, konttoreita, palveluita, palomuureja, tietovarastoja jne.) ei ole olemassa kääntämisaikana, ja näiden elementtien sekoittamista staattisiin elementteihin (esimerkiksi komponentteihin, paketteihin, luokkiin jne.) samassa kaaviossa suositellaankin vältettäväksi. On olemassa erityisiä kaaviotyyppejä (esim. rinnakkaisuuskaavio, käyttöönottokaavio), jotka keskittyvät ensisijaisesti ajonaikaisiin elementteihin, ja on tärkeää erottaa nämä kaksi elementtikategoriaa toisistaan ja välttää niiden sekoittamista mahdollisimman paljon.

Tehdä oletuksia, kuten ”kuvaan tämän sanallisesti” ja ”selitän sen myöhemmin”

• Kaikkea sellaista, mitä ei kuvata kaaviossa itsessään, ei ole olemassa, eikä kaaviota voi täydentää sanallisilla yksityiskohdilla. Miksi? Koska kaikki suullisesti mainitut selitykset, joita ei ole kirjattu kaavioon, häviävät, ja kun jokin muu sidosryhmä (esim. kehittäjä, arkkitehti) myöhemmin lukee kaaviota, hän ei ole tietoinen näistä selityksistä. Pyri sisällyttämään kaikki tarvittavat yksityiskohdat kaavioon, jotta vältytään lisäselvitysten tarpeelta.

Ristiriitaiset detaljitasot tai sekalaiset abstraktiot

• Eri abstraktiotasoihin liittyvien elementtien lisääminen samaan kaavioon voi olla ristiriitaista, koska niitä katsotaan eri näkökulmista. Esimerkiksi komponenttien lisääminen arkkitehtuurikontekstikaavioon tai luokkien lisääminen käyttöönottokaavioon saattaa poiketa itse kaavion tarkoituksesta. Kaaviota luodessasi yritä pysyä samalla abstraktiotasolla.

Sotkuiset tai liian epämääräiset kaaviot, joissa yritetään näyttää liian paljon tai liian vähän yksityiskohtia

• ”Kaikesta pitäisi tehdä mahdollisimman yksinkertaista, mutta ei yksinkertaisempaa” on tunnettu Albert Einsteinille kuuluva sitaatti. Tämä pätee myös arkkitehtuurikaavioihin; kaapatun tiedon taso ja rakeisuus tulisi valita mielekkäästi. Tämä ei ole helppoa; se riippuu käytettävästä arkkitehtuurimallista, arkkitehdin kokemuksesta ja järjestelmän monimutkaisuudesta.

Ohjeita arkkitehtuurikaavioita luotaessa

Yllämainittujen sudenkuoppien lisäksi, joiden välttämiseksi niiden on kuuluttava ennakkotarkistuslistaan, on olemassa myös yleisiä ohjeita siitä, miten kaaviot luodaan oikein:

Valitse optimaalinen määrä kaavioita

• Kuten Philippe Kruchten sanoi, ”arkkitehtuuri on monimutkainen peto. Käyttämällä yhtä ainoaa kaaviota arkkitehtuurin esittämiseen saadaan aikaan käsittämätön semanttinen sotku.” Nykyaikaisten järjestelmien dokumentoimiseksi emme voi päätyä vain yhdenlaisiin kaavioihin, mutta arkkitehtuurikaavioita luotaessa ei ole aina suoraviivaista, mitä kaavioita kannattaa valita ja kuinka monta niitä kannattaa luoda. Ennen päätöksen tekemistä on otettava huomioon useita tekijöitä; esimerkiksi arkkitehtuurin luonne ja monimutkaisuus, ohjelmistoarkkitehdin taidot ja kokemus, käytettävissä oleva aika, ylläpidon vaatima työmäärä ja se, mikä on järkevää tai hyödyllistä sidosryhmien huolenaiheisiin vastaamiseksi. Esimerkiksi verkkoinsinööri haluaa todennäköisesti nähdä selkeän verkkomallin, joka sisältää isännät, tietoliikenneportit ja protokollat; tietokannan ylläpitäjä on huolissaan siitä, miten järjestelmä käsittelee, hallinnoi ja jakaa tietoja jne. Kaikkien näiden näkökohtien perusteella on suositeltavaa valita optimaalinen määrä kaavioita, olipa tuo määrä mikä tahansa.
• Jos kaavioita on liian vähän (esim. liian vähäinen dokumentointi), osa arkkitehtuurista saattaa jäädä piiloon tai dokumentoimatta; toisaalta, jos niitä on liikaa (esim. ylidokumentointi), niiden johdonmukaisuuden, päivittämisen ja pirstaloitumattomuuden ylläpitämiseen tarvittava työ saattaa lisääntyä huomattavasti.

Pitäkää rakenteellinen ja semanttinen johdonmukaisuus eri kaavioissa

• Jokaisten kaavioiden tulisi olla johdonmukaisia toisten kaavioiden kanssa laatikoiden, muotojen, rajojen, viivojen, värien jne. suhteen. Rakenteellisen ulkoasun pitäisi olla sama, eikä kaikilla sidosryhmillä pitäisi olla vaikeuksia ymmärtää eri kehittäjien tiimin sisällä luomia kaavioita. Ihannetapauksessa kannattaa pitäytyä yhteisessä kaaviotyökalussa ja käyttää sitä uudelleen kaikissa projekteissa.
• Semanttisesta näkökulmasta katsottuna kaikki nämä kaaviot olisi synkronoitava säännöllisesti viimeisimpien koodimuutosten kanssa ja niiden välillä, sillä muutos yhdessä kaaviossa saattaa vaikuttaa muihin. Tämä prosessi voidaan käynnistää manuaalisesti tai automaattisesti käyttämällä mallinnustyökalua. Jälkimmäinen on suositeltavin mekanismi, mutta tämä riippuu projektikohtaisesti, ja kaikissa tapauksissa tarkoituksena on säilyttää johdonmukaisuus kaavioiden ja koodin välillä menetelmästä tai työkalusta riippumatta. Simon Brown sanoi, että ”kaavioista ei ole hyötyä arkkitehtuurin parantamisessa, jos ne eivät ole yhteydessä koodiin”, mikä korostaa semanttisen johdonmukaisuuden ajatusta.

Estä kaavioiden pirstaloituminen

• Moninkertaisten kaavioiden olemassaolo saattaa vaikeuttaa arkkitehtuurin kuvauksen ymmärtämistä, mutta myös niiden ylläpito saattaa aiheuttaa merkittävää työtä. Sivuvaikutuksena saattaa esiintyä pirstaloitumista (esim. esimerkiksi kaksi tai useampi kaavio havainnollistaa samaa laatuominaisuutta – suorituskykyä, skaalautuvuutta jne. – mutta kukin niistä on erikseen epätäydellinen). Tällaisissa tapauksissa on suositeltavaa joko poistaa kaaviot, jotka eivät kuvaa olennaisia laatuattribuutteja (jotka liittyvät arkkitehtonisesti merkittäviin vaatimuksiin), tai vielä parempi yhdistää kaaviot (esim. rinnakkaisuus ja käyttöönotto).

Pitäkää jäljitettävyys kaaviokokonaisuuksien välillä

• Historian tarkistaminen, eri kaaviokokonaisuuksien versioiden välisten vertailujen tekeminen sekä edellisten versioiden helppo palauttaminen on myös tärkeää. Sellaisen mallinnustyökalun käyttäminen, joka ei mahdollista tätä, saattaa olla esteenä. Alan viimeisimmät suuntaukset luottavat siihen, että käytetään yksinkertaista ja intuitiivista tavallista tekstikieltä, josta kaaviot luodaan, mikä näyttää ratkaisevan jäljitettävyysongelman. Tällaisen lähestymistavan etuna on myös se, että se varmistaa implisiittisesti kaavioiden välisen homogeenisen rakenteellisen johdonmukaisuuden.

Lisää legendoja arkkitehtuurikaavioiden viereen

• Jos et noudata standardoitua arkkitehtuurin kuvauskieltä (esim. UML, ArchiMate), erittele legendassa yksityiskohtaisesti kaikki kaavion osat (esim. laatikot, muodot, rajaukset, viivat, värit, lyhenteet jne.).
• Jos näin ei ole, lisätään legendaan vain arkkitehtuurin kuvauskieli avaimeksi, eikä lisäselityksiä tarvita, koska jokainen lukija seuraa kielen erityispiirteitä ymmärtääkseen kaaviota.

Onko arkkitehtuurin kuvauskielellä (esim. UML, ArchiMate jne.) väliä?

On paljon mielipiteitä siitä, mikä on oikea kuvauskieli, joka kannattaa ottaa käyttöön projektissa. Jotkut saattavat väittää, että UML on jäykkä eikä tarpeeksi joustava arkkitehtuurisuunnittelun mallintamiseen, näkökulma, josta olen samaa mieltä. Joissakin tapauksissa se saattaa kuitenkin olla enemmän kuin riittävä arkkitehtuurin perusteiden dokumentointiin ilman, että turvaudutaan UML:n laajennettavuusominaisuuksiin, kuten profiileihin ja stereotyyppeihin. Kun tarkastelemme muita kuvauskieliä, voimme nähdä, että ArchiMate on tehokkaampi ja soveltuu UML:ään verrattuna paremmin yritysjärjestelmien mallintamiseen; lisäksi on olemassa BPMN, joka on suunnattu erityisesti liiketoimintaprosesseihin jne. Vertailuja voisi jatkaa, mutta en aio tehdä mitään syvällistä katsausta niiden yli, koska se ei ole tämän artikkelin tavoite.

Arkkitehtuurin kuvauskielen kattavuus ja joustavuus on suuri edistysaskel, ja tämän pitäisi olla vankka kriteeri sitä valittaessa. Mutta minun näkökulmastani todellinen syy on jossain muualla ja liittyy siihen, että arkkitehtuuridokumentaatiota ei luoda lainkaan. Ihmiset pitävät sen luomista usein tylsänä, hyödyttömänä tai turhana. Ohjelmistoprojekteja, joissa ei ole dokumentaatiota tai joissa se on puutteellista, on valtava määrä. En usko, että ihmiset luovat intensiivisesti arkkitehtuurikaavioita tai osallistuvat niiden luomiseen käyttämällä sopimatonta kuvauskieltä, ja jos ne korvattaisiin paremmalla kuvauskielellä, tulokset olisivat hyvin erilaiset. Ei, ihmiset eivät luo mitään arkkitehtuuridokumentaatiota (mukaan lukien arkkitehtuurikaaviot), ja mikä vielä pahempaa, suurimmalla osalla heistä ei ole aavistustakaan siitä, miten se luodaan oikein. Näihin asioihin meidän on puututtava ensin – ymmärrettävä, miksi dokumentoinnilla on merkitystä ja miten sitä luodaan oikein (kouluttamalla ohjelmistosuunnittelijoita); sen jälkeen oikeiden työkalujen valinta tulee luonnostaan.

Miten kaaviot voidaan pitää ajan tasalla, kun järjestelmää kehitetään ja arkkitehtuurin muutokset konkretisoituvat

Kaavioiden ajan tasalla pitämiseen on olemassa muutamia lähestymistapoja; seuraavassa esitän kolme niistä. Ensimmäinen ja helpoin vaihtoehto olisi luoda kaaviot automaattisesti lähdekoodista, joka on perustotuus. Näin taataan, että ne ovat kaikki yhdenmukaisia koodin kanssa. Valitettavasti nykyisillä työkaluilla tämä ei ole vielä täysin mahdollista (ainakaan tietääkseni), koska nykyiset työkalut eivät pysty luomaan minkäänlaisia tarkkoja ja mielekkäitä kaavioita pelkästään lähdekoodin perusteella ilman merkittäviä manuaalisia toimenpiteitä. Len Bass sanoi, että ”ihanteellinen kehitysympäristö on sellainen, jossa dokumentaatio on saatavilla periaatteessa ilmaiseksi napin painalluksella”, mikä tarkoittaa implisiittisesti sitä, että kaaviot luodaan automaattisesti, mutta tähän pisteeseen emme ole vielä päässeet.

Toinen lähestymistapa olisi suunnitella kaaviot ensin käyttämällä erityistä työkalua, joka sitten tuottaa lähdekoodin luurangot (esim. komponentit/paketit rajoineen, API:t), joita kehittäjät käyttävät myöhemmin koodin täydentämiseen. Näin jokainen muutos arkkitehtuurissa on käynnistettävä itse kaaviosta, joka saattaa automaattisesti luoda tai päivittää koodin luurangon uudelleen.

Viimeisessä tapauksessa kaaviot päivitetään manuaalisesti aina, kun uusi ominaisuus, jolla on vaikutusta arkkitehtuurisuunnitteluun, otetaan käyttöön. Jotta voidaan olla varmoja, että kaikki koodimuutokset näkyvät kaavioissa, on suositeltavaa, että kaavioiden päivittäminen on osa kehitysprosessissa tehtävää määrittelyä. Tämä skenaario on vähemmän suositeltava, koska se voi helposti aiheuttaa vanhentuneita tai epäjohdonmukaisia kaavioita (esim. kehittäjät usein unohtavat tai eivät ole sillä tuulella, että päivittäisivät kaavioita), ja valitettavasti näin tapahtuu edelleen suurimmassa osassa projekteja.

Ollemassa olevat työkalut huomioon ottaen suositukseni on sekoitus; automaattisen ja manuaalisesti luotavien kaavioiden sekoittaminen. Yritä esimerkiksi luoda automaattisesti kaavioita, jotka voidaan kohtuullisesti renderöidä lähdekoodiin perustuvilla työkaluilla ilman liikaa kohinaa (esim. liian sotkuista tai merkityksetöntä tietoa). Tähän luokkaan voidaan sisällyttää joko kaaviot, jotka ovat hyvin epävakaita (esim. alttiimpia usein tapahtuville kehitysmuutoksille, ja niiden abstraktiotaso on yleensä alhaisempi) tai, päinvastoin, staattiset kaaviot. Tällaisia kaavioita voivat olla esimerkiksi kontekstikaaviot, viitearkkitehtuurikaaviot, pakettikaaviot, luokkakaaviot, oliokaaviot jne. Joissakin tapauksissa pelkän lähdekoodin perusteella ei kuitenkaan ole selvää, miten järjestelmä täyttää tietyt laatuominaisuudet (esim. käytettävyys, skaalautuvuus, suorituskyky), joten kaavioiden automaattinen luominen ei ole riittävä vaihtoehto. Sitä on täydennettävä manuaalisesti mallinnetuilla kaavioilla. Esimerkkejä tällaisista kaavioista ovat sekvenssikaaviot, tilakaaviot, samanaikaisuuskaaviot, käyttöönottokaaviot, toimintakaaviot jne.

Mitä komplikaatioita (tai yksinkertaistuksia) arkkitehtuurikaavioihin liittyy, kun kyseessä ovat nykyaikaiset arkkitehtuurit (esim.esim. mikropalvelut)?

Mikropalvelut tai mikä tahansa muu moderni arkkitehtuurityyli (esim. palvelimeton, tapahtumapohjainen) ohjaa vain järjestelmän rakennetta, sitä, miten komponentit kommunikoivat keskenään (esim. niiden väliset suhteet) ja mitkä periaatteet niitä ohjaavat. Henkilökohtaisesti en usko, että arkkitehtuurityylin pitäisi muuttaa kaavioiden (ja implisiittisesti arkkitehtuurikuvauksen) luomiseen liittyviä perusteita tai käsitteitä eikä sitä, mitä niiden pitäisi kuvata. Kun kuitenkin puhutaan nykyaikaisista järjestelmäarkkitehtuureista, jotka ovat yleensä monimutkaisempia kuin vanhat ja klassiset järjestelmät (esim. monoliittiset järjestelmät), ne vaikuttavat varmasti arkkitehtuurin kuvaukseen ja epäsuorasti kaavioihin siinä mielessä, että on otettava huomioon useita näkökohtia. Tällaisia näkökohtia voivat olla esimerkiksi ymmärrys hajautettujen komponenttien määrästä (esim. hajautetut mikropalvelut), kunkin komponentin tyypistä, siitä, miten komponentit kommunikoivat keskenään (esim. rajat, API:t, viestit), niiden elinkaaresta ja siitä, kuka omistaa kunkin komponentin.

Kun nämä kaikki otetaan huomioon, olisi oletusarvoisesti otettava huomioon näkymät, jotka kuvaavat järjestelmän hajoamista, kehittämistä, käyttöönottoa ja käytettävyyttä. Kuvitellaan esimerkiksi järjestelmä, jossa on vaikuttava määrä mikropalveluja; tällaisessa tapauksessa kaavioiden määrä saattaa kasvaa merkittävästi, koska jokaisella mikropalvelulla saattaa olla lopulta oma kaaviojoukkonsa. Yhtenäisyyteen (esim. yhden palvelun API:n muuttaminen vaikuttaa muihin X-palveluihin, joten kaikki kaaviot, joihin muutos vaikuttaa, on päivitettävä), hajanaisuuteen (esim. hajautettujen palveluiden välistä korkeaa saatavuutta tai suorituskykyä ei ole koottu yhteen kaaviokuvaan) tai poikkihallinnollisiin huolenaiheisiin (esim. kuka vastaa siitä, että seurannan tai tietoturvan kaltaiset näkökohdat kuvataan kootusti koko järjestelmän elementeissä) liittyviä kysymyksiä ei välttämättä ole helppo käsitellä. Tämän lisäksi saattaa esiintyä haasteita, jotka liittyvät tiimien rinnakkaiseloon ja yhteistyöhön projektin kehittämisen aikana ja jopa sen jälkeen sen ylläpitämiseksi.

Yhteenvetona voidaan todeta, että nykyaikaiset järjestelmät, joissa on monimutkaisia arkkitehtuureja, saattavat tuoda mukanaan ylimääräisiä huolenaiheita, jotka voivat johtaa komplikaatioihin jopa kaaviotasolla.

Tietoa kirjoittajasta

Ionut Balosin on ohjelmistoarkkitehti ja riippumaton tekninen kouluttaja. Hän puhuu säännöllisesti ohjelmistokehityskonferensseissa ja -tapaamisissa eri puolilla maailmaa pitäen esitelmiä, koulutuksia ja työpajoja. Lisätietoja saat hänen verkkosivuiltaan.