Lise Gerd Pedersen bloghoved

Hvad skal staten stille op med sine gamle IT-systemer?

Gennem de sidste 10-15 år har jeg arbejdet på adskillige – især statslige - projekter, hvor en ledelse ønskede helt at udskifte et gammelt, specialudviklet fagsystem, enten fordi det var teknisk forældet eller for at gøre sig fri fra en leverandør. Måske havde en smart sælger ovenikøbet vist dem en flot PowerPoint præsentation med en mere tidssvarende brugergrænseflade.

Mange ledelser forestiller sig, at man må kunne anskaffe et standardsystem. Det ville være fint at købe sig til et quickfix. Så hænger den fremtidige vedligeholdelse på leverandøren, og så er man sluppet af med det ansvar. Men statslige administrative kerneopgaver er ikke standard – de er ofte bundne til dansk lovgivning og danske forhold, og der kun findes én institution, der løser hver given kerneopgave.

Så prøver man måske at tilpasse et standardsystem og skaber derved blot en ny leverandørafhængighed. Nu skal man både betale løbende licenser til standardsystemet og vedligeholde tilpasningerne. Der skal være virkelig meget direkte anvendelig standardfunktionalitet i forhold til specialtilpasning, hvis det skal kunne betale sig. I politiets fejlslagne POLSAG projekt var forholdet eksempelvis helt skævt. Ovenikøbet kan standardsystemets arkitektur og funktionalitet lægge begrænsninger på, hvordan man rent teknisk kan specialudvikle oven på. Løsningerne kan blive meget lidt kønne.

Man undervurderer, hvor meget forretningsviden og specialfunktionalitet, der gennem de sidste 20-30 år er puttet ind i det gamle system … og som typisk ikke er dokumenteret. Da systemerne blev udviklet, var der nogen til at fortælle, hvordan systemet skulle virke. I dag er de medarbejdere på vej på pension, og tilbage sidder yngre medarbejdere, som er vant til, at systemerne gør nogle ting for dem, som de måske endda ikke har indsigt i hvordan. Lovbundne krav er selvfølgelig dokumenterede via lovene, men der findes meget andet knowhow indbygget i systemerne. Så det kan være svært at kravspecificere et nyt system.

Det gamle system er sandsynligvis integreret med en række af institutionens andre systemer. I værste fald er systemerne filtret håbløst ind i hinanden. Sådanne integrationer skal ”trævles op” og genskabes med det nye system – hvis det overhovedet er muligt i forhold til det valgte standardsystem. Det kan medføre, at man skal ind og ændre i de systemer, der integreres med. Man kan jo ikke udskifte det hele på en gang.

Data skal konverteres fra det gamle system ind i det nye system. Det er også en undervurderet opgave, for ofte er kvaliteten af de gamle data ikke i orden, eller også er de registreret i en anden struktur. Så data skal ”vaskes”, kvalitetssikres og omorganiseres, og det tager tid. Mere, end man skulle tro.

Alt i alt er det meget komplekst og ressourcekrævende at udskifte et gammelt IT-system med et nyt, hvad enten man nyudvikler eller tilpasser et standardsystem. Og det er – som alle andre big-bang projekter – risikabelt.

Alternativt kunne man nedbringe risikoen ved at dekomponere det gamle system og modernisere modul for modul over en længere periode. Det er heller ikke en nem opgave, blandt andet fordi styringen af det kræver en dyb faglighed, som sjældent er til stede blandt offentlige projektledere. Statslige styrelser ansætter og lytter desværre stadig hellere til akademikere (uanset fag og erfaring) end ”håndværkere”, fx datamatikere eller andre erfarne IT-folk uden papir på deres kompetencer, og staten kan slet ikke matche lønniveauet for håndværkerne.

Og hånden på hjertet – hvor mange af jer unge, veluddannede systemudviklere finder det attraktivt at blive sat til at omstrukturere og modernisere et gammelt, håbløst system? Er det ikke mere spændende at udvikle et nyt system fra bunden og at arbejde med nye teknologier? Jeg tror, at de fleste leverandører er tilbøjelige til at råde til en total udskiftning alene ud fra den betragtning.

Uanset fremgangsmåde er udskiftning af et gammelt system en utaknemmelig opgave. Brugerne vil i mange tilfælde opleve, at de får stort besvær til gengæld for meget lidt ny funktionalitet her og nu. Blot at opnå status quo i funktionalitet samtidig med, at man afvikler teknisk gæld, kan være et omfattende projekt.

