Jeg lever for ordtaket «Tenk på det du skal gjøre. Ikke tenk på det du ikke skal gjøre.»

En gang i blant bør man imidlertid se tilbake på egne løsninger med et kritisk blikk, for så å koke det ned til det man skal gjøre neste gang man skal lage en custom monitoreringsløsning. I denne bloggposten vil jeg fortelle litt om hvordan jeg feilet i å omgjøre data til kunnskap, og hva jeg lærte av den feilen.

Det startet da jeg var en relativt fersk utvikler. Ny i teamet, ny applikasjons-stack og ingen god forståelse av behovene til verken applikasjonen, kunden eller teamet. Systemet var en multi-tenant-løsning som eksporterte en haug med komplisert data og hver kunde hadde konfigurert en eller mange slike eksporter.

Da jeg kom inn i teamet, ønsket vi å eksponere monitorering til våre kunder, og løsningene levert fra skyleverandøren var ikke bra nok. Så hvordan viser man "helsa" til et sett med skytjenester som eksporterer data? En kollega hadde laget noen endepunkter der jeg kunne hente ut data fra en meldingsbuss. Så jeg, med min begrensede erfaring og mangel på kritisk øye til egne løsninger, lagde noe som så ut omtrent som bildet under.

Så hva er problemet med denne løsningen?

Om man ser dette for første gang, klarer man ikke å avgjøre om dette er en dårlig tilstand for systemet.

Hvis vi ser på dette, viser vi ikke ren data, men informasjon. Hensikten med skjermbildet var å gi et oversiktsbilde, og den informasjonen alene kan ikke gi innsikt i om alt står bra til med integrasjonene. Her har det blitt brukt tid på å implementere, men ikke nok tid på å resonnere rundt de faktiske behovene. Det man ser her, er kø og deadletter på en meldingsbuss. Om man ser dette for første gang, klarer man ikke å avgjøre om dette er en dårlig tilstand for systemet. Man ser at det er noen meldinger på kø og deadletter, men for en utenforstående så kan jo det være helt normalt. Man hadde muligheten til å trykke på hver enkelt eksport for mere informasjon.

(...), MEN JEG GLEMTE DET VANSKELIGSTE OG KANSKJE VIKTIGSTE STEGET. JEG GJORDE IKKE INFORMASJON TIL KUNNSKAP.

Det man viser her med enkel informasjon om hva som er på kø og deadletter forteller ikke en bruker at dette er utenfor normalen, eller om det er et umiddelbart behov for handling. Selv om man hadde mulighet for å inspisere integrasjonene mere nøye ved å trykke på dem, er dette et eksempel på at jeg hadde glemt noe viktig fra studietiden.

Jeg startet med data trukket fra en meldingsbuss, og gjorde dataen til informasjon når jeg aggregerte den og koblet den til en spesifikk kunde, men jeg glemte det vanskeligste og kanskje viktigste steget. Jeg gjorde ikke informasjon om til kunnskap (les gjerne SNL's definisjon).

OM SANNTIDSBILDET ER ANNERLEDES ENN SNITTET DE SISTE DAGENE, VET MAN AT NOE MÅ VÆRE GALT.

Hvordan kunne jeg omgjort denne dataen til kunnskap?

En ting man kunne gjort, var å vise hvor mange av meldingene som ble eksportert suksessfullt de siste 12 timene, og de siste to dagene. Det man oppnår da, er å se når systemet oppfører seg utenom normalen. Om sanntidsbildet er annerledes enn snittet de siste dagene, så vet man at noe må være galt. Man kan selvfølgelig også slenge på et par farger for å kunne se status uten å måtte lese et eneste tall.

Så spørsmålet er egentlig: hvorfor gjorde jeg ikke bare det med en gang? Det er jo en rekke årsaker. Men den viktigste årsaken til at løsningen jeg implementerte ikke var særlig bra, var at jeg ikke brukte 30 minutter ekstra på å tenke på om jeg kunne foredle informasjonen videre. Når jeg satt med denne oppgaven var jeg alt for fokusert på å løse oppgaven til å reflektere over noe annet enn implementasjonen av web-grensesnittet.

Om det er noe man skal ta med seg etter å ha lest denne artikkelen, er at man alltid skal spørre seg selv om det er en måte å foredle informasjon videre når man arbeider med å visualisere data. Samtidig er dette en påminnelse til meg selv om å tenke meg om litt ekstra før jeg hiver meg over koden.