Standardafbildningen af en softwareudviklingsværdistrøm begynder med kodning og slutter med kode i produktion. Du ser ofte devops-diagrammer, der starter med "forretningen" og slutter med "kunden." Denne skildring afspejler imidlertid ikke nøjagtigt kompleksiteten af softwarelevering i virksomhedsskala.
Når du tager et skridt tilbage, ser du mange flere aktiviteter involveret i levering af software til kunder, men nuværende tilgange til styring af disse aktiviteter er rodfæstet i serviceleveringsrammer og ikke i produktionsmodeller. Som sådan forbinder de ikke alle involverede aktiviteter som et enkelt ende-til-ende-system.
Modellen, der anvendes i andre produktindustrier, er forsyningskædemodellen, og ved at anvende denne model på softwarelevering kan du udvide din forståelse af softwareleverings “systemet” ud over devops, hvilket giver dig ny indsigt i, hvordan du optimerer det.
Hvad er forsyningskæden?
Forsyningskæden starter med ideen om, at du kan koordinere alle produktions- og ikke-produktionsaktiviteter som et enkelt system. Supply chain management misforstås ofte som simpelthen ”leverandørledelse”, når det virkelig kun er et aspekt af supply chain management (dog kritisk).
Alle produkt- og servicevirksomheder har en forsyningskæde, og de involverede aktiviteter og deres relative betydning for forsyningskædesystemet vil variere. Kerneideen er dog, at ved at koordinere disse aktiviteter som et enkelt system, får du værdi større end summen af delene og strømmer effektiv levering af denne værdi til interessenter.
Følgende aktiviteter er blot nogle få af de vigtige aspekter af alle forsyningskæder, men for software udføres de entydigt:
Planlægning
I den traditionelle forsyningskæde involverer planlægningsaktiviteter koordinering af aktiver og optimering af strømmen af processer for at afbalancere udbuddet af materialer med efterspørgslen efter produkter. I softwareforsyningskæden indebærer denne koordination at sikre, at den rigtige kode udvikles til de produktfunktioner, der er mest nødvendige. I stor skala med hundreder af applikationer og tusindvis af softwareudviklere er dette en monumental indsats.
Omfanget af planlægningsaktiviteter minimeres ofte af eksisterende devops-modeller. Det er derfor noget ironisk, at de store virksomheder, der har mest brug for devops, skal kæmpe med juridiske, lovgivningsmæssige, kontraktmæssige og kundeforpligtelser, der gør planlægningen lang og kompleks. En tilgang til planlægning i forsyningskæden involverer optimering af grænsefladerne mellem de mange forskellige planlægningsroller og discipliner, der er involveret, og en vigtig succesfaktor er at kunne integrere dem effektivt.
På den ene side ligger de smidige metoder, der styrer udviklingen i virksomheden, ofte i vandfaldsprocesser. Få virksomheder kan undslippe finanspolitiske cyklusser, og agile processer kan indeholde abstraktioner, der er i konflikt med disse cyklusser; for eksempel kan sprints muligvis ikke tilpasse sig grænserne for de finanspolitiske kvartaler. Manglende kommunikation og forbindelser mellem udviklingsprocesser ved hjælp af agile og nonproductionsaktiviteter ved hjælp af vandfald kan føre til spild og ineffektivitet i hele virksomheden.
På den anden side har virksomheds produktplanlægning altid involveret omfattende kravstyrings- og sporbarhedssystemer, og dette er ikke anderledes for softwareprodukter. Kravstyring er især kritisk i stærkt regulerede industrier såsom sundhedspleje, hvor software kan udvikles til medicinsk udstyr, der kan betyde liv eller død for brugerne. Kravsadministration involverer specialværktøjer og metoder, og evnen til at spore troværdighed og kvalitet af deres implementering på tværs af udviklingslivscyklussen kan være kritisk for virksomhedssoftwareprodukter.
Sourcing
I den traditionelle forsyningskæde involverer sourcingkomponenter styring af relationer med leverandører og udvikling af indkøbsstrategier for dele og materialer. Software er også stærkt afhængig af indkøbte komponenter - ifølge nyere forskning fra Sonatype udgør open source nu størstedelen af softwareprodukter: så meget som 80 til 90 procent af koden i moderne applikationer er fra open source-komponenter. Og disse komponenter skaber unikke ledelsesudfordringer.
For det første kan det være svært at beslutte, hvordan man bestemmer kvaliteten af komponenterne, idet mange faktorer påvirker beslutninger som forbrugsevne, test, dokumentation, samfund, support og tendenser inden for teknologi. Det er bydende nødvendigt at have en klar strategi og tilgang til valg af komponenter.
For det andet, da antallet af open source-komponenter balloner, er det en udfordring at vide, hvad de alle sammen er med til at styre dem alle effektivt. Produktledere og ingeniører skal være meget opmærksomme på licensproblemer og sikkerhedsproblemer. Tilstanden for dine open source-komponenter kan ændre sig dagligt, når nye sårbarheder opdages, og vedligeholdere ændrer deres strategier for intellektuel ejendomsret. Og kunder vil vide nøjagtigt, hvad de modtager - mange store virksomheder køber ikke software uden en regning med varer, der beskriver, hvad der er i kassen. Håndtering af alle disse open source-problemer er et centralt aspekt af software produktudvikling.
Fordeling
At få software i kundernes hænder kan involvere et komplekst web af partnere af enhver art: implementering, distribution, integration, forhandler; aftaler af enhver art: OEM'er, licenser, NDA'er, RFP'er; møder af enhver art: demoer, PoC'er, præsentationer; og så meget mere.
Disse forhold fungerer som input, output og endda trin i softwareleveringsprocessen. Tilstanden for et af disse forhold kan direkte påvirke udviklingsaktiviteter. Uden at håndtere dem nøje og forbinde dem med det arbejde, der udføres, forekommer meget håndgribeligt affald.
Forestil dig at levere et epos til et prospekt, der stille blev en mistet mulighed, eller implementere en funktion til en partner, der annullerede deres aftale for en måned siden. Dette sker regelmæssigt, når software leveres uafhængigt af virksomhedens værdistrøm - når softwareleveringsfunktionen ikke er knyttet til forsyningskæden.
Devops-rørledningen skal være tæt forbundet med de partnerskaber, aftaler og mål, som arbejdet udføres for. Koden kan spores og knyttes fra historien til kravet til kundeoptegnelsen i din CRM, alt sammen ved at behandle din softwarelevering som en forsyningskæde og følge med en strategi for integration.
Forestil dig i stedet at være i stand til at overflade alle igangværende aktiviteter, der udføres for en bestemt kontrakt, eller alle de funktioner, der er planlagt til en ny kunde - dette er resultatet af software-supply chain management - synlighed og sporbarhed i hele livscyklussen.
Værktøjer
Mens din klassiske produktionsværktøj kan bestå af skæremaskiner og varmebehandlingsovne, involverer softwareforsyningskæden en klasse værktøjer (forskellige kaldet ALM-værktøjer, livscyklusværktøjer eller devops-værktøjer), der bruges til at styre de forskellige faser af softwarelevering .
Strategien til styring af disse værktøjer er meget forskellig fra den klassiske tilgang, fordi den tekniske og intellektuelle investering i softwareudviklingsværktøjer er enorm og meget indflydelsesrig. Denne type værktøj udvikler sig også hurtigt og stærkt fragmenteret - nutidens Jenkins vil være Hudson fra før. En organisation skal placeres for at have en robust, men alligevel modulær værktøjsstak, en der giver holdene det, de har brug for, samtidig med at de bevarer fleksibiliteten til at tilpasse sig.
Desuden kan værktøjskæden ikke frakobles - den skal flyde information tilbage opstrøms og nedstrøms på tværs af værdikæden for at få viden, hvor det er nødvendigt. Det er vigtigt at undersøge dette område også ud fra et integrationsmæssigt synspunkt - hvordan kan du forbinde aktiviteterne på et givet lag til de omgivende og understøttende supply chain management-aktiviteter?
Konklusion
Virksomheden har historisk adskilt teknologiledelse fra de indtægtsgenererende forretningsområder og behandlet den som et sæt supportaktiviteter drevet af værdier og mål, der er tilpasset levering af tjenester. I en softwaredefineret verden passer den forretningsmodel dog ikke længere.
Kapacitet til levering af software er flyttet ud af det klassisk definerede supportrum og er kommet til at definere alle primære indtægtsgenererende aktiviteter.
Du er derfor nødt til at genoverveje din model som et produktionssystem og bevæge dig mod en, der fanger kompleksitetsforholdene på tværs af værdistrømaktiviteter. Forsyningskæden inkarnerer den tænkning, og når produktionen af softwareprodukter udviklede sig, vil vi helt sikkert se denne model moden.
