Het vinden en doorbreken van ‘bottlenecks’ is een cruciaal onderdeel van de software lifecycle

Abonneer je gratis op Techzine!

De best presterende organisaties hebben de ‘flow’ van software, van idee tot productie en van productie naar gebruik, op orde. Hierdoor kunnen ze hun software continu innoveren. Een goed georganiseerde software supply chain zorgt ervoor dat de gehele toeleveringsketen is geoptimaliseerd voor het algemeen belang van het bedrijf. Dit betekent dat alle activiteiten op elkaar zijn afgestemd voor het ontwikkelen en leveren van software. Organisaties die goed zijn in software delivery hebben oog voor de gehele keten en bestuderen de bottlenecks.

Het idee van een software supply chain bestaat al een hele tijd. Enkele decennia geleden had Eliyahu Goldratt al het inzicht dat het belangrijk is om je te focussen op de ‘bottlenecks’ die de toeleveringsketen vertragen. Activiteiten die vertragen bepalen immers het tempo van de gehele software supply chain en dus ook de groei van een organisatie. Om deze ‘bottlenecks’ te vinden is het zaak om de hele waardeketen goed inzichtelijk te hebben. Zodra deze in kaart is gebracht ben je pas in staat om de ‘bottlenecks’ te vinden. Hoewel er veel soorten zijn, beschrijf ik in dit artikel vijf knelpunten die ik regelmatig tegenkom bij organisaties.

Budget, financiën en planning

Het bepalen van een strategie en planning is een veelvoorkomende ‘bottleneck’. Hoewel het meestal niet aan ideeën ontbreekt, kost het vaak veel tijd om te beslissen in welke activiteiten er als eerste moet worden geïnvesteerd. Vaak gaan hier lange discussies aan vooraf omdat er intern vaak wordt gestreden om mensen en middelen. Sommige individuen denken hierbij meer aan het belang van het team of de divisie waar ze onderdeel van uitmaken, terwijl het algemeen belang van de organisatie wordt ondergesneeuwd.  

Een ander element is teveel tegelijkertijd willen doen. Strategie, planning en financiën worden vaak op jaarbasis vastgesteld. Dit brengt een enorm risico met zich mee, omdat een heel jaar verloren kan gaan als de uitvoering mislukt. Dergelijke risico’s zorgen weer voor meer afstemming over de executie omdat het een enorme impact kan hebben op een organisatie. Om deze ‘bottleneck’ te doorbreken is het belangrijk dat er ruimte is voor kleinere financiële plannen binnen een totale budget planning. Werk bijvoorbeeld in stappen van drie maanden, waardoor een project kan doorgaan met nieuwe inzichten vanuit de markt wanneer het product of de feature is ‘geleverd’. Op deze manier is het risico kleiner. Bovendien biedt het de kans om aanpassingen en veranderingen aan te brengen of een idee verder te optimaliseren als het succesvol is.

Infrastructuur

Zodra bedrijven van de strategie bij de software ontwikkelingsfase zijn beland, doemen er weer tal van ‘bottlenecks’ op. Hoe belachelijk het ook klinkt in deze tijd, het kost vaak maanden voordat een team van developers aan de slag kan. Er moeten aanvragen worden gedaan voor nieuwe development omgevingen, netwerken, security configuraties en setups. Bij on-premise installaties kan het indienen van aanvragen voor nieuwe servers en infrastructuur lang duren en er moet vaak budget worden aangevraagd bij de directie. Door te kiezen voor het juiste cloud-native platform, die dit automatiseren, kunnen deze knelpunten worden opgelost.

Tegen het einde van de software ontwikkelingsfase duikt de infrastructuur weer op als ‘bottleneck’. In veel gevallen is de manier waarop software wordt ‘gepackaged’, ‘released’ en vervolgens tijdens de productie wordt beheerd gespecialiseerd werk. Dit vergt nieuw overleg, tooling en verificatie. Het schalen, monitoren en troubleshooten van software in productie is  een ander type specialisatie dan development. Dankzij het DevOps-denken zijn veel van deze ‘bottlenecks’ opgelost met de ‘shift left’ aanpak. Ontwikkelaars zouden hierbij productiegereedheid en functionaliteit moeten zien als onderdeel van de software die ze maken. IT-beheer zou juist meer kunnen kijken naar het werk van developers.

Architectuur

Een soortgelijk probleem doet zich voor rond de enterprise architectuur. Er moet immers besloten worden hoe er getest en concurrerende proof-of-concepts gebouwd kunnen worden. Om nog maar te zwijgen over de beslissingen rondom de evaluatie, documentatie en het trainen van de ontwikkelaars. Dit is veel op zichzelf, maar wat veel organisaties vergeten is dat de architectuur ook regelmatig onderhouden en geanalyseerd moet worden. Organisaties vinden vaak dat hun bedrijfsvoering uniek is, en dat hierdoor de architectuur ook uniek en passend moet zijn voor de IT omgeving. De realiteit is dat er veel bestaande en bewezen architectuurprincipes en bijbehorende toolsets bestaan, zoals data en middleware technologieën. Als organisaties ervoor kiezen om zelf de architectuur te bepalen en te implementeren, beseffen ze vaak niet dat de architectuur net zo snel moet kunnen worden ontwikkeld als de delen die het beschrijft. Architectuur is immers een ‘levend organisch geheel’, die vaak een heranalyse nodig heeft wanneer een nieuwe of andere weg wordt ingeslagen op het gebied van technologieën. Indien dit niet gebeurt wordt het inflexibel, oud en een nieuwe ‘bottleneck’.

