Skræddersyet applikationsudvikling: byg kun det, der adskiller jer

Skræddersyet applikationsudvikling: byg kun det, der adskiller jer

Skræddersyet applikationsudvikling bliver typisk valgt, når standardsoftware næsten passer, men ikke helt. Det er en god grund — og også den, der oftest fører til et system, ingen tør røre fem år senere. Forskellen ligger i, hvad I vælger at bygge selv, og hvad I lader andre vedligeholde.

Hovedpointerne

  • Byg kun det, der adskiller jer. Alt andet bør købes eller konfigureres.
  • En intern applikation lever i ti år. Vælg teknologi efter, hvem I kan bemande med om fem.
  • Regn med at halvdelen af arbejdet er integrationer til systemer, I ikke selv ejer.
  • Rettigheder og roller er sværere end de ser ud. Afklar dem før datamodellen låses.
  • Uden dokumentation og tests bliver applikationen dyr at ændre længe før den bliver gammel.
  • Start med den proces, der gør mest ondt i dag — ikke med den mest komplette løsning.

Hvornår skræddersyet giver mening

Tre situationer retfærdiggør at bygge selv. Processen er jeres konkurrencefordel, og standardsoftware tvinger jer til at arbejde som alle andre. Eller I betaler for licenser til femten brugere, men bruger tre procent af systemet. Eller ingen leverandør dækker kombinationen af jeres krav, og I ender alligevel med at lime tre systemer sammen.

Omvendt: løn, økonomi, e-mail og dokumenthåndtering skal I ikke bygge. Der findes velfungerende produkter, og jeres version bliver aldrig bedre, kun jeres egen.

Byg kun kernen

Den mest holdbare arkitektur, vi ser i praksis, er en lille skræddersyet kerne omgivet af købte dele. Applikationen indeholder den logik, der er jeres, og henter alt andet fra systemer, der allerede findes: brugerstyring fra jeres identitetssystem, økonomi fra ERP, filer fra et dokumentarkiv.

Det holder kodebasen lille nok til at kunne forstås, og det betyder, at en ny udvikler kan sætte sig ind i den på dage frem for måneder.

Teknologivalget handler om bemanding

Et internt system lever typisk længere end de udviklere, der bygger det. Det afgørende spørgsmål er derfor ikke, hvad der er bedst i dag, men hvem I kan ansætte eller hyre om fem år — og om den teknologi stadig får sikkerhedsopdateringer.

Vælg almindelige rammeværk og undgå eksotiske afhængigheder. Kedelig teknologi er billigere at eje.

Rettigheder, roller og revision

Næsten alle interne applikationer ender med at skulle svare på: hvem må se hvad, hvem ændrede den post, og hvorfor. Det er langt lettere at bygge ind i datamodellen fra start end at tilføje bagefter.

Afklar tre ting inden kodning: rollerne og hvad de må, om nogen skal se data på tværs af afdelinger, og om I skal kunne genskabe historikken for en post. Skal datalaget kunne bære det, hører det under databaseudvikling.

Sådan starter I uden at binde jer

Vælg den ene proces, der koster mest tid i dag, og byg kun den. Sæt den i drift hos de mennesker, der udfører arbejdet, og mål på, om det faktisk går hurtigere. Udvid derefter.

Det er formålet med MVP-udvikling: at finde ud af, hvad applikationen skal være, mens det stadig er billigt at ændre mening. Skal løsningen køre på skrivebordet frem for i browseren, ser vi på desktopudvikling i stedet.

Sådan arbejder vi

Vi bygger forretningsapplikationer som en del af vores applikationsudviklingstjenester, oftest med et dedikeret udviklingsteam, så viden om systemet bliver hos de samme mennesker. Se softwareudviklingstjenester for de øvrige områder.

Ofte stillede spørgsmål

Hvad koster en intern forretningsapplikation?

En afgrænset applikation til én proces med to integrationer ligger typisk på tre til fem måneders udvikling. Prisen drives af antallet af integrationer og af, hvor mange særregler processen indeholder.

Skal vi bygge web eller desktop?

Web, medmindre applikationen skal arbejde offline, tale med lokal hardware eller håndtere meget store filer lokalt. Så er desktop det rigtige.

Hvad sker der, hvis udvikleren forsvinder?

Det afhænger udelukkende af, hvad der er skrevet ned. Kræv opsætningsvejledning, arkitekturnoter og tests fra start. Det er billigere end den viden, I ellers køber tilbage senere.

Kan vi bruge low-code i stedet?

Til formularer og arbejdsgange ofte ja. Til en applikation med egen logik, mange brugere og lang levetid løber I typisk ind i platformens grænser — og så er migreringen dyrere end at have bygget det rigtigt.

Sådan kommer I videre

Byg kun det, der adskiller jer, køb resten, og vælg teknologi efter hvem I kan bemande med om fem år. Start med én proces, mål effekten, og udvid derfra.

Skal vi se på jeres proces? Skriv til os eller book et møde.

Camilla Frederiksen
Camilla Frederiksen

Camilla skriver om skræddersyet softwareudvikling: hvornår det giver mening at bygge selv, hvordan man afgrænser opgaven, så man kun bygger det, der adskiller en, og hvordan systemet forbliver til at vedligeholde efter lanceringen.