Fallstudier: Tre plattformstekniska implementeringar

Även om det finns olika metoder för att implementera plattformsutveckling med plattformsteknikens kapacitetsmodell, visar användarundersökningar att de flesta Microsoft-kunder ingår i ett av tre kundsegment: framväxande innovatör, strategisk byggare och plattformspionjär. Den här artikeln vägleder dig genom en fallstudie för en riktig kund i varje segment. Företagsnamn tas bort för sekretess.

Ny innovatör: Försäkringsbolag

Kundsegment	Fokusområden	Gruppstorlek	Organisationsegenskaper	Frekvens
Ny innovatör	Snabb produktutveckling, automatisering av manuella processer, hantering av ineffektivitet	1–5 (från DevOps- eller molninfrastrukturteam)	Identifierar flaskhalsar för att förbättra leveransen och börjar inse behovet av organisationsomfattande lösningar	Näst vanligaste

Ett stort försäkringsbolag inser att de har olika infrastruktur utspridda över en stor teknikstack. Det finns flera plattformar och miljöer, och det finns inte många sätt för utvecklare att komma igång utan att förlita sig på andra team. Företaget behöver minska sina växande personalkostnader och ha mer standardiserade system.

Vändpunkten var ganska självklart. Med tanke på att vi har flera tekniska plattformar, flera infrastrukturmiljöer, inklusive hybrid, inga självbetjäningsfunktioner i utvecklarportalen och tre enorma olika staplar i vår arkitektur, var vi tvungna att ta in något som Terraform eller en spelare på företagsnivå som GitLab eller GitHub. För att hantera containerbaserade plattformar från slutpunkt till slutpunkt övervägde vi något som OpenShift, Ansible för arbetsflödesautomation och Backstage för IDP:t. Vi gjorde en grundlig utvärdering för att uppnå synergieffekter i en så omfattande teknikstack... Detta är ett mycket enkelt kostnadsfall som innebär att minska arbetskraften eller utvecklarbasen med 30%." - Chefsarkitekt, försäkringsbolag

Utmaning: Deras främsta utmaningar är stigande molnkostnader, efterlevnadsproblem, brist på expertis inom infrastrukturteknik, feljusterade processer och inkonsekvent teamkommunikation.

Försäkringsbolaget planerar att implementera en standardiserad plattform för alla utvecklings- och distributionsaktiviteter för att främja samarbete, påskynda projektkonfigurationen och förenkla styrningen. Företaget fokuserar på tillväxt för alla fem viktiga plattformstekniska drivkrafter.

Investering: Företaget arbetar med en extern partner för att implementera plattformsteknik med hjälp av en modell för att bygga, driva och överföra (BOT). Den externa partnern utvecklar och driver plattformen innan den överförs tillbaka till organisationen när de får expertis och kapacitet att hantera den internt.

Adoption: Det finns ett betydande internt motstånd mot att införa nya metoder. Utvecklare vill inte byta från traditionella metoder till nyare plattformar och verktygsuppsättningar. För att lösa detta driver organisationens ledarskap plattformstekniska implementering genom att binda det till produktivitetsfördelar och göra det till en del av medarbetarnas mål.

Styrelseskick: Teamet för företagsplanering och distribution (EPD) ansvarar för efterlevnad och säkerhet. Den centraliserade styrningsstrukturen är avsiktlig för att upprätthålla hög säkerhet och undvika sårbarheter, vilket gör decentralisering till en utmaning. Det finns en push för att demokratisera distributionen till utvecklare, samtidigt som styrningsprotokoll upprätthålls för att förhindra dataintrång och säkerställa efterlevnad. Målet är att hitta en balans mellan säkerhet och flexibilitet.

Tillhandahållande: Företaget förbättrar effektiviteten och minskar tillhandahållandetiderna genom att införa en mer integrerad och självbetjäningsmodell. Den potentiella minskningen av tid och resurser som läggs på tillhandahållande är en viktig faktor för förändring.

Gränssnitt: Organisationen antar Backstage för sin flexibilitet med öppen källkod, kostnadseffektivitet och utvecklarförtrogenhet. Cortex övervägdes också. Beslutet att välja Backstage drevs av dess kostnads- och integreringsfunktioner.

Mått och feedback: Det har varit svårt att gå över till ett mer meningsfullt feedbacksystem eftersom företaget har ett äldre mätsystem och behöver anpassa tekniska mått till affärs-KPI:er. Företaget planerar att arbeta med att anpassa tekniska insatser till affärsresultat för en mer integrerad mätmetod. Under den här övergången lägger företaget till verktyg och plattformar som tillhandahåller realtidsanalys och observerbarhet.

Strategisk byggare: Finansinstitut

