Man kan se på automatisering som en løk med flere skall, eller med flere lag eller nivåer. Innerst inne er kjerneaktiviteten i automatisering, men uten de ytre lagene blir det pislete og stakkarlige greier. La meg forklare:

• Innerst inne ligger funksjonaliteten. Dersom ikke en automatisert oppgave faktisk løser oppgaven som er målet, så er og blir den dysfunksjonell samme hvordan du snur og vender på det. Dette er gjennomføringen, og de som tror dette er alt det er ved automatisering, har misforstått noe fundamentalt.

• Neste nivå er stabilitet, som er et systems evne til å fortsette å virke over tid. Det motsatte - et ustabilt system - er noe som mer eller mindre faller sammen av seg selv. Stabilitet er viktig i en automatisert oppgave fordi den skal fortsette å kjøre gang på gang i overskuelig fremtid, men det tar tid og testing å sikre at den automatiserte oppgaven er stabilt spesifisert og programmert.

• Tredje nivå er robusthet, som er beslektet med stabilitet, men allikevel fundamentalt forskjellig. Med robusthet menes et systems evne til forsatt å virke selv om omgivelsene rundt det endrer seg. Et stabilt korthus fortsetter å stå av seg selv, mens et robust korthus i tillegg takler at du puster på det og rugger litt i bordet. Stabilitet er viktig for en automatisert oppgave fordi miljøet det skal kjøre innen, garantert kommer til å endre seg over tid - du har kanskje ikke planlagt endringene ennå, men de kommer!

• Det fjerde og siste nivået er elegant feiling. Det betyr at når systemet tross funksjonalitet, stabilitet og robusthet allikevel ikke kan fullføre oppgaven sin, så sier det ifra på en grei og informativ måte. Ting som den ikke har blitt programmert til å takle, skal den heller ikke forsøke å ordne.

Jeg misliker automatiserte jobber når de inntrengende, repeterende og pågående forteller meg om alt som er normalt. Jeg har allerede nok avbrytelser og oppmerksomhetsavledninger i arbeidsdagen til at jeg trenger noe som støyer bare for å fortelle meg at alt er i orden. Nettopp derfor er det viktig at en automatisert jobb holder kjeft sålenge alt er i orden, og kun skriker opp dersom noe er galt. Enkle, hyppige og lettolklige feil bør den settes opp til å håndtere selv, mens de øvrige bør videresendes til en systemadministrator i mest mulig ordrett kopi og med best mulig bakgrunnsinfo. Manuell, inkrementell tilpassing av den automatiserte oppgaven over tid er den enkleste måten å gjøre den stabil og robust på.

Dette betyr ikke at jeg har noe imot statistikkrapportering og logging av at alt er greitt. Det må imidlertid skilles skarpt mellom to ting som har hvert sitt bruksområde: På den ene siden er det som er tilstandslogging som en systemadministrator kan oppsøke for rapportgenerering eller post-mortem debugging. På den andre siden er det som varsler om at noe er galt, og som systemadministrator bør få som avbruddshåndtering.

Ikke misforstå meg dithen at jeg har noe i mot proaktivtitet, tvert imot! Men jeg observerer at proaktivitet er noe som 'alle' skryter av men 'ingen' gjør. Med proaktivitet mener jeg i forbindelse med problemer å handle før de negative konsekvensene har sprunget ut og rammet brukerne. Proaktivitet er hva som ligger bak ordspråket 'bedre føre var enn etter snar'.

Det vanligste er det motsatte av proaktivitet: nemlig reaktivitet. Man fikser ikke doseringene i en sving på E6 før man har fått dødsulykker der, man trekker ikke et produkt fra markedet før man har sett at det er utrygt, man skifter ikke strømforsyningen før man merker at den ikke lengre virker.

Årsaken til dette er kanskje at det er så ufattelig mange ulike feil som kan oppstå, at man av ren matthet ignoreres de fleste. Oftest går det jo allikevel bra, og alternativet er vanligvis å bruke mye ressurser på noe man i ettertid 'ikke fikk bruk for'. Derfor satser man på at det er billigere å rydde opp reaktivt for de relativt få crashene som faktisk kommer.

Så er vi ved sakens kjerne:

• Jeg skulle ønske at flere hadde en bevisst holdning til proaktivitet, reaktivitet og balansen mellom dem, og at det er basert på kostnader, ressursbruk, sannsynlighet og konsekvenser.
• Jeg skulle ønske at flere i forkant var bevisste på hva de håndterte proaktivt og hva de planla å ta reaktivt dersom det skulle bli nødvendig.
• Og jeg skulle ønske at flere i etterkant var ærlige nok til å innrømme at dette krasjet fordi man vurderte at det totalt sett var billigere å rydde i ettertid enn på forhånd å fikse dette og tallrike tilsvarende problemer.

Og mekanismen er enkel: jo større skadekonsekvenser, jo større sannsynlighet og jo lavere proaktive kostnader; jo lavere er terskel for å bruke proaktivitet helt eller delvis for å unngå eller begrense skaden.