Platform Engineeringin kattava opas

Platform Engineering ymmärretään usein erittäin tekniseksi ja aikaa vieväksi kokonaisuudeksi ottaa käyttöön ja ylläpitää. Oikealla suunnittelulla sen ei kuitenkaan tarvitse olla sellaista. Mitä Platform Engineering siis on? Platform Engineering on kokonaisuudessaan kehitystyökaluketjuja tukevien työkalujen ja käytäntöjen kokonaisuus, joka helpottaa kehittäjiä luomaan erinomaisia ohjelmistoja sekä turvaamaan aikaa, rahaa ja kilpailukykyä.

Se luo uusia tai kehittää olemassa olevia Internal Developer Platformeja (IDP). IDP:hen keskittyminen tehostaa toimintaa ja vapauttaa kehittäjille aikaa innovatiiviseen ajatteluun. Hyvin jäsennelty IDP tukee tiimejä ja varmistaa ohjelmistokehityksen elinkaaren kaikkien vaiheiden eheyden ideoinnista tuotantoon.

Hyvin jäsenneltyihin IDP:ihin perustuva Platform Engineering tarjoaa lopulta ”kultaisia polkuja”, jotka kehittäjät voivat ottaa nopeasti käyttöön. IDP-termillä on usein useita merkityksiä, ja sitä käytetään jopa yleiskäsitteenä. Eficodella käytämme sen perinteistä määritelmää, joka huomioi sen aseman, käyttäjät ja teknologian, jonka se kattaa. Meille se on lisäkerros, joka yksinkertaistaa toimintaa ja antaa kehittäjille mahdollisuuden hyödyntää olemassa olevaa teknologiaa ja työkaluja itsenäisesti.

Tekoälyn yleistyessä edelleen Platform Engineering voi auttaa organisaatiotasi parantamaan kilpailukykyään monin tavoin: rakentamalla oman mallin, tallentamalla organisaatiokohtaista kontekstia, kehittämällä tukimalleja tai ajamalla tekoälytyökuormia.

Mikä on Internal Developer Platform? Lue lisää blogikirjoituksestamme ”Internal developer platforms: What they are and why you need one”. Klikkaa alla olevaa linkkiä

Platform Engineering vs. DevOps

Mitä DevOps on? DevOpsissa on kyse tuotehallinnasta, Site Reliability Engineeringistä, teknisestä erinomaisuudesta ja terveestä yrityskulttuurista. DevOps purkaa ohjelmistokehityksen ja operointitiimien välisiä siiloja sekä yhdistää tuotantoympäristöjen loppukäyttäjäpalautteen kehitystiimeihin, jotta ne voivat reagoida markkinatilanteeseen ja oppia kilpailijoitaan nopeammin. Se tarjoaa hyväksi havaitun tavan parantaa liiketoiminnan ketteryyttä ja suorituskykyä.

Autamme satoja organisaatioita kehittämään DevOpsiaan ja uskomme siihen, että arkkitehtuuri rakennetaan oikein. Siksi näemme Platform Engineeringin DevOpsin kehitysvaiheena. Platform Engineering on kohdennettu lähestymistapa ja ajattelutapa, jota sovelletaan strategisesti ja käytännössä useiden tavoitteiden saavuttamiseksi samanaikaisesti.

Jotkut sanovat, että ”DevOps on kuollut – eläköön Platform Engineering!”, tai hakevat verkosta esimerkiksi hakusanalla ”DevOps vs. Platform Engineering”. Nämä kaksi lähestymistapaa kuitenkin täydentävät toisiaan. Platform Engineering hyödyntää DevOps-käytäntöjä ja vähentää samalla kognitiivista kuormitusta, jotta kehittäjät voivat hyödyntää itsepalvelua.

Sovelluskehityksestä tulee yhä monimutkaisempaa DevOpsin laajentuessa. Kehittäjien on opittava uusia digitaalisten alustojen työkaluja, hallittava infrastruktuuria ja asetettava operatiivisia tehtäviä etusijalle samalla, kun he koodaavat uusia ominaisuuksia. Nämä vaatimukset heikentävät tuottavuutta, lisäävät loppuunpalamisen riskiä ja aiheuttavat työuupumusta.