Så hvad skal staten stille op med sine gamle IT-systemer? Ser jeg spøgelser? Nogen gode forslag?

Kommentarer (18)
sortSortér kommentarer
  • Ældste først
  • Nyeste først
  • Bedste først
#1 Peter Nørregaard Blogger

Gode pointer, Lise.

Kravene til systemerne har uafladeligt udviklet sig i 20-30 år. Ingen ændringer er lavet for sjov, alle har et ophæng i nye regler som alle vil have påvirket menneskeskæbner (og måske gør det stadigt) hvis de blev saneret. Kan vi håbe på mere simple forretningskrav fremadrettet? Ikke uden at klippe en hæl og hugge en tå og det er nok svært at se (eller at ønske) ske.

Gamle systemer bliver tynget af teknisk gæld, både fordi de er gamle, men også fordi udviklerne har glemt hvad de tidligere (selv eller andre) har tænkt eller vidst, da de skrev koden. Værktøjsunderstøttelsen er sikkert heller ikke fulgt med tiden. Over tid sander systemerne til.

Som en it-chef i et ministerium sagde til mig engang: "Vi har gået og omhyggeligt spændt snubletråde ud over de sidste 10 år - dem bruger vi nu tiden på at falde over"

Men der er også meget godt:

  • Indkøbte standard-systemer er lykkes på flere områder, fx inden for ESDH og økonomi. Forestil jer hvis hvert fagsystem skulle styre sagsgange, dokumenter, debit og kredit.
  • De fælles registre har også været en god hjælp. Forestil jer det offentliges it-situation uden fx registre for CPR, CVR eller BPR.
  • Staten har også løftet godt mht fællesoffentlige løsninger. Igen, forestil jer statens it-situation UDEN NemID, digital post, NemKonto osv. ov.
  • FDA har løftet meget og vil også fremover løfte kvaliteten.

Vejen frem? Der er ingen nemme løsninger.

Jeg tror ikke vi kommer uden om flere men mindre løsninger med gode afgrænsninger / bounded context, hvor vi hiver funktionalitet ud af de gamle kasser lidt efter lidt.

Der er heller ikke nogen vej uden om i fremtiden at højne arkitekt- og udvikler-håndværket, den gode faglighed, den gode kode, udviklet efter solide principper med god værktøjsunderstøttelse.

Og der er helle ikke nogen vej uden om at være bedre til at opdele designet, så standard-opgaver løftes af solide, gennemtestede og stabile standardprodukter med lang levetid, og at vi så fokuserer udviklingen på resten.

  • 11
  • 0
#2 Thomas Peter Berntsen

Kære Lise

Jeg mener ikke, at du ser spøgelser, tværtimod faktisk. Selvom karrieren netop i år strækker sig henover to årtier, tilhører jeg nok stadig det segment af yngre udviklere, du omtaler. Jeg vil i hvert fald bilde mig dette ind og forsøge mig med en kommentar. :-)

Det er min opfattelse, at den "legacy," der eksisterer i de systemer, som understøtter mange af kerneydelserne i velfærdsstaten ganske rigtigt ikke er synderligt sexet for mange udviklere. Dette på trods af, at den legacy, som systemerne indeholder, jo faktisk er særdeles værdifuld for samfundet. Hvis man betragter “legacy” som noget, der også indrammer de antagelser, forventninger, forretningsregler, og den håndtering af menneskelige og økonomiske værdier og relationer, som systemerne har været bastioner for henover generationer, så bliver den i alle henseender uundværlig.

Det er i denne forbindelse lidt paradoksalt, at hvad der nok er begrebets danske hovedoversættelse, "arv," i mange andre sammenhænge betragtes som noget positivt, men generelt bliver betragtet som noget negativt indenfor netop vores branche. Måske denne sprogbrug i sig selv siger ikke så lidt om, hvor moden denne branche og vores teknologier egentlig (ikke) er, når det kommer til stykket.

Nuvel, som leverandør kan det da også være nærliggende at ville ønske at starte på en frisk med et moderne teknologivalg og en datamigrering væk fra legacysystemet, da udsigten til i stedet at skulle udvikle en løsning, der i vid udstrækning ville augmentere/udvide en gammel platform med nye funktionaliteter eller andre snitflader kunne opleves som særdeles svær at estimere og realisere. Ja, nogle gange er opgaven jo også ligefrem bunden: Kunden vil måske gerne “undslippe” en tidligere løsning, måske som følge af en kompliceret og forladt underliggende platform, en dyr driftsituation, et ineffektivt samarbejde eller måske en kombination af alle tre.

