Kund: Globalt svenskt teknikföretag med komplex IT-miljö.

Utmaning

 
  • 90% kostnadsbesparing.
  • 90% ledtidsreduktion.
  • Konvertera 60% av applikationer till SaaS-leverans.
  • Nya arbetssätt.

Lösning

 
  • Flexibel och automatiserad applikationsplattform.
  • Val av Open Source-lösningar.
  • Agilt arbetssätt.
  • Modern, effektiv drift.

Om Saab Aerospace

Curabitur blandit tempus porttitor. Cras justo odio, dapibus ac facilisis in, egestas eget quam. Donec sed odio dui. Praesent commodo cursus magna, vel scelerisque nisl consectetur et. Nulla vitae elit libero, a pharetra augue.


Kunden hade för att bättre stödja sin verksamhet antagit en ny IT-strategi. En avgörande punkt i den strategin var att man ville se en större andel applikationer levererade som SaaS-tjänster.

Utmaningen
Arbetet startades och man drog slutsatsen att man skulle kunna flytta eller byta ut ca 60 % av sina applikationer till motsvarande SaaS-lösningar. Målet var att kraftigt sänka sina kostnader och att dramatiskt sänka ledtiden för ny funktionalitet i applikationerna, samtidigt som man ville uppnå förbättrad tillgänglighet och prestanda.

I och med detta identifierade man att de resterande 40% av applikationerna som inte kunde flyttas skulle stå för en oproportionerligt stor andel av den totala kostnaden då de var byggda och kördes på äldre infrastruktur och plattformar. Dessa applikationer var huvudsakligen verksamhetsspecifika och anpassade och kunde inte ersättas av standardiserade SaaS-lösningar.

För att sänka kostnaden för kvarvarande applikationer och för att kraftigt korta sina responstider på nya verksamhetsbehov började man titta på att nyttja mjukvarudefinierad infrastruktur byggd på standardkomponenter. Utifrån dessa slutsatser så startade man sitt projekt och satte upp mål.

Framgångsfaktorer i projektet

 
  • En stark vilja och ihärdigt samarbete från A till Ö.
  • En tydlig och löpande kommunikation kring prioriteringar genomgående i projektet.
  • Användningen av Open Source-lösningar.
  • Det fanns alltid en rimlig plan B och en, i nödfall, plan C för oförutsedda problem.

Mål
Det övergripande målet bestämdes till att man skulle bygga en flexibel och automatiserad applikationsplattform för CI/CD. Säkerhetspolicys med exempelvis autentisering, auktorisering, inloggning, spårbarhet och GDPR-efterlevnad skulle vara inbyggda och implementerade i själva plattformen. Utöver detta skulle man också säkerhetsmässigt kunna särskilja tillgången till hela applikationer från tillgången till enskilda informationsobjekt, samt ha full spårbarhet. 

De viktigaste mätbara målen med projektet var att applikationer och uppdateringar med ny verksamhetsfunktionalitet skulle levereras på en tiondel av tiden till en tiondel av kostnaden jämfört med befintlig miljö. Det var mycket ambitiösa mål, men med den insikt man hade skaffat sig om möjligheterna med den nya tekniken så var de inte orealistiska. 

Ett av de viktigaste delmålen i projektet var att sänka ledtiderna för att implementera ny verksamhetsfunktionalitet i de stödsystem som inte hade konverterats till SaaS-tjänster. Det kunde i många fall röra sig om flera år att göra större p.g.a. applikationens höga komplexitet och starka beroenden till andra system. Eftersom ledtiderna kunde vara så långa så innebar det till och med att verksamhetens krav ofta ändrades under tiden som implementationen pågick. 

Strategi gick ut på att ta fram egna Open source-komponenter som kunde byggas ihop till anpassade lösningar och som dessutom uppfyllde de högt uppsatta säkerhetskraven. I jämförelse med hur man traditionellt hade arbetat med att löpande försöka anpassa stora monolitiska system till att leverera verksamhetsspecifik funktionalitet så ansåg man att detta skulle vara ett bättre alternativ, och nödvändigt för att nå målen.

