En ny tilnærming til robust løsningsarkitektur
Norwegian Developers Conference (NDC) er et av årets høydepunkter for teknologientusiaster, og representanter fra Novanet, Lars og Sasa, deltok på en to-dagers workshop ledet av Barry O’Reilly. Målet med workshopen var å utforske avanserte metoder og teorier for å håndtere kompleksitet i programvareutvikling, med et spesielt fokus på Residuality Theory. Denne artikkelen gir en dypere innsikt i de nye kunnskapene og metodene de lærte, og hvordan disse kan anvendes i fremtidige prosjekter for å skape mer robuste og tilpasningsdyktige arkitekturer.
Barry innledet med å fortelle om hvordan programvarearkitektur i stor grad baseres på intuisjon («gut feeling»). Vi har ingen garanti for at valgene vi tar sikrer en robust arkitektur som kan håndtere fremtidige utfordringer og endringer. Men hva er det som gjør at dyktige arkitekter allikevel lykkes gang på gang? Dette ønsket Barry å finne ut av, og han startet sitt forskningsarbeid, som ledet til en ny tilnærming for å arbeide med arkitektur. Barry O’Reilly er en høyt sertifisert arkitekt og har blant annet vært leder for Microsofts arkitekter (Worldwide Lead Solutions Architect Community). I tillegg til sin solide faglige bakgrunn er Barry en dyktig formidler, noe som gjorde workshopen lærerik og interessant.Kompleksitetsteori
Mye av Barrys arbeid rundt Residual Theory tar utgangspunkt i kompleksitetsteori (Complexity Science). Mange digitale systemer er komplekse, men kompleksitet er ikke unikt for digitale systemer. Det finnes mye teori fra blant annet biologi og fysikk som beskriver hvordan man kan arbeide med kompleksitet.
For eksempel fortalte Barry om Cynefin-rammeverket. Det hjelper oss med å identifisere i hvilken kontekst vi tar beslutninger (for eksempel «Chaotic»). Rammeverket gir oss egenskaper for konteksten (for eksempel «lacking constraint») og beskriver hvordan vi bør reagere (for eksempel «act-sense-respond»). Hvis vi ikke har identifisert konteksten («Confusion»), kan det hende vi reagerer feil. Målet er å identifisere konteksten og deretter bevege seg fra en uønsket kontekst til en bedre (for eksempel fra «Chaotic» til «Complex»).
Ved å benytte teori fra dette rammeverket, samt andre som Stacey Matrix og Antifragility, har Barry utviklet sin metode, Residual Theory. I korte trekk fokuserer Residual Theory mindre på å forsøke å spesifisere behov, som skalerbarhet, oppetid, ytelse osv., og mer på hvordan man kan sette arkitekturen under stress. Dette kan gjøres ved å komme opp med tenkte scenarioer hvor systemet blir satt under press, for eksempel «vi får flere brukere enn antatt», «en konkurrent senker prisene» eller «vi ønsker å selge produktet i et annet land». For hvert av disse scenarioene forsøker man å finne en løsning, enten en kommersiell løsning, en teknisk løsning eller begge deler. En kommersiell løsning på «ønsket om å selge produktet i et annet land» kan være å etablere et salgskontor i det aktuelle landet. En teknisk løsning kan være at systemet må støtte flere valutaer. Tanken er at hvis man løser nok av disse fiktive scenarioene og bygger inn de tekniske løsningene i arkitekturen, vil disse løsningene også kunne håndtere reelle fremtidige problemer. Residual Theory gir oss et rammeverk for å arbeide med scenarioer for stress (kalt «Stressors») og deretter iterere over arkitekturen for å gjøre den mer robust.
Lærdommer vi tar med oss
Etter to dager med workshop trekker Lars og Sasa frem disse lærdommene verdt å nevne:
Strukturerte systemer i ustrukturerte miljøer
De systemene vi bygger er i stor grad strukturerte, men det miljøet vi opererer i er ikke strukturert. I den organisasjonen vi arbeider vil ting endre seg. I verden rundt organisasjonen vil ting endre seg.Det er umulig å forutsi hvilke fremtidige utfordringer organisasjonen kan påvirkes av. Dette fører til mange av de problemene vi ser i systemene våre i dag.
Stress systemet
Spesifikasjon og krav (for arkitektur) baseres på antakelser om fremtiden, som åpenbart er vanskelig å forutse. Det er mer sannsynlig å designe en robust systemarkitektur ved å fokusere på hvordan en kan stresse systemet.
Lateral tenking
Som utvikler man vant med å lineær tenking, dvs. man følger en sekvensiell prosess og løser enkelt problemer. Når man skal over i arkitektrollen, må man bli bedre på lateral tenking. Som vil si evnen til å se på problemer fra forskjellige vinkler og komme opp med kreative løsninger. En må være komfortabel med å operere i et usikkert miljø, hvor løsningene ikke nødvendigvis er rett frem.