MED VÄRLDEN SOM ARBETSFÄLT

 

För några dagar sedan läste jag ett uttryck som löd Anekdotisk Evidens. Jag minns inte var jag såg det, och i vilken kontext det användes, men visst är det så att vi fattar många beslut baserat på något som har hänt förr, gärna något stort som aldrig ska få hända igen. En omtumlande händelse i våra liv har för alltid påverkat vårt synsätt om hur saker är beskaffade. En del skulle kalla det erfarenhet.

 

 

 

Jag, liksom de flesta jag känner, arbetar inom "data-branschen´" som Rutger Jönåker kallade det. IT är idag så pass stort att man kan ifrågasätta om man ens kan kalla det en branch längre, då det spänner över alla idag förekommande affärsområden. Kanske arbetar jag själv egentligen med Spel. Eller Data-Center. Eller Ledarskap. Eller Affärsutveckling. Eller så är jag troligen en Förändringsledare - där IT mest är ett verktyg, precis som sexkantsnyckeln förhåller sig till en Ikeamöbel. När jag tänker på vad jag gör så handlar det nog mest om förändring. Jag är först in. Sist ut. Och rör om i grytan under tiden.

 

Många organisationer får ibland problem. Detta har hänt även mig vid ett olika tillfällen inom ramen för den verksamheten jag har befunnit mig i. Vid ett tillfälle fick vi legala problem och var tvungna att parera genom att bygga upp en helt ny fabrik i ett annat land - ifall vi skulle tvingas stänga där vi hade vår produktion. Vid ett annat tillfälle så tappade vi vår korg med ägg, varpå de sprack, och vi drog slutsatsen att man skall inte ha alla ägg i samma korg. Med en iterativ process blev vi hela tiden bättre. The-Toyota-Way metodiken är verkligen effektiv - om man vågar, och orkar, använder den. Lean kallas den - för den oinvigda.

 

 

 

Under senare år har jag haft förmånen att på konsultbasis kliva in i andra företag som inte är min hemma-mark och finner där saker som inte går att förklara på ett rationellt sätt. Det kan vara ett arbetessätt som inte är effektivt, ett teknikval  jag inte kan förklara, eller en organisation som är tämligen oeffektiv. Ofta frågar jag mig hur det kunde bli så? Vad gick snett?

 

För något år sedan så köpte företaget jag arbetar för upp en konkurrent. Två jättar blev ännu större och avdelningarna skulle så integreras. Ett gigantiskt organisationspussel skulle läggas som kan liknas vid 15.000 pusselbitar. Fort skulle det gå också, samtidigt som 1000 pusselbitar slängdes bort och avskedades. Det visade sig att företaget vi hade köpt använde en annan databasteknik än vad vi hade. Vi använde Oracle med DataGuard medan de använde Oracle med RAC. Det senare är något mer kostsamt, men ställer framför allt stora krav på en infastruktur om det skall fungera perfekt.

 

 

 

När vi så skall bygga ihop våra miljöer i klassisk konsolideringsanda så ställs frågan varför det företaget vi köpt valt denna dyra, och komplicerade, databaslösning - en lösning som våra kunder inte specifikt efterfrågar. Först presenteras en analys om vad som skiljer lösningarna åt - men jag får inget svar på varför de egentligen använder RAC - hur kom det beslutet att tas från början?

 

Genom ytterligare efterforskning får jag slutligen ett svar. Tidigare hade man använt DataGuard, men då en disklösning, där databasen sparas, varit alltför långsam så hade man fått problem med sin databasmotor och därmed fått ett produktionsstopp. Detta skulle aldrig få hända igen - varpå man panikinvesterat och köpt RAC. En investering som sannolikt varit den största man gjort på många år.  En lösning som är så stor och så omgärdad med powerpoints att den säkerligen gick utanför budget. Säkert ivrigt påhejade av Oracle som istället för en enkel felsökning valde att rekommendera en ännu större och mer kostsam lösning.

 

 

 

Jag tror vi ofta överreagerar, och att chefer, i stridens hetta och kanske på grund av budget, ofta fattar beslut som är felaktiga. I ovan fall kanske det hade räckt med att tillse att man har ett disklösning som faktiskt var adekvat för behovet. Även om det inte är lika sexigt som att byta databasmotor så hade det säkert räckt alldeles utmärkt. Men att erkänna detta är ju samtidigt att säga att man som IT-chef inte har hanterat situationen väl; utan istället säger man att arkitekturen är felaktig, och att man måste byta databasmotor. Kanske kan man till och med skylla på utvecklarna (som givetvis bara skyller vidare på testarna). Efter några år ser organisationen det som en sjävklarhet att man kör RAC - för det har man alltid gjort - och det är det enda rätta. Det funkar ju. Det man hade innan var ju bevisligen "trasigt".

 

 

För några dagar sedan drabbades vi av torkan som varit på södra Öland. För första gången någonsin tog vattnet i brunnen slut. Jag finner mig genast på Google och söker på hur man gräver eller borrar en större och bättre brunn. Det slår mig att jag agerar som IT-chefen som valde RAC. Det jag borde göra, är att istället reda ut hur jag förbrukar mindre vatten. En tämligen enkel sak om man lägger lite energi på det. Att inte dra för stora växlar och överdriva innebär också att man inte bygger en ny och dyr infrastruktur baserat på ett problem som uppkommer 1 gång per 50 år. Istället kan det vara klokt att se över hur man mitigerar problemet.

 

Om några veckor träffas mitt gäng på en workshop i Rom. Tekniker från hela världen med olika kunskaper, erfarenheter och kulturer. Vi skall diskutera vårt framtida infrastrukturerbjudande. Min uppgift som moderator är att inte acceptera anekdotiska evidenser som en sanning. Vi vet bättre och vi kan bättre. Vi skall använda teknik på rätt sätt, vara i framkant, och ha en kostnadsbild som är acceptabel. För när allt kommer omkring finns det ingen genväg till det perfekta ljudet. Varken med RAC eller en djupborrad brunn - sannolikt två alltför kostsamma lösningar för en alldeles för enkel utmaning.

 

 

 

Vårt jobb, trots att vi gärna ser oss som hard-core-tekniker, handlar inte om sexiga lösningar för dagen (även om det kan vara roligt). Vårt jobb handlar om att de tjänster vi säljer till våra kunder skall vara gångbara, efterfrågade, och funktionsdugliga. Det är det vi kommer bedömmas på när den dagen kommer; inte om vi valde Microsoft eller Linux, EMC eller Hitachi, eller i detta fallet Oracle Dataguard eller Oracle RAC.

 

Likt min jycke Harry så skall vi spendera lika mycket tid på att nosa på marken, som att springa. Och springa - det gör vi först när vi fått upp rätt spår, tills dess lunkar vi vidare. Och likt drift och utvecklare ofta skyller deras tillkortakommanden på testare, så kan man ju faktiskt koda bra och ha redundant infrastruktur - också.