Elke klant is belangrijk
Een belangrijk principe van platform engineering is om te optimaliseren voor uw klanten. Beschouw ontwikkelaars als uw primaire klant en richt u eerst op hun behoeften bij het bepalen van de ontwikkelingstrajecten die u wilt effenen. Ontwikkelaars gebruiken allemaal verschillende hulpprogramma's om hun werk gedaan te krijgen. Als eerste stap begint u klein en evalueert u of u bestaande schermen en oppervlakken kunt verbeteren voordat u een gloednieuw intern ontwikkelaarsplatform implementeert.
Ontwikkelaars zien als uw primaire klant
Het is essentieel om ontwikkelaars te zien als de primaire klant voor uw interne ontwikkelaarsplatform. We verwijzen deze klanten voor het gemak naar ontwikkelaars, maar ze kunnen elk lid zijn van wat het teamtopologiemodel verwijst als op stromen afgestemde teams , inclusief rollen zoals machine learning-professionals of gegevenswetenschappers.
Een succesvolle platform engineering praktijk biedt ontwikkelaars en operators autonomie bij het nemen van beslissingen die ontwikkelaars in staat stellen zich te richten op het leveren van bedrijfswaarde, terwijl ze zich nog steeds houden aan gevestigde standaarden, governance en beveiligingsregels. Kritieke belanghebbenden, ondersteunende teams en experts in specifieke subsystemen (bewerkingen, beveiliging, naleving en architectuur) werken samen met de teambuilding van dit interne platform om hun expertise en best practices te codificeren in sjablonen en systeemmogelijkheden. Het verplaatsen van deze kennis naar een systeem vermindert tegelijkertijd de cognitieve belasting voor ontwikkelaars, verbetert de beveiliging, naleving en kwaliteit en schaalt deze andere rollen beter om echt unieke problemen aan te pakken. Het is echter de ontwikkelaarservaring die ervoor zorgt dat uw platform het meeste voordeel oplevert voor alle betrokkenen.
Dit betekent dat u een klantgerichte benadering volgt voor het plannen en prioriteren van uw platform engineering-inspanningen.
Meer informatie over plannen en prioriteren.
Begrijpen welke ontwikkelingspaden u wilt effenen
Hoewel uw organisatie momenteel verschillende ontwikkelingstrajecten naar productie heeft, is het een vroege stap in uw platform engineering om te begrijpen welke paden ontwikkelaars moeten gebruiken. Het maken van deze aanroep is belangrijk, omdat u zich hiermee kunt richten op het effenen van een efficiënt pad dat nog steeds voldoet aan de vereisten voor ontwikkeling, bewerkingen en governance.
Deze geplaveide paden (en eventuele volledig geplaveide gouden paden) vertegenwoordigen een specifieke set hulpprogramma's voor ontwikkeling en waarneembaarheid, talen, SDK's en services die zijn vormgegeven om te passen bij wat ontwikkeling, bewerkingen en andere belanghebbenden overeenkomen als een representatie van hun best practices. Geplaveide paden moeten benaderingen omvatten voor het stroomlijnen van onboarding, toezicht en pleiten voor intern hergebruik. U hoeft deze geplaveide paden niet te beschouwen als beperkend of geforceerd, maar eerder als het verminderen van ontwikkelaars tot het punt dat ontwikkelteams binnen hen willen blijven.
De truc is echter om niet alleen te begrijpen op welke paden u zich moet richten, maar ook welke secties van het pad als eerste moeten worden geplaveid.
Meer informatie over geplaveide paden.
Maak kennis met gebruikers waar ze zich bevinden
Hoewel het verleidelijk kan zijn om te beginnen met een uniforme portal voor alles in uw interne ontwikkelaarsplatform, is dit vaak niet het beste uitgangspunt.
Uw operationele professionals, SRE's (Site Reliability Engineers) en ontwikkelaars gebruiken allemaal verschillende hulpprogramma's om hun werk gedaan te krijgen. Coderen vindt plaats in een IDE, technische systemen zoals GitHub en Azure DevOps maken gebruik van opdrachtregelinterfaces en realtime samenwerking vindt plaats in Teams en Slack. Vaak zijn deze gebruikers blij met deze schermen en zijn ze op hun hoede voor nog een andere gebruikersinterface om zich zorgen over te maken.
Begin klein en evalueer of u uw bestaande schermen en oppervlakken kunt verbeteren, idealiter via invoegtoepassingen of uitbreidingen, voordat u begint met het bouwen van nieuwe aangepaste ervaringen. Stel uzelf de vraag of mensen beter reageren op een andere nieuwe gebruikerservaring of een verbeterde versie van iets dat u nu hebt? Zelfs als u besluit om een volledig nieuwe portal te bouwen, moet u er rekening mee houden dat u waarschijnlijk meer dan één interface wilt ondersteunen via een API. Hiermee ontgrendelt u ook opties zoals het gebruik van frameworks met weinig code, zodat u geen volledig nieuwe portal-ervaring hoeft te bouwen en hosten.