Vi får frågan ofta — i upphandlingar, på intervjuer och i kafferaster: ”Är inte Delivery Engineering bara ett nytt namn på DevOps?” Korta svaret är nej. Längre svaret är värt fem minuter.
DevOps är ett arbetssätt
DevOps växte fram som en motreaktion på den klassiska väggen mellan utvecklare som skriver koden och operations som driftar den. Idén är enkel: samma team som bygger funktionen ska också ansvara för att den funkar i produktion. ”You build it, you run it.” Det är inte en roll — det är ett sätt att organisera ansvar.
Praktiskt innebär det att utvecklingsteam äger automation, observability, on-call och infrastrukturen kring sin egen tjänst. Inte hela molnplattformen — bara sin del av den. Och fördelningen mellan ”sin del” och ”någon annans del” är ett av de viktigaste designbesluten en organisation gör.
Delivery Engineering är en disciplin
Delivery Engineering handlar om vägen från commit till produktion. Pipelines, byggsystem, artefakt-hantering, release-strategier, feature flags, progressive delivery. Det är inte en filosofi — det är ett hantverk. Och det är ofta ett eget team som bygger plattformen som låter alla andra team leverera snabbt och säkert.
Tänk på det så här: om DevOps säger ”team X äger sin tjänst hela vägen ut”, så säger Delivery Engineering ”här är spåret som tar dig dit utan att du behöver uppfinna det själv”.
Var överlappar de?
I praktiken: CI/CD. Båda disciplinerna investerar tungt i pipelines, men av olika skäl. Ett DevOps-team bygger pipelines för sin egen tjänst. Ett Delivery Engineering-team bygger pipelines som plattform — så att 50 andra team inte behöver bygga sin egen variant.
Det är där förvirringen kommer ifrån. Verktygen är samma. Syftet är olika.
När behöver man vad?
Liten organisation, ett fåtal team — då räcker DevOps-tankesättet. Varje team äger sin grej från ände till ände och bygger precis så mycket pipeline som de själva behöver.
När ni växer och hamnar med 10+ team som alla löser samma deployment-problem på 10 olika sätt, då börjar Delivery Engineering bli en investering som betalar sig snabbt. Inte för att teamen inte klarar sig själva — utan för att det är slöseri att alla uppfinner samma hjul, och för att en gemensam plattform gör att de tjatigaste delarna av leveransen blir någon annans problem.
Vårt korta svar
DevOps berättar hur ni delar ansvar. Delivery Engineering berättar hur ni delar verktygen. Båda behövs — men inte alltid lika mycket samtidigt.
Om någon påstår att det är samma sak — fråga vad de menar med båda. Ofta menar de bara CI/CD.