Een model bouwen van de softwareleveringsketen

De standaardweergave van een waardestroom van softwareontwikkeling begint met codering en eindigt met code in productie. Je ziet vaak devops-diagrammen die beginnen met 'het bedrijf' en eindigen met 'de klant'. Deze afbeelding geeft echter niet nauwkeurig de complexiteit van softwarelevering op bedrijfsschaal weer.

Als je een stap terug doet, zie je veel meer activiteiten die betrokken zijn bij het leveren van software aan klanten, maar de huidige benaderingen om deze activiteiten te beheren zijn geworteld in serviceleveringskaders en niet in productiemodellen. Als zodanig verbinden ze niet alle betrokken activiteiten als één end-to-end-systeem.

Het model dat in andere productindustrieën wordt gebruikt, is het supply chain-model, en door dat model toe te passen op softwarelevering, kunt u uw begrip van het softwareleverings "systeem" verder uitbreiden dan devops, waardoor u nieuwe inzichten krijgt in hoe u het kunt optimaliseren.

Wat is de toeleveringsketen?

De supply chain begint met het idee dat u alle productie- en niet-productieactiviteiten als één systeem kunt coördineren. Supply chain management wordt vaak verkeerd begrepen als simpelweg 'leveranciersbeheer', terwijl dat eigenlijk maar één aspect is van supply chain management (hoewel een kritiek aspect).

Alle product- en dienstenbedrijven hebben een toeleveringsketen en de betrokken activiteiten en hun relatieve belang voor het toeleveringsketensysteem zullen variëren. Het kernidee is echter dat door het coördineren van deze activiteiten als een enkel systeem, u meer waarde krijgt dan de som van de onderdelen en een efficiënte levering van die waarde aan belanghebbenden mogelijk maakt.

De volgende activiteiten zijn slechts enkele van de belangrijke aspecten van alle toeleveringsketens, maar voor software worden ze uniek uitgevoerd:

Planning

In de traditionele toeleveringsketen omvatten planningsactiviteiten het coördineren van activa en het optimaliseren van de stroom van processen om het aanbod van materialen in evenwicht te brengen met de vraag naar producten. In de toeleveringsketen van software houdt die coördinatie in dat de juiste code wordt ontwikkeld voor de productkenmerken die het meest nodig zijn. Op grote schaal, met honderden applicaties en duizenden softwareontwikkelaars, is dit een monumentale onderneming.

De omvang van planningsactiviteiten wordt vaak geminimaliseerd door bestaande devops-modellen. Het is dan ook enigszins ironisch dat de grote ondernemingen die het meest devops nodig hebben, te maken hebben met wettelijke, regelgevende, contractuele en klantverplichtingen die de planning lang en complex maken. Een supply chain-benadering van planning omvat het optimaliseren van de interfaces tussen de vele verschillende planningsrollen en disciplines die betrokken zijn, en een belangrijke succesfactor is het effectief kunnen integreren ervan.

Enerzijds zijn de flexibele methodologieën die de ontwikkeling in de onderneming sturen, vaak ingebed in watervalprocessen. Er zijn maar weinig bedrijven die ontsnappen aan cycli van fiscale planning, en agile processen kunnen abstracties bevatten die in strijd zijn met die cycli; Sprints zijn bijvoorbeeld mogelijk niet in lijn met de grenzen van de fiscale kwartalen. Gebrek aan communicatie en verbindingen tussen ontwikkelingsprocessen die gebruik maken van agile en niet-productieactiviteiten die gebruik maken van waterval, kunnen leiden tot verspilling en inefficiëntie binnen het bedrijf.

Aan de andere kant omvatte de planning van bedrijfsproducten altijd uitgebreide systemen voor het beheer van vereisten en traceerbaarheid, en dit is niet anders voor softwareproducten. Vereistenbeheer is vooral van cruciaal belang in sterk gereguleerde industrieën zoals de gezondheidszorg, waar software kan worden ontwikkeld voor medische apparatuur die levens of dood kan betekenen voor de gebruikers. Vereistenbeheer omvat gespecialiseerde tools en methodologieën, en de mogelijkheid om de betrouwbaarheid en kwaliteit van hun implementatie gedurende de ontwikkelingscyclus te traceren, kan van cruciaal belang zijn voor bedrijfssoftwareproducten.   

Sourcing

In de traditionele toeleveringsketen omvat het inkopen van componenten het beheren van relaties met leveranciers en het ontwikkelen van inkoopstrategieën voor onderdelen en materialen. Software is ook sterk afhankelijk van componenten die afkomstig zijn van bronnen - volgens recent onderzoek door Sonatype vormt open source nu de meerderheid van softwareproducten: maar liefst 80 tot 90 procent van de code in moderne applicaties is van open source componenten. En deze componenten zorgen voor unieke managementuitdagingen.