Eller også har man som leverandør måske skabt sig et image til at kunne tiltrække sig de helt unge udviklere, hvor—hvis man skal sætte tingene på spidsen—eksempelvis udsigten til nærmest kun at skulle arbejde på greenfield-projekter samt en relativ frihed til at vælge kvartalets populære kodebibliotek til en ny brugerflade har fået en signifikant betydning, og hvor der derfor næsten ikke kan eksistere nogen positiv diskurs om “legacy”: Legacy bliver i et sådant miljø hurtigt noget, “de andre” udviklede, og som er langsomt, ineffektivt og besværligt.

Personligt er jeg af den holdning, at man som udgangspunkt bør behandle velfærdsstatens legacy-systemer med en høj grad af værdighed og ydmyghed, for de fleste systemer har på hvert deres område udgjort sin egen vigtige rygrad i at skabe, opretholde og udvikle ét af de bedste velfærdssystemer, som civilisationen vel endnu har set.

Hvis et system tilmed har fejlet i skabe den fornødne værdi for brugerne, har det som biprodukt nok formået at skabe mere indblik i en tidligere manglende forståelse for krav og ønsker, hvordan et system ikke skulle designes eller implementeres eller i, hvordan et projekt ikke skulle køres. At der så mangler en IT-havarikommission til at afdække disse læringer med, som Poul-Henning Kamp ofte fremhæver, er så en anden sag.

Der er netop, hvilket ofte debatteres her på Version2, mange udfordringer med IT-understøttelsen af lovgivning og tjenester i den offentlige forvaltning, ligesom der også ofte er problemer med de måder, som mange udbud og projekter tilrettelægges på. Det er min opfattelse, at man kunne gribe en del af arbejdet med IT-understøttelse af det offentlige an på andre måder, der i højere grad kunne komme brugere og borgere til gode, end det er tilfældet i dag.

Jeg synes i denne forbindelse, at det er positivt, at man fra centraladministrationens side ønsker at forholde sig kritisk til omkostningerne til konsulentbistand i det offentlige. Jeg er dog ikke overbevist om, at man på samme tidspunkt helt formår at gøre det tilpas nemt for softwareudvikleren i den private sektor at forestille sig, at man kunne “vælge sin mission og gøre en forskel” som softwareudvikler i det offentlige uden samtidig at løbe en stor risiko for at ende som en grå mus i hjørnet af et uhjælpeligt projekt og uden tilstrækkeligt med karrieremæssig udvikling indenfor rækkevidde.

Selvom USA som samfund på mange områder er meget forskelligt fra det danske, vil jeg alligevel fremhæve United States Digital Service (USDS) som et eksempel på etableringen af et organ, der forsøger at se kompleksiteten i øjenene og prøver at tiltrækker sig udviklere, der har mod på at prøve kræfter med den - og være meget stolte af det undervejs. Bare prøv at læse tjenestens value proposition:

We’re solving big problems

Millions of people use Federal Government services every day. Veterans apply for health care. Immigrants apply for naturalization. Too often, outdated tools and complex systems make these interactions cumbersome and frustrating.

To improve these services, USDS hires top technologists into term-limited ‘tours of civic service.’ By working alongside civil servants, they help build better tools for the people.

Kilde: https://www.usds.gov

Jeg kender mange garvede og kreative IT-folk fra mindre konsulenthuse og softwarevirksomheder, som kærer sig meget om velfærdssamfundet, men for hvem vejen til at få indflydelse og hands-on med vigtige projekter virker uoverskuelig, fx som følge af SKI-krav og krav om deltagelse i store udbud etc.

Personligt har det i flere år været min overbevisning, at der eksisterer et stort potentiale for et Danish Digital Services, hvor man som IT-professionel i en periode kunne komme “i trøjen” i vellønnet tjeneste for Velfærdsdanmark og bidrage med sine spidskompetencer til at løse nogle af de store udfordringer, som samfundet står overfor i takt med en stadig højere grad af digitalisering.