Platform Engineerit ovat avainasemassa DevOpsin vakioprosessien yksinkertaistamisessa

Kuvittele yritys, joka luo web-sovelluksia yhtenäisellä rakenteella: tietokanta, RESTful API -rajapintoja tarjoava backend ja verkkopohjainen käyttöliittymä. Vaikka käyttöön on otettu moderneja ohjelmistotyökaluja ja malleja, kehitysprosessi perustuu edelleen vahvasti manuaaliseen työhön. DevOps Engineerit vastaavat Docker-tiedostojen luomisesta, Terraform-skriptien kirjoittamisesta, projektikohtaisten build-putkien määrittämisestä ja ympäristöpäivitysten hallinnasta.

Yleensä Platform Engineer toimii asiantuntijana, joka työskentelee tiiviisti kehittäjien kanssa. Hän ohjaa järjestelmän käyttöönottoa ja käyttöä kehittäjien tarpeiden mukaisesti, huolehtii monitoroinnista ja hälytyksistä sekä auttaa kehittäjiä täyttämään Service Level Agreement (SLA) -sopimusten vaatimukset. DevOps-tiimien toimintaympäristössä tämä johtaisi kriittisiin pullonkauloihin, pidentäisi kehittäjien läpimenoaikoja ja kuormittaisi DevOps Engineerejä merkittävästi.

Platform Engineerit yksinkertaistavat tätä Internal Developer Platformin (IDP) avulla automatisoimalla tehtäviä itsepalvelusta alkaen. Kehittäjien ei tarvitse määrittää Git-repositorioita manuaalisesti, sillä käyttäjät voivat pyytää IDP:tä luomaan nopeasti käyttäjäryhmiä ja integroimaan automaattisesti oikean CI/CD-mallin.

Osa Platform Engineereistä tekee jopa yhteistyötä johdon kanssa sisällyttääkseen pitkän aikavälin tavoitteet ja yrityksen vision kehityksen elinkaareen. Monilla yrityksillä on joko omia asiantuntijoita tai tarve konsulteille. Tässä Eficode astuu mukaan.

Platform Engineering ei korvaa DevOps-käytäntöjä, vaan rakentuu niiden pohjalle

Platform Engineering tarjoaa tiimeille helpon tavan käynnistää projekteja standardoitujen mallien avulla. Nämä mallit on rakennettu itsepalveluominaisuuksilla varustettuun IDP:hen, joten tiimit voivat alkaa tuottaa arvoa heti sen sijaan, että käyttäisivät viikkoja projektin käynnistämiseen ja ongelmanratkaisuun.

Itsepalvelu antaa kehittäjille mahdollisuuden toimia itsenäisesti ja vaatimusten mukaisesti ilman liiallista kuormitusta. Näin Platform Engineerit voivat keskittyä merkittävämpiin arkkitehtuurihaasteisiin, parantaa nykyisiä ominaisuuksia ja mukauttaa järjestelmää muuttuviin tarpeisiin.

Tutustu podcast-jaksoon ”Platform engineering done right”, jossa käsitellään IDP:n kyvykkyyksiä portugalilaisessa Millenium BCP -pankissa.

Platform Engineering hyödyntää Site Reliability Engineeringiä parhaana käytäntönä

Google oli Site Reliability Engineeringin (SRE) edelläkävijä. SRE keskittyy ohjelmistosovellusten operointiin ja kehittämiseen laajassa mittakaavassa. Vaikka termit kuulostavat samankaltaisilta, Platform Engineering ja Site Reliability Engineering ovat eri asioita. SRE liittyy pääasiassa operointiin: palvelun ylläpitämiseen sekä sen jatkuvan saatavuuden ja ajantasaisuuden varmistamiseen. SRE tarjoaa kuitenkin myös mallin palvelunhallintaan, jota voidaan soveltaa IDP:ihin. Erityisen toimiva on "Site Reliability Engineering - How Google Runs Production Systems" -teoksessa kuvattu lähestymistapa. Platform Engineering puolestaan sisältää SRE-ajattelun ja tarkastelee kokonaisvaltaisemmin prosessien, ihmisten ja teknologian välisiä yhteyksiä.

