PRIO/SAP jämfört med moderna system.

Inrtoduktion
Försvarsmakten har köpt in ett stort system modell Ä (äldre), till en engångskostnad på 2.5 miljarder och återkommande kostander runt 200 miljoner per år, för att automatisera verkets adminisration av tillgångar. Trots så omfattande investerignar i administrativa system kommer officerarna i medeltal enligt rycktesvägen att spendera 40% av sin tid åt att förse systemet med uppgifter. Det jag försöker mig på är en jämförelse mellan FMs och investmentbankers IT lösningar för att greppa det ofattbara som drabbbats FM. Frågan jag ställer är om FM inte kunde gjort det bättre?

Mina kunskaper kretsar kring teknologi och utvecklingsmetodik de 6 största investeringsbankerna använder sig av, (Goldman Sachs, Morgan Stanley, Merrill Lynch, Lehamn Brothers, CitiGroup, och Barclays Bank). Varför jag använder investeringsbanker i jämförelsen är dels p.g.a. min bakgrund och dels p.g.a. påfallande likheter i de krav som ställs på system teknologi.

System arkitektur
Till vänster i bilden är ett SAP baserat system som PRIO och till höger ett antal heterogena system baserat på gemensam teknologi.

Gul färg representerar PRIO funktionalitet. Kostnaden och utvecklingstiden för att leverera PRIO funktionalitet mha en modern arkitektur är mycket liten jämfört med vad det tar att ta fram lösningen mha SAP. Anledningen är att mycket av funktionaliteten och resurserna redan fins i form av moduler, protokoll, gränssnitt, funktioner, infrastruktur och databaser samt i andra system. Arkitekturen gör det nämligen möjligt för alla övriga system att återanvända funktionalitet i äldre system medels adapters. Förutsättningen är förstås att alla komponenter och system kommunicerar via standariserade protocol och format (objekt). Integreringen av moduler och äldre system underlättas dock avservärt tack vare möjligheten att utifrån specifikationer automatiskt generera protkol, format och formatöversättningar.

Load-balancing, fail-over and disaster recovery
Låt oss se hur försvarsmakten likt en typisk investmentbank kan lösa problem som uppstår då det inträffar en katastrof, t.ex. en jordbävning, och hur alla system i organisationen delar på datorer, nätverk och databaser utan att behöva sätta upp och driva separata datacentraler eller datorer for varje specifikt system.

Exempel,

En kompanichef sitter med sin PC på I19 och kör ett antal system(tex PRIO) indirekt via en gemensam infrastruktur. FM har ett antal datacentraler, bla i Uppsala och Stockholm.

Scenario (effektiv resursfördelning): Eftersom systemen körs på gemensam hårdvara utspridd i Sverige och att hårdvaru resurserna administreras via den gemensamma infrastrukturen kan antalet tilldelade datorer ökas eller minskas beroende på belastning. När alla använder PRIO och det körs tunga bakgrunds-jobb blir systemet lätt långsamt. Då kan systemet automatiskt leta land och rike runt efter datorer för att fördela belastningen och tom använda alla FMs datorer om så behövs.

Scenario 2 (disaster recovery): Stockholm bombas sönder och hela datacentralen slås ut. Detta leder till att ett timglas visas på kompanichefens skärm under en minut. När timglaset försvinner fortsätter han att använda PRIO, som nu körs i Uppsala, som om ingenting hänt.

Bild från en powerpint presentation.

Vad som möjliggör detta är att alla datorer betraktas som ett moln (Cloud Computing) dar PC i förväg inte har en aning om vad datorerna finns. PCn anropar systemet och systemet i Stockholm svarar. PCn kopplar up sig mot Stockholm och kör tills länken bryts. När detta händer anropas systemet på nytt och då svarar Uppsala. PCn kopplar up sig mot Uppsala och kör tills länken bryts. Alla transaktioner som gått till Stockholm har kopierats över till Uppsala under tiden kompanichefen uppdaterat data i Stockholm. Alltså kan kompanichefen fortsätta lugnt utan att märka något.

Visst kan detta också åstadkommas med hjälp av SAS men att dubblera SAS/PRIO är alldeles för dyrt.

Systemutvecklings metodik
Grundprincipen är att system lever och växer som organismer kring användare där moduler levereras eller uppdateras kontinuerligt baserat förändringar i kraven. Utvecklingsprocesser (marketat med gul färg) körs i parallell till skillnad från traditionell teknisk utveckling där alla steg måste avslutas innan nästa steg kan påbörjas. Den senare metoden kallas för vatenfallsmetoden. Problem med vatenfallsmetoden är att fel som införs i inledande steg ökas exponentiellt för varje steg i utvecklingskedjan och är i slutfasen mycket tidödande och kostsamma att rätta till. Att analysera, designa, konstruera och testa samtidigt är en nödvändighet eftersom utveckling i sin natur är abstrakt, experimentell och innovativ till skillnad från att rita och bygga ett hus.


Användardriven utveckling
Investment banker låter i regel användarna driva utvecklingen av system och utgör därför en aktiv del i utvecklingsprocessen. Användarna formulerar krav, som i sin tur används av utvecklarna för att analyserar resursåtgång, leveranstider, mm. Beväpnade med estimat (d.v.s., resursåtgång, leveranstider, mm) kan användarna prioritera delleveranser. Ett effektivt sätt att öka förståelsen för kraven och eliminera missförstånd är att bygga prototyper, vilka sedan ingår som en del i kravmodellen(krav specifikationen). Val av moget/mogen object-orienterat IT folk, utvecklingsmetodik och teknologi är avgörande för att snabbt och enkelt kunna ta fram prototyper. Slutligen, användarna använder två system: ett produktionssystem och en updaterad version (User Acceptance Test). Den senare levereras så snart alla användare samtycker och inga fel uppstått.

Att bygga team runt användarna

Malin Lindquist (Tokyo/Japan)