(Toim. Kuna tegemist on uudse teooriaga, millel puudub eestikeelne vaste, siis artiklis kasutatakse ingliskeelset väljendit. Küll aga tuleb teooria nimetus mõistest “residue”. Teooria keskne idee on tekitada stressoreid ja analüüsida, mida nende stressorite üles leidmiseks arhitektuuris parandama peaks. Ehk et põhiliselt keskendutakse paranduste kontrollimisele, mitte stressoritele ega algseisule. Seetõttu võiks teooriat kutsuda “paranduste teooriaks”. Otsetõlkes oleks nimetus aga “jääkide teooria” ehk mis jääb arhitektuurist alles pärast parandusi.)
Tarkvaraarhitektid seisavad pideva väljakutse ees luua tugevaid ja vastupidavaid tarkvaralahendusi. Põhiküsimused on aga järgmised:
1) Mis üldse on hea tarkvaraarhitektuur?
2) Kuidas seda süstemaatiselt luua?
3) Millised on võtmetegurid, mida tuleb varajases arenguetapis arvesse võtta?
Kuigi nendele küsimustele pole üheseid vastuseid ega konkreetseid meetmeid tõhusate arhitektuurisüsteemide loomiseks, on mõned tarkvaraarhitektid selles ettevõtmises edukamad kui teised, võttes kasutusele residuality theory.
Mis on residuality theory?
Residuality theory on uus kontseptsioon tarkvarasüsteemide kujundamiseks, rõhutades lisaks tarkvara kavandatud eesmärgile ka tulevaste probleemide ennetamist ja lahendamist. Teooria autor Barry O’Reilly väidab, et tarkvarasüsteemid ei peaks olema keerukad ja staatilised, vaid võimelised stressi all muutuma. “Vaadeldes süsteeme jääkide ja nendega seotud stressorite komplektidena, saame paremini mõista, kuidas kujundusotsused mõjutavad tarkvarasüsteemide elutsüklit ja nende ettearvamatut keerukust,” ütleb ta.
Barry M O’Reilly tarkvarasüsteemidest:
“Me ei saa tulevikku ennustada. Aga me saame mõjutada jääki. Meie arendajatena saame otsustada, kuidas süsteem võib laguneda.”
Uptime tarkvaraarhitekti Tanel Hiobi sõnul on residuality theory tegelikult complexity theory, mis on tarkvarasüsteemidele kohandatud. Põhiprintsiip seisneb selles, et lahendades hulga suvalisi probleeme, on tõenäoline, et lahendatud on ka paljud teised probleemid, mis võivad tulevikus ette tulla. Sealhulgas ootamatud sündmused või olukorrad, mida arendaja pole ette näinud. Eesmärk on arendada tarkvara, mis suudab kohaneda probleemidega, mille tekkimist ei saanudki ette teada.
Analüüs
Residuality theory põhjal peame looma süsteemi, mis suudab toime tulla keskkonnaga, millesse ta paneme. Kuidas aga valideerida selle kontseptsiooni põhjal loodud tarkvaraarhitektuuri tõhusust? Arhitektid saavad toetuda järgmisele protsessile:
1. Disainige üks lihtne arhitektuurisüsteem
Ehitage üks juhuslik simulatsioon, millele järgneb seose analüüs. Residuality theory muudab need sammud mitte vaid selgeks, aga ka võimendab, parandades seeläbi süsteemi vastupidavusvõimet tundmatutele stressitekitajatele ja suurendades kvaliteeti.
2. Stressorite analüüs
Kõigepealt tuvastage ja analüüsige juhuslikke stressoreid, millega tarkvarasüsteem võiks oma kavandatud keskkonnas kokku puutuda. Kujundusotsused peaksid olema juhitud stressitekitajatest.
Teiseks määrake jääkide käitumised, mida tarkvarasüsteem peaks stressitekitajatele reageerides näitama. Nende käitumiste tuvastamine peaks võimaldama süsteemil jääda funktsionaalseks, toimida optimaalselt ja taastuda võimalikest häiretest
3. Intsidentide maatriks
Intsidentide maatriksi abil tuvastatakse seoseid erinevate süsteemi komponentide vahel. Maatriksit kasutatakse kõikide stressitekitajate, jääkide, protsesside, voogude ja tarkvarakomponentide kaardistamiseks. Ta aitab tarkvarainseneril tuvastada kõige suurema mõjuga stressoreid ja õrnemaid komponente. Viimased saab sarnasuse alusel kokku rühmitada – hüperliminaalne seos (hyperliminal coupling) – isegi kui koodi kahe komponendi omavaheline seos puudub, siis läbi ärilise lähteülesande see seos ikkagi eksisteerib.
Intsidentide maatriks annab ülevaate sellest, kuidas erinevad stressorid süsteemi mõjutavad. Maatriksile on märgitud süsteemi komponendid ja võimalikult palju stressoreid, mis on eelnevatel sammudel juba tuvastatud. Oluline on lihtsalt ära märkida, millised stressorid milliseid komponente otse mõjutavad ning seejärel kokku liita read ja tulpade väärtused. Lõpptulemust vaadates võime süsteemi kohta uusi järeldusi tegema hakata.
Kui mõni stressor mõjutab paljusid komponente, näitab see süsteemi haavatavust selle konkreetse stressori suhtes. Sellisel juhul tuleks süsteem uuesti läbi mõelda ja kaaluda võimalusi, kuidas stressorile paremini vastu seista. Üks võimalus on lisada midagi, mis võtaks löögi enda peale, kaitstes seeläbi süsteemi terviklikkust ja toimimist.
Kui mõni komponent saab väga paljude stressoritega pihta, viitab see komponendi liigsele haavatavusele. Sellised komponendid saab paralleliseerida või lihtsalt tugevamaks kirjutada, et nad ei oleks nii kergelt mõjutatavad.
Mõnikord tekib olukord, kus mitu pealtnäha täiesti erinevat komponenti saavad pihta sama stressoriga. See tähendab, et oleme avastanud nähtamatu hüperliminaalse seose, mida ongi keeruline arendaja silmade läbi märgata. Kui see seos on ära märgitud, siis arenduse või hoolduse käigus on hea teada, kuidas muudatused võivad mõjutada ka teisi seotud komponente. Kui juhtub nii, et mõlemad komponendid saavad täpselt samade stressoritega pihta, vihjab see tegelikult komponentide identsusele. Niimoodi paistavad hajutatud monoliidid mikroteenuste arhitektuurist kenasti välja. Oluline on aga tähele panna olukordi, kus mitu komponenti on haavatavad peaaegu samadele stressoritele. Kuigi arhitekti kõhutunne võib öelda, et need komponendid võib sellisel juhul kokku panna, tuleb olema ettevaatlik. Liigne ühendamine võib suurendada süsteemi keerukust ja teha selle rikete tuvastamise ja tõrkeotsingu keerulisemaks.
Ideaalis võiksid kõik numbrid maatriksis alla kolme jääda, kuna see vähendaks komponentide vaheliste seoste arvu ning muudaks süsteemi haldamise lihtsamaks. Praktiliselt pole see alati võimalik, kuid siiski võiksime seda arvesse võtta.
Empiiriline tõendus
Empiiriline tõendus on oluline üleminekuks intuitsioonilt inseneritööle. Residuality theory-l põhineva disainiprotsessi valideerimiseks on tarvis reaalseid tõendeid, mis kinnitaksid esialgseid ideid ja hüpoteese.
Testimisfaasis jagatakse stressitekitajad kahte erinevasse kogumisse: treenimine ja testimine. Kui treenimise stressorite abil ehitatakse uus süsteem, siis testimisfaasis võrreldakse seda algse arhitektuuriga ehk et vaadeldakse kumb arhitektuur peab testimise stressoritele paremini vastu.
Y = lihtsa arhitektuuri mõju üle elanud stressorite arv
X = uue, residuality theory’l põhineva arhitektuuri mõju üle elanud stressorite arv
Nii arvutatakse jääkindeksi Ri. Kui Ri on suurem kui 0, siis test on olnud edukas ja tõenäoliselt suudab süsteem taluda tulevikus tekkivaid häireid.
Residuality theory rakendamine praktikas
Residuality theory pole küll väga laialt veel levinud, aga ta on kindlasti intrigeeriv raamistik praktilisteks lahendusteks. Raimo Seero ütleb, et alateadlikult on varem justkui teooriale sarnaselt mõeldud, aga mitte kunagi pole seda tehtud nii süstemaatiliselt. Ta lisab, et residuality theory iroonia on selles, et kui kõik õigesti teha, siis ei märkagi, et midagi oleks nüüd väga teistmoodi. Arenduse lõpufaasis tekib lihtsalt vähem probleeme ja kõik saavad kergemini oma tööga edasi minna.
Tagantjärgi on Seero ja tema tiim analüüsinud mitmeid arendusi. Üks neist puudutas autouste lukustamist autorendi ettevõtte projekti näitel. Nimelt, kui uste lukustamise käsk auto poole teele saadeti, siis edukas vastus ei tähendanud alati, et uksed füüsiliselt lukku läksid. Mõni komponent võis vahepeal katki minna. Esimesed äpi versioonid üritasid UX (kasutajakogemuse) mõistes olla ettevaatlikud ja ei lubanud uste lukustamist, kui süsteem arvas, et uksed on juba lukus. Üsna ruttu saadi aga aru, et parem on alati uste lukustamist äpist lubada. Kui niisugune süstemaatiline analüüs oleks tehtud kohe alguses, oleks ehk sellist probleemi arenduses vältida saanud.
Teine näide puudutab üht jaekaubanduse kampaaniaprojekti, mis hõlmas eelmise kampaaniate haldamise loogika väljavahetust mitmete Uptime’i ja partnerite süsteemide kaudu. Kuigi klient oli alguses skeptiline projektiga seotud ajakulu suhtes, ilmnes projekti lõppfaasis siiski mitmeid ette ennustatud probleeme, mis tiimipoolse ettenägelikkuse tõttu õnneks kiiresti tuvastati ja kergelt lahendati. Vastasel juhul oleks neid ees oodanud palju ebameeldivaid üllatusi.
Süsteemne lähenemine tarkvaraarhitektuuri ehitamiseks
Residuality theory pakub tarkvaraarhitektidele ja inseneridele süsteemset lähenemist, et disainifaasis proaktiivselt riske vähendada ja tagada jätkusuutlik tarkvaraarhitektuur ka pidevalt muutuvate nõudmiste korral. Võttes arvesse nii parimaid tavasid, analüüsi kui ka empiirilisi teste, saavad arhitektid oma disaini jooksvalt täiustada ning tagada tarkvarasüsteemide pikaajalise toimivuse ja efektiivsuse.