Én af tjenestens opgaver kunne eksempelvis være—på vegne af de myndigheder, der oplever et snarligt tab af det grå guld af systemfolk—at lade sig indlejre og analysere og dokumentere viden om legacy-systemer samt at udarbejde pragmatiske, ja, måske endda ligefrem snusfornuftige, løsningsmodeller for levetidsforlængelse og augmentering af systemerne med moderne API’er og brugerflader i de mange grå nuancer mellem ren udskiftning/greenfield og “ingen rører serveren”/legacy. Jo, systemer og teknologier forældes naturligvis fra tid til anden så meget, at komplette udskiftninger af platforme er nødt til at finde sted, men der eksisterer et rum af muligheder for at levetidsforlænge, inden det sker, samt for at bygge afløsersystemer, der gradvis kan tage over, og mange af de pragmatiske løsningsmodeller lever i dette rum.

Hvorfor egentlig ikke gøre det rigtig fedt (og beundringsværdigt) for os med digitale kompetencer at bidrage med vores kompetencer til vores allesammens virksomhed, som samfundet jo er? Måske endda smide et diplom, lidt sildesalat og muligheden for selv at vælge sin bærbare computer oveni? Jeg har en tro på, at en sådan konstruktion for en stund kunne få mange af karrierekonsulenterne ud af de velpolstrede stole i det private, og jeg er overbevist om, at det også kunne give en ny generation af digitale produktudviklere (herunder softwareudviklere) et helt nyt perspektiv på, hvor fantastisk IT i det offentlige egentligt er at arbejde med - og hvorfor vi kan være meget stolte af alt den legacy.

  • 19
  • 1
#3 Torben Mogensen Blogger

I stedet for at lave store monolitiske systemer, så lav en masse små programmer, der gør meget lidt hver især, men som kan kommunikere med hinanden ved brug af veldefinerede (og veldokumenterede!) protokoller eller delte filer (med veldokumenterede formater).

Så kan man skifte de enkelte programmer ud lidt efter lidt, og man kan relativt nemt tilføje ny funktionalitet.

Så længe protokoller og filformater er veldokumenterede og åbne (så en leverandør ikke kan hindre andre i at bruge dem), er man ikke bundet til en specifik leverandør.

  • 10
  • 0
#4 Mads Rasmussen

Alt i alt er det meget komplekst og ressourcekrævende at udskifte et gammelt IT-system med et nyt, hvad enten man nyudvikler eller tilpasser et standardsystem. Og det er – som alle andre big-bang projekter – risikabelt.

Alternativt kunne man nedbringe risikoen ved at dekomponere det gamle system og modernisere modul for modul over en længere periode. Det er heller ikke en nem opgave, blandt andet fordi styringen af det kræver en dyb faglighed, som sjældent er til stede blandt offentlige projektledere.

Problemet skyldes at systemer får lov til at blive legacy systemer, hvis de er i konstant udvikling, så er der slet ikke behov for at lave big bang udskiftninger, som 9/10 gange alligevel går i vasken, med milliard regning til skatteyderne som eneste produkt.

Jeg vil vædde med at det er billigere at vedligeholde og løbende modernisere et system, end at lave et helt nyt når det gamle system er forældet.

  • 4
  • 0
#5 Peter Nørregaard Blogger

Principielt er jeg enig, Mads.

I praksis kan det være en anden sag:

  • Fx når der sker et paradigmeskift. En proceduralt sprog (fx COBOL) konverteret til et objektorienteret sprog (fx Java) bliver aldrig godt.
  • Også når forretningsdomænet flytter sig (gradvist eller i større ryk) og dermed skurrer mod løsningsdomænet og dets implementering, vil vedligehold ikke være nok.

Er der også andre tilfælde, jeg ikke har fået øje på?

  • 0
  • 0
#6 Esben Wolf

Glimrende indlæg - og den vigtigste pointe er nok, at "bare" ikke findes. Alle råd om, at "man skal bare..." bør lægges til side, eftersom der ikke findes enkle løsninger på de beskrevne, komplekse problemstillinger. Man kan have en fornemmelse af, at vi har komplekse it-løsninger, fordi vi har komplekse regelværk. Og omvendt: Det har været muligt at udtænke komplekse regelværk og lade dem vokse i alle mulige retninger med podninger af undtagelser og særregler, fordi vi har it til at understøtte det. Administrationen af de statslige forhold - og alt muligt andet, herunder også i private organisationer, ville knapt kunne tænkes uden it. To mulige veje at gå kan være: 1) Iværksæt noget "reverse engineering" i tide. Få udboret og beskrevet de indbyggede (men ellers udokumenterede) forretningsregler. 2) Hvis man vil begynde forfra med et helt nyt it-system, skulle man måske overveje også at begynde helt forfra med reglerne. Man må spørge sig selv om, hvad behovet egentlig er. Skal man fokusere blindt på en ny og velkørende bil eller burde man hellere overveje sit transportbehov?

  • 5
  • 0
