IT-udviklingsprojekt blev en succes med on-site konsulenter

Et IT-udviklingsprojekt hos en international udbyder af robotbrøndløsninger til olie- og gasindustrien, lykkedes med stor succes på grund af IT-konsulenter der sad on-site hos virksomheden. Virksomheden havde i en længere periode  haft udfordringer med deres IT systemer og integrationer imellem dem.

En tung IT-løsning som ikke fungerede organisatorisk 

Set med IT-briller, var deres løsning alt for tung, ikke veldokumenteret og svær at teste. Deres systemdesign og arkitektur var forældet, langsom og havde i bund og grund en stor risiko for fejl. Deres system var monolitisk hvor man blandt andet brugte database som log storeage uden mulighed for monitorering, fall back eller disaster recovery.

Rent organisatorisk, var deres viden ikke fordelt jævnt i organisationen. Det resulterede blandt andet i flaskehalse og risiko for tab af værdifuld viden.

Sidst, men ikke mindst, var der en lang række krav til dataintegritet, sikkerhed og mobilitet i form af online-offline synkronisering.

En lang række spørgsmål presser sig på

En af fordelene ved at have eksterne konsulenter tilknyttet er, at de kan danne sig et overblik over arbejdsgange, eksisterende dokumentation og DevOps processer. Områder, som kan være svære at se, når man sidder i afdelingen til daglig. Efter nogle gode samtaler med virksomhedens ansatte, havde vi klarlagt nogle spørgsmål, som vi skulle have svar på:

• Hvordan fremtidssikrer vi forretningskritiske systemer?
• Hvordan forenkler og strømliner vi DevOps processer?
• Hvordan bryder vi den monolitiske opbygning af software samtidig med at overholde de fundamentale principper for bedste praksis indenfor softwareudvikling?
• Kan vi genbruge noget af den gamle kodebase for at spare tid og ikke gentage de samme rutiner?
• Kan vi tage brug af eksisterende funktionalitet i skyen?
• Hvordan sikrer vi dataintegritet og muliggør backups og disaster recovery?

Verden er ikke statisk – og heldigvis for det

Efter den indledende research og interviews med kunden gik vi i gang med at udtænke en løsningsarkitektur, der passer kundens behov bedst. Derudover var det klart at organisationen ikke var klar til de store ændringer med det samme, så der skulle udtænkes en trinvis strategi. Organisationen skulle have tid til at vænne sig til det nye system og uddanne medarbejderne.

Verden er ikke statisk – og heldigvis for det. Så imens vi udtænkte løsningen, påbegyndte kunden også migreringer af nogle af de centrale forretningssystemer fra on-premise til skyen. Denne migrering stillede yderligere krav til arkitekturen.

Fra monolit til microservices

Vi valgte at, angribe problemet fra flere sider. Udviklingsmæssigt skulle vi afbalancere fremtidssikring og stabilitet. Dvs. den teknologi der skulle vælges, skulle være rimelig up to date samtidig med at den var afprøvet med solid mulighed for support og opdatering.

Arkitektonisk valgte vi at, bryde monolitten i flere funktionelle enheder, nemlig microservices. Største fordel ved at implementere disse er at de er nemme at vedligeholde, evt. udskifte og opgradere uden at det har store konsekvenser for systemet som helhed. For at sikre et robust transportlag der samtidig havde mulighed for midlertidig data lag (cache), valgte vi, message queue teknologi.

Teknologivalg faldt på .NET Core teknologi da den er robust, relativt nem at vedligeholde og opgradere samt kompatibel med de systemer vi skulle integrere løsningen med. Det viste sig at, den ene komponent ikke kunne blive udviklet i .NET Core. Det løste vi nemt ved at skifte til .NET Framework 4.6 i stedet.

Eftersom systemet blev udtænkt som modulær og distribueret var der behov for at centralisere visse komponenter for at kunne drifte systemet. Valget faldt på Azure BLOB Storage hvor man kunne centralisere logs for monitorering og alarmering. Fordel ved at bruge en cloud baseret audit system var, at det var uafhængigt af den lokale infrastruktur og derfor immun overfor evt. systemnedgang, fejlopsætning, osv. Derudover var der behov for en centraliseret konfiguration for at undgå diskrepanser og miskonfigurationer hvis man implementerede de traditionelle konfigurationsfiler for hver service. Vi valgte Azure AppConfiguration som en enkelt og intuitiv løsning til udfordringen. Denne feature i Azure cloud gav os mulighed for at skabe en generisk løsning der nemt kunne udvides efter behov uden at det krævede specialviden om emnet. Yderligere implementerede vi de nødvendige data oversættelsesfiler (data mappers) for at kunne integrere data mellem forskellige systemer på tværs af teknologier og platforme vha. den afprøvede HTTPS -protokollen. Skalering i alle retninger blev pludseligt ikke et issue længere.

Projektledelse, CI/CD, Test og dokumentation hjalp vi kunden med at indføre nogle standardrutiner i Azure DevOps. Vi skabte en transparent proces hvor kunden kunne følge med uden den helt store tekniske kunnen. Med tiden begyndte kunden selv at tage mere og mere ejerskab af processen og løsningen hvilket var formål fra starten af.

On-site igennem hele udviklingsprocessen

Igennem hele udviklingsprocessen var vi ude hos kunden (on-site), for bedre at kunne afstemme forventninger og imødekomme de ændringer der pludselig opstod. På den måde sikrede vi os den nødvendige agilitet.

Da systemet gik i test, og vi begyndte med bugfixing lærte vi hurtigt værdien ved at sidde tæt sammen med kunden. I stedet for at der skulle indkaldes til møder, eller sendes lange mails, havde kunden mulighed for direkte kontakt i tilfælde af fejl el.lign.

Endvidere kan vi konkludere, at lige meget hvor meget man forbereder sig, vil der unægtelig komme noget ind fra siden, man ikke havde forventet. Eksempelvis skete det med en applikation der ikke havde været en del af scopet, da der ikke var viden om at den benyttede det gamle setup. I stedet for at problemet blev eskaleret, blev det hurtigt aftalt, at vi fik kodet den om, til at kunne passe ind i den nye integration.

Den værdi der er – både for konsulenten og kunden – ved at kunne tale sammen over bordet medvirker til at fejl ikke udvikler sig til større problemer.

Vil du læse mere om vores IT-udvikling afdeling, så klik her.