En av de første programmeringsoppgavene vi forsøkte oss på i faget "EDB for humanister" på begynnelsen av 1980-tallet var å lage et dataprogram som leste en fil med folketellingsdata, hvor en rad/linje i fila inneholdt informasjon om én person, og informasjonselementene (navn, adresse, osv.) var delt med skråstrek bortover raden/linja. Filene med dataene og selve programmet lagret vi i samme katalog.
En slik type databehandling, hvor program og data går hånd-i-hånd, ligger lagret på samme sted, og man ikke trenger noe "ekstra" for verken å få tak i data eller bearbeide dem, kan vi kalle 1-lags-arkitektur.
Det er flere ulemper ved en slik tilnærming til databehandling, ikke minst den at både program og data må distribueres på nytt, hvis (når) data og/eller kode endres eller oppdateres. Da er det bedre å legge dataene for seg, f.eks. i en database, og kun distribuere programmet som behandler dataene, når det endres eller oppgraderes, f.eks. når man vil ha på plass ny funksjonalitet.
Man har nå fått en 2-lags-arkitektur, som er mye mer hensiktsmessig enn den opprinnelige 1-lags-arkitekturen. Men merk at man nå har åpnet opp for en "profesjonalisering" av det å sette opp og drifte en database som skiller seg fra den kunnskapen og kompetansen man må ha for å lage et brukergrensesnitt, dvs. programmet som håndterer og presenterer dataene i databasen for sluttbruker. Dette gjelder ikke minst når man bygger store og kompliserte databaser med f.eks. rollestyrt tilgang til dataene, og hvor man skiller mellom dem som kun kan lese data versus de som kan oppdatere data og dem som administrerer de forskjellige tilgangene til data.
Et viktig element når man gir noen tilgang til data, enten det er for lese, skrive (oppdatere) eller administrere andres tilgang til data er å være sikker på at den som aksesserer dataene i databasen (logger inn) kan autentiseres (sjekkes) mot et offentlig
register med riktige og oppdaterte personopplysninger. Denne typen data lagres ofte i firmaets eller enhetens lønns- og personalsystem. Men i det systemet ligger det mer enn bare den informasjonen som trengs for autentisering, bl.a. lønnsinformasjon, så det er sikrere å kopiere de nødvendige dataene over i et annet system eller en katalog. Og for å kunne gjenbruke disse dataene om en person på tvers av enheter og organisasjoner, bør det være ett sentralt register man kan slå opp i for å sjekke integriteten til en person. Feide er et sånt system, ID-porten et annet. Vi har nå fått lagt på et nyttig autentiseringslag som gjør at vi har kommet opp i 2,5-lagsarkitektur.
I denne 2,5-lagsarkitekturen ligger fortsatt mye av brukerstyringen og datahåndteringen, det såkalte "business or logic layer", i selve databasen som integrert kode+struktur (f.eks. SQL+tabeller). Er dette en god løsning mon tro? Nei har man funnet ut, bl.a. fordi man da låser mye av datahåndteringen og forståelsen i databasen, og er ikke åpen for endringer i teknologi eller hvis man vil bytte ut databasen, f.eks. gå fra Oracle til PostgreSQL. Man bør derfor åpne for et 3. lag mellom databasen og brukergrensesnittet.
Vi har nå en IT-arkitektur som involverer flere personer med hver sin (spiss)kompetanse, og disse kan det være formålstjenlig å organisere i et team. Et slikt team bør ha en teamleder eller en prosjektleder som kan kalle inn til møter, skrive referat og mase på de forskjellige leddene/lagene (personene), slik at infrastrukturen faktisk kan fungere som en sømløs helhet.
Nå er det vel nok kompetanse (personer) involvert i utviklingsløpet tenker man, kanskje? Ikke helt, fordi vi har glemt testerne! Uten dedikerte testere, hvis jobb det er å lage testplaner, kalle inn til testmøter og utarbeide testrapporter kommer man ikke i mål med utviklingsprosjektet.
Og hva med kravene, flere lovpålagte, om design/layout, UX (integrasjonsdesign) og UU (universell utforming)? Til disse oppgavene trenger man også personer med spisskompetanse, før teamet kan sies å være komplett.
Endelig tenker man kanskje at man er i mål. Ikke helt, for hva skjer hvis det oppstår et sikkerhetshull i ett, eller flere, av applikasjonslagene eller i databasen. Man bør få på plass en IT-sikkerhetsekspert i utviklingsteamet, slik at man unngår denne typen hendelser. Lagrer vi forresten personopplysninger i databasen? Hvis så, og databasen ligger i skyen, f.eks. på Amazons servere i USA, så er kanskje ikke det lov. Man bør av den grunn få tak i en IT-jurist som kan hjelpe til med å tolke regelverket på hvor, og hvordan, persondata lovlig kan lagres.
Vi kan nå liste opp den typen kompetanse et moderne utviklingsteam av en mellomstor IT-løsning bør ha tilgang på/ha i teamet:
- Designer
- UX-person
- UU-person
- Frontend-/Brukergrensesnittutvikler
- Mellomlagsutvikler/-arkitekt
- Databaseekspert/-drifter
- Testingeniør/-ekspert
- Prosjektleder
- IT-sikkerhetsoffiser
- IT-jusekspert
I denne forbindelse kan det være relevant å sitere fra en artikkel i Khrono nylig om kritikken av (tregheten i) utviklingen av Nasjonalt vitenarkiv (NVA):
"— Den viktigste årsaken til forsinkelsen er imidlertid tilgang på IT-utviklere, da det generelt i markedet er liten tilgang på den typen teknologikompetanse vi trenger." (Frode Arntsen, produktområdeleder, Sikt)
Av det vi har skrevet ovenfor er det ikke bare teknologikompetanse som trengs for å komme i mål med å et utviklingsprosjekt i 2022. Av og til lengter man tilbake til 1983.
