You Aren’t Gonna Need It

Jag har turen att arbeta inom IT men kommer från en bakgrund som mjukvaruingenjör, vilket ger mig ett något annorlunda perspektiv på IT-världen, både genom att jag förstår mycket av det som sker bakom kulisserna med släppcykler och funktioner och genom att jag tillämpar kunskap från den branschen på den här.

Inom mjukvaruingenjörsgemenskapen har konceptet “You Aren’t Gonna Need It” eller YAGNI blivit populärt på senare år. YAGNI uppstod inom gruppen Extreme Programming (XP) av agila utvecklare och formuleras som denna regel: “Implementera alltid saker när du faktiskt behöver dem, aldrig när du bara förutser att du behöver dem.”

Jag brukar omformulera YAGNI inom utveckling till “Investera inte i något förrän du vet att du behöver det.” Men konceptet är detsamma – om du lägger tid och pengar på att bygga delar som du inte är säker på att du någonsin kommer att behöva tar du på dig risker, såsom att inte få ut värde så tidigt som möjligt (genom att fokusera på det som inte spelar någon roll ännu samtidigt som du försummar det som gör det) och att investera i teknik som aldrig kommer att användas (eftersom kraven ändras, projektet ställs in och så vidare).

Detta koncept låter sig överföras till IT ytterst väl. Både design och inköp påverkas i hög grad, eller borde påverkas, av YAGNI. Lagring är ett utmärkt exempel. Investera inte i lagring i dag som du tror att du kommer att använda i morgon. Vi kan räkna upp många skäl till varför tidig lagringsinvestering är dålig: verksamheten har liten eller ingen förmåga att korrekt förutsäga sin egen tillväxt, IT är dåligt på att förutsäga lagringstillväxt utifrån verksamhetstillväxt, pengars tidsvärde, och att köpa lagring i dag är mer kostsamt än att köpa samma lagring i morgon. Varje gång vi köper baserat på förutsägelser tar vi på oss risk. Förutsägelser slår sällan in.

Om vi köper för mycket lagring i dag betalar vi ett överpris för den lagringen, eftersom lagringskostnaderna sjunker dramatiskt över tid. Om vi köper med 100 % marginal och det tar tre år eller mer innan vi använder den marginalen betalar vi för mycket för lagringen och får äldre teknik, medan ett köp senare skulle ge oss bättre insikt i vad vi faktiskt behöver vid den tidpunkten (inte bara kapacitet, utan även hastighet, tillförlitlighet, funktioner och så vidare), lägre kostnad och fler alternativ.

Att köpa för mycket är en risk, att köpa för lite är en annan. Att köpa för lite är förstås mindre av en risk men ändå ett bekymmer. Om du köper i dag för behov tre år framåt och efter två år plötsligt får en kraftig behovstopp kan du ha överinvesterat i en plattform eller teknik som inte kan möta dina behov.

Lagring är ett exempel, men detta kan tillämpas på allt från mjukvarulicenser till CPU-kapacitet, minne, tekniker för hög tillgänglighet och till och med stationära datorer. Få verksamheter skulle köpa hundra procent fler stationära datorer bara för att vara redo för en förutspådd ökning av personalstyrkan om tre år, men märkligt nog tvekar de inte att göra det på andra områden.

Genom att köpa det som krävs för det omedelbara behovet och skjuta upp inköpsbeslut till senare finns det en betydande möjlighet till kostnadsbesparingar och teknikförbättringar. I vissa fall kan det vara så att det framtida behovet aldrig uppstår, vare sig på grund av felaktiga förutsägelser, förändringar i marknad eller strategi eller en förändring av den tekniska inriktningen, internt eller externt.

Utöver inköp kan YAGNI tillämpas på nätverksdesign. Det är inte ovanligt att stora, komplexa designer föreslås och implementeras baserat på förväntad tillväxt som ofta ligger flera år bort och, ärligt talat, sällan är särskilt sannolik i en realistisk värld. Att till exempel bygga en komplex miljö med hög tillgänglighet med dyr licensiering, komplext nätverk och mycket lagring för en förväntad företagstillväxt i framtiden, när bara två servrar och en bra säkerhetskopieringsplan är allt som är kostnadsmässigt motiverat i dag, är riskabelt. Inte nog med att den nödvändiga tillväxten måste inträffa för att motivera IT-utgiften – den måste dessutom inträffa så snabbt att pengarnas tidsvärde är motiverat och att teknikens kostnad inte sjunker så mycket att det skulle ha varit mer kostnadseffektivt att implementera två system. Det är förvånande hur lätt det kan hända att en mindre, provisorisk lösning som följs av implementeringen av ett system i större skala när det behövs kan bli långt billigare, helt enkelt för att kostnaden för att bygga det större, mer komplexa systemet har sjunkit så mycket i pris sedan det första systemet sattes på plats – och då har vi ännu inte räknat in risken för felaktiga förutsägelser.

Att spendera tidigt har ytterligare en risk – det binder upp företagets ekonomi i oanvänd arkitektur. Dessa pengar skulle kunna investeras i andra delar av verksamheten för att få verksamheten att växa. I extrema fall skulle överinvestering i infrastruktur kunna bidra till att ett företag går omkull fullständigt – en självuppfyllande situation där själva underlåtenheten att tillämpa YAGNI skapade just den situation där YAGNI var som mest tillämpligt. Den arkitekterade lösningen behövdes aldrig, eftersom företaget gick omkull.

YAGNI är en process för riskreducering. Att arbeta utifrån de behov du känner till i stället för de behov du förutser.

Kanske köper IT-avdelningar för mycket i dag för att de tilldelas specifika budgetar. Det är förståeligt att IT slutar i ett teknikrafsande där man försöker implementera vad man kan när verksamhetens nycker ler mot dem. Detta är dock en ytterst dålig affärspraxis. Företag behöver inse att stora summor pengar slösas bort på IT, eftersom IT tvingas implementera system med antagandet om klärvoajans utifrån godtyckliga budgetar från verksamheten utan förankring i den verkliga världen. IT sitter fast i att köpa det de kan “sälja in” till verksamheten utifrån ofta mycket oklara faktorer, och verksamheten finansierar ofta IT tämligen nyckfullt. Detta skapar en mycket osund relation mellan verksamhet och IT, där IT slösar pengar för att man har föga val och verksamheten ser IT som ett slöseri eftersom de inte tillåts arbeta effektivt.

För att åtgärda denna situation behöver verksamheten och IT samarbeta. IT behöver agera mer som en affärsmässigt kunnig enhet, och verksamheten behöver luta sig mot IT för vägledning och inte använda förutsägelsebaserad budgetering eller trassla in sig i att välja tekniska tillvägagångssätt utan den tekniska förståelsen för konsekvenserna av dessa val. IT behöver kunna lita på att verksamheten fattar logiska ekonomiska affärsbeslut, och verksamheten behöver kunna lita på att IT fattar logiska tekniska beslut för verksamheten. Verksamheten driver IT, IT möjliggör verksamheten. Det är en symbiotisk relation. Om verksamheten insisterar på att låta IT förutspå och arbeta utifrån fasta budgetar kommer IT att fortsätta tvingas överspendera och överarkitektera närhelst det är möjligt, i hopp om att vara förberett för morgondagen då budgeten kanske inte godkänns. Om IT anförtroddes att begära det som behövs och verksamheten anförtroddes att finansiera tekniska behov vid rätt tidpunkt skulle båda kunna arbeta mer effektivt för det gemensamma bästa.

Slutsats: Investera inte tidigt – du vet inte vad tekniken eller verksamheten kommer att göra i morgon.