Luotettavuus Platform Engineeringissä

Ohjelmistosovellus ei voi tarjota korkeampaa Service Level Agreementia (SLA) kuin sen teknologiapinon alemmat kerrokset. Jotta sovellukselle voidaan taata 99,9 %:n saatavuus, kaikkien sen infrastruktuurikomponenttien on tarjottava sama taso. SLA:t ovat tärkeitä alustatiimin ja alustaa käyttävien kehitystiimien välillä. Ne muodostavat lupauksen kokonais-SLA:ista ja antavat kehitystiimeille odotetun luotettavuustason.

Service Level Objective (SLO) määrittää tavoitteen palvelutasolle, jota mitataan Service Level Indicatorilla (SLI). Oikeiden SLO:jen valitseminen on haastavaa, mutta välttämätöntä alustatiimin suorituskyvyn mittaamisen ja liiketoiminnan menestyksen kannalta. Virhebudjetin sekä SLI:n ja SLO:n välisen marginaalin avulla alustatiimit voivat tasapainottaa innovoinnin ja luotettavuuden.

Huomautus: SLO:t ja virhebudjetit tulisi myös julkaista, jotta sidosryhmien odotukset ovat selkeät.

Alustatiimit ja häiriönhallinta

Alustatiimeillä on keskeinen rooli niiden alustalla ja infrastruktuurissa toimivien ohjelmistosovellusten luotettavuudessa. Lisäksi niiden on otettava vastuu alustatiimille kuuluvien osien ongelmista häiriöiden tai muiden ongelmatilanteiden aikana.

Tiimien vuorovaikutusmallit

Site Reliability Engineering (SRE) -tiimit tekevät tiivistä yhteistyötä kehitystiimien kanssa, ja niiden välinen yhteistyö muuttuu sovelluksen edetessä. SRE-tiimi voi yhdistää enablement- ja operointitiimien rooleja sekä tarjota sparrausta skaalautuvuudesta ja luotettavien palvelujen rakentamisesta tiettyyn pisteeseen asti. SRE-tiimin tulisi ottaa täysi vastuu yhden tai useamman digitaalisen alustapalvelun luotettavuudesta. Tämä eroaa alustatiimistä, jonka odotetaan tarjoavan kehittäjätiimien käyttöön self-service-rajapintoja. Alustatiimi tarvitsee tuotemaisen ajattelutavan ja tiiviin palautesyklin kehitystiimien kanssa rakentaakseen oikeita asioita.

Erilaisilla organisaatioilla on erilaisia haasteita, mutta yksi asia on varma: alustan on pysyttävä joustavana ja mukautuvana. Se on myös suunniteltava ennakoimaan tarpeita, kuten arvioimaan AI Native -valmiutta ja ymmärtämään, miten tekoäly voi tuoda tehokkuutta ja kustannussäästöjä. Toimialasta riippumatta kolme asiaa korostuu.

Nopeampi markkinoillepääsy

Kyse ei ole vain ohjelmistojen nopeasta käyttöönotosta, vaan myös uusien ohjelmistoratkaisujen laajemmasta vaikutuksesta käyttäjäkokemukseen ja liiketoiminnan kasvuun. Vankka alusta toimii muutoksen vauhdittajana ja voi vapauttaa kehittäjät infrastruktuurin hallinnan yksityiskohdista, jotta he voivat keskittyä käyttäjille ja liiketoiminnalle tärkeimpien ominaisuuksien ja toiminnallisuuksien kehittämiseen.

Parempi kustannustehokkuus

