Lær at leve med knopskydende it-systemer

Engang imellem bør man stoppe og se med friske øjne på de gamle it-systemer, der vokser organisk over tid.

Det er nærmest uundgåeligt, at egenudviklede it-systemer laver små knopskydninger og over tid får flere features, der bryder det scope, som oprindeligt var tænkt for systemet.

Det er der egentlig ikke noget galt i, men man bør engang imellem stoppe op og finde ud af, om systemet er det mest velegnede til at opfylde forretningens behov, eller om eksempelvis et standardsystem vil være billigere og bedre.

Det er vurderingen fra Peter Nørregaard, Expert Director hos Devoteam, der jævnligt rådgiver virksomheder om, hvordan it-arkitektur bedst kan understøtte forretningsmæssige behov.

»Når forretningen ønsker at vide lidt mere om kunden, er der ingen grund til at gå ud at bruge flere hundredtusinder eller måske et par millioner kroner på at købe et CRM-system,« forklarer Nørregaard og fortsætter:

»I stedet registrerer man bare lige hvornår man har talt med kunden og laver et lille kommentarfelt i et eksisterende system. Det vokser stille og roligt der fra. Det er mere reglen end undtagelsen, at vi ser den slags knopskydning,« siger Peter Nørregaard.

Fra kundekartotek til CRM

I en udvikling med mange små trin vokser det eksisterende simple kundekartotek nærmest organisk til et omfattende CRM-system.

Afhængig af hvor designbevidste og velstrukturerede udviklerne er, kan de mange nye tilføjelser og features betyde, at den tekniske gæld i systemet vokser.

»Når man sidder midt i en udviklingsproces kan det være svært at se, at det måske vil være fornuftigt at skifte til et standard CRM-system, men hvis man laver det skifte, vil man fjerne meget udviklings- og vedligeholdelsesbyrde fra it-afdelingen, så den i stedet for kan koncentrere sig om at lave skræddersyet understøttelse af de områder, hvor virksomheden virkelig skal kunne noget særligt,« foreslår Peter Nørregaard.

Hvordan kan man undgå at spilde tid på udvikling af noget som standardsystemer understøtter bedre?

»Jamen, jeg ved ikke, om man skal undgå det. Prøv at forestille dig det modsatte: hver eneste gang der identificeres et nyt behov, så køber man et nyt standardsystem til at håndtere det. Det betyder, at it-afdelingen skal have kritisk viden om måske 20 specialiserede standardsystemer. Her er man nødt til at overveje, om it-afdelingen nu også har kapaciteten til at beherske og udnytte de forskellige standardsystemer,« svarer Peter Nørregaard.

»Ved at udvikle knopskydningen løbende holdes forretningsunderstøttelsen ajour og selvom de små gradvise ændringer øger den tekniske gæld, så kan det være en udmærket vej at gå, når man gør det med åbne øjne.«

Kasseeftersyn af it-miljø

Med den strategi er der derfor behov for engang imellem stoppe op og lave en revision af it-systemerne og vurdere, om de systemer man har, reelt giver nok værdi for pengene.

»Det afhænger af virksomheden, men måske hvert tredje eller hvert femte år kan man lave et slags kasseeftersyn af it-miljøet. Det kan også være i forbindelse med større ændringer,« foreslår Peter Nørregaard.

Han er også blogger for Version2 og skrev for et stykke tid siden en anbefalelsesværdig blog om faldgruberne ved teknisk gæld.

Her hedder det blandt andet:

»En virksomhed kan få en ekstern part til at lave review af systemerne (mine kollegaer har lavet et par stykker) og en vurdering af det vedligeholdelsesmæssige efterslæb på systemet. Det sker ofte når man står overfor at lave større investeringer i systemet, skifte til et nyt eller blot vil have, at systemerne er supporterede hele vejen ned igennem stakken. Her, hvor der er konkrete scenarier at vurdere op imod, giver det (teknisk gæld, red.) mening. En generel vurdering af gældens størrelse vil derimod være noget usikker.«