Development

Het kiezen en definiëren van de developer methodologie kan ook een ‘bottleneck’ zijn. Ondanks dat er veel frameworks, tools en agile development methodologieën zijn, willen veel teams zich specialiseren en hun eigen toolchain bouwen. Hoewel de afgelopen 20 jaar veel van deze ‘bottlenecks’ zijn aangepakt dankzij agile development, is het een belangrijke factor om in de gaten te houden.

Om dezelfde redenen kan het kiezen van de developer tools en frameworks ook een ‘bottleneck’ vormen. In eerste instantie willen organisaties soms de keuzevrijheid inperken omwille van stabiliteit, security en compliance, terwijl dit binnen agile ontwikkeling niet bevorderlijk is voor de autonomie in de product teams. Aan de andere kant willen organisaties ontwikkelteams zoveel mogelijk vrijheid bieden. Dit kan voor de selectie van tools en services en onboarding van deze technologieën weer een bottleneck vormen. Het is daarom verstandig om een middenweg te vinden. Door teams wel de vrijheid van keuze te geven binnen een van te voren bepaald pallet, welke binnen de architectuur en veiligheidseisen passen, wordt er een bepaalde verantwoordelijkheid bij de infrastructuur gelegd.

Governance & Security

Governance is de laatste ‘bottleneck’. Met ‘governance’ bedoel ik alle controles en verificaties van regels die moeten worden gevolgd. Dit kan gaan over het naleven van het beleid, security audits of zelfs het volgen van enterprise-architectuurregels. Het controleren of deze regels worden gevolgd kost bijzonder veel tijd, omdat er maar weinig mensen zijn die zich aan de regels houden en er grondige controles moeten worden uitgevoerd. Het argument dat deze controles moeten worden overgeslagen, klinkt meestal absurd en gevaarlijk. Wie wil er nu niet voor veiligheid en wettelijke naleving zorgen? Governance is echter nog steeds een veel voorkomende ‘bottleneck’. Gelukkig kan dat knelpunt op verschillende manieren worden aangepakt.

Ten eerste geldt, net als bij infrastructuur, hoe eerder compliant je bent des te beter. Vaak worden governance-checks uitgevoerd nadat ontwikkelaars klaar zijn met coderen. Dit betekent dat ontwikkelaars vaak geen diepgaande kennis hebben van de governance-behoeften (inclusief security) om het de eerste keer goed te doen. Wanneer een auditor een probleem vindt, moet hij de software terugsturen naar development en zal het proces vanaf dat punt opnieuw beginnen. Bij DevSecOps daarentegen worden security specialisten eerder bij het ontwikkelingsproces betrokken, waardoor security uitdagingen worden opgelost en verbeterd.

Ten tweede zullen sommige governance-regels niet meer hoeven worden opgevolgd of toepasbaar zijn. Gecertificeerd worden voor compliance en begrijpen waarom dit noodzakelijk is, kost veel tijd en is een langdurig proces. Dit betekent dat organisaties huiverig zijn om de governance frameworks opnieuw te bekijken. Naarmate de tijd verstrijkt kunnen de feitelijke regels veranderen. Hoewel het misschien riskant en duur lijkt om de governance-regels opnieuw te bekijken, kan het goedkoper zijn dan een ‘governance-bottleneck’.

Het vinden en doorbreken van ‘bottlenecks’ is cruciaal

Kortom, het vinden en doorbreken van ‘bottlenecks’ is een ongelooflijk belangrijk onderdeel van de levenscyclus van software. Voor bedrijven die afhankelijk zijn van software om hun kernactiviteiten en klantgerichte activiteiten uit te voeren, is aandacht besteden aan ‘bottlenecks’ een kerntaak van het bedrijf. Om de ‘bottlenecks’ te vinden en de discipline te hebben om ze te doorbreken, heb je een compleet end-to-end-overzicht nodig. Daarnaast heb je ook eindbeslissers nodig om er iets aan te doen. Het succes van de algehele organisatie is dan ook de verantwoordelijkheid van het senior management. Door ‘bottlenecks’  te vinden en te doorbreken, beschikt het management over een zeer effectieve tool om een ​​efficiënt en succesvol systeem op te bouwen.

Dit is een ingezonden bijdrage van Rouven Besters, Regional Director Benelux & Nordics bij VMware Tanzu. Via deze link vind je meer informatie over de mogelijkheden van het bedrijf.