Skræddersyede applikationer: Indes som udvikler og hostingpartner
I vores tidligere opslag om automatiseret brugeroprettelse i hybride AD-miljøer beskrev vi, hvordan en afgrænset, specialbygget løsning kan erstatte behovet for et større HR-system. Samme tilgang bruger vi i stigende grad til andre typer interne værktøjer: kalender- og bookingsystemer, ressourcestyring, godkendelsesflows og integrationer mellem systemer, der ikke taler sammen af sig selv. Her er et kig på, hvordan vi griber det an teknisk.
Udvikling med AI som værktøj
Vi bruger AI-assisteret udvikling til at generere den første version af kode, datamodeller og brugerflader. Det forkorter vejen fra kravspecifikation til en kørende prototype betydeligt, så kunden kan teste på noget konkret tidligt i forløbet.
Den genererede kode behandles som ethvert andet udkast: Den gennemgås, refaktoreres og testes, før den går i produktion. Særligt autentificering, adgangsstyring og håndtering af data gennemgås manuelt, da det er her, fejl har størst konsekvens. Koden versionsstyres i Git, og deployment sker via CI/CD-pipelines, så ændringer er sporbare og kan rulles tilbage.
Valg af hostingplatform
Platformen vælges ud fra opgavens karakter, ikke omvendt. Her er et par eksempler:
Azure Function Apps kan bruges vi til event- og tidsdrevne opgaver: en timer trigger, der synkroniserer data hver nat, en HTTP trigger, der modtager webhooks, eller en queue trigger, der behandler opgaver asynkront. Funktionerne kører serverless, skalerer automatisk og afregnes efter forbrug, hvilket gør dem velegnede til automatiseringer med svingende eller lav belastning.
Docker-containere kan bruges til webapplikationer og API'er, hvor vi ønsker et ensartet runtime-miljø fra udvikling til produktion. En container kan køre i Azure, men også på kundens egen infrastruktur, hvis data af compliance- eller latensmæssige årsager skal blive on-prem.
Kubernetes er relevant, når en løsning består af flere services, skal have høj tilgængelighed eller skal kunne skalere horisontalt under belastning. For mindre løsninger er det ofte overkill, og så vælger vi den simplere vej.
Integration og sikkerhed
De fleste løsninger skal passe ind i et eksisterende Microsoft-miljø. Typisk betyder det:
Login via Entra ID med app registrations og single sign-on, så brugerne ikke får endnu et sæt adgangskoder, og adgang styres via eksisterende grupper
Managed identities mellem Azure-ressourcer, så der ikke ligger credentials i konfiguration eller kode
Azure Key Vault til de hemmeligheder, der ikke kan undgås, fx API-nøgler til tredjepartssystemer
Microsoft Graph, SharePoint, Dataverse og Dynamics 365 som datakilder og -mål, når løsningen skal læse fra eller skrive til eksisterende systemer
Application Insights til logning og overvågning, så fejl opdages, før brugerne melder dem
I hybride setups med on-prem AD eller lokale systemer bruger vi fx hybrid connections eller en lokal agent, så cloud-delen kan kommunikere med on-prem ressourcer uden at åbne indgående porte i firewallen.
Hvorfor skræddersyet?
Et standardsystem dækker ofte 80 % af behovet og kræver tilpasning af processerne til de sidste 20 %. En specialbygget løsning dækker præcis den proces, der skal understøttes, og intet andet. Det giver en mindre kodebase, færre afhængigheder og en løsning, der er lettere at forstå og vedligeholde. Til gengæld kræver den, at kravene er klart afgrænsede, og det er derfor, vi bruger tid på at forstå processen, før vi bygger.
Har I en proces eller forretningsbehov, som I overvejer at automatisere eller bygge et værktøj til, er I velkomne til at kontakte Indes for en teknisk snak om mulighederne.
