Self-service utan att bygga en portal
Portalen är äntligen live. Ett halvår och tre utvecklare på heltid har den kostat: en katalog över alla tjänster, färdiga mallar, en knapp som skapar en ny miljö, och en backlog med plugins som fortfarande växer. Samma vecka beställer ett team sin första riktiga miljö genom portalen. Bakom knappen skapas en ticket i någon annans kö. Väntan är densamma, den har bara fått ett snyggare gränssnitt.
Self-service har blivit synonymt med portal. Det är ett dyrt missförstånd.
Portalen är gränssnittet, inte lösningen
Prata med ett plattformsteam om self-service och inom fem minuter handlar samtalet om en developer portal: Backstage, Port eller något egenbyggt. Det är begripligt. Portalen är den synliga delen, den som går att visa på en demo och peka på i en roadmap.
Men self-service är inte samma sak som en produkt. Det är en egenskap: ett team får det de behöver utan att vänta på ett annat team. Portalen är ett av flera möjliga gränssnitt till den egenskapen, men gränssnittet är det minst viktiga lagret. En portal utan automation bakom är bara en snyggare kö: formuläret ser modernt ut, men det som händer efter att någon klickat på skicka är samma väntan som förut.
Tre saker gör self-service, ingen är en portal
Färdiga byggblock med vettiga defaults. En modul för en miljö, en databas, ett namespace, där det säkra valet redan är förvalt. Teamet ska behöva ange det som är unikt för dem, inget annat.
Ett sätt att beställa utan att fråga. Teamet ska själva kunna uttrycka vad de behöver, i ett format som går att validera maskinellt. En fil i ett git-repo räcker.
Automatisk verkställighet. När beställningen är godkänd ska den rullas ut utan att en människa i plattformsteamet gör något. GitOps eller en pipeline, valet spelar mindre roll. Det manuella steget ska bort.
Lägg märke till att alla tre är osynliga. Inget av det här går att visa på en demo. Det är också därför det så ofta prioriteras bort till förmån för portalen, trots att det är här värdet sitter.
Gränssnittet finns redan
Många portalprojekt utgår från att det grafiska gränssnittet är den största friktionen. För utvecklare är det ofta inte där friktionen ligger. Det de vill ha är att slippa byta sammanhang, att inte behöva lämna editorn och terminalen och logga in i ett separat verktyg bara för att beställa en miljö. För många utvecklingsteam är det bästa gränssnittet det de redan har öppet: koden och git.
Så en fil i ett repo och en pull request slår en portal för de flesta team. Inte för att det ser bättre ut, utan för att det inte kräver att någon lär sig ett nytt verktyg eller lämnar det de redan gör. Tröskeln är låg för ett team som redan jobbar så.
Men vänta, en granskning, försvinner inte self-service då? Nej. Self-service betyder inte noll granskning. Det betyder att ingen annans kö är inblandad. Granskaren sitter i samma team och samma standup, så väntan mäts i minuter, inte dagar. Kontrollen stannar där kostnaden för fördröjningen faktiskt bärs.
Det här flyttar fokus från verktyget till flödet. Ett repo, ett schema och ett deployflöde som redan finns kan ge ett team ett fungerande gränssnitt på några dagar. Ett portalprojekt kan sluka ett halvår innan det första riktiga flödet fungerar. De flesta organisationer har redan delarna, de har bara inte insett att det färdiga gränssnittet redan ligger öppet på utvecklarnas skärmar.
Vad portalen faktiskt kostar
Jag har inget emot Backstage, det är ett imponerande stycke ingenjörskonst. Jag har något emot att börja där. Backstage är inte en produkt du installerar. Det är ett ramverk du bygger en produkt med: en TypeScript-applikation som ditt team äger, med plugins som ska uppgraderas, en katalog som ska hållas ren och en drift som aldrig tar slut. Backstage kommer från Spotify och växte fram i en helt annan skala än ett litet plattformsteam.
Om ditt plattformsteam är tre personer är kalkylen en annan. Då blir portalen inte ett gränssnitt till plattformen. Den blir plattformsteamets huvudprodukt, medan den riktiga plattformen, byggblocken och automationen, blir det som hinns med vid sidan av. Det är att bygga skyltfönstret innan butiken har ett lager.
När portalen förtjänar sin plats
Det finns ett läge där portalen är rätt: när automationen redan fungerar och friktionen som återstår handlar om överblick. Femtio team, hundratals tjänster, och ingen vet längre vad som finns, vem som äger vad eller hur man kommer igång. En katalog och en samlad ingång löser ett verkligt problem där.
Byggs den i den ordningen blir portalen ett avgränsat projekt. Den blir ett skal ovanpå samma PR-flöden och API:er som redan gör jobbet, inte ett system med egen logik. Ordningen är hela poängen: automation först, portal sist.
Ställ motfrågan
Börja med byggblocken, PR-flödet och automationen. Portalen kan vänta. När den väl behövs blir den grädden på moset, inte hela investeringen.
Och nästa gång någon demar en portal och kallar den self-service, ställ motfrågan: vad händer efter att formuläret har skickats? Rullar något ut är det self-service. Blir det en ticket är det en snyggare kö.
Står ni inför ett portalbeslut, eller vill ni ha self-service som fungerar redan nästa kvartal? Så jobbar jag.