Standardavbildningen av en programvareutviklingsverdistrøm begynner med koding og slutter med kode i produksjonen. Du ser ofte devops-diagrammer som starter med "virksomheten" og slutter med "kunden." Imidlertid gjenspeiler denne skildringen ikke nøyaktig kompleksiteten i programvarelevering i bedriftsskala.
Hvis du tar et skritt tilbake, ser du mange flere aktiviteter involvert i å levere programvare til kunder, men nåværende tilnærminger til å administrere disse aktivitetene er forankret i rammer for tjenesteleveranser og ikke i produksjonsmodeller. Som sådan kobler de ikke alle aktivitetene som er involvert som et eneste ende-til-ende-system.
Modellen som brukes i andre produktindustrier er forsyningskjedemodellen, og ved å bruke den modellen på programvarelevering, kan du utvide din forståelse av "system" for programvarelevering utover devops, og gi deg ny innsikt i hvordan du kan optimalisere den.
Hva er forsyningskjeden?
Forsyningskjeden starter med ideen om at du kan koordinere alle produksjons- og ikke-produksjonsaktiviteter som et enkelt system. Supply chain management blir ofte misforstått som ganske enkelt "leverandøradministrasjon", når det egentlig bare er ett aspekt av supply chain management (men kritisk).
Alle produkt- og tjenestevirksomheter har en forsyningskjede, og de involverte aktivitetene og deres relative betydning for forsyningskjedesystemet vil variere. Kjerneideen er imidlertid at ved å koordinere disse aktivitetene som et enkelt system, får du større verdi enn summen av delene og flyter effektiv levering av denne verdien til interessenter.
Følgende aktiviteter er bare noen få av de viktige aspektene ved alle forsyningskjeder, men for programvare blir de utført unikt:
Planlegger
I den tradisjonelle forsyningskjeden involverer planleggingsaktiviteter koordinering av eiendeler og optimalisering av prosessflyten for å balansere tilbudet av materialer med etterspørsel etter produkter. I programvareforsyningskjeden innebærer samordningen å sørge for at riktig kode blir utviklet for de produktfunksjonene som trengs mest. I stor skala, med hundrevis av applikasjoner og tusenvis av programvareutviklere, er dette en monumental innsats.
Omfanget av planleggingsaktiviteter minimeres ofte av eksisterende devops-modeller. Det er da litt ironisk at de store virksomhetene som trenger devops mest, må kjempe med juridiske, regulatoriske, kontraktsmessige og kundeforpliktelser som gjør planleggingen lang og kompleks. En forsyningskjedetilnærming til planlegging innebærer å optimalisere grensesnittene mellom de mange forskjellige planleggingsrollene og fagområdene som er involvert, og en viktig suksessfaktor er å kunne integrere dem effektivt.
På den ene siden ligger de smidige metodikkene som styrer utviklingen i bedriften ofte i fosseforløp. Få virksomheter kan unnslippe finansplanleggingssykluser, og smidige prosesser kan inneholde abstraksjoner som er i konflikt med disse syklusene; for eksempel kan det hende at sprints ikke stemmer overens med grensene for de finanspolitiske kvartalene. Manglende kommunikasjon og sammenhenger mellom utviklingsprosesser ved bruk av smidige og ikke-produksjonsaktiviteter ved bruk av foss kan føre til avfall og ineffektivitet i hele virksomheten.
På den annen side har bedriftens produktplanlegging alltid involvert omfattende kravstyrings- og sporbarhetssystemer, og dette er ikke annerledes for programvareprodukter. Kravadministrasjon er spesielt viktig i høyt regulerte bransjer som helsevesen, der programvare kan utvikles for medisinsk utstyr som kan bety liv eller død for brukerne. Kravadministrasjon innebærer spesialiserte verktøy og metoder, og evnen til å spore troverdigheten og kvaliteten på implementeringen av dem i løpet av utviklingslivssyklusen kan være avgjørende for bedriftsprogramvareprodukter.
Sourcing
I den tradisjonelle forsyningskjeden innebærer innkjøpskomponenter å administrere relasjoner med leverandører og utvikle anskaffelsesstrategier for deler og materialer. Programvare er også sterkt avhengig av komponenter - ifølge nyere undersøkelser fra Sonatype, utgjør åpen kildekode nå flertallet av programvareprodukter: så mye som 80 til 90 prosent av koden i moderne applikasjoner er fra komponenter med åpen kildekode. Og disse komponentene skaper unike ledelsesutfordringer.
For det første kan det være vanskelig å bestemme hvordan man skal bestemme kvaliteten på komponentene, med mange faktorer som påvirker avgjørelser som forbruksevne, testing, dokumentasjon, fellesskap, støtte og trender i teknologi. Å ha en klar strategi og tilnærming til valg av komponenter er viktig.
For det andre, ettersom antall åpne kildekomponenter ballonger, er det en utfordring å vite hva de alle får med seg, og administrere dem alle effektivt. Produktledere og ingeniører må ta nøye hensyn til lisensieringsproblemer og sikkerhetsproblemer. Tilstanden til komponentene med åpen kildekode kan endres daglig når nye sårbarheter oppdages og vedlikeholdere endrer strategiene for immateriell eiendom. Og kunder vil vite nøyaktig hva de mottar - mange store bedrifter vil ikke kjøpe programvare uten en regning med varer som beskriver hva som er i esken. Å administrere alle disse åpen kildekode-problemene er et sentralt aspekt av programvareutvikling.
Fordeling
Å få programvare i hendene på kundene kan involvere et komplekst nett av partnere av alle slag: distribusjon, distribusjon, integrering, forhandler; avtaler av alle slag: OEM, lisenser, NDA, RFP; møter av alle slag: demoer, poCs, presentasjoner; og så mye mer.
Disse forholdene fungerer som innganger, utganger og til og med trinn i programvareleveringsprosessen. Tilstanden til noen av disse relasjonene kan direkte påvirke utviklingsaktiviteter. Uten å håndtere dem nøye og koble dem til arbeidet som utføres, oppstår veldig håndgripelig avfall.
Tenk deg å levere et epos for et prospekt som stille ble en tapt mulighet, eller distribuere en funksjon for en partner som kansellerte avtalen for en måned siden. Dette skjer regelmessig når programvare leveres uavhengig av verdistrømmen til virksomheten - når programvareleveringsfunksjonen ikke er knyttet til forsyningskjeden.
Devops-rørledningen må være nært knyttet til partnerskap, avtaler og mål som arbeidet utføres for. Koden kan spores og knyttes fra historien til kravet til kundeoppføringen i CRM, alt ved å behandle programvareleveransen din som en forsyningskjede og følge med en strategi for integrering.
Tenk deg i stedet å kunne overflate alle pågående aktiviteter som utføres for en spesifikk kontrakt, eller alle funksjoner som er planlagt for en ny kunde - dette er resultatet av programvareleverandørkjedestyring - synlighet og sporbarhet gjennom hele livssyklusen.
Verktøy
Mens det klassiske produksjonsverktøyet ditt kan bestå av stansemaskiner og varmebehandlingsovner, inkluderer programvareleverandørkjeden en klasse verktøy (også kalt ALM-verktøy, livssyklusverktøy eller devops-verktøy) som brukes til å administrere de forskjellige stadiene av programvareleveransen .
Strategien for å håndtere disse verktøyene er veldig forskjellig fra den klassiske tilnærmingen fordi den tekniske og intellektuelle investeringen i programvareutviklingsverktøy er enorm og svært innflytelsesrik. Denne typen verktøy utvikler seg også raskt og er veldig fragmentert - Jenkins i dag vil være Hudson fra før. En organisasjon må være posisjonert for å ha en elastisk, men likevel modulær verktøystabel, en som gir teamene det de trenger, og samtidig beholde fleksibiliteten til å tilpasse seg.
Videre kan ikke verktøykjeden kobles fra - den må strømme informasjon tilbake oppstrøms og nedstrøms over verdikjeden for å få kunnskap der det er behov for det. Det er viktig å undersøke dette området også fra et integreringsperspektiv - hvordan kan du koble aktivitetene i et gitt lag til de omkringliggende og støttende forsyningskjedestyringsaktivitetene?
Konklusjon
Virksomheten har historisk skilt teknologiledelse fra de inntektsgenererende forretningsområdene, og behandlet den som et sett med støtteaktiviteter drevet av verdier og mål tilpasset levering av tjenester. I en programvaredefinert verden passer imidlertid ikke den forretningsmodellen lenger.
Programvareleveringsevne har flyttet seg ut av det klassisk definerte støtteområdet og har kommet til å definere alle primære inntektsgenererende aktiviteter.
Du må derfor tenke nytt på modellen din som et produksjonssystem og gå mot en som fanger opp kompleksitetsforholdene på tvers av verdistrømaktiviteter. Forsyningskjeden legemliggjør den tenkningen, og etter hvert som produksjonen av programvareprodukter utviklet seg, vil vi helt sikkert se denne modellen moden.
