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.
...men det er dyrt at lave god journalistik. Derfor beder vi dig overveje at tegne abonnement på Version2.
Digitaliseringen buldrer derudaf, og it-folkene tegner fremtidens Danmark. Derfor er det vigtigere end nogensinde med et kvalificeret bud på, hvordan it bedst kan være med til at udvikle det danske samfund og erhvervsliv.
Og der har aldrig været mere akut brug for en kritisk vagthund, der råber op, når der tages forkerte it-beslutninger.
Den rolle har Version2 indtaget siden 2006 - og det bliver vi ved med.
