Close

Hoe je de wildgroei van software kunt inperken

Drie tekenen dat je te maken hebt met een wildgroei in software en wat je eraan kunt doen

Headshot van Andrew Boyagi
Andrew Boyagi

Senior Evangelist


De monoliet verdwijnt snel. Talloze bedrijven over de hele wereld gebruiken nu een losjes gekoppelde architectuur voor de ontwikkeling van software. Gedistribueerde, autonome teams verdelen monolithische toepassingen in verzamelingen van componenten, zoals microservices.

Waarom? Een losjes gekoppelde architectuur maakt het eenvoudiger om de prestaties en veerkracht van software op te schalen en tegelijkertijd het risico en de doorlooptijd te verminderen om nieuwe toepassingsfuncties te leveren. De voordelen zijn ook niet alleen beperkt tot software. Een losjes gekoppelde architectuur stelt teams in staat om zelfstandig te werken en regelmatig wijzigingen door te voeren die nuttig voor gebruikers zijn. Autonome teams die software maken in een losjes gekoppelde architectuur hebben een hoger niveau van geluk, betrokkenheid en productiviteit.

Nieuwe manieren van werken brengen echter nieuwe uitdagingen met zich mee. Door een dynamische en schaalbare omgeving te creëren waarin afzonderlijke componenten onafhankelijk van elkaar worden gebouwd, neemt de complexiteit toe. Dit leidt tot een nieuw soort uitdaging: wildgroei in software.

Compass-logo.

Compass gratis uitproberen

Verbeter je ontwikkelaarservaring, catalogiseer alle services en verbeter de gezondheid van je software.

illustratie van blokken

Wat is wildgroei van software?


Software-wildgroei is wanneer het aantal toepassing- of softwarecomponenten binnen een omgeving snel groeit en verandert, waardoor de complexiteit aanzienlijk toeneemt en traditionele methoden voor softwarebeheer falen. Dit scenario komt meestal voor als het tempo toeneemt in een gedistribueerde softwarearchitectuur.

Het moderniseren van zelfs een enkele monolithische toepassing zal waarschijnlijk resulteren in honderden microservices die worden beheerd door meerdere teams die onafhankelijk en regelmatig nieuwe productfuncties releasen. De uitbreiding hiervan naar een toepassingsportfolio houdt mogelijk in dat duizenden microservices in meerdere ontwikkelingsteams moeten worden geïntroduceerd. Het is geen verrassing dat traditionele manieren om zelfs een kleine toepassingsportfolio te beheren waarschijnlijk niet op lange termijn succesvol zullen zijn. Tijdens de weg van Atlassian naar duizenden microservices die vandaag de dag ten grondslag liggen aan onze producten, ontdekten we dat het inperken van de wildgroei van software essentieel was om de kracht van een losjes gekoppelde architectuur en autonome teams te ontsluiten.

pictogram code-store
gerelateerd materiaal

Microservices vs. monolithische architectuur

Pictogram van drie ringen
Oplossing bekijken

Verbeter je DevEx met Compass

De symptomen van een wildgroei aan software kunnen in het begin moeilijk te herkennen zijn. Het kan beginnen met kleine ergernissen die terzijde worden geschoven ten gunste van dingen met hogere prioriteit. Maar als er niets aan wordt gedaan, kan een wildgroei ontwikkelteams met een hogere cognitieve belasting verlammen, de betrokkenheid van teams verminderen en de voordelen van een losjes gekoppelde architectuur ongedaan maken. Zoals het spreekwoord zegt: '20 jaar geleden was het beste moment om een boom te planten. Het beste moment daarna is nu.' Met andere woorden, succes in de toekomst is gebaseerd op het temmen van de wildgroei aan software voordat het een probleem wordt.

Hieronder vind je de drie tekenen van een wildgroei in software en wat je kunt doen om de chaos het hoofd te bieden en tegelijkertijd een innovatieve en dynamische omgeving te creëren die het potentieel van elk team benut.

Beoordelingen na incidenten identificeren upstream veranderingen als hoofdoorzaak