Yhtenäinen alusta toimii strategisen taloudenhallinnan vauhdittajana. Infrastruktuurin ja työkalujen keskittäminen alustalle lisää kustannusten läpinäkyvyyttä ja antaa palveluomistajille paremmat edellytykset toimia. Näkyvyyden ansiosta tiimit voivat arvioida ja tasapainottaa kustannuksiaan luottavaisesti sekä suhteuttaa ne tuottamaansa liikevaihtoon ja liiketoiminta-arvoon. Kustannustietoisuuden ja liiketoimintalähtöisen päätöksenteon yhdistelmä edistää kulttuuria, jossa IT-investoinneissa keskitytään arvon tuottamiseen yhtä paljon kuin kustannusten hallintaan.

Hyödynnä tekoälyä tarpeen mukaan

Tekoälystä on epäilemättä tullut merkittävä puheenaihe kaikissa organisaatioissa. Tämä johtaa usein pirstaleisiin toteutuksiin ja vaihtelevaan määrään kontekstia tukevaa materiaalia. Innovointi on tärkeää, mutta jossain vaiheessa tarvitaan skaalautuvuutta. Silloin tukeva alusta tulee kuvaan mukaan.

Näe tekoäly käytännössä. Katso, kun Eficoden Lead Digital Solutions and AI Kalle Mäkelä kertoo tekoälyn käytännön sovelluksista. Napsauta alla olevaa linkkiä.

Parempi Developer Experience

Osaavien kehittäjien houkutteleminen ja sitouttaminen on ratkaisevan tärkeää jokaiselle ohjelmistovetoiselle organisaatiolle. Investoimalla ohjelmistotoimituksen yhtenäistäviin ja sujuvoittaviin alustoihin organisaatio luo kehittäjilleen selkeät ja turvalliset raamit, joiden puitteissa toimia. Erinomainen alusta tarjoaa tervetulleen ympäristön projektien käynnistämiseen ja turvallisen tavan kokeilla uutta.

Vahvan teknologiakokonaisuuden ansiosta Platform Engineering -tiimi voi auttaa kehittäjiä tekemään merkityksellistä työtä ilman kitkaa ja vaivaa. Kehittäjien luovuutta voivat usein kuormittaa esteet, jotka syntyvät siitä, että käytäntöjen, tietoturvan ja dokumentaation on pysyttävä yhdenmukaisina eri tiimien ja järjestelmien välillä. Tätä kutsutaan usein kognitiiviseksi kuormaksi.

Lue lisää Henrik Høeghin puheesta The DEVOPS Conference Stockholm 2023 -tapahtumassa.

Entä oma toimialasi?

Yksikään organisaatio ei ole samanlainen, mutta yleiset tarpeet ja huomioitavat asiat riippuvat organisaation toimialasta ja siihen liittyvästä liiketoimintaympäristöstä.

Säännellyt organisaatiot: kilpailukykyä Platform Engineeringin avulla

Organisaatiot, joilla on tiukkoja compliance- ja sääntelyvelvoitteita, kuten rahoituslaitokset, lääkeyritykset ja viranomaiset, tarvitsevat Platform Engineering -ratkaisuja, jotka huomioivat niiden hallintamekanismeja koskevat vaatimukset ja tuottavat vaikutuksia vaarantamatta liiketoiminnan kilpailukykyä.

Näiden organisaatioiden innovointia ja kykyä houkutella osaajia voivat usein hidastaa välttämättömät, perusteelliset prosessit ja dokumentointi, jotka ovat hitaita ja toisinaan byrokraattisia. Ne tarvitsevat modernin alusta-ajattelun, joka mahdollistaa esimerkiksi automaattisen compliancen policy as coden avulla, jäljitettävyyden, ohjelmiston materiaaliluettelon, tekoälyavusteisen auditoinnin ja yhdenmukaiset ympäristöt. Kun alusta suunnitellaan ketteräksi ja joustavaksi sekä hyödynnetään älykästä ohjelmistokehitystä, säännellyt organisaatiot voivat saavuttaa:

• Helpommat kehityssyklit.

• Paremmat johtamisen näkymät.

• Nopeamman arvon tuottamisen asiakkaille.

• Pienemmän kognitiivisen kuormituksen kehittäjille.

