Ohjelmistokehityksen arvovirran tavallinen kuvaus alkaa koodauksesta ja päättyy tuotannossa olevaan koodiin. Näet usein devops-kaavioita, jotka alkavat "liike" ja päättyvät "asiakas". Tämä kuvaus ei kuitenkaan kuvaa tarkasti ohjelmistotoimituksen monimutkaisuutta yrityksen mittakaavassa.
Kun otat askeleen taaksepäin, näet monia muita toimintoja, jotka liittyvät ohjelmistojen toimittamiseen asiakkaille, mutta nykyiset lähestymistavat näiden toimintojen hallintaan juurtuvat palvelujen toimituskehyksiin eikä tuotantomalleihin. Sellaisena ne eivät yhdistä kaikkia mukana olevia toimintoja yhtenä kokonaisuutena.
Muilla tuoteteollisuuksilla käytetty malli on toimitusketjumalli, ja soveltamalla tätä mallia ohjelmistojen toimitukseen voit laajentaa ymmärrystäsi ohjelmistotoimitusten "järjestelmästä" devopsin ulkopuolella, jolloin saat uuden käsityksen sen optimoinnista.
Mikä on toimitusketju?
Toimitusketju alkaa ajatuksesta, että voit koordinoida kaikki tuotanto- ja ei-tuotannolliset toimet yhtenä järjestelmänä. Toimitusketjun hallintaa ymmärretään usein väärin yksinkertaisesti "toimittajan hallinnaksi", vaikka se onkin tosiasiassa vain yksi toimitusketjun hallinnan osa (tosin kriittinen).
Kaikilla tuote- ja palveluyrityksillä on toimitusketju, ja mukana olevat toiminnot ja niiden suhteellinen merkitys toimitusketjujärjestelmälle vaihtelee. Ydinajatuksena on kuitenkin, että koordinoimalla nämä toiminnot yhtenä järjestelmänä saat arvoa, joka on suurempi kuin osien summa, ja kyseisen arvon virtauksen tehokkaan toimittamisen sidosryhmille.
Seuraavat toiminnot ovat vain muutamia tärkeitä näkökohtia kaikissa toimitusketjuissa, mutta ohjelmistoille ne suoritetaan ainutlaatuisesti:
Suunnittelu
Perinteisessä toimitusketjussa suunnittelutoimintoihin kuuluu resurssien koordinointi ja prosessien virran optimointi materiaalien tarjonnan ja tuotteiden kysynnän tasapainottamiseksi. Ohjelmistojen toimitusketjussa tähän koordinointiin kuuluu sen varmistaminen, että oikeaa koodia kehitetään eniten tarvittaville tuoteominaisuuksille. Suuressa mittakaavassa, satojen sovellusten ja tuhansien ohjelmistokehittäjien kanssa, tämä on monumentaalinen pyrkimys.
Suunnittelutoiminnan laajuus minimoidaan usein olemassa olevilla devops-malleilla. On siis ironista, että suurten yritysten, jotka tarvitsevat eniten rahaa, on kohdeltava lakisääteisiä, sääntelyyn perustuvia, sopimusperusteisia ja asiakassitoumuksia, jotka tekevät suunnittelusta pitkäksi ja monimutkaiseksi. Toimitusketjun lähestymistapa suunnitteluun sisältää useiden eri suunnitteluroolien ja tieteenalojen välisten rajapintojen optimoinnin, ja keskeinen menestystekijä on niiden integrointi tehokkaasti.
Toisaalta ketterät menetelmät, jotka ohjaavat yrityksen kehitystä, ovat usein vesiputousprosesseissa. Harvat yritykset voivat välttää verosuunnittelusyklit, ja ketterät prosessit voivat sisältää abstraktioita, jotka ovat ristiriidassa näiden jaksojen kanssa; esimerkiksi sprintit eivät välttämättä ole linjassa finanssipolitiikan vuosineljännesten rajojen kanssa. Viestinnän ja yhteyksien puute kehitysprosesseissa, joissa käytetään ketterää ja muuta kuin tuotantotoimintaa vesiputousta käyttämällä, voi johtaa tuhlaukseen ja tehottomuuteen koko liiketoiminnassa.
Toisaalta yrityksen tuotesuunnitteluun on aina liittynyt kattavia vaatimustenhallinta- ja jäljitettävyysjärjestelmiä, ja ohjelmistotuotteilla ei ole eroa. Vaatimusten hallinta on erityisen kriittinen hyvin säännellyillä aloilla, kuten terveydenhuollossa, jossa lääketieteellisiä laitteita varten voidaan kehittää ohjelmistoja, jotka voivat merkitä käyttäjien elämää tai kuolemaa. Vaatimusten hallinta sisältää erikoistuneita työkaluja ja menetelmiä, ja kyky jäljittää niiden toteuttamisen uskollisuus ja laatu koko kehityksen elinkaaren ajan voi olla kriittinen yrityksen ohjelmistotuotteille.
Hankinta
Perinteisessä toimitusketjussa komponenttien hankinta tarkoittaa suhteiden hallintaa toimittajien kanssa sekä osien ja materiaalien hankintastrategioiden kehittämistä. Ohjelmistot luottavat myös voimakkaasti hankittuihin komponentteihin - Sonatypen viimeaikaisen tutkimuksen mukaan avoimet lähdekoodit muodostavat nyt suurimman osan ohjelmistotuotteista: jopa 80-90 prosenttia nykyajan sovellusten koodista on peräisin avoimen lähdekoodin komponenteista. Ja nämä komponentit luovat ainutlaatuisia hallinnan haasteita.
Ensinnäkin voi olla vaikeaa päättää, miten komponenttien laatu määritetään, ja päätöksentekoon vaikuttavat monet tekijät, kuten kulutus, testaus, dokumentointi, yhteisö, tuki ja tekniikan suuntaukset. Selkeä strategia ja lähestymistapa komponenttien valintaan on välttämätöntä.
Toiseksi, vaikka avoimen lähdekoodin komponenttien ilmapallojen lukumäärä onkin haaste, vaikka tiedätkin, mitä ne kaikki päästävät hallintaan. Tuotepäälliköiden ja insinöörien on kiinnitettävä erityistä huomiota lisensointiin ja turvallisuuskysymyksiin. Avoimen lähdekoodin komponenttien tila voi muuttua päivittäin, kun uusia haavoittuvuuksia löydetään ja ylläpitäjät muuttavat henkisen omaisuuden strategioita. Ja asiakkaat haluavat tietää tarkalleen, mitä he saavat - monet suuret yritykset eivät osta ohjelmistoja ilman tavaralomaketta, joka kuvaa pakkauksen sisältöä. Kaikkien näiden avoimen lähdekoodin ongelmien hallinta on keskeinen osa ohjelmistotuotekehitystä.
Jakelu
Ohjelmistojen saaminen asiakkaiden käsiin voi edellyttää monimutkaista kaikenlaisten kumppaneiden verkkoa: käyttöönotto, jakelu, integrointi, jälleenmyyjä; kaikenlaiset sopimukset: OEM-valmistajat, lisenssit, NDA: t, RFP: t; kaikenlaiset kokoukset: esittelyt, PoC: t, esitykset; ja paljon muuta.
Nämä suhteet toimivat syötteinä, tuotoksina ja jopa vaiheina ohjelmiston toimitusprosessissa. Näiden suhteiden tila voi vaikuttaa suoraan kehitystoimintaan. Hallitsematta niitä tarkasti ja yhdistämättä niitä suoritettavaan työhön syntyy hyvin konkreettista jätettä.
Kuvittele, että toimitat eepoksen mahdollisuudelle, josta on hiljaa menetetty mahdollisuus, tai otat käyttöön ominaisuuden kumppanille, joka peruutti sopimuksensa kuukausi sitten. Tämä tapahtuu säännöllisesti, kun ohjelmisto toimitetaan riippumatta yrityksen arvovirrasta - kun ohjelmiston jakelutoimintoa ei ole liitetty toimitusketjuun.
Devops-putki on liitettävä tiiviisti kumppanuuksiin, sopimuksiin ja tavoitteisiin, joiden vuoksi työtä tehdään. Koodi voi olla jäljitettävissä ja yhdistettävissä tarinasta vaatimukseen CRM: n asiakastietueeseen käsittelemällä ohjelmistojesi toimitusta toimitusketjuna ja seuraamalla sitä integrointistrategialla.
Kuvittele sen sijaan, että pystyt esittelemään kaikki keskeneräiset toiminnot, jotka suoritetaan tietyn sopimuksen perusteella, tai kaikki uudelle asiakkaalle suunnitellut ominaisuudet - tämä on ohjelmistojen toimitusketjun hallinnan tulos - näkyvyyden ja jäljitettävyyden koko elinkaaren ajan.
Työkalut
Vaikka klassinen valmistustyökalusi voi koostua muotoleikkauskoneista ja lämpökäsittelyuunista, ohjelmistojen toimitusketjuun kuuluu joukko työkaluja (eri nimillä ALM-työkalut, elinkaarityökalut tai devops-työkalut), joita käytetään ohjelmistotoimituksen eri vaiheiden hallintaan .
Näiden työkalujen hallinnan strategia eroaa hyvin perinteisestä lähestymistavasta, koska tekniset ja henkiset investoinnit ohjelmistokehitystyökaluihin ovat valtavat ja erittäin vaikuttavat. Tämän tyyppinen työkalu on myös nopeasti kehittyvä ja erittäin pirstoutunut - tämän päivän Jenkinsistä tulee menneiden aikojen Hudson. Organisaatiolla on oltava sijainti joustavalla mutta modulaarisella työkalupinolla, joka tarjoaa tiimeille tarvitsemansa säilyttäen samalla joustavuuden sopeutua.
Työkaluketjua ei voida myöskään irrottaa - sen on kuljettava tietoa takaisin ylävirtaan ja alavirtaan arvoketjun yli saadakseen tietoa sinne, missä sitä tarvitaan. On kriittistä tutkia tätä aluetta myös integraation näkökulmasta - miten voit yhdistää tietyn kerroksen toiminnot ympäröiviin ja tukeviin toimitusketjun hallintatoimintoihin?
Johtopäätös
Liiketoiminta on historiallisesti erottanut teknologianhallinnan tuloja tuottavista liiketoiminta-alueista ja käsittänyt sitä tukitoimintojen joukona, jonka arvot ja tavoitteet ohjaavat palvelujen toimittamiseen. Ohjelmistomäärittelyssä tämä liiketoimintamalli ei kuitenkaan enää sovi.
Ohjelmistojen toimituskyky on siirtynyt pois klassisesti määritellystä tukitilasta, ja se on määritellyt kaikki ensisijaiset tuloja tuottavat toiminnot.
Siksi sinun on mietittävä mallisi uudelleen tuotantojärjestelmänä ja siirryttävä kohti mallia, joka kuvaa monimutkaisuussuhteet arvovirran toimintojen välillä. Toimitusketju ilmentää tätä ajattelua, ja kun ohjelmistotuotteiden tuotanto kehittyy, näemme tämän mallin varmasti kypsyvän.
