Om juridiska problem kopplade till databaser i IT-system

När man lär sig om juridiska frågor relaterade till IT-system krävs det inte bara en systematisk kunskap om lagar, utan det är också viktigt att förstå komponenterna i IT-systemet. I denna artikel kommer vi att förklara hur IT-system är uppbyggda av olika delar och hur dessa delar fungerar tillsammans. Vi kommer också att diskutera juridiska frågor som är särskilt relaterade till databaser, vilket kan vara svårt att se från användarens perspektiv.

IT-system består av “skärmar” och “logik”

Vad menas med “skärmar” i ett IT-system?

När man försöker förstå strukturen i ett IT-system, är det mest iögonfallande oftast skärmens yttre utseende. I själva verket, i den allmänna processen för systemutveckling, följer vanligtvis “skärmdesign” och organisering av “skärmövergångar” efter “kravdefinition”, där funktioner identifieras och analyseras. Dessa aspekter av skärmens yttre utseende är naturligtvis synliga för användaren som beställer systemutvecklingen, och det är också området där kommunikation mellan användaren och leverantören oftast sker. I följande artikel förklaras “samarbetsplikten” som användaren har gentemot leverantören i hela processen för systemutveckling, för att uppnå projektets mål.

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

I denna artikel förklaras huvudsakligen att användaren har en skyldighet att samarbeta med leverantören i faser som grundläggande design (dvs. skärmar) i systemutvecklingsprocessen.

“Skärmar” i ett IT-system beskrivs vanligtvis enligt reglerna för datorspråk som HTML och CSS. Diskussioner om IT-systemets “skärmar” innefattar olika termer som “frontend”, “UI (User Interface)”, men huvudfokus ligger på aspekter som “användarvänlighet” och “läsbarhet”.

Vad menas med “logik” i ett IT-system?

Men om ett IT-system enbart består av “skärmar”, blir det bara en “skärm” utan någon “rörelse” eller “förändring”. Även om inmatning från användaren och utmatning av data sker på “skärmen”, finns det en “beräkningsprocess” i bakgrunden.

Denna osynliga del av systemet, som kan kallas “systemets baksida”, utför komplexa beräkningar och kontroller. Processer som att söka data från skärmen, ändra data, lägga till eller ta bort data, är möjliga tack vare en förkonstruerad databas i bakgrunden. Olika operationer på databasinformation utförs vanligtvis med ett datorspråk som kallas SQL.

Att skapa en väg från en knapp eller liknande på skärmen till exekvering av nödvändiga SQL-uttryck, det är genom detta som en fullständig bild av ett system med rörelse och förändring uppnås.

För övrigt, diskussioner om att sätta ihop olika logik som inte syns från “skärmen” kan ibland kallas “backend”.

Det är riskabelt att endast diskutera system utifrån deras “utseende” på skärmen

Den förklaring vi har gett hittills utgör grunden för strukturen på IT-system (som antas fungera på webben). Förståelse för dessa frågor har stor betydelse även när det gäller juridiska diskussioner, konfliktförebyggande i projekt och krishantering. Mer specifikt kan det uppstå kommunikationsmissförstånd mellan användare som endast fokuserar på “utseendet” på skärmen och leverantörer som hanterar viktiga uppgifter på den osynliga “logiska” sidan.

Risken att användare och leverantörer har helt olika bekymmer

Till exempel, användare som fokuserar på “skärmen” när de pratar om IT-system tenderar att vara likgiltiga för komplexiteten i dess interna struktur. Just därför kan de inte förstå hur mycket en “liten tilläggsfunktion” eller “mindre specifikationsändring” som verkar trivial på ytan kan påverka många processer. Till exempel förklarar följande artikel de juridiska problem som ofta uppstår när man avvecklar befintliga system som för närvarande är i drift i samband med utvecklingen av nya system.

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

Här förklaras det att problem ofta uppstår vid dataöverföring till det nya systemet i samband med avvecklingen av det gamla systemet. Med andra ord, det faktum att interna beräknings- och kontrollmekanismer kan vara mycket mer komplexa än man kan föreställa sig från utsidan kan bli en oväntad källa till problem för användarna. Dessutom, eftersom användarna inte förstår “leverantörens känslor” som skapar systemet, kan det hända att efterföljande ändringar kommer fram bit för bit.

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

I sådana fall där specifikationsändringar eller tillägg av funktioner beordras efteråt, kan frågan om det är möjligt att öka ersättningen efteråt bli ett allvarligt problem.

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

Användares likgiltighet mot “logiken” bakom kan vara en risk

Det finns också fall där de delar som inte kan observeras av användaren blir stora incidenter när problem uppstår. Här är några exempel.

Risken för problem inom underhåll och säkerhet

Detta inkluderar situationer där det är omöjligt att implementera ytterligare funktioner, och systemet blir gradvis långsammare och slutar fungera under användning.

Det finns också en metod som kallas “SQL-injektion”, som är en säkerhetsattack som utnyttjar brister i koden som implementerats på skärmsidan för att stjäla personlig och konfidentiell information som inte bör visas på skärmen. Vi behandlar detaljerat fall där detta har lett till allvarliga konflikter i följande artikel.

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

Huvudtemat för denna artikel är riskerna med att använda ramverk och bibliotek, men de rättsfall som presenteras handlar om fall där attacker har utförts med hjälp av SQL-injektion.

Risken att styrningen inte når operatörens arbete

Det faktum att IT-systemanvändare är likgiltiga för “logiken” bakom kan leda till problem med att styrningen inte når operatörens arbete. I följande artikel behandlar vi vikten av att hantera databaser, med temat “förlust av data på grund av operatörens försummelse”.

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

Risken att logiken är felaktig även om systemet fungerar korrekt på ytan

Från det faktum att systemdiskussionen inte stannar vid “skärmen” innebär det att även om systemet fungerar korrekt på ytan, kan “logiken” bakom vara felaktig. Detta kan plötsligt upptäckas i oregelbundna uppgifter som “en gång var sjätte månad” eller “en gång om året”, även om det inte var uppenbart i den dagliga grundläggande verksamheten.

I sådana fall blir det juridiskt sett ett problem med defektgaranti, inte ett fall av kontraktsbrott, för “ett system som har levererats en gång och där brister har upptäckts i efterhand”.

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

Om en defekt upptäcks efter godkännande, beskriver vi åtgärderna i detalj i följande artikel.

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

Sammanfattning

Systematisk förståelse för både systemutveckling och juridik

Det är viktigt att förstå vilken komponent i IT-systemet som problemet uppstod i, innan man identifierar de juridiska frågorna som rör systemutveckling. Oavsett om det är ett juridiskt problem eller ett problem med IT-systemet, är det särskilt viktigt i konflikter som uppstår i systemutvecklingsprojekt att inte förlora överblicken och att anstränga sig för samarbete mellan olika branscher.