Sulautettuja järjestelmiä hyödyntävät organisaatiot: Platform Engineeringin uudelleenajattelu

Yritykset, jotka valmistavat teknologiaan perustuvia tai teknologialla parannettuja tuotteita, tarvitsevat Platform Engineering -ratkaisuja, jotka tukevat niiden tavoitteita. Älykelloja valmistavista organisaatioista autoja toimittaviin yrityksiin kaikki ovat riippuvaisia sulautetusta teknologiasta. Näille organisaatioille keskeistä on lyhentää markkinoillepääsyn aikaa ja pitää tarjonta ajan tasalla. Haasteita aiheuttavat vanhentuneet tai vanhenevat ohjelmistot sekä ohjelmistokehitysprosessit ja -alustat, joiden merkitys nähdään toissijaisena.

Alustaratkaisujen rakentaminen edellyttää näiltä tuotetta painottavilta ja operatiiviseen toimintaan keskittyviltä organisaatioilta laajaa osaamista, mutta osaaminen on usein siiloutunut kehitystiimeihin ja teknologiaosastoille. Siksi ne tarvitsevat modernin alusta-ajattelun, joka menee toiminnallisuutta pidemmälle ja huomioi vakauden sekä päivitysnopeuden. Sen tulee sujuvoittaa työnkulkuja, tarjota dataohjattuja näkymiä, parantaa laatua, varmistaa turvalliset päivitykset ja datanhallinta sekä tukea parempaa päätöksentekoa. Näille organisaatioille Platform Engineeringin mahdollisuuksien uudelleenajattelu tarkoittaa paitsi tyytyväisempiä asiakkaita myös tyytyväisempiä kehittäjiä.

Ohjelmisto-organisaatiot: innovaatio edellä Platform Engineeringissä

Ohjelmisto edellä toimivat yritykset toimivat nopeasti muuttuvassa ja kilpailullisessa liiketoimintaympäristössä, ja ne tarvitsevat usein ohjelmistokehitykseen mallin, joka toimii mahdollisimman itsenäisesti. Teknologiatyökalut voivat olla hajanaisia ja kehitysprosessit sekavia, mikä hidastaa kehittäjien tuottavuutta ja markkinoillepääsyä. Turhautuminen vie liikaa ajatustyötä, joka pitäisi käyttää innovointiin. Nämä organisaatiot tarvitsevat yhtä modernin ja mukautuvan alusta-ajattelun kuin ne itse ovat – sellaisen, joka vapauttaa kehittäjät keskittymään luovaan työhönsä.

Platform Engineering -ratkaisut voivat sisältää esimerkiksi systemaattisia yhteistyötapoja, tiimikohtaisia dashboardeja, Continuous Improvement/Continuous Delivery (CI/CD) -putkimallipohjia sekä golden patheja turvalliseen, skaalautuvaan ja nopeaan ohjelmistokehitykseen. Tulokset näkyvät esimerkiksi näin:

• Yhdenmukaiset kehittäjäympäristöt.

• Pienempi kognitiivinen kuormitus.

• Sujuva kehittäjien perehdytys.

• Kustannusten optimointi.

• Sisäänrakennettu tietoturva ja compliance.

Katso, miten autoimme TV2 Denmarkia uudistamaan pilvi-infrastruktuurinsa ja rakentamaan sisäisen kehittäjäalustan, joka tukee sen kehittäjien luovuutta. Klikkaa alla olevaa linkkiä.

Jokaisella alustalla on kaksi puolta – operatiiviset kyvykkyydet ja Developer Experience. Muutamat nyrkkisäännöt auttavat luomaan kestävän ja vankan perustan mille tahansa organisaatiolle.

Yhteistyön voima

Teknisten tiimien on tehtävä yhteistyötä organisaation sidosryhmien kanssa saadakseen Internal Developer Platformin (IDP) rakentamiseen tarvittavan tuen ja resurssit. Johdon tuki on ratkaisevan tärkeää, sillä IDP:n rakentaminen vaatii merkittäviä resursseja eikä kyse ole pelkästään teknisistä haasteista.

