Platform engineering v roce 2026: kdy se interní platforma vyplatí

Co data o platformách skutečně říkají

Platform engineering je podle definice DORA sociotechnická disciplína: tým staví sdílené nástroje, služby a „golden paths“, po kterých ostatní týmy dostanou aplikaci bezpečně do provozu bez toho, aby musely rozumět celé infrastruktuře. Podstatné je slovo sociotechnická. Většina neúspěchů nemá technickou příčinu.

Nejcitovanější čísla pocházejí z reportu DORA 2024. Uživatelé interní platformy byli o 8 % produktivnější, jejich týmy podávaly o 10 % lepší výkon a výkonnost organizace v dodávání a provozu softwaru vyšla o 6 % výš. Tentýž report ale u týchž respondentů naměřil přibližně o 8 % nižší throughput a o 14 % nižší stabilitu změn než u těch, kdo platformu nepoužívají.

Druhá polovina té věty se v prezentacích pro vedení obvykle vynechává. DORA ji přitom nepovažuje za okrajovou: v souhrnu hlavních zjištění vedle přínosu pro produktivitu výslovně zmiňuje „varovné signály“ pro výkonnost dodávání softwaru a v kapitole o platformách doporučuje upřednostnit funkce, které vývojářům dávají samostatnost.

Proč může platforma dodávání zpomalit? Report sám nabízí několik hypotéz a žádnou nepovažuje za potvrzenou. Platforma přidává další mechanismy, kterými změna musí projít, a další předávky mezi systémy. Dává týmům jistotu pouštět se do rizikovějších změn, nebo její automatické kontroly kvality nestačí. Anebo ji firmy zavádějí právě tam, kde už dodávání drhne. Ve všech případech pomáhá totéž: samoobsluha. Podle DORA přináší dalších 5 % produktivity, když vývojář dokončí úkol bez zásahu platformního týmu.

Rok 2026: platforma jako podmínka pro AI

Report DORA 2025, postavený na odpovědích téměř 5 000 lidí z oboru, posunul debatu jinam. AI v práci používá 90 % respondentů a 90 % organizací má aspoň jednu interní platformu; podle DORA má 76 % z nich vyhrazený platformní tým. Hlavní závěr: AI funguje jako zesilovač. Kde je platforma kvalitní, má zavedení AI silný pozitivní vliv na výkonnost organizace. Kde je slabá, je vliv zanedbatelný.

Totéž vydání potvrzuje, že AI má nadále negativní vztah ke stabilitě dodávání. Víc změn rychleji znamená víc příležitostí něco rozbít, pokud chybí automatické testy, rychlá zpětná vazba a mantinely v pipeline. Tyto mantinely jsou přesně to, co má platforma poskytovat. Podrobněji se nasazování v éře AI věnuje článek o automatizaci deploymentu.

Stejným směrem míří i dodavatelské průzkumy, které je ovšem potřeba brát s vědomím, kdo je platí. Perforce (Puppet) v červenci 2026 zveřejnil výsledky od 820 respondentů: AI v infrastrukturních workflow používá 66 % organizací, ale plně autonomní AI hlásí jen 31 %. U organizací se zralou interní platformou (IDP) je to 44 %.

Na jarním KubeConu v Amsterdamu CNCF a SlashData 24. března 2026 představily Technology Radar, podle kterého 35 % organizací integruje AI workloady hybridně – přidává specializované nástroje ke stávající platformě, místo aby stavělo novou. Maintaineři Backstage tam podle shrnutí z BackstageConu (začal 23. března) a KubeConu představili rozpracovanou podporu MCP a směr „AI-native“ portálu.

Kdy se platforma vyplatí a kdy je to drahá hračka

Platforma je investice s fixními náklady: lidé, kteří ji staví a udržují, nedodávají funkce zákazníkům. Vrací se jen tehdy, když odstraňuje opakovanou práci dostatečně mnoha týmům. Rozhodnutí proto nezávisí na trendu, ale na několika měřitelných znacích.

