DevOps-teamstopologieën

De distributie van rollen, verantwoordelijkheden en vertrouwen tussen IT-teams en toepassingenteams is van cruciaal belang voor de operationele transformatie die betrokken is bij de overstap naar de cloud op schaal.

IT-teams streven ernaar om de controle te behouden. Toepassingseigenaren proberen flexibiliteit te maximaliseren. Het evenwicht dat u uiteindelijk tussen deze twee doelen tot stand brengt, is van invloed op het succes van uw cloudbedrijfsmodel.

Volgens de wet van Conway produceren teams Architecturen op basis van hun communicatiestructuur. Het begrijpen van dit principe is essentieel wanneer u werkt aan het bereiken van de benodigde balans tussen autonomie en controle. Elke organisatie die een systeem ontwerpt (breed gedefinieerd) produceert een ontwerpstructuur die een kopie is van de communicatiestructuur van die organisatie.

Vanuit het oogpunt van DevOps moeten organisaties optimaliseren voor snelle reactie op de behoeften van klanten. Teams die hun toepassingen en systemen bezitten, ontwerpen en implementeren, vinden hun hoogste autonomie in architecturen met de volgende kenmerken:

• Evolutionaire architectuur die constante wijzigingen ondersteunt
• Implementeerbaarheid
• Testbaarheid

Conways oplossing is om de wet van Conway te omzeilen. Als uw organisatie een bepaalde structuur volgt om services en producten te produceren en wilt optimaliseren, moet u uw organisatiestructuur herzien. Ontwikkel uw team en organisatiestructuur om uw gewenste architectuur te bereiken.

Dit principe leidt tot opzettelijk ontworpen teamtopologieën waarin teams verantwoordelijk zijn voor het end-to-end van toepassingen, systemen of platforms die ze bezitten om de volledige discipline van DevOps te bereiken.

De volgende tabel biedt een vereenvoudigde categorisatie van deze teams.

Team type	Definitie
Teams voor toepassingsworkloads	Deze teams bouwen toepassingen die directe bedrijfsresultaten stimuleren voor een segment van het bedrijfsdomein. In de context van Azure Landing Zones zijn deze teams verantwoordelijk voor de end-to-end levenscyclus van toepassingsworkloads.
Platformteams	Deze teams bouwen aantrekkelijke interne platforms om de levering te versnellen en de cognitieve belasting van workloadteams van toepassingen te verminderen. In de context van Azure Landing Zones zijn deze teams verantwoordelijk voor de end-to-end levenscyclus van de Azure Landing Zone.
Teams faciliteren	Deze teams helpen vaardigheidstekorten te overbruggen door andere teams te ondersteunen met gespecialiseerde vaardigheden zoals DevOps.

Ontwerpoverwegingen

• Stel een platformoverschrijdend team in voor het ontwerpen, bouwen, inrichten, beheren en onderhouden van de levenscyclus van uw Azure Landing Zone. Dit team kan leden van uw centrale IT-team, beveiliging, naleving en bedrijfseenheden omvatten om ervoor te zorgen dat een breed spectrum van uw onderneming wordt weergegeven. Zorg ervoor dat u antipatroonvermijdt.

• Overweeg om een inschakelend team te maken dat DevOps-functies kan bieden ter ondersteuning van toepassingen en platforms die geen bestaande DevOps-mogelijkheden hebben, of een bedrijfscase om er een vast te stellen (bijvoorbeeld verouderde toepassingen met minimale ontwikkelmogelijkheden).

• Beperk uw toepassingsworkloadteams niet tot centrale artefacten, omdat dit hun flexibiliteit kan belemmeren. U kunt op beleid gebaseerde governance en op rollen gebaseerd toegangsbeheer van Azure (Azure RBAC) gebruiken om consistente basislijnconfiguraties af te dwingen en ervoor te zorgen dat toepassingsteams (bedrijfseenheid) flexibel genoeg zijn om te innoveren, maar nog steeds kunnen profiteren van een vooraf gedefinieerde set sjablonen.