Kundsegment	Fokusområden	Gruppstorlek	Organisationsegenskaper	Frekvens
Strategisk byggare	Samarbete, minska redundanta insatser, delade lösningar, standardisering, kostnadshantering	1–15 tekniska experter (utvecklare och infrastrukturspecialister)	Ledningen ser utvecklare som kunder, delvis integrerade plattformstekniska funktioner (självbetjäning inte helt antagen)	Vanligaste

Finansinstitutet är på en medelnivå av DevOps-mognad, med några återanvändbara centrala artefakter, standardiserade riktlinjer och grundläggande automatisering som hanteras via kod. Organisationen har nått en punkt där storleken på dess utvecklingsteam och mångfalden av dess verktyg och metoder skapar betydande kostnader. Institutionen hade tusentals anpassade verktyg som användes i företaget och många komplexa organisationsbehov. Banken planerar att erbjuda utvecklare en "gyllene väg" för att förbättra produktiviteten som har inbyggd flexibilitet samtidigt som man undviker en strategi som passar alla.

"Så tanken var att vi skulle visa dem [utvecklare] att denna [gyllene väg] är ett sätt att göra det som kommer att förbättra din produktivitet, men det är inte det enda sättet. Eller hur? Så vi ville lämna tillräckligt med utrymme för utvecklaren att känna att de har befogenhet att göra ändringar i den här vägen som vi berättar för dem. Så när dessa vägar definieras i CTO-teamet är frågan alltid, vilka är de vägar som ska definieras som kommer att fungera för majoriteten av personerna i banken? Som jag sade är vi mycket komplexa. Det finns tusentals verktyg som används över hela banken. Så en storlek passar alla var alltid det största problemet." - Verkställande direktör, finansinstitut

Utmaning: Deras främsta utmaning är höga kostnader och ineffektivitet på grund av många olika verktyg och metoder. Företaget vill se till att plattformen uppfyller varje teams specifika behov utan att orsaka problem eller vara en alltför direktivmetod som kan hindra implementeringen. Finansinstitutet saknar också expertis för att utveckla anpassade plattformslösningar internt.

Finansinstitutet planerar att fokusera på tillväxt för tre viktiga faktorer: införande, styrning och etablering och förvaltning. Banken vill öka implementeringen av plattformslösningen, integrera styrningen bättre och skapa automatiserade verktyg för resursetablering.

Investering: Finansinstitutet har ett centralt ingenjörsteam med 120 personer spridda över flera platser över hela världen. Cirka 20 medlemmar utgör ett COE-team (center of excellence). COE-teamet distribuerar metodtips, plattforms- och DevOps-metoder för alla andra affärsdivisioner.

Adoption: Plattformsteknikern fokuserar på att framtvinga principer som angetts av COE-teamet för att vägleda tekniska åtgärder. Företaget planerar också att motivera team med offentligt synliga prestandamått. På det hela taget vill banken öka plattformsanvändningen utan att förlita sig på strikta direktiv och mått. De står dock inför utmaningar när det gäller att lära coe-teamet att hantera de olika tekniker som används i olika teknikteam. Ett stort hinder är oron för att plattformen kanske inte uppfyller enskilda teams specifika behov, vilket kan orsaka problem.

Styrelseskick: Plattformslösningen är en internt utvecklad portal som fungerar som en central hubb för utvecklare som erbjuder verktyg, guider, kodningsstandarder och videor. Lösningen innehåller ett test om minimikrav för företag (MERS) för att säkerställa efterlevnad innan kodningen börjar. Portalen innehåller en version av Stack Overflow för support, certifierade teknikerprofiler och en introduktionsresa för att bekanta nya utvecklare med standarder och verktyg. Företaget planerar att effektivisera resurshanteringen och integrera styrningen i utvecklingslivscykeln, ta bort flaskhalsar och locka topptekniska talanger med en modern verktygsuppsättning.

Provisionering: COE-teamet skapade "smidiga flöden" för utvecklare för att öka produktiviteten samtidigt som flexibiliteten bibehålls. Målet är att erbjuda en effektiv väg samtidigt som anpassning tillåts. När CTO-teamet utformar dessa vägar strävar de efter att tillgodose de flesta utvecklare, men bankens komplexitet, med tusentals verktyg i bruk, försvårar implementeringen av en standardiserad metod. För att skala plattformen planerar organisationen att implementera automatiserad resursetablering för att uppfylla de olika behoven hos sina många tekniska team.

Gränssnitt: Den interna utvecklarportalen skapades främst internt. Det kallas internt för DevOps-portalen, även om den omfattar bredare plattformstekniska funktioner utöver bara DevOps. Portalen fungerar som en centraliserad resurs för utvecklare och innehåller olika verktyg, utbildningsmaterial, videor och utbildningar samt åtkomst till automatiseringsverktyg, självstartsguider och containerbaserade avbildningar för utveckling. Portalen är också integrerad med säkerhetsverktyg som Sonatype för kodgenomsökning och innehåller ett register över godkända avbildningar och pannplåtskod.

