Platform Engineering Capability Model

  • 20 minutter

Platformkonstruktion er beregnet til at være en rejse. En gradvis, iterativ tilgang er generelt mere effektiv end forsøg på en storstilet, øjeblikkelig gennemførelse eller udelukkende at være afhængig af top-down-mandater. Trinvise fremskridt, startende med minimalt levedygtige produkter (MVP'er), gør det muligt for teams at tilpasse deres tilgang over tid, samtidig med at de inkorporerer feedback undervejs.

Platformens tekniske livscyklus repræsenterer en struktureret tilgang til at sikre, at en platform er pålidelig, skalerbar og løbende forbedres. Denne livscyklus omfatter forskellige faser, der hver især bidrager til platformens langsigtede succes.

Et vigtigt element i livscyklussen er Platform Engineering Capability Model, som giver en omfattende struktur til vurdering, planlægning og implementering af platform engineering indsats. Modellen beskriver modenhedsniveauer, bedste fremgangsmåder og kritiske funktioner, der kræves i hver fase i livscyklussen, og sikrer, at der er overensstemmelse med organisationens mål og brugerbehov.

Modellen beskriver status for modning af platformkonstruktion på tværs af fem faser: Indledende, Gentagelig, Defineret, Administreretog Optimering af. I indledende-fase har organisationer begrænset struktur med ad hoc-processer og minimal investering i platformfunktioner. Efterhånden som de går videre til den gentagelige fase, opstår der grundlæggende processer, men vedtagelsen og styringen forbliver uoverensstemmende. Den defineret fase markerer etableringen af klare standarder og processer, hvor brugerne begynder at anvende platformløsninger bevidst. I fasen Administreret styres platforme aktivt, ressourcer klargøres og administreres effektivt, og brugerinteraktioner er konsistente via standardiserede grænseflader. I optimering af fase forbedres platforme løbende via robuste feedbackmekanismer, målte resultater og tilpassede funktioner, der er tilpasset brugerbehov og organisatoriske mål.

Modellen evalueres ud fra seks egenskaber: Investment, der afspejler tildelingen af ressourcer og finansiering; vedtagelse, der fokuserer på brugerregistrering og -udnyttelse; Styring, der sikrer tilgængelighed af ressourcer, omkostningskontrol og beskyttelse af data/IP; Klargøring & Administration, der definerer, hvordan ressourcer installeres og vedligeholdes. Grænseflader, der omhandler brugerinteraktioner med platformen. og Måling & Feedback, der fremhæver løbende forbedringer via målepunkter for ydeevne og brugerindsigt. Tilsammen stemmer disse funktioner nøje overens med de nøgleområder, der er beskrevet i Cloud Native Computing Foundation's platform engineering-modenhedsmodel og afspejler niveauet af organisationens platform engineering-modenhed.

Hvis du vil bruge Modellen Platform Engineering Capability, skal du først vurdere, hvor din organisation i øjeblikket står i hvert af de seks egenskabsområder. Du kan udføre denne vurdering manuelt eller fuldføre undersøgelsen Platform Engineering Capability Model. Når du har identificeret dine aktuelle faser, kan du angive fremtidige mål for vækst og oprette et diagram over din organisations status for hver egenskab. Status behøver ikke at ske på tværs af alle funktioner på én gang. Fokuser på de områder, der giver mest mening for din organisation.

diagram, der viser vigtige faktorer og faser i Platform Engineering Capability Model.

Investering

I takt med at investeringskapaciteten udvikler sig gennem hver fase, fokuserer den på, hvordan personale og midler allokeres til platformfunktioner med fokus på budget og personale, områdestyring og måling af investeringsafkast.

  • Indledende (frivillig): Platformfunktioner opstår af nødvendighed, drevet af individuelle teknikere, der frivilligt løser øjeblikkelige taktiske behov. Budget og bemanding er minimale, og arbejde, der typisk ikke er finansieret og udført sammen med eksisterende ansvarsområder. Løsninger er begrænset til specifikke problemer med begrænset videndeling på tværs af teams. Investeringsafkastet måles ud fra, hvor effektivt øjeblikkelige krav håndteres, og hvordan de påvirker de centrale projektresultater.
  • Gentagelig (ad hoc-bidrag): Dedikerede teams begynder at håndtere tilbagevendende udfordringer, f.eks. inkonsekvent klargøring eller sikkerhedshuller, men indsatsen forbliver stort set reaktiv. Budgetter og bemanding er begrænset til tværgående bekymringer med begrænset empowerment på tværs af organisationen. Områdestyring fokuserer på specifikke problemer uden et bredere platformperspektiv. ROI måles ved at forbedre håndteringen af vigtige udfordringer, f.eks. reduktion af efterslæb.
  • Defineret (driftsklart – dedikeret team): Centralt finansierede platformteams opstår med fokus på at fremskynde levering af software og løse tekniske krav. Lederskab begynder at fremme samarbejde og implementere indledende DevOps-praksisser, men der er stadig udfordringer med at måle teamværdien. Budget og bemanding formaliseres for centrale teams, så de opfylder tekniske behov. Løsninger bliver bredere og løser almindelige udfordringer på tværs af teams, selvom fokus fortsat er kortsigtet. ROI måles ved gevinster i leveringshastighed.
  • Administreret (skalerbar – som produkt): Der sker en kulturel ændring, hvor udviklere behandles som kunder med lederskab, der understreger empati og en produktledet tilgang. Platformteams fungerer som produktteams, bemandet med udviklere, produktchefer og eksperter i brugeroplevelse. Områdestyring er i overensstemmelse med produktoversigter, gennemset i samarbejde med teknikerteams for at imødekomme organisationens behov. INVESTERINGSAFKAST vurderes gennem forbedret udviklertilfredshed, hvilket afspejler løbende forbedringer og tilpasning til brugerbehov.
  • Optimering (aktiveret økosystem): Investering fokuserer på innovation, vedligeholdelse af platformens relevans med bidrag, der tilskyndes på tværs af organisationen. Platformteams introducerer avancerede funktioner, f.eks. forbedringer af sikkerhed og ydeevne, så produktteams kan bygge uden at være afhængige af en central efterslæb. Budgetter strækker sig ud over centrale teams, hvor der er tilgængelige midler på tværs af organisationen. Områdestyring lægger vægt på at muliggøre hurtig vidensdeling i hele organisationen. INVESTERINGSAFKAST måles gennem vedvarende forbedringer i udviklertilfredsheden.

Adoption

Funktionen Adoption fokuserer på, hvordan brugerne finder og bruger dine platformtekniske løsninger og deres tilbud, hvilket afspejles i registreringen, valget og brugen af tjenester, værktøjer og teknologier. I takt med at organisationer udvikler sig, skifter tilgangen til indførelse fra uformel og sporadisk brug til en mere struktureret og deltagelsesbaseret model, hvor brugerne aktivt interagerer med platformen, og bidrager til dens udvikling. Dette forløb afspejler, hvordan brugerregistrering, beslutningstagning og brugspraksis udvikler sig over tid lige fra indledende uformel registrering til fuld deltagelse i platformens udvikling.

  • Indledende (uformel): Indførelsen er inkonsekvent, idet teams uafhængigt forbedrer processer uden koordinering på organisationelt plan. Eksterne værktøjer foretrækkes ofte frem for interne. Platforme opdages uformelt, hovedsageligt via mund til mund eller tilfældige møder, hvor teknikerteams vælger tjenester baseret på deres specifikke behov. Hvert team vedligeholder sine egne scripts og værktøjer, der er skræddersyet til dets unikke krav.
  • Repeatable (Mandated): Organisationen giver mandat til brugen af delte platforme, men egenskaberne er begrænset til almindelige use cases, hvilket gør det svært at imødekomme usædvanlige krav. Brugerregistrering er afhængig af vejledning til platformteamet, ofte via intern dokumentation eller direktiver. Teams kan vælge mandattjenester via uformelle diskussioner med platformteamet. På trods af at processer bygges op omkring platformsstandarder, kan teams muligvis ikke fuldt ud anvende dem eller være utilfredse med resultaterne.
  • Defineret (annonceret): Platformfunktioner fremmes aktivt og tilpasses teamets behov. Platformteamet samarbejder med teknikerteams om at tilbyde tjenester af høj kvalitet, der reducerer driftsomkostningerne. Nogle teams kan dog stadig opleve lavt investeringsafkast på grund af afhængighed af forældet praksis og teknisk gæld. Teams finder funktioner via direktiver, der dækker typiske use cases, og platformteamet opfordrer til brug gennem samarbejde. Advocacy for platformbrug sker også uformelt via teamambassadører.
  • Administreret (værdidrevet): Produktteams genkender og vælger platformfunktioner for den klare værdi, de giver, når de reducerer den kognitive belastning og tilbyder tjenester af høj kvalitet. Platforme understøttes af omfattende dokumentation, ergonomiske grænseflader og selvbetjenings-UX til hurtig klargøring. Teams foretrækker nu interne platforme frem for selv at bygge løsninger eller være afhængige af eksterne udbydere. Registrering og beslutningstagning strømlines med teams, der bruger skabeloner, forummer og dokumentation til fuldt ud at understøtte indførelsen af platforme.
  • Optimering (deltagelse): Produktteams bidrager aktivt til at forbedre platformfunktionerne ved at foreslå nye funktioner og rettelser. Der er processer på plads, så brugerne kan identificere krav og samarbejde om bidrag. Developer Advocates og ambassadors fremmer et internt community og udvider ejerskabet af platformen til bidragydere. Platformteknikere arbejder tæt sammen med produktteams for at forstå behov og foreslå nye funktioner, så brugerne kan indsende pullanmodninger og deltage i anmeldelser.

Styreformer

I takt med at styringsfunktionen udvikler sig, fokuserer den på at sikre, at brugerne har adgang til de ressourcer og egenskaber, de har brug for, samtidig med at de administrerer omkostninger, data og intellektuel ejendomsret. Denne progression vurderes på baggrund af flere kategorier, herunder definition af politikker og rammer, implementering af politikker, overvågning og afhjælpning af overholdelse og administration af adgang. Styring udvikler sig fra manuelle og reaktive processer til et integreret, forudsigende system, der balancerer centraliseret styring med adaptiv administration til skiftende behov.

  • Initial (Independent): Styring er manuel, afhængig af centraliseret kontrol og gatekeeping, hvilket hindrer skalerbarhed. Udviklere og sikkerhedsteams arbejder uafhængigt af hinanden og reagerer reaktivt på politikovertrædelser. Overholdelse opretholdes via minimale standarder, hvor sikkerhedsforanstaltninger ofte tilføjes som eftertanke. Adgangstilladelser tildeles på baggrund af øjeblikkelige behov uden en standardiseret proces.
  • Gentagelig (dokumenteret): Organisationen begynder at dokumentere og dele politikker, men disse forbliver grundlæggende og uoverensstemmende anvendt. Styringsværktøjer som billetsystemer introduceres for at administrere politikgennemgange, men processen forbliver manuel og langsom. Overvågningsprocesser er etableret, men stadig reaktive. Nogle roller og tilladelser standardiseres, men håndhævelsen er stadig forskellig.
  • Defineret (standardiseret): Styring bliver centraliseret og standardiseret for at forbedre ensartethed og effektivitet på tværs af alle teams. Politikker dokumenteres og administreres centralt med en vis grad af automatisering i implementeringsprocessen. Vigtige styringsstandarder opretholdes gennem regelmæssig overvågning, og adgangskontrol automatiseres med et formelt RBAC-system, selvom udviklingsteams stadig har begrænset kontrol over politikændringer.
  • Administreret (integreret): Sikkerhed og overholdelse af angivne standarder integreres problemfrit i arbejdsprocesser med automatisering, der sikrer, at politikker anvendes ensartet på tværs af systemer og teams. Overvågning i realtid og avancerede analyser hjælper med at registrere og forhindre huller i styringen. Politikker er integreret i CI/CD-pipelines, og adgangsstyring styres af principper for mindst mulige rettigheder med automatiserede anmeldelser, der sikrer en mere proaktiv og integreret tilgang til styring.
  • Optimering (forudsigende): Styring bliver dynamisk og kontekstafhængig, reagerer på ændrede betingelser og optimerer adgangskontrol. Forudsigende analyser hjælper med at identificere potentielle risici, før de opstår, hvilket muliggør proaktiv afhjælpning. Politikker finjusteres løbende ved hjælp af avancerede analyser, og adgangskontrol justeres dynamisk baseret på faktorer i realtid, f.eks. brugerplacering og adgangstid, hvilket sikrer overholdelse, samtidig med at tilpassede arbejdsprocesser aktiveres.

Klargøring og administration

Med funktionen Klargøring og administration er fokus på, hvordan brugerne opretter, udruller og administrerer ressourcer. Processen udvikler sig fra manuelle, siloiserede operationer til et adaptivt, automatiseret system, der balancerer fleksibilitet med styring, og sikrer, at ressourcerne klargøres effektivt, samtidig med at overholdelseskravene opfyldes. Dette forløb strækker sig over faser, der er kategoriseret ved at definere klargøringsprocesser, besvare og administrere anmodninger og overvåge ressourceallokering.

  • Indledende (manuel): Udviklere konfigurerer infrastruktur manuelt baseret på vejledning fra it- eller arkitekturteams, hvilket fører til uoverensstemmelser og forsinkelser. Uden standardiserede processer gennemgås anmodninger manuelt, hvilket øger risikoen for fejl. Denne fremgangsmåde bliver uholdbar i takt med, at efterspørgslen vokser, og at der skabes ineffektiv drift i siloer.
  • Repeatable (Coordinated): Organisationen begynder at centralisere klargøringsprocesser ved hjælp af billetsystemer til at administrere infrastrukturanmodninger. Der kræves stadig manuelle godkendelser, men nogle fejl reduceres, men der er stadig flaskehalse. Teams begynder at bruge standardværktøjer til overvågning af ressourcer, selvom visningen forbliver siloiseret og projektspecifik.
  • Defineret (brolagt): Klargøringsprocesser formaliseres på tværs af organisationen ved hjælp af Infrastruktur som kode (IaC), standardiserer skabeloner og værktøjer. Anmodninger håndteres via strukturerede arbejdsprocesser, selvom platformteamet kan kæmpe med stigende efterspørgsel. Centraliserede dashboards gør det muligt at overvåge ressourceallokering, hvilket giver bedre indsigt i ydeevnen.
  • Administreret (automatiseret): Klargøring bliver automatiseret og integreret i CI/CD-pipelines, minimerer den manuelle indsats og sikrer ensartede udrulninger. Styrings- og overholdelseskontrol er integreret i arbejdsprocesser. Automatiserede selvbetjeningsfunktioner giver brugerne mulighed for at klargøre ressourcer i kontrollerede parametre. Skalering automatiseres baseret på forbrugsmønstre for at optimere ydeevnen.
  • Optimering (adaptiv): Klargøring bliver adaptiv ved hjælp af intelligente systemer til at foregribe infrastrukturbehov i realtid. Denne tilgang sikrer effektiv ressourceallokering, samtidig med at styring og overholdelse bevares. Systemer håndterer proaktivt anmodninger, balancerer fleksibilitet med styring, mens ydeevne og omkostningseffektivitet optimeres via forudsigende analyser.

Grænseflader

I grænsefladefunktionen er den primære overvejelse, hvordan brugerne interagerer med og bruger platformtjenesterne og -produkterne. Dens fremskridt fokuserer på at etablere standarder, øge brugerautonomi og problemfrit integrere platformfunktioner i eksisterende arbejdsprocesser. Tilgangen udvikler sig fra inkonsekvente, manuelle processer til et selvbetjent, integreret system, der forbedrer brugeroplevelsen og driftseffektiviteten.

  • Indledende (brugerdefinerede processer): Brugerne interagerer med platformen via forskellige inkonsekvente, brugerdefinerede processer, der løser øjeblikkelige behov, men som mangler standardisering. Teknikere konfigurerer miljøer uafhængigt af hinanden ved at konsultere kolleger eller være afhængige af personlige fremgangsmåder, og de vælger værktøjer og processer til diagnosticering af programadfærd uden nogen fastlagte retningslinjer. Videndeling er uformel, og klargøringstjenester kræver ofte dyb support fra udbydere på grund af manglen på formaliserede processer, som begrænser skalerbarhed og effektivitet.
  • Repeatable (lokale standarder): Teknikere og teams begynder uformelt at definere standarder for at forbedre videndelingen, selvom konsekvens fortsat er en udfordring på grund af afhængighed af individuel forpligtelse. Nogle teams bruger muligvis dokumentation eller objektbeholdere til at definere deres konfigurationsprocesser, men disse fremgangsmåder varierer over tid, hvilket kræver en indsats for at afstemme. Diagnosticering af programfunktionsmåde bliver mere standardiseret i teams med en vis afhængighed af DevOps eller it-teams for at få adgang til udrullede ressourcer. Mens lokale standarder opstår, forbliver de løst definerede og inkonsekvente på tværs af teams.
  • Defineret (standardværktøj): Grænseflader bliver mere ensartede med introduktionen af standardiserede værktøjer og dokumenterede fremgangsmåder. Centrale teams administrerer skabeloner og dokumentation med såkaldte brolagte veje eller gyldne stier, der styrer, hvordan funktioner skal klargøres og overholdes. Disse værktøjer og processer opfylder brede organisatoriske behov, selvom der stadig ofte er behov for ekspertsupport. Teams kan ændre skabeloner, men ændringer integreres ikke altid centralt, hvilket kan føre til ineffektiv vedligeholdelse af konsistens. Diagnosticering af programfunktionsmåde følger standardiserede fremgangsmåder for adgang til og analyse af udrullede ressourcer, hvilket giver større ensartethed på tværs af teams.
  • Managed (Self-Service Solutions): Platformen muliggør større brugerautonomi ved at levere selvbetjeningsløsninger med minimal vedligeholdelsessupport. Brugerne har adgang til ensartede, brugervenlige grænseflader, der gør det muligt for dem at finde og redigere skabeloner og dermed oprette et brugercentreret miljø, der forbedrer anvendeligheden. Værktøjer til diagnosticering af programadfærd og observation af ressourcer gøres tilgængelige efter behov via platformen, så brugerne har de ressourcer, de har brug for, uden at være meget afhængige af eksterne teams. Videndeling lettes ved at finde og ændre skabeloner, hvilket øger værdien af platformfunktioner.
  • Optimering (Integrated Services): Platformfunktioner integreres problemfrit i de værktøjer og processer, som teams allerede bruger, f.eks. CLI eller IDE'er, hvilket gør dem til en naturlig del af brugernes arbejdsprocesser. Nogle funktioner klargøres automatisk baseret på brugerbehov, og platformen indeholder fleksible byggesten til brug på højere niveau, der kan kræve mere tilpasning. Platformteams vurderer løbende, hvilke funktioner der er mest effektive, og guider yderligere investeringer for at optimere platformtilbud. Platformen konfigurerer automatisk observability for udrullede programmer, hvilket giver adgang til diagnosticeringsdata i realtid og strømliner processen med overvågning og administration af programfunktionalitet.

Målinger og feedback

Funktionen Målinger og feedback omfatter indsamling, analyse og indarbejdelse af målepunkter og feedback for at vurdere succesen af platformkonstruktionspraksisser. Dens modenhed afspejles ved at skifte fra ad hoc- og uformelle metoder til en proaktiv, datadrevet kultur, hvor feedback og indsigt integreres i løbende forbedringsprocesser, der styrer strategiske beslutninger og platformudvikling.

  • Indledende (ad hoc): I den indledende fase er målings- og feedbackprocesser inkonsekvente og fragmenterede. Målepunkter indsamles uden klar justering af organisationens mål, hvilket resulterer i ufuldstændige og upålidelige data. Feedback indsamles uformelt og ofte anekdotisk med minimalt engagement fra interessenter. Derfor træffes beslutninger på baggrund af begrænsede oplysninger, og det er svært at måle det sande investeringsafkast for platformkonstruktionspraksisser. Dokumentation af feedback og resultater er minimal, og læring registreres eller deles sjældent.
  • Gentagelige (strukturerede processer): Grundlæggende feedbackmekanismer, f.eks. undersøgelser eller forummer, oprettes for at registrere brugeroplevelser mere systematisk, men disse processer varierer stadig på tværs af teams. Målingen af succes er ofte fokuseret på aktivitetsbaserede målepunkter, f.eks. udrulninger eller tidslinjer, hvilket giver en vis indsigt i ydeevnen, men mangler et bredere resultatbaseret perspektiv. Feedback forbliver uformel og nedefra, selvom den begynder at påvirke planlægningen. Der er en vis indsats for at engagere interessenter, men det er stadig begrænset, og den indledende dokumentation af processer og feedback oprettes, men den er ikke omfattende eller anvendes konsekvent.
  • Defineret (konsistent): Feedbackindsamling bliver mere formaliseret og standardiseret, hvilket giver mulighed for dybere indsigt i brugerbehov og vigtige målepunkter. Målepunkter skifter til resultatbaserede målinger, f.eks. udviklerproduktivitet, selvom det fortsat er en udfordring at knytte dem til økonomiske resultater. Feedbackanalyse er systematisk ved hjælp af både kvalitative og kvantitative metoder og standardmålepunkter som DORA (DevOps Research and Assessment er et sæt målepunkter, der måler softwareleveringsydeevne, herunder leveringstid, udrulningshyppighed, gennemsnitlig tid til gendannelse og ændring af fejlfrekvens) eller SPACE (tilfredshed og trivsel, ydeevne, aktivitet, kommunikation og samarbejde og effektivitet er en struktur, der bruges til at måle udviklerproduktiviteten på tværs af disse fem dimensioner). ansat. Regelmæssige gennemgangssessioner med tværfunktionelle teams sikrer aktivt engagement med interessenter. Omfattende dokumentation af feedbackprocesser, resultater og erfaringer vedligeholdes og deles på tværs af teams.
  • Administreret (indsigt): På nuværende tidspunkt er feedbackmekanismer og målerammer robuste og fokuseret på strategiske forretningsresultater. Datadrevet indsigt guider platformhandlinger, og feedback er integreret i platformkøreplanerne, og det giver løbende forbedringer. Avancerede analyser bruges til at vurdere platformens indvirkning på forretningsmæssige resultater, f.eks. omsætningsvækst, og feedback er korreleret med målepunkter for ydeevne for at identificere vigtige områder til strategisk forbedring. Interessenter på tværs af organisationen er dybt involveret i feedbackprocessen med struktureret samarbejde for at undgå siloer. Dynamisk dokumentation i realtid afspejler løbende feedback og erfaringer, der er tilgængelige for alle interessenter.
  • Optimering (Proaktiv): Feedback- og målingsprocesser er tæt integreret i organisationens kultur og skaber en proaktiv tilgang til at foregribe og tilpasse sig fremtidige udfordringer og muligheder. Forudsigende analyser og avancerede målepunkter bruges til at forudsige fremtidige behov og muligheder, hvilket gør det muligt for platformen løbende at udvikle sig som svar på ændrede betingelser. Feedback er fuldt integreret i en kontinuerlig forbedringscyklus, og der etableres en feedbackkultur på tværs af alle niveauer i organisationen. Dynamisk dokumentation i realtid afspejler løbende feedback og opdateres løbende, så det sikres, at de erfaringer, der er gjort, deles og er tilgængelige for alle interessenter.