Poslední řádek je nejčastější důvod, proč platformní iniciativy selhávají. Portál nad neuspořádanou infrastrukturou nic nevyřeší, jen přidá další věc k údržbě. Kdo nemá hotové základy, má začít u nich – viz článek o chaosu v infrastruktuře před zaváděním AI.

Protiargument je legitimní: malá firma s jedním produktem si vystačí se slušnou pipeline, sdíleným Terraform modulem a dokumentací. To není selhání, to je správně dimenzované řešení.

Minimální životaschopná platforma pro 20–100 vývojářů

White paper CNCF o platformách definuje platformu jako integrovanou sadu schopností nabízenou podle potřeb jejích uživatelů a připomíná, že velmi jednoduchou „platformou“ může být i wiki stránka s odkazy na standardní postupy. DORA mezi doporučeními uvádí totéž jinými slovy: začít minimální životaschopnou platformou pro nejběžnější workflow.

Pro firmu této velikosti to v praxi znamená čtyři stavební kameny:

• Jedna až tři golden paths. Šablona repozitáře pro nejčastější typ služby: kostra aplikace, Dockerfile, pipeline s testy a bezpečnostními kontrolami, manifesty pro deployment, základní dashboard a alerty. Jak má taková pipeline vypadat, popisuje stránka Ideální pipeline.
• Samoobslužná prostředí a zdroje. Databáze, fronta nebo namespace vzniknou pull requestem do repozitáře s ověřenými moduly, ne ticketem.
• Mantinely v kódu. Politiky (např. OPA), limity a povinné kontroly jsou součástí cesty, takže bezpečná varianta je zároveň ta nejsnazší.
• Dokumentace a evidence vlastnictví. Kdo službu vlastní, kde běží, jak se nasazuje. Stačí soubor v repozitáři a vygenerovaný přehled.

Evidence vlastnictví nemusí čekat na portál. Popisný soubor ve formátu, který používá Backstage, lze zavést hned a portál nad ním postavit později:

apiVersion: backstage.io/v1alpha1
kind: Component
metadata:
  name: fakturace-api
  description: REST API pro vystavování faktur
  annotations:
    github.com/project-slug: firma/fakturace-api
spec:
  type: service
  lifecycle: production
  owner: tym-finance
  system: fakturace

Kdo to má dělat

Orientačně: malý tým s jasným mandátem, ve kterém aspoň jeden člověk dělá produktovou práci – mluví s vývojáři, určuje priority, říká ne. Nemusí to být samostatná pozice. Průzkum komunity Platform Engineering mezi 518 praktiky uvádí, že vyhrazeného platformního produktového manažera má jen 21,6 % organizací a 25,4 % nemá produktové myšlení vůbec. U 13,1 % stojí platforma na dobrovolné, nefinancované práci, což odpovídá nejnižšímu stupni zralosti.

Backstage, alternativy a otázka, zda portál vůbec potřebujete

Backstage je open-source framework pro vývojářské portály, původně ze Spotify, dnes projekt CNCF. V březnovém radaru CNCF a SlashData se spolu s Helmem a kro umístil v kategorii „adopt“ pro doručování aplikací. To z něj dělá výchozí volbu – a zároveň nejčastější past.

Backstage není hotový produkt, ale framework. Vyžaduje vývoj v TypeScriptu, údržbu pluginů a pravidelné upgrady. Pro firmu se stovkami vývojářů je to rozumná cena za flexibilitu. Pro firmu s padesáti vývojáři může provoz portálu spotřebovat kapacitu, která měla jít do golden paths.

Rozhodující není nástroj, ale pořadí. Portál je rozhraní k platformě, ne platforma sama. Pokud za tlačítkem „vytvořit službu“ nestojí funkční automatizace, vznikne hezký rozcestník, který nikdo neotevírá.

Platforma jako produkt: metriky a model zralosti