Een vroeg symptoom van wildgroei in software is wanneer meerdere beoordelingen na een incident (PIR's) erop wijzen dat upstream veranderingen de hoofdoorzaak van een incident zijn. Een groeiend aantal microservices en een toenemend aantal veranderingen binnen een omgeving kunnen de bestaande normen op het gebied van samenwerking tussen ontwikkelaars en de coördinatie van veranderingen onder druk zetten. Zelfs een kleine verhoging van de veranderingsfrequentie van maandelijks naar wekelijks voor één gemoderniseerde toepassing kan resulteren in 100 keer meer releases per maand. Geen wonder dat ontwikkelaars hun manier van samenwerken moeten aanpassen. Incidenten doen zich vaker voor in de productie wanneer de normen voor samenwerking tussen ontwikkelaars niet schaalbaar zijn in een snel veranderende omgeving.

Het creëren van een niet-opdringerige manier voor ontwikkelaars om op de hoogte te zijn van upstream en downstream veranderingen is een geweldige manier om de impact van de wildgroei in software in te perken. Binnen Atlassian gebruiken we Compass — een portal voor ontwikkelaars dat teams helpt gedistribueerde architecturen te navigeren — om ontwikkelingsteams in-app notificaties te sturen over ingrijpende veranderingen in de upstream en downstream services. Het bevestigen van deze notificatie geeft de initiatiefnemer van de verandering een signaal dat teams die verantwoordelijk zijn voor afhankelijke services op de hoogte zijn van de verandering. Dit biedt de mogelijkheid om samen te werken aan de verandering als er problemen worden verwacht, waardoor de kans op onbedoelde gevolgen voor de productie wordt verkleind. Aangezien incidenten zich onvermijdelijk voordoen in een dynamische omgeving, is samenwerking tussen ontwikkelaars tijdens een incident van cruciaal belang om services snel te herstellen.

In beoordelingen na een incident waarbij upstream veranderingen de hoofdoorzaak zijn, komt het vaak voor dat de tijd om services te herstellen wordt beïnvloed door de tijd die nodig is om de problematische upstream verandering vast te stellen, samen met het team of de persoon die eigenaar is van de service. Het is logisch dat het verkorten van de tijd die nodig is om de foutieve upstream verandering te identificeren, uiteindelijk ook de gemiddelde tijd tot herstellen (MTTR) verkort. Dit wordt lastiger bij een losjes gekoppelde architectuur, waar services een uitgebreide afhankelijkheidshiërarchie hebben en de hoofdoorzaak van een incident overal plaats kan vinden. Van oudsher doorzoeken incidentresponders de logboeken of veranderingsrecords om vast te stellen welke wijziging mogelijk een incident heeft veroorzaakt. In een dynamische omgeving is dit vergelijkbaar met het zoeken naar een speld in een hooiberg.

Binnen Atlassian gebruiken we de activiteitsfeed in Compass om de MTTR te verminderen. Hierin worden alle gebeurtenissen voor upstream systemen weergegeven, samen met de gegevens van het team dat eigenaar is. Dit verkort de tijd voor het sorteren aanzienlijk door de samenwerking tussen ontwikkelaars te ondersteunen tijdens een incident. Incidenten zullen voor blijven komen, maar het tijdig identificeren van een upstream verandering als hoofdoorzaak van een incident is van cruciaal belang om ervoor te zorgen dat de impact tot een minimum wordt beperkt en de services snel worden hersteld.

Wildgroei van software

De activiteitsfeed in Compass toont alle gebeurtenissen voor upstream systemen, waardoor de tijd voor het sorteren tijdens een incident wordt verkort.

De output van het team is hoog, maar er wordt niets afgerond


De overgang naar een losjes gekoppelde architectuur is één van de belangrijkste onderdelen voor het creëren van de productiviteit en het welzijn van een team: het vermogen om zelfstandig en met veel autonomie te kunnen handelen. Als er niets aan wordt gedaan, kan een wildgroei van software sommige van deze voordelen teniet doen, wat resulteert in een druk maar onproductief en ongelukkig team. Een veelgehoorde klacht bij gesprekken met ontwikkelingsteams is "alles werkt goed totdat we met een ander team in contact moeten komen." Dit wordt nog versterkt wanneer de wildgroei van software een probleem veroorzaakt. Een snel groeiende en veranderende omgeving beperkt de mogelijkheid voor ontwikkelaars om bij te houden wie ze moeten inschakelen voor upstream- en downstream-afhankelijkheden, wat uiteindelijk resulteert in een vertraging en een toename van frustratie bij teams die proberen om snel te presteren.

Hypothetisch gezien kunnen Alpha-team en Beta-team elke week hetzelfde aantal issues en storypoints in Jira naar 'voltooid' verplaatsen. Het Alpha-team besteedt 90 procent van zijn inspanningen om nieuwe functies naar productie te brengen, terwijl het Beta-team 30 procent besteedt aan nieuwe functies en 70 procent aan het uitzoeken hoe ze kunnen omgaan met de vele upstream-services waar ze afhankelijk van zijn. Beide teams hebben dezelfde hoeveelheid output, maar waarschijnlijk wordt alleen Alpha als productief beschouwd. De wildgroei van software maakt de behoefte aan samenwerking tussen teams duidelijker. Het vinden van slimme manieren waarop autonome teams on-demand betrokken kunnen zijn is essentieel om de kracht van een losjes gekoppelde omgeving te benutten.

In een snel groeiende en dynamische omgeving is het vermogen om informatie zelf te beheren belangrijk voor de productiviteit en het welzijn van een team. Eén manier om dit te bereiken is door een gecentraliseerde softwarecomponentencatalogus te implementeren met gedecentraliseerd beheer; dit is een gecentraliseerde catalogus waarbij elk team verantwoordelijk is voor het creëren en updaten van de services die ze bezitten. Traditionele omgevingen hebben gewoonlijk een gecentraliseerde catalogus die wordt beheerd door een specifiek team of specifieke functie. Dit kan echter de snelheid waarmee veranderingen plaatsvinden in een gedistribueerde omgeving niet bijhouden, waardoor teams schaduw-wiki's gaan maken over met wie en hoe ze moeten handelen. Binnen Atlassian hebben we vastgesteld dat een gedecentraliseerde aanpak de onzichtbare en verspilde moeite tussen teams vermindert, de mogelijkheden voor zelfbediening verbetert en een omgeving creëert met on-demand betrokkenheid. Het tegengaan van de wildgroei in software door zelfbedieningsinformatie over upstream- en downstream-afhankelijkheden beschikbaar te maken, is een geweldige manier om de productiviteit van teams te verbeteren, met aanvullende effecten op het welzijn en de betrokkenheid van het team.

Screenshot van de gebruikersservice van Compass.

Compass biedt een centrale locatie voor informatie speciaal voor ontwikkelaars over de softwarecomponenten die zij bezitten en waarvan ze afhankelijk zijn.

Veranderingsmanagement wordt het knelpunt


Een ander belangrijk teken van een wildgroei in software is wanneer toezichtsfuncties, zoals verandermanagement en cyberbeveiliging, steeds meer een knelpunt worden voor het doorvoeren van veranderingen in productiesystemen. Deze functies spelen een cruciale rol in het zorgen dat aan de standaarden en verwachtingen van de organisatie wordt voldaan voordat veranderingen in de productie worden doorgevoerd. Ze worden echter minder effectief als er wildgroei van software plaatsvindt. In een omgeving met een wildgroei van software raken toezichtsfuncties geleidelijk overbelast naarmate het tempo van veranderingen toeneemt, waardoor er een backlog ontstaat aan wijzigingen en aanvragen die moeten worden beoordeeld, waardoor productie-implementaties worden vertraagd. Uit het 2022 rapport over de status van DevOps bleek dat 56 procent van de respondenten van mening was dat de softwarebeveiligingsprocessen van hun organisatie het ontwikkelingsproces vertragen.

In een ideale wereld worden beveiligingspraktijken geïntegreerd in ontwikkelingsprocessen, maar in werkelijkheid hebben veel organisaties mensen die veranderingen beoordelen voordat de productie wordt geïmplementeerd. Dit is niet effectief op de schaal die nodig is in een gedistribueerde omgeving. Het vertraagt niet alleen het vermogen van de organisatie om veranderingen teweeg te brengen, maar kan ook leiden tot frictie tussen ontwikkelingsteams en degenen die ervoor moeten zorgen dat aan de standaarden van de organisatie wordt voldaan.

In een omgeving met veel wildgroei van software is het van cruciaal belang om hoge snelheid mogelijk te maken en tegelijkertijd op grote schaal te voldoen aan de gewenste standaarden van de organisatie. Geautomatiseerde of deels geautomatiseerde scorecards zijn een uitstekende manier om standaarden van de organisatie duidelijk te maken en het is een niet-opdringerige manier om de naleving in de hele omgeving te controleren. Bij Atlassian gebruiken we Compass om de kwaliteitsstandaarden en verwachtingen van organisaties vast te stellen — de scorecard voor elk softwarecomponent geeft de organisatie transparantie over naleving. Teams en technische leiders kunnen standaarden voor producten toevoegen aan scorecards, zodat iedereen in de organisatie een volledig overzicht krijgt van de kwaliteitsverwachtingen en -statussen van de organisatie. Dit is een belangrijke verschuiving van toezicht- en nalevingscontroles aan het einde van een leveringscyclus naar het vroegtijdig formuleren van verwachtingen en teams de mogelijkheid te geven om daar tijdens het ontwikkelingsproces aan te voldoen. Toezichtsteams kunnen verwachtingen stellen in een dynamische omgeving, terwijl leveringsteams de mogelijkheid hebben om de vereisten tijdens de leveringscyclus te begrijpen en eraan te voldoen. Aangezien de impact van een wildgroei van software schadelijk kan zijn voor zowel de softwarelevering als de toezichtsteams, bieden scorecards een mogelijkheid om wildgroei onder controle te krijgen.

afbeelding van gegevensbeveiliging

De scorecard van Compass wordt gebruikt om inzicht te krijgen in de gezondheid van softwarecomponenten, aan de hand van een aantal gedefinieerde verwachtingen.

Conclusie...


Er is geen wondermiddel om de wildgroei van software tegen te gaan. Maar succes op lange termijn is gebaseerd op het vroegtijdig identificeren en aanpakken van de gevolgen van een wildgroei van software. Enkele van de eerste indicatoren van een wildgroei van software zijn als meerdere incidenten veroorzaakt worden door upstream en downstream veranderingen, drukke teams die hun doelen niet halen en knelpunten in het toezicht. De beste manier om de wildgroei van software te identificeren, is door met je ontwikkelaars te praten en inzicht te krijgen in de uitdagingen waarmee ze worden geconfronteerd.

Atlassian heeft Compass ontwikkeld om wildgroei van software in te perken door de complexiteit van gedistribueerde architecturen te beheren terwijl ze schalen. Compass is een uitbreidbaar ontwikkelaarsplatform dat verspreide informatie over engineeringoutput en teamsamenwerking samenbrengt op één centrale, doorzoekbare locatie.

Meer informatie over Compass

Andrew Boyagi
Andrew Boyagi

Andrew leidt DevOps Evangelism bij Atlassian en heeft meer dan 20 jaar ervaring in softwarelevering en servicebeheer in bedrijfsorganisaties. Hij biedt een praktisch perspectief op hoe teams en organisaties de voordelen van DevOps maximaal kunnen benutten op basis van ervaringen uit de praktijk.
Voordat hij bij Atlassian kwam, was Andrew Executive Manager bij de Commonwealth Bank of Australia, waar hij een platformtechnische functie oprichtte en ontwikkelde die 7.000 engineers ondersteunde. Andrew heeft een MBA behaald aan de Southern Cross University.


Deel dit artikel
Volgend onderwerp

Aanbevolen artikelen

Bookmark deze resources voor meer informatie over soorten DevOps-teams of voor voortdurende updates over DevOps bij Atlassian.

Toelichting DevOps

Compass-community

illustratie obstakels overwinnen

Tutorial: Een component aanmaken

Afbeelding van kaart

Ga gratis aan de slag met Compass

Meld je aan voor onze DevOps-nieuwsbrief

Thank you for signing up