Versnellen van innovatie: Softwareontwikkeling automatiseren voor concurrentievoordeel

Traditionele softwareontwikkeling is traag. Het is tijd voor een heroverweging.

Bijna drie jaar geleden formuleerde Microsoft's Satya Nadella beroemd dat "ieder bedrijf een softwarebedrijf zal zijn". Vandaag is de $500 miljard wereldwijde softwaremarkt op koers om te verdubbelen naar $1 biljoen in 2030.

J.P. Morgan heeft volgens hun meest recente filing 40.000 software-engineers (meer dan Alphabet). Elk groot bedrijf loopt de engineers de deur in om de concurrentie te overstijgen in ontwikkeling. Het grote probleem is dat traditionele softwareontwikkeling traag, gefragmenteerd en verspillend is.

Bijvoorbeeld: elke week spendeert de gemiddelde software-engineer 4 uur wachten op tests, 3,5 uur wachten op builds, en 3 uur aan omgevingsbeheer – meer dan een kwart van hun werkweek niet daadwerkelijk waarde creërend. Wanneer u bedenkt dat engineers vaak de hoogst betaalde mensen in organisaties zijn, is dit duidelijk een groot probleem. Echter, dingen veranderen.

Een van de leidende ontwikkelplatformen, CircleCI, wedde dat AI en automatisering de sleutel zouden zijn om software-innovatie te versnellen en engineers vrij te maken voor belangrijk werk. In het afgelopen jaar introduceerde het bedrijf een aantal automatiserings- en machine learning-verbeteringen die de wachttijd van engineers met 50% reduceren. Het is een van de vele redenen waarom meer dan 300.000 ontwikkelaars, inclusief die bij Facebook, Spotify, GoPro, InstaCart en velen anderen, zich hebben gewend tot CircleCI om sneller te gaan.

Het bedrijf wordt geleid door Jim Rose – een zesvoudige oprichter met eerdere investeringen van Google Ventures, Foundation Capital en Marc Andreessen. Sinds zijn aanstelling bij CircleCI iets meer dan vier jaar geleden, heeft Rose de omzet met meer dan 450% verhoogd en het bedrijf uitgegroeid tot een echt spannende entiteit.

Geïnteresseerd in meer over het automatiseren van softwareontwikkeling en het versnellen van innovatie, sprak Information Age met Rose over het onderwerp.

Wat is de huidige staat van de softwaremarkt?

Op dit moment zijn er nog veel bedrijven en individuen die verschillende processen handmatig uitvoeren. Als u nadenkt over het proces van digitale transformatie, gaat het eigenlijk om het stimuleren van een softwareontwikkelteam.

Eén is het proberen om software uit on-premise datacenters te halen en in cloud-native omgevingen te brengen, waar u direct toegang heeft tot rekenkracht.

Het tweede is dat software, traditioneel of in veel gevallen, gezien is als een richtlijn of bijkomstigheid van het primaire bedrijf. Nu realiseert u zich dat alle soorten bedrijven – van banken tot autofabrikanten tot retailers – allemaal beseffen dat software kern is van wat ze doen. En dus moeten ze uitzoeken wat ze bezitten en hun activa consolideren en integreren als standaard.

Eenmaal bedrijven deze directe toegang tot rekenkracht hebben en structuren waar ontwikkelaars in kunnen werken, zit er meestal een soort mengelmoes van verschillende platforms en processen tussenin.

In de meeste gevallen hebben ze heel lange waterfall software release-processen met veel handmatige stappen en dan veel handmatige scripts. In sommige gevallen voor meer geavanceerde winkels, hebben ze misschien de eerste generatie automatiseringsoplossingen, maar naarmate teams sneller gaan, beginnen die te breken.

En dat is waar we nu in komen en bedrijven helpen navigeren. Naarmate hun softwareteams sneller gaan, bouwen ze meer software en proberen ze het sneller te doen; om zowel responsief te zijn op kansen in de markt maar ook op potentiële negatieve veranderingen. Bedrijven moeten volledig nadenken over hoe al die stukjes bij elkaar passen.

Is deze snelheid waar u naar verwijst de hoofdknoop in softwareontwikkeling?

Bedrijven en ontwikkelteams proberen sneller te gaan omdat de markt sneller gaat. Ze proberen uit te zoeken hoe ze snel kunnen werken zodat ze kansen kunnen aanpakken.

De enige manier om daar te komen is om alle stappen die niet noodzakelijk menselijke interventie vereisen, te automatiseren, want in plaats van het over minuten, uren en dagen te doen, kunt u het in seconden doen.

Naarmate teams sneller gaan, en software uw primaire winkel naar de klant is, moet u ervoor zorgen dat de kwaliteitsniveaus hoog zijn; u moet ervoor zorgen dat het niet crasht of dat u geen beveiligingskwetsbaarheden heeft, bijvoorbeeld.

Dus, als u nadenkt over agile, gaat het om proberen nimbler te worden, zowel vanuit een kwaliteitsperspectief als vanuit een snelheidsperspectief.

In de VS gaat het allemaal om snelheid, maar door sneller te gaan, kleinere stukjes te integreren en in staat te zijn software op een consistentere basis te releasen, wordt uw software inherent beter. Al die angsten rond deployen verdwijnen als u het vijf, acht, vijftien keer per week doet, en in sommige gevallen hebben we klanten die het 100 keer per dag doen.

Deployment wordt een non-issue.