De nya lösningarna fick inte på något sätt kompromissa med organisationens säkerhetskrav. För att förkorta ledtiden blev ett agilt arbetssätt med Continuous integration/Continuous deployment (CI/CD) helt nödvändigt. Detta arbetssätt kan dock innebära att man inte kan säkerhetsverifiera all kod som produceras. I traditionell utveckling arbetar man i allmänhet med att först bygga funktionalitet för att sedan, när den är färdig, adressera säkerhetskraven. För att fullt ut kunna dra nytta av ett agilt arbetssätt så behövde man alltså försöka eliminera tiden för utveckling av säkerhetsfunktionalitet. Resultatet blev att man valde att bygga in säkerhet i plattformen så att applikationerna aldrig behövde implementera säkerhet utan påtvingades säkerheten från plattformen.

Ett annat utgångskrav var att kostnaderna för själva plattformen inte fick öka med antalet användare – som ett resultat av kravställning, valdes Open Source-lösningar. Ett agilt arbetssätt, enligt DevOps och med CI/CD, passar perfekt med Open Source då Open Source-kod och komponenter utvecklas på samma sätt, och därmed kontinuerligt uppdateras.

På så sätt blir arbetssättet även ett slags arv från Open Source-världen och traditionella arbetssätt skulle vara mycket svåra att applicera.

Valet av Open Source blir än mer naturligt av ett annat krav som ställdes på plattformen, nämligen att det inte fick förekomma inlåsningseffekter eller potentiella framtida konflikter eller utmaningar runt immateriella rättigheter (IPR).

För att komma ner till en tiondel av kostnaden stod det tidigt klart att en stor del av dessa kostnadssänkningar måste komma från en mer effektiv drift. Denna effektivisering uppnår man genom en hög grad av automatisering. För att nå denna höga grad av automatisering valde man att basera sin lösning på en containerplattform. Som en bieffekt av detta erhöll man, tack vare containerplattformens egenskaper, dessutom extremt hög tillgänglighet utan extra insatser. Framtida insatser blir helt på kundens initiativ och styrs varken av licensvillkor eller rättigheter som måste förvärvas. Man kan helt enkelt göra vad man vill, hur man vill och när man vill.

Direktiven var klara. Grundläggande var att alla säkerhetspolicys måste följas och det medgavs inga undantag. Däremot medgavs undantag för att inte fullt ut följa befintliga processer vilket blir en nödvändighet med nya arbetssätt. Detta var dock inte att beteckna som ett ”fribrev”. Processen skulle leverera samma resultat som de tidigare även om arbetssättet fram till resultat skilde sig mot tidigare.

Andra direktiv som togs fram under projekteringen var t ex tydliga vägval i projekteringen kring vilka licenstyper av Open Source man skulle använda för att undvika eventuella rättighetsproblem. Ytterligare direktiv var att man i projektet inte kunde använda GPL-bibliotek (GNU Public Licenses). Användande av GPL-bibliotek innebär att man måste dela med sig av resultatet, ett förfarande som inte hade levt upp till kraven i kundens interna policys.

Det fanns en vision i projektet som till stora delar realiserades. Valet av att bygga in säkerhetskraven i plattformen innebar att man som utvecklare helt kunde fokusera på den verksamhetsstödjande funktionaliteten och i utvecklingsprocessen kunde släppa hänsyn till säkerhetskraven. En del av samma vision var att särskilja datat från applikationen. Detta var i vissa fall svårt att implementera då olika funktioner och verktyg är gjorda för att applikationen äger sitt data. Funktionen finns idag i plattformen men används inte av alla applikationer. En del utgångspunkter fick också omvärderas då vissa grundantaganden helt enkelt inte visade sig inte stämma till 100 %. Här kan man se att det hade sparat tid och resurser om man från början hade tagit fram fler use case.

Projektet använde uteslutande Open source-komponenter och standardiserad hårdvara för att hålla kostnader nere och undvika inlåsningseffekter. Som IaaS-plattform valdes OpenStack. På detta lager fanns sedan ett containerlager med Docker-containers och Kubernetes kompletterad med ett antal tilläggsmoduler som t ex ISTIO. De programmeringsspråk som användes i projektet var gramför allt Go, men också Javascript och Python. Dessa har utvecklats till att bli något av en standard för många Open Source-applikationer. För att bygga produktionskedjan och realisera CI/CD nyttjades GIT Lab.

