Juridiske problemer forbundet med databaser i IT-systemer

Når man skal forstå juridiske problemer relateret til IT-systemer, kræves der ikke kun en systematisk forståelse af lovgivningen, men det er også vigtigt at forstå de forskellige komponenter i et IT-system. I denne artikel vil vi gennemgå, hvordan et IT-system er opbygget, hvordan de forskellige dele interagerer med hinanden, og hvordan det fungerer. Vi vil også diskutere juridiske problemer, der er særligt relevante for databaser, som kan være svære at se fra brugerens perspektiv.

IT-systemer består af “skærme” og “logik”

Hvad er “skærme” i IT-systemer

Når man forsøger at forstå strukturen i et IT-system, er det mest iøjnefaldende sandsynligvis skærmens udseende. I en typisk systemudviklingsproces følger “skærmdesign” og “skærmovergange” normalt efter “kravspecifikation”, hvor funktioner og lignende identificeres. Dette aspekt af skærmen er naturligvis synligt for brugeren, der bestiller systemudviklingen, og det er også området, hvor der er mest kommunikation mellem brugeren og leverandøren. I den følgende artikel forklarer vi “samarbejdspligten”, som brugeren har over for leverandøren i hele systemudviklingsprocessen, for at opnå projektets mål.

https://monolith.law/corporate/user-obligatory-cooporation[ja]

I denne artikel forklarer vi hovedsageligt, at brugeren har en pligt til at samarbejde med leverandøren, især i faser som grundlæggende design (dvs. skærme).

“Skærme” i IT-systemer er normalt skrevet i overensstemmelse med reglerne for computersprog som HTML og CSS. Når vi taler om “skærme” i IT-systemer, bruger vi forskellige betegnelser som “frontend”, “UI (User Interface)”, osv., men det primære fokus er på “brugervenlighed” og “læsbarhed” set fra brugerens perspektiv.

Hvad er “logik” i IT-systemer

Men hvis et IT-system kun består af “skærme”, ville det bare være en “skærm” uden nogen “bevægelse” eller “ændring”. Selvom input fra brugeren og outputvisning foregår på “skærmen”, er der en “beregning” involveret i processen.

Disse komplekse beregninger og kontroller udføres af komponenter, der ikke er synlige for brugeren, eller hvad man kunne kalde “bagsiden” af systemet. Processer som at søge efter data fra skærmen, ændre data, tilføje eller slette data er kun mulige, fordi der er en forudbygget database i baggrunden. Forskellige operationer på databasens information udføres normalt med et computersprog kaldet SQL.

At skabe en vej fra en knap placeret på skærmen til udførelsen af den nødvendige SQL-kommando er det, der fuldender det samlede billede af et system med bevægelse og ændring.

For øvrigt, diskussioner om opbygningen af forskellige logikker, der ikke er synlige fra “skærmen”, kan ofte blive omtalt som “backend”.

Det er en risiko kun at diskutere systemer ud fra deres ‘visuelle’ aspekt

Indtil videre har vores forklaringer dannet grundlaget for strukturen i IT-systemer (antaget at de fungerer på nettet). Forståelse for disse emner har stor betydning i forhold til juridiske diskussioner, konfliktforebyggelse i projekter, krisehåndtering osv. Konkret kan der opstå misforståelser i kommunikationen mellem brugere, der kun fokuserer på det ‘visuelle’ aspekt på skærmen, og leverandører, der også håndterer vigtige opgaver på den usynlige ‘logiske’ side.

Det er en risiko, at brugere og leverandører har helt forskellige fokusområder

For eksempel, brugere, der taler om IT-systemer med fokus på ‘skærmen’, har en tendens til at være ligeglade med kompleksiteten af den interne struktur. Derfor kan de ofte ikke forstå, hvor meget indflydelse selv små ændringer eller tilføjelser af funktioner kan have på mange processer. I den følgende artikel forklarer vi de juridiske problemer, der ofte opstår, når man skal afskaffe det eksisterende system, der i øjeblikket er i drift, i forbindelse med udviklingen af et nyt system.

