Blog

Så här skulle jag arbeta med Platform Engineering om jag var CTO

SEP 28, 2023

Platform Engineering har ekat i teknikvärlden ett tag nu, men vad är det egentligen?

Dan Grøndahl Glavind

Dan is a seasoned DevOps Consultant at Eficode with 10+ years of experience working with software development. Dan has helped a wide variety of Danish companies become better at delivering software and is currently focussing on helping teams and organizations build platform engineering capabilities.

Det är en disciplin i skärningspunkten mellan teknik, verksamhet och människor. Den handlar om att skapa en smidig Developer Experience (DevX) som främjar produktivitet, innovation och tillväxt. Den optimerar, gör processerna för mjukvaruleverans tillförlitliga och säkerställer deras motståndskraft – ryggraden i tekniska infrastrukturer. Men hur navigerar en chief technology officer (CTO) i all denna komplexitet? Jag besvarar den frågan och fler i den första delen av min bloggserie i sju delar, där jag som DevOps-konsult gestaltar en CTO.

”Om jag vore CTO skulle jag ta mig an Platform Engineering så här” av Dan Grøndahl Glavind. Läs bloggserien i sju delar:Del 1: Vikten av stöd från ledningenDel 2: Att etablera en organisation för Platform EngineeringDel 3: Så kan plattformsteam nå ambitiösa målDel 4: Ett mantra för framgångsrika plattformsteamDel 5: Att navigera ett produktmindset i plattformsteamDel 6: Att mäta framgång bortom siffrorna i plattformsteamDel 7: Att kommunicera framgångar och utmaningar i plattformsteam

Del 1: Vikten av stöd från ledningen

Att anamma Platform Engineering är inte bara ett tekniskt skifte, utan ett paradigmskifte. För en CTO handlar det inte bara om ”hur”, utan också om ”varför”. För att driva en så betydande transformation bör du först fundera över:

  • Vilka är de bakomliggande målen?

  • Har ni nått en punkt där det inte bara är genomförbart, utan också fördelaktigt, att omvandla er utvecklingsverksamhet till plattformar?

  • Har ni den kapacitet som krävs, eller finns det områden ni kan stärka?

Genom att hantera dessa frågor kan du lägga upp en handlingsplan som stämmer överens med era mål. Här är några vanliga mål i branschen.

Jag vill korta tiden till värde

Inom mjukvaruutveckling prioriteras ofta ”time to value” redan från början. Det handlar i grunden om tiden mellan att en idé initieras och att du ser konkreta resultat. Men det handlar inte bara om att snabbt driftsätta mjukvara, utan också om att förstå den bredare påverkan ny mjukvara har på verksamheten och användarna.

Tänk dig att lansera en mjukvarulösning som direkt förändrar användarupplevelsen (UX) och leder verksamheten mot tillväxt. Det vore som att så ett frö och se det gro direkt.

Feedback är avgörande. Mjukvara behöver användarfeedback på samma sätt som en planta behöver solljus, vatten och omsorg. Samla in den så snart som möjligt för att förfina mjukvaran och göra den mer effektiv. Det är den kontinuerliga cykeln av att bygga, mäta och lära som skapar värde, där en robust plattform fungerar som katalysator.

Den tar hand om det tunga arbetet och låter utvecklarna fokusera på det de gör bäst – att koda och innovera. Genom att skydda dem från infrastrukturhanteringens komplexa detaljer kan de fokusera på att skapa de funktioner som är viktigast för användarna.

Tänk på en kock som arbetar i ett toppmodernt kök. Med rätt verktyg och miljö kan fokus ligga på att skapa aptitretande rätter, inte på utrustning som krånglar eller ingredienser som saknas. Inom mjukvaruutveckling är plattformen köket och utvecklarna kockarna. De skapar lösningar som tillfredsställer användarna och hjälper verksamheten att lyckas.

Jag vill koppla verksamhet till kostnader

I moderna IT-miljöer har jag sett att IT-ledare ofta fokuserar på kostnadsbesparingar. Det kan jämföras med att dra ur kontakten till servrar för att spara på elräkningen – det kan spara pengar, men är inte praktiskt.

Här blir en enhetlig plattform avgörande. Den fungerar som en katalysator för strategiska metoder för ekonomistyrning, exempelvis FinOps, genom att förenkla integreringen av metadata – taggar och etiketter kopplade till kostnadsställen eller affärsenheter – i resurser. Du kan enkelt lägga till dessa identifierare genom standardiserade driftsättningsprocesser eller ”golden paths” och göra dem obligatoriska utan flera lager av byråkrati.

Genom att centralisera den här funktionen i en plattform främjar du kostnadstransparens och ger teamen rätt förutsättningar. Med bättre insyn kan teamen se om utgifterna stämmer överens med det övergripande affärsvärdet.

I slutändan främjar det en kultur där IT-investeringar handlar lika mycket om att skapa värde som om att hålla kostnaderna under kontroll.

Jag vill investera i Developer Experience (DevX) för att attrahera talanger

I teknikvärlden råder hård konkurrens om talanger, och i takt med att AI fortsätter att utvecklas är skickliga utvecklare mer eftertraktade än någonsin. Men hur gör du ditt företag till arbetsplatsen utvecklare drömmer om?