• Dwing uw toepassingsteams niet af om een centraal proces of inrichtingspijplijn te gebruiken voor het instantiëren of beheren van toepassingsresources. Bestaande teams die al afhankelijk zijn van een DevOps-pijplijn voor het leveren van toepassingen, kunnen nog steeds hun huidige hulpprogramma's gebruiken. Houd er rekening mee dat u Azure Policy kunt gebruiken om organisatiestandaarden af te dwingen en naleving op schaal te beoordelen en beveiligingsoverwegingen voor uw DevOps-processen te beoordelen.

• Een dekentoepassing van een DevOps-model brengt niet direct geschikte DevOps-teams tot stand.

• Investeringen in technische mogelijkheden en resources zijn essentieel.

• Toepassingsteams voor sommige oudere toepassingen hebben mogelijk niet de technische resources die nodig zijn om te worden afgestemd op een DevOps-strategie.

Ontwerpaanaanvelingen

De volgende secties bevatten ontwerpaanbevelingen om u te begeleiden bij het ontwerpen van uw teamtopologieën.

Teamtopologieën afstemmen met uw cloudbedrijfsmodel

Zorg ervoor dat u uw teamtopologieën uitlijnt met het gewenste cloudbedrijfsmodel.

Stel een kernproces in voor operationele fitnessbeoordelingen zodat u de problemen die kunnen voortvloeien uit uw teamstructuren volledig begrijpt.

Functies definiëren voor uw platformteam

De volgende lijst bevat een aanbevolen set functies voor het platformteam dat verantwoordelijk is voor uw Azure Landing Zones:

• Architectuurbeheer
• Abonnement inrichten en delegeren van vereist netwerk-, identiteits- en toegangsbeheerbeleid
• Platformbeheer en -bewaking (holistisch)
• Kostenbeheer (holistisch)
• Platform-as-Code (beheer van sjablonen, scripts en andere middelen)
• Algemene bewerkingen in Microsoft Azure binnen uw Microsoft Entra-tenant (beheer van service-principals, Registratie van Microsoft Graph API en roldefinities)
• Azure RBAC (holistisch)
• Sleutelbeheer voor centrale services (eenvoudig protocol voor e-mailoverdracht en domeincontrollers)
• Beleidsbeheer en afdwinging (holistisch)
• Beveiligingsbewaking en controles (holistisch)
• Netwerkbeheer (holistisch)

Functies definiëren voor uw toepassingsworkloadteams

De volgende lijst bevat een aanbevolen set functies voor uw toepassingsteams die verantwoordelijk zijn voor toepassingsworkloads:

• Toepassingsbronnen maken en beheren via een DevOps-model
• Databasebeheer
• Toepassingsmigratie of -transformatie
• Toepassingsbeheer en -bewaking (toepassingsbronnen)
• Azure RBAC (applicatiebronnen)
• Beveiligingsbewaking en -controles (toepassingsbronnen)
• Geheimen- en sleutelbeheer (toepassingssleutels)
• Kostenbeheer (toepassingsbronnen)
• Netwerkbeheer (toepassingsbronnen)

Functies definiëren voor het inschakelen van teams

De volgende lijst bevat een aanbevolen set functies voor een ondersteuningsteam dat verantwoordelijk is voor het helpen van uw andere teams:

• Definitie van horizontale (cross-function) richtlijnen en mogelijkheden om de juiste expertise in uw organisatie te verkrijgen, wat zorgt voor afstemming met uw algemene cloudbedrijfsmodel (zoals DevOps)
• Ondersteuning, training en coaching voor andere teams om het benodigde expertiseniveau te bereiken
• Het opzetten van een gemeenschappelijke set herbruikbare sjablonen en bibliotheken voor uw toepassings- of platformteams en het bevorderen van InnerSourcing, zoals door Azure geverifieerde modules.

Interactiemodi tussen teams definiëren

De doelstellingen van interacties tussen uw teams zijn:

• Autonomie bereiken
• Blokkering van afhankelijkheden opheffen
• Verspillingstijd minimaliseren
• Knelpunten voorkomen

Team Topologieën beschrijft drie interactiemodi voor teams:

Interactiemodus	Beschrijving
samenwerking	Teams werken nauw samen.
X-as-a-Service	Teams gebruiken of bieden iets aan andere teams met minimale samenwerking, vergelijkbaar met interacties van externe leveranciers.
vergemakkelijken	Teams helpen of worden geholpen door een ander team om belemmeringen te verwijderen.