Model zralosti platform engineeringu od CNCF hodnotí pět oblastí – investice, adopci, rozhraní, provoz a měření – na čtyřech stupních od „provisional“ po „optimizing“. Užitečný je hlavně jako zrcadlo. U adopce rozlišuje stav, kdy jsou týmy na platformu tlačeny zvenčí („extrinsic push“), od stavu, kdy ji chtějí samy („intrinsic pull“).

Podle zmíněného průzkumu Platform Engineering závisí 36,6 % organizací stále na nařízení shora a jen 28,2 % hlásí, že uživatelé platformu používají kvůli její vlastní hodnotě. Ještě výmluvnější je měření: 29,6 % organizací neměří úspěch platformy vůbec a 24,2 % neví, zda se jejich metriky zlepšily.

Platforma, jejíž přínos nikdo nezná, je první položka na seznamu při škrtání rozpočtu. Stačí přitom málo:

DORA k tomu přidává jedno konkrétní vodítko pro priority: mezi doporučeními pro platformní týmy vyzdvihuje jasnou zpětnou vazbu o výsledku úkolu. Vývojář má po spuštění pipeline nebo žádosti o prostředí okamžitě vidět, co se stalo a proč to případně selhalo.

Anti-patterny, které platformu spolehlivě pohřbí

DORA na stránce věnované platform engineeringu jmenuje pět typických pastí. Každou lze rozpoznat podle konkrétního příznaku:

• „Postavíme to a oni přijdou.“ Platforma vzniká bez rozhovorů s uživateli. Příznak: roadmapa obsahuje technologie, ne problémy vývojářů.
• Věž ze slonoviny. Standardy přicházejí shora bez možnosti výjimky. Příznak: týmy si staví stínové pipeline.
• Ticket-ops. Platformní tým je přejmenovaný provoz, který vyřizuje žádosti. Příznak: fronta ticketů roste s počtem vývojářů.
• Velký třesk. Rok práce na dokonalé platformě před prvním uživatelem. Příznak: žádný tým ji nepoužívá v produkci po prvním čtvrtletí.
• Jedna velikost pro všechny. Stejná cesta pro webovou službu, datovou pipeline i ML model. Příznak: nejvíc výjimek žádají týmy s nejvyšší přidanou hodnotou.

K tomu patří jeden rok 2026 specifický: stavět kvůli AI druhou, oddělenou platformu. Průzkum Platform Engineering uvádí, že 55,9 % organizací už provozuje více než jednu platformu. Každá další znamená další sadu mantinelů k údržbě – a AI agent, který generuje infrastrukturu, potřebuje stejné politiky jako člověk.

Co udělat v pondělí

Rozhodnutí o portálu, Backstage a rozšiřování týmu odložte, dokud první golden path nepoužívají aspoň dva týmy dobrovolně. Do té doby by šlo o investici do rozhraní k něčemu, co ještě neexistuje.

Klíčové poznatky

• Přínos není zaručený. DORA 2024 naměřila u platforem vyšší produktivitu (8 %) i nižší throughput (8 %) a stabilitu změn (14 %). Bez měření nelze poznat, na které straně firma je.
• AI zvyšuje sázky. Podle DORA 2025 rozhoduje kvalita platformy o tom, zda se zavedení AI projeví na výkonnosti organizace.
• Začít tence. Jedna až tři golden paths, samoobsluha přes Git a mantinely v kódu. Portál až poté.
• Platforma je produkt. Potřebuje vlastníka, uživatelský výzkum a metriky; téměř 30 % organizací přitom úspěch platformy neměří vůbec.
• Čísla o rozšíření se liší násobně. Od 28 % do 76 % organizací s vyhrazeným týmem podle zdroje. Rozhodovat se má podle vlastních úzkých míst, ne podle trendu.
• Pro malé firmy s jedním stackem je dobrá pipeline, sdílené moduly a dokumentace dostatečné řešení.