Under själva utvecklingen av plattformen skapades ett arbetssätt som gav förmågan att testa funktioner innan de var färdiga. Detta var viktigt men ger trots allt en ganska liten positiv effekt jämfört med traditionella metoder. Den stora skillnaden kom när kunden började nyttja plattformen och man började ställa krav på förändringar för att stödja verksamheten. I vissa fall kunde man i projektet ta emot en förfrågan om ny eller förändrad funktionalitet på förmiddagen och driftsättning kunde sedan ske redan under samma eftermiddag. Det är bara möjligt med ett agilt arbetssätt och CI/CD.

Automatiserade tester ger också en högre slutkvalitet och bidrar till kortare ledtider. En bieffekt är också att när man bygger en sådan här arbetsmodell så får man automatiskt en verifieringsmiljö (staging-miljö) som hela tiden är en direkt kopia av produktionsmiljön. Det ger fantastiska möjligheter att testa och tar helt bort den välkända utmaningen att hålla en separat testmiljö aktuell.

Ur processen får man också en stor mängd statistik och man kan i både testmiljön och produktion parallellt köra olika versioner av samma programvara för att dra slutsatser om stabilitet och andra faktorer. Det innebär att när rättningen av en bugg testas så kan man omgående bedöma stabilitet och utfall. Och eftersom det i processen inte finns någon överlämning mellan olika funktioner så tas denna information tillvara och går tillbaka in i processen vilket även ökar effektiviteten ytterligare.

En konsekvens av tekniken, när all funktionalitet blir mjukvara, är att precis allt plötsligt kan mätas. Detta riskerar att skapa ett brus och det kan ibland vara svårt att skilja ut den viktiga informationen. Det gör i sig att automatisering blir en nödvändighet. Det innebär också att man inte kan arbeta på traditionellt sätt med drift.

Man ska också komma ihåg att de vinster man får med mjukvarudefinierad infrastruktur delvis betalas med mer hårdvarukapacitet. Om man ska få den redundans och automation man eftersträvar så krävs helt enkelt mer hårdvara vilket ofta underskattas.

Ytterligare en konsekvens, som egentligen kanske inte är en baksida är att man kan få en ”inflation” av applikationer. Detta är i sig inte negativt men det är en konsekvens man kanske inte har tagit med i sina ursprungliga planer. En parallell till detta är övergången från fysiska till virtuella servrar som påbörjades runt förra sekelskiftet. Då flerdubblades i många fall antalet servrar. För att hantera det stora antalet applikationer så blir även här automation en nödvändighet.

Omställningen i arbetssätt är också värd att nämna. Arbetssättet är nytt och det kan ibland upplevas svårt att gå igenom omställningen, om man är inkörd på traditionella metoder.

Inom DevOps arbetar man i sina roller mindre som djupa specialister. I DevOps krävs en lite bredare kompetens och även intresse. Den stora skillnaden är ju att det är samma människor som arbetar med både utveckling och drift även om det finns olika nyanser i kompetensen såtillvida att man har sin största tyngd i antingen Dev eller Ops. Men man behärskar ändå helheten på ett rimligt bra sätt. Detta drivs av att i stort sett allt man ”tar i ” är mjukvara.

Projektet som beskrivs i denna case study var ett mycket stort projekt med global täckning. Komplexiteten i utvecklingsarbetet drivs till stor del av komplexiteten i verksamheten. Som exempel kan nämnas säkerhetskraven där man i det här fallet insåg att säkerhetsarbetet skulle kräva en mycket stor insats om man inte dramatiskt förändrade arbetssättet. 

Automatiserade containermiljöer och moderna utvecklingsmetoder är mycket effektiva för en så stor miljö som detta. Gäller det också mindre miljöer? Svaret är definitivt ja på den frågan. Vi är övertygade om att i stort sett alla organisationer kommer införa liknande miljöer, och dessutom bygga cloud native-applikationer för sina verksamheter som komplement till standardiserade SaaS-tjänster. Måhända kommer man behålla en del av sin traditionella infrastruktur där det passar, men vinsterna är så stora att det är värt ansträngningen. 