Ten eerste kan het moeilijk zijn om te beslissen hoe de kwaliteit van de componenten moet worden bepaald, waarbij veel factoren van invloed zijn op beslissingen zoals verbruikbaarheid, testen, documentatie, gemeenschap, ondersteuning en trends in technologie. Het hebben van een duidelijke strategie en aanpak voor het selecteren van componenten is absoluut noodzakelijk.

Ten tweede, aangezien het aantal open source-componenten enorm stijgt, is het een uitdaging om te weten wat ze allemaal kunnen meedragen en ze allemaal effectief te beheren. Productmanagers en ingenieurs moeten goed letten op licentiekwesties en beveiligingskwesties. De toestand van uw open source-componenten kan dagelijks veranderen naarmate nieuwe kwetsbaarheden worden ontdekt en beheerders hun intellectuele eigendomsstrategieën wijzigen. En klanten willen precies weten wat ze krijgen - veel grote ondernemingen zullen geen software kopen zonder een stuklijst waarin staat wat er in de doos zit. Het beheren van al deze open source-problemen is een kernaspect van de ontwikkeling van softwareproducten.

Distributie

Om software in handen van klanten te krijgen, kan een complex web van allerlei soorten partners betrokken zijn: implementatie, distributie, integratie, wederverkoper; overeenkomsten van allerlei aard: OEM's, licenties, NDA's, RFP's; bijeenkomsten van alle soorten: demo's, PoC's, presentaties; en zoveel meer.

Deze relaties dienen als input, output en zelfs als stappen in het softwareleveringsproces. De toestand van al deze relaties kan een directe invloed hebben op ontwikkelingsactiviteiten. Zonder ze nauw te beheren en aan te sluiten op het werk dat wordt uitgevoerd, ontstaat er zeer tastbare verspilling.

Stel je voor dat je een epos levert aan een potentiële klant die stilletjes een gemiste kans werd, of een functie implementeert voor een partner die zijn overeenkomst een maand geleden heeft opgezegd. Dit gebeurt regelmatig wanneer software wordt geleverd onafhankelijk van de waardestroom van het bedrijf - wanneer de softwareleveringsfunctie niet is gekoppeld aan de toeleveringsketen.

De devops-pijplijn moet nauw aansluiten bij de samenwerkingsverbanden, afspraken en doelen waarvoor wordt gewerkt. Code kan traceerbaar zijn en worden gekoppeld van het verhaal tot de vereiste tot en met het klantrecord in uw CRM, allemaal door uw softwarelevering te behandelen als een toeleveringsketen en door een integratiestrategie te volgen.

Stelt u zich in plaats daarvan voor dat u alle lopende activiteiten die worden uitgevoerd voor een specifiek contract of alle geplande functies voor een nieuwe klant - dit is het resultaat van software supply chain management - zichtbaarheid en traceerbaarheid over de hele levenscyclus kunt laten zien.

Hulpmiddelen

Hoewel uw klassieke productietooling kan bestaan ​​uit stansmachines en ovens voor warmtebehandeling, omvat de toeleveringsketen van software een klasse van tools (ook wel ALM-tools, levenscyclustools of devops-tools genoemd) die worden gebruikt om de verschillende stadia van softwarelevering te beheren. .

De strategie voor het beheren van deze tools is heel anders dan de klassieke benadering, omdat de technische en intellectuele investering in softwareontwikkelingstools enorm en zeer impactvol is. Dit type tool ontwikkelt zich ook snel en is sterk gefragmenteerd - de Jenkins van vandaag zullen de Hudson van weleer zijn. Een organisatie moet gepositioneerd worden om een ​​veerkrachtige maar modulaire toolstack te hebben, een die teams voorziet van wat ze nodig hebben, met behoud van de flexibiliteit om zich aan te passen.

Bovendien kan de gereedschapsketen niet worden losgekoppeld - het moet informatie stroomopwaarts en stroomafwaarts door de waardeketen stromen om kennis te krijgen waar het nodig is. Het is van cruciaal belang om dit gebied ook vanuit het oogpunt van integratie te onderzoeken: hoe kunt u de activiteiten op een bepaalde laag verbinden met de omliggende en ondersteunende activiteiten voor supply chain management?

Conclusie

Het bedrijfsleven heeft in het verleden technologiemanagement gescheiden van de inkomstengenererende bedrijfstakken en het behandeld als een reeks ondersteunende activiteiten die worden aangedreven door waarden en doelstellingen die zijn afgestemd op de levering van diensten. In een softwaregedefinieerde wereld past dat businessmodel echter niet meer.

Softwareleveringscapaciteit is uit de klassiek gedefinieerde ondersteuningsruimte verdwenen en is gekomen om alle primaire inkomstengenererende activiteiten te definiëren.

U moet daarom uw model als productiesysteem heroverwegen en evolueren naar een systeem dat de complexiteitsrelaties tussen waardestroomactiviteiten vastlegt. De toeleveringsketen belichaamt dat denken, en naarmate de productie van softwareproducten evolueert, zullen we dit model zeker volwassen zien worden.