Tiimivetäjien tehtävänä on myös varmistaa sitoutuminen: heidän on innostettava kehittäjiään yhteistyöhön. Onnistumisen avain on läpinäkyvä rakennusprosessi, jossa keskitytään käyttöönottoon ja helppokäyttöisiin käyttöliittymiin sekä tuetaan sovellusten operatiivista puolta.

Lue lisää blogikirjoituksestamme ”Platform Engineering -organisaation perustaminen”.

Valitse työkalusi viisaasti

Onnistuneen IDP:n rakentamisessa on kyse paljon muustakin kuin työkaluista, mutta oikeilla työkaluvalinnoilla on silti merkitystä. Kannattaako valita jokin vaihtoehdoista, rakentaa itse vai ostaa tai ottaa käyttöön valmis ratkaisu? Nämä ovat keskeisiä kysymyksiä. Jokaisella organisaatiolla on omat tarpeensa, prosessinsa, toimintaperiaatteensa ja budjettinsa – olennaista on rakentaa organisaatiollesi sopiva ratkaisu.

Linkit: työkaluketjun arviointi tai teknologiaan keskittyvä arviointi.

Valitsitpa virtuaalikoneiden ja Kubernetesin, on-premise-ratkaisun ja pilven tai eri deployment-työkalujen välillä, oikea valinta edellyttää sen arvioimista, mitä työkalu tarjoaa joko alustan rakentajalle tai käyttäjälle. Usein on myös pohdittava, kuljetko yksisuuntaisesta ovesta vai voitko siirtyä helposti toiseen ratkaisuun, kun teknologiat ja työnkulut muuttuvat.

Suurempien päätösten tekeminen voi vaatia uudenlaista yhteistyötä, sillä mukana on monia sidosryhmiä. Teknisten kyvykkyyksien, käytäntöjen, tietoturvan ja juridisten vaatimusten lisäksi päätöksiin vaikuttavat hankinta, talous ja muut organisaatiorajat ylittävät toiminnot. Onneksi kaikki IDP:n rakentamiseen liittyvät päätökset eivät ole näin monimutkaisia. Matkaasi ohjaavat useat alan standardit ja parhaat käytännöt. Monet avoimen lähdekoodin työkalut ovat kypsyneet, samoin standardit, joita monet kaupalliset tuotteet noudattavat. Usein standardien noudattaminen mahdollistaa useiden kokonaisuutesi osien vaihtamisen tai hieman vaikeamman päätöksen siirtämisen prosessin myöhempään vaiheeseen.

Valinnastasi riippumatta pääset aina alkuun ilman täysin räätälöidyn ratkaisun rakentamista. Muokkaa kuitenkin markkinoilla saatavilla olevia työkaluja tarpeidesi mukaan, jotta voit käyttää aikaa alustan käyttäjien tarpeiden täyttämiseen liian monimutkaisten toteutusten kanssa kamppailun sijaan. Vaikka pidämme toteutusten luovasta prosessista, omien ratkaisujen rakentamiseen voi ja kannattaa käyttää vain rajallisesti aikaa.

Lue lisää artikkelista ”Valitse viisaasti: konsultin opas developer portaalin valintaan”.

Säilytä uteliaisuutesi: kokeile ja kehitä

On tavallista ajautua syvälle vankan peruskerroksen rakentamiseen. Haluamme, että kaikki on valmiina ennen kuin ensimmäinen tiimi siirtyy alustalle. Haluamme myös tarjota kehittäjillemme erinomaisen kokemuksen, joten ajattelemme, että kaiken pitää olla "valmista", jotta he voivat ajaa palveluitaan.

Todellisuudessa peruskerros ei koskaan ole täysin valmis. Voimme keskittyä ohuimpaan toimivaan alustaan ja omaksua ajattelutavan, jossa parannuksia tehdään asteittain. Näin voimme rakentaa pienemmissä osissa (ja ketterämmin) sekä validoida ratkaisuja kehittäjiemme kanssa useammin. Muuten käyttäisimme paljon aikaa sen rakentamiseen, mitä uskomme kehittäjien haluavan, ilman että saisimme sille vahvistusta.

