Päättyykö DevOps-transformaatiosi koskaan?

Olet ehkä jo huomannut, että DevOps-transformaatio ei koske vain ohjelmistokehitystä ja IT-toimintoja. Nykyään DevOps on liiketoiminta-ajattelua korkeimmalla tasolla. Olennainen osa DevOpsia on vastuun ottaminen työn tuloksista, niiden ymmärtäminen ja se, että ne vaikuttavat päätöksentekoosi juuri nyt.

DevOps kuuluu C-Suiteen

Vaikuttavin DevOps toteutuu C-Suitessa, sillä parhaat DevOps-transformaatiot koskevat kaikkia ja edellyttävät kokonaiskuvaa. Ilman tätä näkökulmaa DevOpsisi digitaalisessa transformaatiossa rajoittuu yksittäisiin tiimeihin, etenee hitaammin ja kalliimmin eikä tuota parhaita mahdollisia tuloksia.

C-Suite voi saada koko organisaation toimimaan yhtenäisenä kokonaisuutena niin, etteivät tiimit odota muiden ratkaisevan mahdollisia ongelmia myöhemmin. Tämä edellyttää, että jokaisella tiimillä on DevOps-asenne ja että se kantaa vastuun työnsä tuloksista aina tuotantoon käyttöönottoon ja ylläpitoon asti. DevOps syntyi IT:ssä, missä se loi kehittäjille ja IT-toiminnoille yhteisen tavoitteen: toistuvien prosessien automatisoinnin, kustannusten pienentämisen ja markkinoillepääsyn nopeuttamisen.

Nykyään DevOps voi saavuttaa täyden potentiaalinsa vain C-Suitessa. DevOpsin tulee tukea ylimmän johdon päätöksentekoa (innovaatiot, uudet tuotteet, uudet markkinat) ja edistää nopeaa toimintaa automaattisten mittareiden avulla, jotka osoittavat sen toimivuuden.

DevOps-transformaatiollasi tulisi olla päättymispäivä

Täydet hyödyt saavutetaan vasta, kun transformaatio itseohjautuvasti kehittyväksi organisaatioksi on valmis. Siksi siihen on pyrittävä ja sitä on vaadittava heti transformaatiopolun alusta lähtien. Jotta transformaatio voisi joskus päättyä – koska organisaatiosi toimii edistyneenä DevOps-organisaationa kaikilla tasoilla, myös C-Suiten päätöksenteossa – sille tarvitaan päättymispäivä.

Jotta DevOps-transformaatiollasi olisi päättymispäivä, harkitse tarkkaan ennen kuin perustat hajautettuja, organisaation sisäisiä DevOps-osastoja. Vähintäänkin suunnittele etukäteen, mitä organisaatiossasi tapahtuu transformaation valmistuttua. Muuten vaarana on DevOps Team -siilojen syntyminen (katso DevOps Topologiesin kuvaus ”Anti-type B”), jolloin vastuu DevOpsin toteuttamisesta jää DevOps Teamille eikä kuulu jokaiselle organisaatiosi tiimille.

DevOps-transformaatio tulisi sen sijaan nähdä selkeästi rajattuina projekteina, jotka toteutetaan ennalta sovitussa aikataulussa ja joilla on päätepiste eli päättymispäivä. Siihen mennessä organisaatiosi on saanut DevOpsin kaikki hyödyt käyttöönsä ja toteuttaa sekä jakaa niitä päivittäisessä työssä.

DevOps-transformaation neljä vaihetta päättyvät päättymispäivään

Miksi yritykset eivät aseta DevOps-transformaatiolleen aikarajaa?

Yritykset tekevät DevOps-transformaatiosta jatkuvan koettelemuksen tyypillisimmin palkkaamalla omia DevOps-asiantuntijoita ja sijoittamalla heidät olemassa oleviin tiimeihin tai perustamalla uuden DevOps-tiimin.

