De probleemruimte definiëren
Naarmate u uw interne ontwikkelplatform gaat definiëren, is het essentieel om eerst de thinnest viable platform (TVP) te definiëren. Dit is een variant van het idee van een minimum viable product (MVP) in het klassieke productbeheer.
In Plannen en prioriteren vindt u meer informatie over het definiëren (of verbeteren) van uw TVP. Maar voordat we er zijn, kan dit diagram u helpen om na te denken over hoe u zich in de loop van de tijd kunt ontwikkelen. Houd er rekening mee dat het belangrijkste probleem van uw organisatie ertoe kan leiden dat u afwijkt van wat hier wordt beschreven vanwege uw bestaande investeringen of behoeften van de organisatie. Essentieel is dat u niet verder hoeft te gaan naar de volgende fase, tenzij uw organisatie deze nodig heeft.
Als u helemaal opnieuw begint, vertegenwoordigt dit een algemene voortgang. In de beginfase richt u zich op de detectie van de benodigde mogelijkheden, fit-gap-analyse van producten met krimpverpakking en het maken van het minimale aantal hulpprogramma's of platformmogelijkheden. Als u vervolgens schaalt, begint u zich waarschijnlijk te richten op herbruikbaarheid en het begeleiden van mensen naar vooraf gedefinieerde geplaveide paden met herbruikbare assets. Ten slotte stapt u over op een consument-achtig 'digitaal winkel'-model om het eenvoudiger te maken om toepassingen te bouwen en te onderhouden. U moet overal een productmentaliteit volgen, dus we raden u niet aan tot het einde te springen en uw specifieke traject varieert. Deze laatste fasen lijken het meest op 'product' in krimp verpakt in de traditionele zin, maar dit is een bestemming, geen startpunt.
Gezien de omvang van dit onderwerp raden we u aan om de wijze waarop u over platform engineering praat in vier onderwerpgebieden op te delen. Door uw denkwijze op deze manier te categoriseren, kunt u eenvoudiger een plan opstellen en communiceren voor uw investeringen in de loop van de tijd. Deze gebieden zijn:
- Technische systemen: een samengestelde mix van DevOps-suites zoals GitHub en Azure DevOps en andere ontwikkelhulpprogramma's en -services. Naast essentiële DevOps-hulpprogramma's en -services, zoals CI/CD of pakketbeheer, bevat dit gebied ook mogelijkheden die rechtstreeks tijdens het coderingsproces worden gebruikt, zoals cloudgebaseerde coderingsomgevingen, codescanners en liters en AI-assistenten zoals GitHub Copilot.
- Toepassingsplatform: een gecureerde selectie van services (zoals IaaS, PaaS en waarneembaarheid) die zijn gericht op elke 'app-stack' (toepassingsklasse, app-model, talen) die een organisatie wil gebruiken om bedrijfswaarde te leveren. Dit omvat een combinatie van app-stackspecifieke services en algemene services die overal worden gebruikt. Een voorbeeld van een toepassingsplatform kan Azure Container Apps, Cosmos DB voor opslag, Azure Key Vault voor geheimen, voor op identiteit en rollen gebaseerd toegangsbeheer, Azure Policy voor naleving en controle, waarneembaarheid via Grafana en een gerelateerde netwerktopologie.
- Toepassingssjablonen: Een set goed gedefinieerde, door de organisatie gemaakte, snelstartsjablonen die richtlijnen voor een bepaalde toepassingsplatform, taal en set technische systemen inkapselen die goed beginnen en juist blijven. Ze kunnen verwijzen naar andere gecentraliseerde sjablonen en starterscode, API- en SDK-verwijzingen, CI/CD-pijplijnen, configuratie van hulpprogramma's en meer bieden.
- Selfservicemogelijkheden voor ontwikkelaars: dit is de lijm voor uw platform-engineering. Het is een combinatie van API's, orchestrators, een catalogus, sjablonen en gebruikerservaringen die zijn ontworpen om ontwikkelaars minder werk te laten doen en ontwikkelteams in staat te stellen zichzelf te bedienen en meer autonoom te zijn, terwijl ze zich nog steeds houden aan selecties en richtlijnen/governance uit de vorige drie gebieden.