Mått och feedback: COE-teamet är öppet för feedback och begär det aktivt från tekniska team. Utvecklarrådgivare och ambassadörer samlar också in feedback för COE-teamets räkning. Feedbackprocessen är mestadels informell.

Plattformspionjär: Programvaruföretag

Kundsegment	Fokusområden	Gruppstorlek	Organisationsegenskaper	Frekvens
Plattformspionjär	Behandla utvecklare som kunder, hantera plattform som en produkt, stark utvecklarupplevelse	16+ med specialiserade grupper	Betonar ansvar, egenmakt och innovation, främjar självbetjäning och minimal kontextväxling	Minst vanligt

Programvaruföretaget är på en hög nivå av DevOps-mognad. Företagets utvecklare kan själv etablera molntjänster i enlighet med företagets riktlinjer. Företagets stora plattformsteam med över 250 medlemmar har framgångsrikt utvecklat anpassade plattformslösningar för organisationen. Företaget planerar att undersöka hur de kan fortsätta att förbättra sin organisation genom plattformsutveckling framöver.

"Hur gör vi för att våra utvecklare ska kunna leverera bättre programvara snabbare och (billigare)?.. Vi behöver fortfarande undersöka och investera i vad som kan vara den idealiska lösningen som kan fungera för vår strategi för flera moln... finns det ett system som kan skalas efter utvecklarnas olika behov?.. Vi använder generativa AI- och AI-drivna lösningar som är inbyggda för dokumentation och informationsidentifiering. Vårt mål är att göra utvecklarna ansvariga." - Senior Engineering Leader, software company

Utmaning: Företagets främsta utmaning är att ta reda på hur man fortsätter att förfina sina redan starka plattformstekniska metoder på sätt som sparar pengar, utforskar generativ AI, ökar implementeringen och arbetar för en miljö med flera moln.

Programvaruföretaget planerar att fokusera på att växa för fyra viktiga faktorer: investeringar, implementering, etablering och hantering samt gränssnitt. Programvaruföretaget fungerar redan på hög plattformstekniknivå och vill fortsätta. Företaget planerar att utforska sätt att integrera generativ AI (med styrning), öka plattformsimplementeringen och implementera måttdrivna feedbackslingor.

Investering: Plattformen finansieras och stöds genom ett samarbete mellan CTO- och CFO-kontoren. Ett dedikerat plattformsteam, bildat genom att omlokalisera resurser, innehåller 250 till 280 medlemmar som arkitekter och ingenjörer. Teamet övervakar beräkning, körning, CI/CD, verktyg och observerbarhet, med fokus på kostnadseffektivitet. De utforskar generativ AI för infrastrukturskalbarhet men inser att ytterligare forskning och investeringar behövs.

Adoption: Utvecklarna antog ursprungligen plattformen främst för kostnadsoptimering och effektivitet, drivet av pandemin. Interna kampanjer, inklusive hackathons, främjar plattformen och visar fördelar som insikter om tjänstmognad. Plattformsteamet hade svårt att övertyga vissa team att gå från sina befintliga installationer till plattformen.

Styrelseskick: Styrningsmodellen för plattformen är strukturerad kring ett centralt plattformsteam som hanterar kärnelement. Enskilda tjänstteam bidrar med plugin-program. Det finns en granskningsprocess för alla bidrag för att verifiera att de överensstämmer med organisationens standarder och uppfyller bredare behov. Plattformsteamet underhåller en tjänstkatalog och tjänstkarta för att spåra metadata och beroenden, som hjälper till att säkerställa ansvar och resurshantering. Dessutom inrättades ett dedikerat styrningsorgan specifikt för AI-program för att hantera deras användning och säkerställa efterlevnad av standarder.

Etableringen: Plattformsteamet tillhandahåller en centraliserad men flexibel plattform för skapande, distribution och hantering av resurser. Plattformen bygger på Kubernetes och använder Argo CD för CI/CD. Verktyget erbjuder anpassade mallar och fördefinierade arbetsflöden. Plattformen innehåller ett utvecklarhem där användarna kan hantera sin infrastrukturlivscykel från etablering till distribution. Teams bidrar med skräddarsydda plugin-program för att förbättra funktionaliteten. Målet är att hantera infrastruktur för flera moln sömlöst med en skalbar plattform.

Gränssnitt: Utvecklare använder utvecklarens hem på plattformen för att hantera infrastruktur, etablering och hela utvecklingslivscykeln. Plattformens plugin-baserade arkitektur möjliggör anpassning, medan generativ AI förbättrar dokumentationen och sökbarheten.

Mått och feedback: Organisationen samlar in feedback genom undersökningar och använder mått som DORA (distributionsfrekvens, ledtid, ändringsfelfrekvens och genomsnittlig tid till återställning) för att utvärdera plattformens effektivitet. Dessa mått kategoriseras i flexibilitet och stabilitet för att hitta flaskhalsar och förbättra resultaten.