Vaikka haluamme rakentaa pienissä vaiheissa, meidän tulisi pitää katse eteenpäin ja miettiä roadmapia, sillä modernille ohjelmistolle on paljon vaatimuksia. Joskus on vaatimuksia, joista ei voida tinkiä ja jotka on sisällytettävä heti alkuvaiheeseen, mutta meidän pitäisi pystyä ratkaisemaan ne viivästyttämättä ensimmäisiä käyttäjiä.

Jos epäröit siirtyä tuotantoon ja tarvitset vielä hieman lisätyötä, ota yhteyttä kollegoihisi. He haluavat sinun onnistuvan ja tarjoavat apuaan alustan testaamiseen.

Jos haluat oppia lisää Platform Engineeringin haasteista ja sudenkuopista, tutustu Dan Grøndahl Glavindin puheenvuoroon "Platform Engineering is Hard, and We are Doing it Wrong" DevOpsDays Denmark 2023 -tapahtumassa.

Useimmat ohjelmistokehityksen arviointitavat keskittyvät paikalliseen tuottavuuteen, laatuun ja toimitusprosessin johdonmukaisuuteen. DevOpsin osalta käytössä on vakiintuneita mittareita DevOps Research Assessment (DORA) -ohjelman ansiosta:

• Käyttöönottojen tiheys.

• Muutosten läpimenoaika.

• Keskimääräinen palautumisaika.

• Muutosten epäonnistumisaste.

• Luotettavuus.

Näiden mittareiden avulla voimme mitata DevOps-kulttuurin ja -käytäntöjen vaikutuksia määrällisesti IT-suorituskykyyn ja laatuun liittyvinä tekijöinä. Viime aikoina huomio on siirtynyt siihen, miten kehittäjät kokevat työnsä ja millaisena he sen arvon näkevät. Tätä arvioidaan DevX-keskeisellä lähestymistavalla.

Developer Experiencen mittaaminen

DevExin mittaaminen voi tuntua haastavalta, sillä käsite on hyvin laaja. Siksi kannattaa aloittaa viitekehyksestä, joka tunnistaa DevExin kolme keskeistä ulottuvuutta: palautesyklit, kognitiivinen kuormitus ja flow-tila. Nämä ulottuvuudet korostavat, että DevEx ei ole vain tekninen kysymys, vaan ennen kaikkea kehittäjien kokemuksiin liittyvä asia. Näkemysten kerääminen on hyvä alku, mutta kollegoiden ja tiimien välisten epävirallisten keskustelujen merkitystä ei pidä unohtaa.

Kehittäjät ovat ihmisiä, eikä yksittäinen määrällinen mittari voi kuvata DevExiä tarkasti. Siksi on tärkeää kerätä kehittäjiltä laadullista palautetta kyselyillä. Palaute kertoo muun muassa siitä, miten monimutkaiseksi kehittäjät kokevat koodin käyttöönoton ja alustan käytön sekä kuinka tyytyväisiä he ovat niihin. Esimerkiksi:

• Helppokäyttöiset työkalut auttavat kehittäjiä sujuvoittamaan kehitystä ja käyttöönottoja nopeasti ja vaivattomasti.

• Itsepalveluominaisuudet tukevat kehittäjien itsenäisyyttä ja hallintaa.

• Laadukas dokumentaatio auttaa kehittäjiä toimimaan monimutkaisissa infrastruktuureissa.

• Alusta mahdollistaa DevExiin liittyvien erilaisten mittareiden keräämisen.

• Nopea kehitysympäristön käyttöönotto lisää tuottavuutta ja luovuutta minimum viable productien toteuttamisessa.

Platform Engineering ei tarkoita vain tuottavuuden parantamista ja innovoinnin nopeuttamista. DevExiä parantamalla hyvä alusta lisää kehittäjien tyytyväisyyttä, mikä parantaa henkilöstön pysyvyyttä, osaajien houkuttelua ja liiketoimintatavoitteiden saavuttamista.