Det rejser umiddelbart spørgsmålet om, hvorfor en ekstern part skulle være bedre til at identificere et vedligeholdelsesmæssigt efterslæb end dem, der sidder med det til dagligt.

Friske øjne med holistisk syn på systemer

»Arkitekten eller udviklerne er selvfølgelig dem, der bedst ved, hvor der er shortcuts og quickfix i koden. Dem, der har siddet med koden, kender historikken bag, men der kan være brug for at der kommer nogle eksterne ind over og validerer systemets overordnede egnethed og om det eksempelvis er tid til at udskifte med standardsystemer,« siger Peter Nørregaard.

Han skelner mellem den let identificerbare tekniske gæld som eksempelvis kan være, at udvikleren i en arkitektur med et data access-lag vælger at skyde genvej til databasen ved at anvende SQL-kald direkte fra den nye kode i stedet for at anvende data access-laget, og så den mere skjulte tekniske gæld, hvor koden ikke leverer den oprindeligt tiltænkte forretningsmæssige understøttelse godt nok.

»Nogle gældsposter er nemme at finde, mens det er sværere at finde større gældsposter som kode der ikke opfylder intentionen med hvad koden egentlig skulle hjælpe forretningen med,« siger Peter Nørregaard.

Her er det nødvendigt med et mere overordnet syn, hvor der også kigges på, hvordan systemet understøtter arbejdsprocesser.

»Det kan være arbejdsprocesser, hvor en kundeservicemedarbejder skal ind i to systemer for at sætte noget op. Det kan være, at man ikke har fået den slags indtænkt i systemet.«

Tunnelsyn trods agilitet

Trods de seneste års megen fokus på agil udvikling med løbende feedback på nye features kan udviklere stadig have en tendens til at fortabe sig i tekniske detaljer, hvor den overordnede hensigt med en ny feature måske glemmes.

»Man risikerer kun at kigge på træerne i stedet for at se på skoven,« som Peter Nørregaard formulerer det.

Et tilsvarende tunnelsyn kan også komme til udtryk, når det gælder en virksomheds it-arkitektur.

»Hvis man har en godt sammentømret og erfaren gruppe, der har udviklet et system, så ser de systemet som hammeren, der kan løse mange problemer. De ved måske ikke, om det de har lavet er unikt for virksomheden, eller om det er noget, som kan løses med en commodity, et standardsystem eller SaaS. Vores udgangspunkt er, at identificere hvor virksomheden reelt har brug for at være unik, og hvor virksomheden kan anvende noget som er standard og billigt,« siger Peter Nørregaard.

Er en opdateret kravspecifikation en god ide?

Som Version2 tidligere har beskrevet, kan det ofte være et problem at vide, hvad et ældre system indeholder af forretningslogik, hvilket er noget Peter Nørregaard kan nikke genkendende til.

»Problemet med gammel kode er, at der ikke er nogen, der har det samlede overblik over hvad systemet kan. Man har måske dokumenteret nogle moduler og nogle skærmbilleder, men hvad systemet kan er ikke blevet vedligeholdt i en samlet kravspecifikation, hvis der overhovedet har været en sådan,« siger Peter Nørregaard.

For at få det overblik kan man i forbindelse med et kasseeftersyn af it-miljøet udarbejde en kravspecifikation baseret på forretningens behov.

»Her skal man se på forretnings-kravene og afdække forretningsprocesserne i en mini-kravspecifikation. Så kan man finde ud af, om det givne område kan understøttes med nogle standardsystemer,« anbefaler Peter Nørregaard.

Version2's søstermedie DigiTech har tidligere interviewet ITU-professor Søren Lauesen om problemorienterede kravspecifikationer, hvor han blandt andet anbefaler, at kravspecifikationer løbende opdateres efterhånden som systemet ændres, så man altid har en opdateret beskrivelse af et system.