Aan de kwaliteitskant, een van de grote issues voor softwareontwikkeling in het verleden is dat als u maar een keer per kwartaal released, u een heel moeilijke tijd heeft om ervoor te zorgen dat alle veranderingen die u in uw applicatie introduceert, daadwerkelijk samenwerken. Vaak ziet u bedrijven een big bang release doen en dan besteden ze de volgende 60, 90 dagen aan het repareren van alle dingen die geregresseerd en gebroken zijn. In deze methode vertraagt uw softwarecyclus, maar lijdt ook de kwaliteit van de applicatie zelf.

Vanuit een agile perspectief is dat wat mensen proberen aan te pakken.

Hoe kan een organisatie veranderen om softwareontwikkelteams te accommoderen, ondersteunen en stimuleren?

Er zijn een paar verschillende manieren.

Eén is dat developers moeilijk te werven zijn en dus wilt u ervoor zorgen dat alle tijd die vanuit een ontwikkelperspectief wordt besteed, gewijd is aan het bouwen van uw speciale software, wat dat ook mag zijn; als u een bank bent, een geweldige bankapplicatie bouwen, als u een e-commerce app bent, een geweldige e-commerce app bouwen. Ik denk dat een van de grote gebieden waar mensen ondergeïnvesteerd hebben, is dat softwareontwikkelaars historisch dingen bouwden. Dat is wat ze doen, ze bouwen software. Dus de ontwikkelcyclus is ondergeïnvesteerd vanuit een third-party app perspectief.

Er zijn gewoon dingen zoals, bijvoorbeeld, testautomatisering en continuous delivery infrastructuur die teams niet zelf hoeven te bouwen. U bent veel beter af het te verkrijgen van iemand anders die gespecialiseerd is in dat gebied, zodat u kunt focussen op het ding waar u goed in bent. Het zou alsof u iemand vertelt dat ze een koffiezetapparaat moeten bouwen en ze een boel koperen pijpen, soldeer en kleppen geeft. U zou dat nooit doen. Maar historisch is ontwikkeling zo behandeld. Dus zeker de juiste tools en platforms op de juiste plaats zetten is echt kritisch, helemaal van de datacenter tot aan de planningstools.

Ik denk dat het tweede deel is dat in een traditioneel waterfall-model, softwareontwikkeling meestal de rol van catcher speelt, dus de applicatie wordt veel eerder in het proces gedefinieerd en dan, op het moment dat het ontwikkelteam het krijgt, zijn er een aantal beslissingen genomen die wel of niet werken en wel of niet haalbaar of makkelijk te doen zijn.

Er is deze notie van shift left, wat probeert ontwikkeling steeds verder op in de planningcyclus te duwen, zodat de zorgen of behoeften van het ontwikkelteam in overweging worden genomen zowel in de constructie van de applicatie als in de levering. En als u er vanuit een operationeel perspectief naar kijkt, betekent dat dat u echt moet nadenken over hoe een applicatie geopereerd wordt veel eerder in de levenscyclus. Als u bijvoorbeeld probeert cloud-native apps te bouwen, moet u ze op een heel specifieke manier architecten, wat betekent dat u die beslissing moet nemen en onderdeel moet zijn van dat proces veel eerder.

Wanneer teams meer software-first, agile processen adopteren, eindigt u met een triangulatie van zorgen. U heeft de mensen en de business owners en productmanagers die bezitten waarom u iets bouwt. U heeft de technische architecten en softwareontwikkelaars die echt praten over hoe u het bouwt. En dan heeft u de operators, degene die verantwoordelijk zijn voor het daadwerkelijk runnen ervan, die uitzoeken wat u eigenlijk aan het eind van dat hele proces runt. Iedereen moet betrokken zijn. En dat kan een harde transitie zijn voor sommige bedrijven.

Hoe kunnen AI en automatisering software-innovatie stimuleren en verbeteren?

Met automatisering kunt u taken automatiseren die zowel vooraf bepaald zijn als zelflerend. Een voorbeeld zou zijn als u elke keer als u een stuk software probeert te releasen, een third-party test moet doen tegen een ander third-party betalingssysteem. In het verleden met die taken, zou u een QA-team moeten inhuren dat essentieel probeerde transacties te verwerken en het allemaal handmatig te doen, wat ongelooflijk traag is. Het is ook ongelooflijk vol met fouten en complicaties.

Dit zijn perfecte voorbeelden van taken die volledig geautomatiseerd moeten zijn in uw testsuite – al die dingen die u weet dat u steeds weer gaat doen, moet u die taken automatiseren om ze deterministisch en voorspelbaar te maken. En uiteindelijk snel.

Er zijn kansen om die herhalende taken die elke minuut die een developer besteedt aan het herhalen van die dingen, een verspilling van tijd is en, eerlijk gezegd, een verspilling van geld.

Dus als u kijkt naar AI en software die gebouwd wordt, in plaats van te denken over het duwen van voorspellende deterministische software, duwt u een model. En het model is een sandbox van vooraf geconcipiëerde noties van hoe iets zou kunnen werken en dan, naarmate mensen erdoorheen gaan, en tests worden gedraaid, verandert en evolueert het model naarmate het meer leert over hoe dingen wel of niet werken. Dat zet een ongelooflijke hoeveelheid druk op het testsysteem.

Als u nadenkt over enkele van de AI-misstappen wanneer u situaties heeft waarin er onbewuste bias in de AI zit, waar de AI soort van de les loopt en begint mensen uit te sluiten uit bepaalde applicaties, of dingen afsluit, dat zijn alle situaties waar vanuit een testperspectief uitdagend zijn.

Het wordt steeds ingewikkelder, maar het wordt ook veel, veel sneller en responsiever. Dus u zult alleen de inclusie van AI en machine learning in softwareontwikkeling zien toenemen. Maar nu moet u alle benodigde frameworks hebben om te kunnen testen op al die veranderingen.