#7 Ditlev Petersen

Hvorfor egentlig ikke gøre det rigtig fedt (og beundringsværdigt) for os med digitale kompetencer at bidrage med vores kompetencer til vores allesammens virksomhed, som samfundet jo er? Måske endda smide et diplom, lidt sildesalat og muligheden for selv at vælge sin bærbare computer oveni?

Sådan en slags Purple Heart for systemvedligehold? Jeg tror slet ikke, at de mennesker, der er gode til den slags, vil værdsætte diplomer og sildesalat. Måske sådan mere diskret anerkendelse? Positiv omtale i stedet for ... hvad man nu kalder den slags. At overleve med den slags arbejde burde virkelig være en anbefaling. At have bestået en ildprøve.

  • 1
  • 0
#8 Klavs Klavsen

Hej Thomas,

Jeg kender mange garvede og kreative IT-folk fra mindre konsulenthuse og softwarevirksomheder, som kærer sig meget om velfærdssamfundet, men for hvem vejen til at få indflydelse og hands-on med vigtige projekter virker uoverskuelig, fx som følge af SKI-krav og krav om deltagelse i store udbud etc

Du har HELT ret.. Jeg har selv været ude i diverse offentlige institutioner og jeg er sågar blevet bedt om at vurdere hvordan et system til "alt for mange penge for alt for lidt" kunne "udskiftes".. Men da jeg var tekniker lyttede man ikke til mit svar (smid standard systemet på porten, da det faktisk slet ikke understøtter jeres forretningsbehov og byg nyt af standard komponenter. f.ex. med dokumenthåndteringssystem der burde være blevet implementeret vha. en git backend og et API - og så kan i få jeres frontend udviklere til at lave specialiserede UI's til de forskellige brugertyper i har.. Endda selvom jeg har vist dem hvor hurtigt jeg kunne få deres egne folk til at lave et sådant setup (få dage for et simpelt API i f.ex. PHP som de havde folk der kunne) - bygget på et standard framework..

Så HVIS man skulle gide den slags, SKAL der følge en aftale med om at man, hvis man kan "blive enige med 2 andre" i en given gruppe af teknikere - om at det er en "God idé" - så kan man gå videre..

Uden den slags aftaler, bliver saglig argumenter ignoreret efter forgodtbefindende - og så ender man med at skulle forsøge at redde røven på latterlige systemer der ALDRIG skulle have set dagens lys - istedet for at kunne dele fælles komponenter på tværs af systemer i hele det offentlige system (som IMHO var sådan det offentlige BURDE samarbejde på tværs - der er så mange fælles dele på tværs af systemer).

Og så burde alle disse komponenter IMHO være udvikler efter "public money, public code" princippet - det ville også hjælpe til at alle kommuner (og alle lande) - kunne drage fordel af det man laver.. Det kunne IMHO være en temmelig god u-landsbistand - at bidrage til et IT system til hospitalsvæsnet f.ex. - som også andre lande kunne anvende.

  • 8
  • 0
#9 Jørgen Elgaard Larsen

Fx når der sker et paradigmeskift. En proceduralt sprog (fx COBOL) konverteret til et objektorienteret sprog (fx Java) bliver aldrig godt. Også når forretningsdomænet flytter sig (gradvist eller i større ryk) og dermed skurrer mod løsningsdomænet og dets implementering, vil vedligehold ikke være nok.

Det kommer an på, hvad man mener med vedligehold.

Alt for ofte kaldes det for "vedligehold", når man bliver ved med at mase ny funktionalitet ned i et legacy-system, men at man ikke ændrer ved den grundlæggende struktur i systemet. Så bliver alt til lappeløsninger.

Rigtig vedligehold er omfatter en løbende refactoring, hvor også centrale dele af systemet skrives om fra bunden

  • 4
  • 0
#10 Klavs Klavsen
  • 2
  • 0
#11 Lise Gerd Pedersen Blogger

Tak, Peter. Du har ret i, at der er positive udviklinger, og dem vil jeg heller ikke underkende. Men det er kun toppen af isbjerget at implementere standardsystemer for det, der vitterligt er standardopgaver (ESDH, økonomi, timeregistrering osv.).

Min erfaring med ESDH-systemerne (som i sin tid vandt FESD-kontrakterne) og Navision Stat for år tilbage var i øvrigt, at de ikke havde API og var svære at integrere med. Sådanne systemer skal jo netop kunne ligge som services i bunden (som Klavs skriver), så man kan bygge institutionsspecifik funktionalitet ovenpå. Måske er det blevet bedre siden.

FDA og de fællesoffentlige komponenter peger alle i den rigtige retning. Det løser dog ikke problemet med den del af isbjerget, der gemmer sig under vandet. Institutionsspecifikke, gamle fagsystemer.

  • 3
  • 1
#13 Lise Gerd Pedersen Blogger

uden samtidig at løbe en stor risiko for at ende som en grå mus i hjørnet af et uhjælpeligt projekt og uden tilstrækkeligt med karrieremæssig udvikling indenfor rækkevidde

Jeg tror, at du rammer hovedet på sømmet her. Selv om man kan se samfundsværdien i at udvikle offentlige IT-systemer, kan man blive demotiveret af håbløse projekter og faglig inkompetent ledelse.

  • 9
  • 0
#14 Lise Gerd Pedersen Blogger

Ja, Torben - det var sådan, man i bagklogskabens ulideligt klare lys skulle have gjort. Men mange af systemerne er udviklet, før det var almindelig praksis. Det kan være uhyggelig svært at dekomponere et system, der er en stor portion spaghetti - og det er du nødt til, før du kan modernisere modul for modul.

  • 8
  • 0
#15 Klavs Klavsen

Sådanne systemer skal jo netop kunne ligge som services i bunden (som Klavs skriver), så man kan bygge institutionsspecifik funktionalitet ovenpå. Måske er det blevet bedre siden.

Ikke dem jeg har set.. De har fået knappet et håbløst SOAP interface ovenpå, med indlejrede XML schemer i XML schemaer og inkonsistens - der på ingen måde underbygger de faktiske behov for f.ex. validering af data mm. og samtidigt koster absurd meget, for noget der reelt ikke er vildt komplekst - med en UI alle brugerne hader (og som man ikke kan fikse fordi det er en integreret del).

  • 2
  • 0
#16 Lars Pedersen

Legacysystemet er ofte en database som alle andre programmer er afhængige af. Og hvem har så designet det vigtigste system overhovedet? Desværre er det ofte Henning og Torben, som engang i 90'erne begyndte at lave databasen. De havde lidt erfaring fra Excel og Visual Basic. De havde også kendskab til det domæne de skulle modellere, men ikke andet. F.eks. vidste de ikke at det de lavede var en model. De havde intet begreb om part-of, type-of relationer eller om generalisering og specificering af begreber. Forholdet mellem typer og instanser var ukendt for dem. Komposition og nedarvning, definition af relationer, forholdet til virkelige fænomener - alt dette var ukendt for dem. Ligeså værdien af navngivningskonventioner, symmetri i definitioner og hvorfor mange-til-mange relationer er dårlige. Men famlende sig frem fik de lavet en model, og der kunne nu laves programmer oven på den.

Senere kom der jo nye programmører til, som godt kunne se at det ikke var så godt. Men fra starten fik de at vide, at det kunne ikke laves om. Torben og Henning havde forladt firmaet men der var jo skrevet programmer som man risikerede ikke ville virke længere.

I stedet blev programmørerne enige om ikke at ændre noget, men kun lave workarounds. De gav hinanden ros, når de fandt løsninger der var smarte, men ikke gav mening, når bare man undgik at lave noget om. Til sidst kunne programmørerne ikke længere finde ud af at designe - de kunne kun lave ulogiske workarounds. Man afskaffede de sidste definitioner i modellen og fik en stor gang nonsens. Dokumentation blev også opgivet, for det risikerede at forhindre at man kunne lave workarounds når man ikke måtte bruge tabellerne til hvad som helst.

  • 3
  • 2
#17 Jørgen A Thomsen

Man må spørge sig selv om, hvad behovet egentlig er. Skal man fokusere blindt på en ny og velkørende bil eller burde man hellere overveje sit transportbehov?

Som talt ud af mit hjerte. I mit lange IT-liv har jeg utallige gange set, at 'vi skal have et nyt system, men det skal kunne nøjagtig det samme som det gamle på den samme måde'. Alle tanker om revurdering af den underliggende forretningsgang afvises på forhånd. Det nye system bliver også derefter: komplekst og usammenhængende.

  • 7
  • 0
Log ind eller Opret konto for at kommentere