I centrum för en utvecklares beslutsprocess står mjukvaran de arbetar med. En robust och modern teknikstack i en jobbannons fungerar som en fyr som signalerar företagets driv för innovation. Den visar utvecklarna att de kan göra skillnad.

För en utvecklare som går från ett jobb där det tar månader innan ändringar når produktion till ett där det tar dagar är det som att byta häst och vagn mot en sportbil!

Det betyder inte att utvecklare bara jagar snabbhet. De söker meningsfullt arbete. De värdesätter ren kod, samarbetsinriktade miljöer och utmaningar som utvecklar deras förmåga.

Så var passar Platform Engineering in i helheten? Genom att effektivisera. Organisationer i toppklass kortar inte ledtiderna för driftsättning av ren tur; de investerar strategiskt i plattformar för att samla och påskynda mjukvaruleveransen. I praktiken lägger de tydliga och säkra spår. Utvecklarplattformar är inte bara verktyg – de förändrar spelplanen.

Jag vill ha regelefterlevnad för mjukvara utan manuellt arbete

Att navigera i regelefterlevnadens värld känns som en återgång till tiden då man lite slentrianmässigt kallade mjukvara för ”program” och uppdateringar för ”säsongshändelser”. Spola fram till i dag, så ser spelplanen helt annorlunda ut.

Snabba releaser kräver strikta regler, och låt oss vara ärliga: även om vi ibland muttrar över det finns complianceåtgärder av en god anledning. Med tanke på hur sårbart det digitala landskapet är är starkare säkerhet och integritet inte längre ett val, utan en nödvändighet.

Här kommer Internal Developer Platform (IDP) in i bilden

Den gör inte bara compliance hanterbart, utan integrerar det så smidigt i arbetsflödet att det känns intuitivt. Se den som en pålitlig kollega som alltid stöttar dig.

Till exempel:

  1. Automatiserade revisionsspår: En IDP kan automatiskt logga alla ändringar, så att det finns tydlig dokumentation över vem som gjorde vad och när. Det säkerställer inte bara regelefterlevnad, utan ger också ovärderliga insikter om oförutsedda problem skulle uppstå.

  2. Policy as code: I stället för att granska processer manuellt kan du definiera specifika policyer som kod i IDP:n. Om en utvecklare gör något som inte uppfyller kraven markerar plattformen det och vägleder utvecklaren till att göra rätt. Detta proaktiva arbetssätt kan minska antalet fel drastiskt.

  3. Säker Self-Service: Utvecklare behöver ofta åtkomst till vissa resurser. I stället för att vänta på manuella godkännanden, som kan leda till shadow IT, erbjuder en IDP självbetjäningsportaler där åtkomst ges utifrån fördefinierade regler – för både snabbhet och regelefterlevnad.

  4. Konsekventa miljökonfigurationer: Att konfigurera varje miljö korrekt kan vara en mardröm ur ett complianceperspektiv. Med en IDP kan du skapa mallar för miljöer och säkerställa konsekventa, kompatibla och säkra konfigurationer redan från början.

Automatiserade revisionsspår: En IDP kan automatiskt logga alla ändringar, så att det finns tydlig dokumentation över vem som gjorde vad och när. Det säkerställer inte bara regelefterlevnad, utan ger också ovärderliga insikter om oförutsedda problem skulle uppstå.

Policy as code: I stället för att granska processer manuellt kan du definiera specifika policyer som kod i IDP:n. Om en utvecklare gör något som inte uppfyller kraven markerar plattformen det och vägleder utvecklaren till att göra rätt. Detta proaktiva arbetssätt kan minska antalet fel drastiskt.

Säker Self-Service: Utvecklare behöver ofta åtkomst till vissa resurser. I stället för att vänta på manuella godkännanden, som kan leda till shadow IT, erbjuder en IDP självbetjäningsportaler där åtkomst ges utifrån fördefinierade regler – för både snabbhet och regelefterlevnad.

Konsekventa miljökonfigurationer: Att konfigurera varje miljö korrekt kan vara en mardröm ur ett complianceperspektiv. Med en IDP kan du skapa mallar för miljöer och säkerställa konsekventa, kompatibla och säkra konfigurationer redan från början.

Att integrera sådana skyddsmekanismer i en IDP förvandlar compliance från ett hinder till en smidig del av utvecklingsprocessen. Med dessa automatiserade skyddsmekanismer på plats är det enklare att följa reglerna än att kringgå dem. Utvecklarna kan fokusera på det de gör bäst – att innovera och skapa – utan att ständigt behöva oroa sig för bristande regelefterlevnad. I slutändan handlar det om att säkerställa trygghet utan att hämma kreativiteten.

Inom Platform Engineering är CTO:ns roll inte bara att vara en teknikledare, utan också en visionär. Det handlar om att sätta tydliga mål, förstå helheten och få hela organisationen att ställa sig bakom visionen.

I grunden handlar Platform Engineering om mer än teknik – det är en kombination av verksamhetens ambitioner, teamdynamik och tekniska möjligheter.

Så hur etablerar vi en organisation för Platform Engineering? Läs del två i min bloggserie för att ta reda på det.

  • Platform engineering
  • DevOps

Subscribe to our newsletter