»Det lyder jo som en god ide, men samtidig er det også en løbende opgave og udgift som virksomheden har for at nedbringe risikoen om nogle år, hvor man eventuelt skal skifte platform. Der er ikke mange der har tid og råd til den øvelse. Dokumentationen skal naturligvis være på plads, men hvis jeg skal være lidt kæk, så er jeg ikke sikker på at en opdateret kravspecifikation er nødvendig,« siger Peter Nørregaard, der da heller ikke har oplevet kunder, der løbende opdaterer kravspecifikationen efterhånden som systemerne ændres og udbygges.

Tips og korrekturforslag til denne historie sendes til tip@version2.dk
Følg forløbet
Kommentarer (4)
sortSortér kommentarer
  • Ældste først
  • Nyeste først
  • Bedste først
Lise Gerd Pedersen Blogger

Artiklen indeholder efter min mening rigtig mange fornuftige synspunkter. Jeg vil gerne fremhæve dette:

Vores udgangspunkt er, at identificere hvor virksomheden reelt har brug for at være unik, og hvor virksomheden kan anvende noget som er standard og billigt

En ofte forekommende misforståelse på ledelsesniveau er, at man kan købe et standardsystem til noget, som absolut ikke er standard. Det kan blive en meget dyrere og dårligere løsning end selv at udvikle oven på standardkomponenter.

Hans Nielsen

"En ofte forekommende misforståelse på ledelsesniveau er, at man kan købe et standardsystem til noget, som absolut ikke er standard. Det kan blive en meget dyrere og dårligere løsning end selv at udvikle oven på standardkomponenter."

Der er jeg delvis ening og meget ening i.
Men hvis man starter med at bruge FOSS og til de tilhørende OS, Database og sprog.
Samtidigt med at man sikkert sig ejerskabet over koden, kræve open og fri kilde kolde,
fri for patenter med veldokumentere kode og krav.

Så vil et sådan system blive billigere på ande lange banne, samt være meget lættere at udvikle og vedligholde.
Hvis vi snakker meget store speciale systemer, så er det også langt billigere og mere sikkert, at sikker sig at de mennesker som vedligeholder systemet er ansat og betalt direkte. Istedet for at bruge et meget fordyrende extra lag, som koster penge. Som et privat firma.

Hvis de firmaer som leveret til staten, virkeligt levere et færdigt produkt til til tiden, og pris.
Så skulle man da vælge dem.
Men hvis de alligevel vælger at opfinde alt fra bunde, og ikke levere til tid og pris.
Så kan det offenlige lige så godt selv lave lort i det, det bliver sikkert billigere.

Denny Christensen

Det væsentligste er stadig at kunne levere de kapabiliteter/services der efterspørges, og der kan en knopskydning på et eksisterende system være fint - og det hele kan udstilles pænt til omverdenen.

Stadig mener jeg at det der implementeres skal være 'familiært' i forhold til det system det implementeres i og at den teknologiske platform ikke giver unødige problemer ved anvendelser.

»Ved at udvikle knopskydningen løbende holdes forretningsunderstøttelsen ajour og selvom de små gradvise ændringer øger den tekniske gæld, så kan det være en udmærket vej at gå, når man gør det med åbne øjne.«

Mjoeh ... dem der har åbne øjne skal så inkludere de relevante faggrupper og ikke dem der ikke skal sikre konsistens på længere sigt :-) så sund fornuft er stadig vigtigt.

Teknisk gæld kan man med fordel opbygge sammen med en vedtaget plan for tiltag der skal implementere en løsning der fjerner den tekniske gæld. Ønsker man ikke det har man pr definition ikke teknisk gæld.

Simon Rigét

Ingen større virksomhedder er ens, og det er deres IT behov heller ikke. vist kan man bruge standardsystemer mange steder. Men det er blevet et forslidt mantra, i de øvre ledelseslag der er hævet over IT kompetencer.

Virksomhedderne er ikke trænet i at tænke deling og open source. Hvis de var det, og gjorde en indsats for at finde smarabejdspartnere, tror jeg at de kunne komme langt, med skræddersyede moduler, samtidigt med at de kunne dele meget af vedligeholdelsesbyrden med andre.

Log ind eller Opret konto for at kommentere