Modernisering af legacyapplikationer betyder ikke at skrive hele softwaren om på én gang. For mange virksomheder er det bedre første spørgsmål, hvilken funktion der skal ændres, hvad der foreløbig kan fortsætte, og hvordan en ordre forbliver korrekt under overgangen. DAXS ville derfor først gennemgå en eksisterende Windows- eller Linux-applikations data, grænseflader og producentgodkendelser, før en ny brugerflade, API eller platform vælges.
At flytte den eksisterende VM kan adskille operativsystem og hardware, men moderniserer ikke selve applikationen endnu. Accept af en VMware/Proxmox-migrering er et selvstændigt trin. Her handler det om den langsigtede ændring af funktioner og integrationer, mens virksomheden fortsætter driften.
Beskriv først bestanden, og træk derefter en grænse
En kortlægning kræver mere end en liste over servernavne. Hver tjenestes applikationskort omfatter ejer, brugergrupper, Windows- eller Linux-version, database og drivere, batchjob, fildelinger, printere, identitetskilde, indgående og udgående grænseflader samt vedligeholdelses- og licensaftaler. Særligt vigtige er mindre synlige veje: en natlig CSV-eksport til bogholderiet, en tjenestekonto med udløbende adgangskode eller en arbejdspladsklient, hvis version er bundet til serveren.
Ved proprietær software afgør producenten, hvilke gæsteoperativsystemer, databaseversioner, drivere og virtualiseringsmiljøer der understøttes. Direkte skrivning i databasen kan virke som en enkel integration, men kan bryde forretningsregler, garantibetingelser og senere opdateringer. DAXS ville først undersøge et dokumenteret API, en godkendt eksport eller producentens SDK. Uden et understøttet integrationspunkt kan trinvis udskiftning være teknisk eller kontraktligt uegnet; så kræves en anden beslutning med leverandøren.
Et eksempel: forny ordrestatus, behold ordrekernen
Antag, at intern ordrestyring har en Windows-applikationstjeneste, en SQL-database og en natlig eksport. Kunder spørger ofte til ordrestatus, mens den gamle kerne behandler ordrer og fakturaer pålideligt. Den første nye funktion kunne være en læsevisning, der får data gennem en godkendt grænseflade. Ordrekernen og dens database forbliver foreløbig autoritative.
Et integrationslag oversætter gamle identifikatorer og statusværdier til en dokumenteret ny model. Princippet kendes som en adapter eller Anti-Corruption Layer. Det er ikke et magisk API foran en ukontrolleret database: rettigheder pr. ordre, autentificering, inputkontrol, frekvensgrænser, logning og svartider skal vurderes på ny. OWASP nævner objektbaseret autorisation og autentificering blandt de centrale API-risici. Selv en ren statusforespørgsel må ikke afsløre andres ordrer.
Først når læsefunktionen er stabil, kan en afgrænset skriveproces følge, eksempelvis oprettelse af én ordretype. Nu bliver dataansvaret afgørende: så længe den gamle kerne er autoritativ, må den nye brugerflade ikke i det skjulte skabe en anden uafhængig sandhed. For hver post fastlægges det, hvilket system der må skrive, hvordan input genkendes entydigt, og hvordan fejl, forsinkede beskeder og rettelser afstemmes. Samtidig skrivning fra begge systemer er ingen overgangsplan uden en forretningsmæssig konfliktmodel.
Fire etaper med et målbart stoppunkt
| Etape | Ændring | Dokumentation før næste etape |
|---|---|---|
| 1. Sikr den eksisterende løsning | Registrer afhængigheder, aftaler, dataforløb og gendannelige sikkerhedskopier | Gendan applikation og database i testnetværket; afstem en prøveordre med fagområdet |
| 2. Adskil læsning | Brug godkendt eksport/API til den nye statusvisning | Mål status, læserettigheder, opdateringsforsinkelse og belastning mod det gamle system |
| 3. Flyt ét skrivetilfælde | Før kun én ordretype gennem den nye grænseflade; fastlæg dataansvar | Bogfør hver ordre præcis én gang, afstem bilag og rettelser, øv vejen tilbage |
| 4. Afvikl den gamle del | Sluk først efter dokumenteret overtagelse af funktioner og data | Ingen uafklarede skjulte kaldere, eksport-/opbevaringspligter eller producentafhængigheder |
Denne trinvise udskiftning af funktioner ligner Strangler Fig-mønstret. Det passer ikke overalt: kan forespørgsler ikke omdirigeres, spærrer leverandøren alle grænseflader, eller er det lille system let at erstatte helt, kan en adapter kræve mere arbejde end den giver værdi. Overgangslaget kræver selv overvågning, kapacitet og en operatør; det må ikke blive et nyt enkelt fejlpunkt.
Fastlæg tilbagevejen før den første produktionsskrivning
Ved en læsebaseret statusvisning er tilbagevejen ofte enkel: deaktiver den nye visning, brug fortsat ordrekernen, og undersøg årsagen. Efter første skrivning til en ny database er det ikke længere nok at skifte en proxy tilbage. Nye ordrer, annulleringer og bilag skal tilbageføres eller afstemmes fagligt. Hvert skifte skal derfor have en sidste afstemt datatilstand, et entydigt skrivestop, eksport-/importprocedurer, ansvarlige og en øvelse. Microsoft advarer udtrykkeligt om, at rollback bliver vanskeligere, når gamle dataobjekter er fjernet.
Det gamle miljø må heller ikke glemmes under paralleldriften. Hvis operativsystem eller applikation ikke længere får sikkerhedsopdateringer, skal de berørte tjenester, netværksveje og adgange begrænses målrettet, overvåges og have en slutdato. Et nyt API foran fjerner ikke sårbarheden i den gamle kerne. Om isolering er tilstrækkelig, afhænger af den konkrete risiko og producentens tilgængelige tiltag.
Vurder indsats og grænser ærligt
En sammenligning over tre eller fem år omfatter mindst kortlægning, producent- og licensafklaring, adapterudvikling, datamapping, sikkerhedskontrol, testdata, faglig accept, paralleldrift, overvågning og senere afvikling. Hertil kan komme nye system-/databaselicenser og oplæring af dem, der midlertidigt driver begge miljøer. Paralleldrift er en bevidst omkostning, ikke et gratis mellemtrin. En trinvis løsning er først umagen værd, når undgåede risici og nye funktioner retfærdiggør den faktiske indsats; et generelt besparelsesprocenttal kan ikke udledes.
DAXS ville sammen med fagområdet vælge en lille, synlig første grænse, eksempelvis statusforespørgslen, og acceptere den efter korrekte data, svartid, mulighed for support og gendannelse. Derefter afgøres det, hvilken næste funktion der faktisk behøver en selvstændig tjeneste. For det tekniske grundlag for en eksisterende VM beskriver Proxmox i virksomheden infrastrukturrammen; planlæg drift af API-adgange supplerer den senere grænsefladedrift. Vil man oprette et konkret applikationskort, kan DAXS kontaktes via Kontakt.
Kilder: Microsoft Azure Architecture Center: Strangler Fig-mønstret · Microsoft: Anti-Corruption Layer-mønstret · OWASP: API Security Top 10.
