5 faldgruber ved platform engineering
Rigtigt grebet an kan platform engineering reducere kognitiv load, forkorte time-to-market og skabe bedre flow i hverdagen for udviklere. Forkert grebet an kan det blive endnu et lag kompleksitet, der flytter problemerne i stedet for at løse dem.
Ved alle større tekniske og organisatoriske initiativer er der faldgruber, som kan underminere værdien, hvis man ikke er opmærksom. Vi har spurgt Martin Schmidt Daugaard, der er Cloud Architect, hvad man skal være opmærksom på, hvis man arbejder med eller overvejer platform engineering. Læs med og blive klogere på, hvor du ikke ønsker at bevæge dig hen.
- At bygge en platform for platformens skyld
En af de mest grundlæggende faldgruber er at gøre platformen til målet i sig selv. Når fokus bliver at “bygge en platform”, frem for at løse konkrete problemer for forretningen og udviklerne, risikerer man at ende med et teknisk flot, men forretningsmæssigt irrelevant produkt.
”Platform engineering er ikke et prestigeprojekt eller et arkitektonisk monument. Det er et middel til at skabe hurtigere, mere stabil og mindre friktionsfyldt udvikling,”
Hvis udviklernes hverdag ikke bliver mærkbart bedre, eller forretningen ikke bevæger sig hurtigere og mere sikkert, er platformen i praksis ikke lykkedes – uanset hvor elegant den er bygget.
- Ivory tower‑beslutninger og manglende brugerinddragelse
En anden klassisk faldgrube opstår, når platformteams isolerer sig og træffer beslutninger uden tæt dialog med dem, der skal bruge platformen. Hvis arkitektur, værktøjer og processer defineres ud fra, hvad der er teknisk fordelagtigt, frem for hvad der løser reelle pains, opstår der hurtigt afstand mellem platform- og udviklingsteams.
“Vi skal lytte til dem, der bruger platformen. Udviklerne skal ses som en kunde, og det er deres udfordringer med fx kognitive load og manglende flow, vi skal prøve at løse,”
Det betyder, at man ikke blot skal lytte til deres løsningsforslag, men især forstå de problemer, de møder i hverdagen. Platforme, der designes fra et elfenbenstårn, risikerer at være rigtige på papiret, men forkerte i praksis.
- Overstandardisering og en for rigid “paved road”
Standardisering er en vigtig del af platform engineering, men den bliver en faldgrube, når den bliver for rigid. En paved road, der er obligatorisk i alle situationer, efterlader ikke plads til særlige behov, eksperimenter eller forretningskritiske afvigelser.
Hvis teams med legitime krav bliver tvunget ind i løsninger, der ikke passer til deres kontekst, vil de enten blive bremset i deres leverancer eller finde uofficielle veje udenom platformen. En god platform tillader afvigelser, men gør konsekvenser og ansvar tydelige. Alternativet er snowflake‑løsninger og tab af tillid til platformen.
”Vi er alle sammen skabt dovne og vil følge den vej, hvor vi bruger mindst mulig energi. Det er derfor, vi følger skovstierne i stedet for at gå ind gennem træerne. Derfor skal vi gøre det nemt for udviklerne og skabe en vej, der er nemmere at følge end at træde udenfor,”
- Tool‑fetichisme og “shiny object syndrome”
Det skinner og er flot. Derfor må det være godt. Nogle gange lader vi værktøjer og teknologier styre retningen i ren begejstring over teknologien. Når platformbeslutninger træffes, fordi et værktøj er populært, nyt eller “lækkert”, risikerer man at skabe unødvendig kompleksitet.
Teknologier som Kubernetes, avancerede cloudservices eller komplekse CI/CD-opsætninger kan være de rigtige valg, men kun i den rette kontekst. Platform engineering bør tage udgangspunkt i friktion, skala og organisatoriske behov, ikke i trends. Ellers ender man med at løse problemer, man endnu ikke har.
- At automatisere dårlige processer
Automatisering er ofte en central del af platform engineering, men den bliver en faldgrube, hvis man blot automatiserer eksisterende arbejdsgange uden at gentænke dem. At “sætte strøm til” en uhensigtsmæssig proces gør den ikke bedre, men blot hurtigere og sværere at ændre senere.
”Det er afgørende at huske, at platform engineering er arkitekturarbejde frem for automation. Det handler ikke bare om at sætte strøm til eksisterende processer, men at gentænke vores arbejdsgange,”
Uden arkitektoniske overvejelser og klar adskillelse af ansvar risikerer man at skabe tæt koblede systemer, platform drag og øget driftsrisiko. Platform engineering kræver, at du stopper op og spørger: Er det her en proces, vi bør understøtte – eller en, vi bør gentænke, eller måske endda helt fjerne?
Platforme lykkes ikke på teknologi.
De lykkes på adfærd.
De fem faldgruber, som Martin peger på, har noget helt centralt til fælles: Platform engineering fejler sjældent, fordi teknologien ikke virker. Det fejler, fordi fokus flytter sig væk fra det egentlige formål:
- Når platformen bliver vigtigere end den værdi, den skal skabe.
- Når vi glemmer at tage udvikleren alvorligt som kunde.
- Når standarder bliver vigtigere end mennesker.
- Når værktøjer vælges før løsninger.
- Når vi automatiserer det eksisterende i stedet for at forbedre det.
En god platform kan gøre en kæmpe forskel for både udviklere og organisation. Den gør det nemmere at gøre det rigtige – at følge vejen fremfor at fare vild i skoven. Og det er værd at huske på, fastslår Martin:
“Målet er ikke at bygge en platform. Målet er at hjælpe udviklere med at levere: hurtigere, mere stabilt og med mindre friktion. I det øjeblik platformen begynder at stå i vejen, eller bliver bygget for sin egen skyld, har vi mistet retningen.”