https://monolith.law/corporate/the-transition-from-the-oldsystem[ja]

Her forklarer vi, at der ofte opstår problemer med datamigrering fra det gamle system til det nye system. Med andre ord, det faktum, at de interne beregnings- og kontrolmekanismer kan være meget mere komplekse end man kan forestille sig, kan være en uventet kilde til problemer for brugerne. Desuden kan situationer, hvor ændringer kommer gradvist efter systemet er blevet implementeret, opstå netop fordi brugerne ikke forstår ‘leverandørens perspektiv’.

https://monolith.law/corporate/howto-manage-change-in-system-development[ja]

I sådanne tilfælde, hvor der efterfølgende beordres ændringer i specifikationer eller tilføjelser af funktioner, kan spørgsmålet om, hvorvidt det er muligt at øge betalingen efterfølgende, også blive et presserende problem.

https://monolith.law/corporate/increase-of-estimate[ja]

Det er en risiko, at brugere er ligeglade med den bagvedliggende ‘logik’

Desuden kan de dele, som brugeren ikke kan observere, i nogle tilfælde have udviklet sig til store hændelser, når problemerne først bliver opdaget. Her er et eksempel.

Risiko for problemer med vedligeholdelse og sikkerhed

Dette omfatter situationer, hvor det bliver umuligt at implementere yderligere funktioner, eller hvor systemet gradvist bliver langsommere og til sidst stopper med at fungere.

Derudover er der en metode kaldet ‘SQL-injektion’, som er en sikkerhedsangreb, der udnytter mangler i koden implementeret på skærmsiden for at stjæle personlige og fortrolige oplysninger, der ikke bør vises på skærmen. Vi behandler detaljeret en sag, der blev en alvorlig konflikt som følge af dette, i den følgende artikel.

https://monolith.law/corporate/risks-of-libraryuse-and-measures[ja]

Hovedtemaet for denne artikel er risiciene ved at bruge frameworks og biblioteker, men den retssag, vi præsenterer, handler om et angreb på en sårbarhed ved hjælp af SQL-injektion.

Risiko for, at governance ikke når ud til operatørens arbejde

Det faktum, at IT-systembrugere er ligeglade med den bagvedliggende ‘logik’, kan også føre til problemer med, at governance bliver svært at anvende på arbejdet for dem, der driver IT-systemet. I den følgende artikel forklarer vi vigtigheden af at håndtere databaser i forbindelse med temaet ‘tab af data på grund af operatørens fejl’.

https://monolith.law/corporate/dataloss-risk-and-measures[ja]

Risiko for, at logikken er forkert, selvom systemet ser ud til at fungere korrekt

Det faktum, at diskussioner om systemer ikke kun handler om ‘skærmen’, betyder, at selvom et system ser ud til at fungere korrekt på overfladen, kan den underliggende ‘logik’ være forkert. Dette kan blive opdaget uventet i forbindelse med uregelmæssige opgaver, såsom ‘en gang hver sjette måned’ eller ‘en gang om året’.

I sådanne tilfælde bliver det et spørgsmål om ansvar for mangler (ikke misligholdelse af forpligtelser) i henhold til loven for ‘tilfælde, hvor mangler opdages efterfølgende i et system, der allerede er leveret’.

https://monolith.law/corporate/defect-warranty-liability[ja]

Hvis der opdages en fejl efter accept, forklarer vi detaljeret processen i den følgende artikel.

https://monolith.law/corporate/system-flaw-measure-after-acceptance[ja]

Opsummering

Systematisk forståelse af både systemudvikling og jura

Det er vigtigt at forstå, hvilken komponent i IT-systemet der er opstået et problem med, før man kan identificere de juridiske spørgsmål, der er forbundet med systemudvikling. Både fra et juridisk og et IT-systemperspektiv er det vigtigt i konflikter, der opstår i systemudviklingsprojekter, at man ikke mister overblikket over det store billede. Det anses for at være særligt vigtigt at gøre en indsats for samarbejde på tværs af forskellige brancher.