Tästä on välitön hyöty: se vaikuttaa konsulttiyrityksen palkkaamista edullisemmalta. Pitkällä aikavälillä se on kuitenkin kalliimpaa, sillä nämä työntekijät pysyvät palkkalistoillasi ja heille on löydettävä uusia projekteja DevOps-transformaation valmistuttua. Vaarana on, että transformaation ensimmäisen vaiheen jälkeen omat DevOps-insinöörisi – jotka sopisivat paremmin tehokkaaseen kehitystyöhön – pitävät kiinni DevOps-vastuista, joiden tulisi jakautua tiimin tai koko organisaation kesken.

Eikö omien DevOps-asiantuntijoiden palkkaaminen ole paras tapa säilyttää DevOps-osaaminen transformaation valmistuttua? Se voi vaikuttaa siltä, koska DevOps-asiantuntijat pysyvät osana osastoasi. Konsulttien kanssa työskentelyyn liittyy luonnollisesti riski, että he vievät osaamisen mukanaan ja jäät riippuvaiseksi lisäkonsultoinnista. Omilla asiantuntijoilla on kuitenkin hintansa: kun DevOps-asiantuntijat ovat pysyvä osa organisaatiotasi, muille työntekijöille – myös C-Suitessa – välittyy viesti, ettei DevOps-vastuu kuulu heille. Tämä heikentää merkittävästi ohjelmistotuotantosi, kehitystiimiesi ja DevOps-transformaatiosi vaikuttavuutta.

Päättymispäivällä varustetun DevOps-transformaation hyödyt

Käsittelin jo joitakin hyötyjä. Tässä vielä lisää syitä suhtautua asiaan vakavasti.

1) Päättymispäivällä rajattu transformaatio pienentää kustannuksia pitkällä aikavälillä ja tekee niistä läpinäkyvämpiä: tiedät arvioidun hinnan sille, mitä mikäkin transformaation vaihe tai tavoite maksaa.

2) Transformaation lopputuloksena tulisi olla koko organisaation kattava DevOps-koneisto. Jos päätät rakentaa sen ulkopuolisen avun avulla, muista, että koneiston osia ovat kehittäjäsi ja tekninen johto. Koneisto toimii vasta, kun kehittäjät osaavat DevOpsin erittäin hyvin. Näin organisaatiosi arvon tuottamisen kannalta olennainen DevOps-osaaminen pysyy organisaation sisällä. Muussa tapauksessa voidaan perustellusti todeta, ettei DevOps-transformaatio ole valmis.

Jos esimerkiksi aloitat DevOps-transformaation DevOps-konsulttiyrityksen kanssa, saat heti käyttöösi parhaat käytännöt organisaatioista, joiden kanssa konsulttiyritys on aiemmin työskennellyt – nyt juuri sinun tarpeisiisi mukautettuina. Kun palkkaat yksittäisiä henkilöitä, heidän muista organisaatioista saamansa kokemus lakkaa karttumasta, kun he aloittavat työskentelyn kanssasi.

3) Nopeus on erittäin tärkeää. Lyhyemmät läpimenoajat ovat etu, joka alan johtavilla toimijoilla ympäri maailman jo on. Siksi DevOps on enemmän kuin mukava lisä, ja se on yksi syy siihen, miksi siitä on tulossa johdon tavoite. Asettamalla päättymispäivän tunnustat, ettei DevOps-transformaatio ole kaukainen päämäärä, vaan tavoite, jonka yhä useammat ovat jo saavuttaneet ja jonka organisaatiosi haluaa saavuttaa mahdollisimman nopeasti.

DevOps-transformaatiollasi tulisi olla päättymispäivä. Onko sillä jo?

Organisaatioon ei tarvitse perustaa uutta tiimiä, jonka ei alun perinkään pitäisi olla olemassa, vain jotta toiminta olisi tehokkaampaa. DevOps on hyvää strategiaa, avointa ja tukevaa kulttuuria, vastuun ottamista, parhaiden käytäntöjen jakamista ja kaiken mahdollisen automatisointia. Se ei ole erillinen toiminto, joten sen ei pitäisi olla myöskään erillinen osasto.

Epäiletkö? Ensimmäinen askel on DevOps-arviointi ja tiekartta, vaikka suunnittelisitkin DevOps-transformaation toteuttamista itse. Jos haluat kuulla tästä lisää, ota yhteyttä.