Mindre miljöer kommer också bli effektivare med motsvarande plattform och DevOps, däremot så finns det här sannolikt en undre  gräns för att motivera detta. Man behöver ha ett antal applikationer och någorlunda stor last för att det ska bli värt den tid och de resurser som går åt. Utvecklingen inom området går dock så fort att det nu finns tillgängligt färdiga komponenter som saknades i början av projektet och som nu kan nyttjas som byggstenar i ett nytt projekt. Den utvecklingen innebär att man över tid kan bygga betydligt mindre lösningar.  

Komplexiteten i arbetet drivs främst av komplexiteten i verksamheten, tex säkerhetsmässigt i en större organisation eller olika efterlevnadskrav. Men man kan givetvis börja utan alla sådana krav är implementerade i plattformen. Men mycket finns ”gratis” i verktyg som kan konfigureras att möta verksamhetskrav. Det finns många val på vägen och ”en minsta plattform” kan man få i drift på någon månad.  

En annan viktig erfarenhet som självklart gäller för många typer av IT-projekt är att inte uppfinna hjulet igen. Istället för att bygga egna mjukvaror så bör man bygga in i projektet att alltid leta upp mjukvaror i komponenter som kan bindas ihop för att åstadkomma önskad funktionalitet. Utvecklingen går så fort att ju fler egna mjukvaror man har, desto större blir underhållsbehovet. Använd Open Source och fundera även på om du inte ska tillhandahålla dina resultat som Open Source också. 

Utvecklingen går mycket snabbt och detta projekt pågick över flera år. En lärdom man kan dra från projektet är att om man skulle påbörja att realisera detta idag, så skulle man välja en ”färdig” managementlösning för Kubernetes. Plattformar som Rancher eller Red Hat OpenShift gör administration av större kubernetesmiljöer mycket enklare och snabbare. Manuell hantering blir både tungt och komplicerat. 

Tjänster som kunden köper från ELITS

 
  • Konsulter
  • Aaa
  • Bbb
  • Ccc
  • Ddd

Resultat
Hur lyckades då projektet leverera mot de uppsatta målen? Projektet uppnådde i hög grad de offensivt satta målen:

  • En tiondel av ledtiden.
    Fram till idag så har kunden nått en genomsnittlig ledtidsreduktion på 70%, inte de målsatta 90%.
  • En tiondel av kostnaden.
    Själva plattformen gav kostnader långt under 10% i jämförelse med en traditionell infrastrukturlösning. Om man också väger in kostnaderna för att realisera alla verksamhetskrav så nåddes inte målet fullt ut, då kravinsamlingen var tidskrävande. Kunden vittnar om att ledtider mellan idé och implementerad funktion har blivit mycket kortare.

Även om man inte nådde ända fram mot de direkt kvantifierbara målen så vittnar kunden om att man ser hela projektet som en betydande framgång. Man har dramatiskt sänkt sina kostnader samtidigt som man mycket snabbare, och med högre kvalitet levererar värde och funktionalitet till sin verksamhet.

Utöver detta så upplever man också stora vinster med att ha anammat nya arbetssätt i sin organisation. Utöver de direkta vinsterna kopplade till detta projekt så ser man också att en delvis ny organisation och nya arbetssätt ger dynamiska effekter som man har nytta av även på andra håll i verksamheten.

Men man ska ha en beredskap för att den första upplevelsen innebär att man måste anamma nya arbetssätt även i verksamheterna. Även om detta snabbt förändras är olika verksamheters vana att arbeta med agila arbetssätt mycket olika och det påverkar deras förmåga att dra nytta av den, t ex med sänkta ledtider. Men för samtliga kunder, även de med mindre vana, har de positiva effekterna blivit stora.


Nyfiken och vill veta mer?

Kontakta oss och få svar från någon av våra experter. Vänligen lämna dina uppgifter, så återkommer vi till dig snarast möjligt.

Kontakta oss idag!