Platform Engineering -ominaisuusmalli

  • 20 minuuttia

Alustan suunnittelun on tarkoitus olla matka. Asteittainen ja toistuva lähestymistapa on yleensä tehokkaampi kuin laaja-alainen, välitön täytäntöönpano tai yksinomaan ylhäältä alas -valtuutukset. Lisäävä kehitys, alkaen pienimmillä elinkelpoisilla tuotteilla, antaa tiimeille mahdollisuuden tarkentaa lähestymistapaansa ajan mittaan ja sisällyttää samalla palautetta.

Alustan suunnittelun elinkaari edustaa jäsenneltyä lähestymistapaa, jolla varmistetaan, että ympäristö on luotettava, skaalattava ja että sitä parannetaan jatkuvasti. Tämä elinkaari kattaa erillisiä vaiheita, jotka vaikuttavat ympäristön pitkän aikavälin menestykseen.

Elinkaaren olennainen osa on Platform Engineering Capability Model, joka tarjoaa kattavan kehyksen käyttöympäristöjen suunnittelun arviointiin, suunnitteluun ja toteuttamiseen. Mallissa esitellään erääntymistasot, parhaat käytännöt ja tärkeät ominaisuudet, joita vaaditaan elinkaaren kussakin vaiheessa, ja varmistetaan tasaus organisaation tavoitteiden ja käyttäjien tarpeiden kanssa.

Mallissa kerrotaan käyttöympäristön suunnittelukäytäntöjen kypsyttämisen edistymisestä viidessä vaiheessa: Initial, Repeatable, Defined, Managed, ja Optimizing. organisaatioilla on Initial -vaiheessa rajallinen rakenne, ad hoc -prosessit ja vähäiset sijoitukset käyttöympäristön ominaisuuksiin. Kun ne etenevät toistettavissa vaiheessa, perusprosesseja syntyy, mutta käyttöönotto ja hallinto ovat edelleen epäjohdonmukaisia. Defined vaihe merkitsee selkeiden standardien ja prosessien luomista, ja käyttäjät alkavat ottaa käyttöympäristöratkaisuja käyttöön tarkoituksella. Hallittujen -vaiheessa ympäristöjä hallitaan aktiivisesti, resursseja valmistellaan ja hallitaan tehokkaasti ja käyttäjien vuorovaikutus on yhdenmukaista standardoitujen liittymien kautta. Lopuksi Optimointi -vaiheessa ympäristöjä parannetaan jatkuvasti luotettavien palautemekanismeja, mitattujen tulosten sekä käyttäjien tarpeisiin ja organisaation tavoitteisiin sopivien mukautuvien toimintojen avulla.

Malli arvioidaan kuuden toimintakyvyn perusteella: Investment, jossa kuvastetaan resurssien ja rahoituksen varaamista; käyttöönotto, painopisteenä käyttäjien etsintä ja käyttö; hallinta, resurssien helppokäyttöisyyden, kustannusten hallinnan ja tietojen/IP-suojauksen varmistaminen; valmistelu & hallinta, miten resurssit otetaan käyttöön ja ylläpidetään; -liittymät, mikä käsittelee käyttäjien toimia käyttöympäristön kanssa; and Measurement & Feedback, korostaen jatkuvaa parannusta suorituskyvyn mittareiden ja merkityksellisten tietojen avulla. Yhdessä nämä ominaisuudet vastaavat tiiviisti Cloud Native Computing Foundationin alustan suunnittelun erääntymismallissa kuvattuja avainalueita ja heijastavat organisaation alustan suunnittelun erääntymistasoa.

Jos haluat käyttää käyttöympäristön suunnittelun ominaisuusmallia, arvioi ensin, missä organisaatiosi on tällä hetkellä kullakin kuudelle ominaisuusalueelle. Voit suorittaa tämän arvioinnin manuaalisesti tai viimeistellä Platform Engineering Capability Model -kyselyn. Kun olet määrittänyt nykyiset vaiheet, määritä kasvun tulevat tavoitteet ja kaavioi kunkin ominaisuuden edistyminen organisaatiossasi. Edistymisen ei tarvitse tapahtua kaikissa ominaisuuksista kerralla. Keskity alueisiin, jotka ovat järkevimpiä organisaatiollesi.

kaavio, joka näyttää Platform Engineering Capability Modelin keskeiset ohjaimet ja vaiheet.

Investointi

Investointiominaisuuden kehittyessä kussakin vaiheessa painopisteenä on se, miten henkilöstö ja varat kohdennetaan käyttöympäristön ominaisuuksiin painottaen budjetointia ja henkilöstöä, vaikutusalueen hallintaa ja sijoitetun pääoman tuoton mittaamista.

  • Alkuperäinen (vapaaehtoinen): Alustan ominaisuudet nousevat esiin välttämättömyydestä yksittäisten insinöörien vapaaehtoisesti reagoimalla välittömiin taktisiin tarpeisiin. Budjetti ja henkilöstö ovat vähäisiä, ja työt ovat tyypillisesti rahastoimattomia ja ne suoritetaan olemassa olevien vastuiden rinnalla. Ratkaisut on rajoitettu tiukasti, ja ne on kohdistettu tiettyihin ongelmiin, jotka liittyvät rajoitettuun tiedon jakamiseen tiimien välillä. ROI:a mitataan sen mukaan, miten tehokkaasti välittömät vaatimukset käsitellään, ja niiden vaikutusta projektin keskeisiin tuloksiin.
  • Toistettavissa (ad-hoc-osallistumiset): Varatut tiimit alkavat käsitellä toistuvia haasteita, kuten epäjohdonmukaista valmistelua tai suojauspuutteita, mutta ponnistelut ovat edelleen suurelta osin reagoivia. Budjetit ja henkilöstö on rajoitettu ristiinleikkauksiin, ja vaikutusmahdollisuuksia on rajoitettu koko organisaatiossa. Vaikutusalueen hallinta keskittyy tiettyihin aiheisiin ilman laajempaa koko ympäristön kattavaa perspektiiviä. ROI:ia mitataan parannuksilla tärkeimpien haasteiden, kuten keskeneräisen keskeneräisen toiminnan, käsittelyssä.
  • Defined (Operationalized - Dedicated Team): Keskitetysti rahoitetut käyttöympäristötiimit nousevat esiin keskittyen ohjelmistojen toimituksen nopeuttamiseen ja teknisten vaatimusten käsittelemiseen. Johtaminen alkaa edistää yhteistyötä ja toteuttaa alkuperäisiä DevOps-käytäntöjä, mutta tiimiarvon mittaamisessa on edelleen haasteita. Keskustiimit virallistavat budjetin ja henkilöstön teknisten tarpeiden täyttämiseksi. Ratkaisut tulevat laajempiksi ja käsittelevät yleisiä haasteita eri tiimeissä, vaikka painopiste on edelleen lyhytaikainen. ROI mitataan toimitusnopeuden kasvulla.
  • Hallittu (Skaalattava - Tuotteena): Kulttuurinen muutos tapahtuu, jossa kehittäjiä käsitellään asiakkaina, joilla on johtajuus ja jotka korostavat empatiaa ja tuotepohjaista lähestymistapaa. Käyttöympäristötiimit toimivat kuten tuotetiimit, joilla on kehittäjiä, tuotepäälliköitä ja käyttäjäkokemuksen asiantuntijoita. Vaikutusalueen hallinta on linjassa tuotekartoiden kanssa, ja sitä on tarkasteltu yhteistyössä suunnittelutiimien kanssa koko organisaation laajuisten tarpeiden täyttämiseksi. ROI-arviointia arvioidaan kehittäjien tyytyväisyyden parantuessa, mikä heijastelee jatkuvia parannuksia ja vastaa käyttäjien tarpeita.
  • Optimointi (käytössä oleva ekosysteemi): Investoinnit keskittyvät innovointiin ja säilyttävät ympäristön osuvuuden koko organisaatiossa kannustavien osallistumisten kanssa. Käyttöympäristötiimit esittelevät kehittyneitä ominaisuuksia, kuten suojauksen ja suorituskyvyn parannuksia, joiden avulla tuotetiimit voivat luoda luottamatta keskitettyyn keskeneräisiin ominaisuuksiin. Budjetit ulottuvat keskusryhmiä pidemmälle, ja rahoitusta on käytettävissä koko organisaatiossa. Vaikutusalueen hallinnassa painotetaan nopeaa ja koko organisaation laajuista tietojen jakamista. ROI mitataan kehittäjien tyytyväisyyden jatkuvilla parannuksilla.

Adoptio

Käyttöönottoominaisuus keskittyy siihen, miten käyttäjät löytävät ja käyttävät ympäristösi suunnitteluratkaisuja ja niiden tarjouksia. Tämä heijastuu palveluiden, työkalujen ja teknologioiden etsimiseen, valintaan ja käyttöön. Kun organisaatiot kypsyvät, lähestymistapa käyttöönottoon siirtyy epävirallisesta ja satunnaisesta käytöstä jäsennellympään ja osallistuvampaan malliin, jossa käyttäjät ovat aktiivisesti yhteydessä ympäristöön, vaikuttavat sen kehitykseen. Tämä edistyminen kuvastaa sitä, miten käyttäjien etsintä, päätöksenteko ja käyttökäytännöt kehittyvät ajan mittaan alkuperäisestä epävirallisesta etsimisestä täyteen osallistumiseen ympäristön kehittämiseen.

  • Alkuperäinen (epävirallinen): Käyttöönotto on epäjohdonmukaista, sillä tiimit parantavat prosesseja itsenäisesti ilman organisaation laajuista koordinointia. Ulkoisia työkaluja suositellaan usein sisäisten työkalujen sijaan. Ympäristöt löydetään epävirallisesti, lähinnä suusanallisten tai sattumakohtaisten kohtaamisten kautta, ja suunnittelutiimit valitsevat palveluita erityistarpeidensa perusteella. Jokainen tiimi ylläpitää omia komentosarjojaan ja työkalujaan, jotka on räätälöity sen yksilöllisten vaatimusten mukaisesti.
  • Toistettavissa (annettu): Organisaatio valtuuttaa jaettujen alustojen käytön, mutta ominaisuudet on rajoitettu yleisiin käyttötapauksiin, mikä vaikeuttaa epätavallisten vaatimusten noudattamisen vaikeuttamista. Käyttäjien etsintä perustuu ympäristötiimin ohjeisiin, jotka perustuvat usein sisäisiin ohjeisiin tai direktiiveihin. Tiimit voivat valita valtuutettuja palveluita epämuodollisten keskustelujen kautta alustatiimin kanssa. Vaikka prosessit on rakennettu alustan standardien ympärille, tiimit eivät ehkä täysin ota niitä käyttöön tai saattavat olla tyytymättömiä tuloksiin.
  • Määritetty (mainostettu): Ympäristön ominaisuuksia ylennetään aktiivisesti tiimin tarpeiden mukaisesti. Ympäristötiimi tekee yhteistyötä suunnittelutiimien kanssa tarjotakseen laadukkaita palveluita, jotka vähentävät toiminnallista yleiskustannuksia. Joillakin tiimeillä saattaa kuitenkin edelleen olla alhainen tuotto, koska ne ovat riippuvaisia vanhentuneista käytännöistä ja teknisestä velasta. Tiimit löytävät ominaisuuksia tyypillisiä käyttötapauksia käsitteleviä direktiivejä käyttämällä, ja käyttöympäristötiimi tukee käyttöä yhteistyön kautta. Alustakäyttöä kannattaa käyttää myös epävirallisesti tiimilähettiläiden kautta.
  • Hallittu (arvopohjainen): Tuotetiimit tunnistavat ja valitsevat käyttöympäristön ominaisuudet sille selkeälle arvolle, jonka ne tarjoavat kognitiivisen kuormituksen vähentämisessä ja laadukkaiden palvelujen tarjoamisessa. Käyttöympäristöjä tukevat laaja dokumentaatio, ergonomialiitännät ja omatoiminen käyttökokemus nopeaan valmisteluun. Tiimit suosivat nyt sisäisiä ympäristöjä itse ratkaisujen luotuksella tai ulkoisilla palveluntarjoajilla. Etsintä ja päätöksenteko ovat virtaviivaisia, ja tiimit käyttävät malleja, keskustelupalstoja ja dokumentaatiota alustan käyttöönoton täyteen tukeen.
  • Optimointi (osallistuva): Tuotetiimit osallistuvat aktiivisesti ympäristön ominaisuuksien parantamiseen ehdottamalla uusia ominaisuuksia ja korjauksia. Käyttäjät voivat tunnistaa vaatimukset ja tehdä yhteistyötä eri osallistujien työpanosten parissa. Kehittäjien edustajat ja lähettiläät vaalivat sisäistä yhteisöä, joka laajentaa alustan omistajuutta osallistujille. Käyttöympäristön teknikot tekevät tiivistä yhteistyötä tuotetiimien kanssa tarpeiden ymmärtämiseksi ja ehdottavat uusia ominaisuuksia, jotta käyttäjät voivat lähettää pull-pyyntöjä ja osallistua tarkistuksiin.

Hallintotapa

Hallinnon kyvyn kehittyessä sen painopisteenä on sen varmistaminen, että käyttäjät voivat käyttää tarvitsemiaan resursseja ja ominaisuuksia ja samalla hallita kustannuksia, tietoja ja immateriaalioikeuksia. Tätä edistymistä arvioidaan useiden luokkien perusteella, mukaan lukien käytäntöjen ja kehysten määrittäminen, käytäntöjen toteuttaminen, seuranta ja vaatimustenmukaisuuden lieventäminen sekä käyttöoikeuksien hallinta. Hallinto kehittyy manuaalisista ja reagoivista prosesseista integroituun, ennakoivaan järjestelmään, joka tasapainottaa keskitetyn hallinnan ja mukautuvan hallinnan kehittyviä tarpeita varten.

  • Alkuperäinen (riippumaton): Hallinto on manuaalista ja perustuu keskitettyyn valvontaan ja portinpitoon, joka estää skaalattavuuden. Kehittäjät ja tietoturvatiimit työskentelevät itsenäisesti ja vastaavat reagoivasti käytäntörikkomuksiin. Yhteensopivuutta ylläpidetään vähimmäisstandardien kautta, ja suojaustoimenpiteitä lisätään usein jälkiajatuksilla. Käyttöoikeudet myönnetään välittömien tarpeiden perusteella ilman standardoitua prosessia.
  • Toistettavissa (dokumentoitu): Organisaatio alkaa dokumentoida ja jakaa käytäntöjä, mutta ne pysyvät perus- ja epäyhtenäisinä. Lippujärjestelmien kaltaiset hallintotyökalut otetaan käyttöön käytäntöjen tarkistusten hallitsemiseksi, mutta prosessi pysyy manuaalisena ja hitaana. Valvontaprosessit ovat vakiintuneet, mutta ne ovat silti reagoivia. Jotkin roolit ja käyttöoikeudet on standardoitu, mutta pakottaminen ei edelleen ole mahdollista.
  • Määritetty (standardoitu): Hallinnasta tulee keskitettyä ja standardoitua johdonmukaisuuden ja tehokkuuden parantamiseksi kaikissa tiimeissä. Käytännöt on dokumentoitu ja hallittu keskitetysti ja toteutusprosessissa on jonkin verran automaatiota. Keskeiset hallintostandardit pidetään voimassa säännöllisin väliajoin, ja käyttöoikeuksien valvonta on automatisoitu virallisella RBAC-järjestelmällä, vaikka kehitystiimeillä on edelleen rajallinen valvonta käytäntömuutoksissa.
  • Hallittu (integroitu): Suojaus ja yhteensopivuus integroidaan saumattomasti työnkulkuihin, ja automaatio varmistaa, että käytäntöjä käytetään johdonmukaisesti kaikissa järjestelmissä ja tiimeissä. Reaaliaikainen seuranta ja edistynyt analytiikka auttavat havaitsemaan ja estämään hallinnon puutteita. Käytännöt on upotettu CI-/CD-jaksoihin, ja käyttöoikeuksien hallintaa säätelevät vähiten etuoikeuden periaatteet automatisoiduilla tarkistuksilla, mikä varmistaa ennakoivamman ja integroidun lähestymistavan hallintoon.
  • Optimointi (ennakoiva): Hallinnosta tulee dynaamista ja kontekstin huomioon ottavaa, se reagoi olosuhteiden muuttamiseen ja käyttöoikeuksien valvonnan optimoinniin. Ennakoiva analytiikka auttaa tunnistamaan mahdolliset riskit ennen niiden ilmenemistä, mikä mahdollistaa ennakoivan lieventämisen. Käytäntöjä tarkennetaan jatkuvasti kehittyneen analysoinnin avulla, ja käyttöoikeuksien hallintaa mukautetaan dynaamisesti reaaliaikaisten tekijöiden, kuten käyttäjän sijainnin ja käyttöoikeusajan, perusteella, mikä takaa vaatimustenmukaisuuden ja ottaa käyttöön räätälöityjä työnkulkuja.

Valmistelu ja hallinta

Valmistelu- ja hallintaominaisuuden avulla painopisteenä on se, miten käyttäjät luovat, ottavat käyttöön ja hallitsevat resursseja. Prosessi kehittyy manuaalisista siiloista mukautuvaksi ja automatisoiduksi järjestelmäksi, joka tasapainottaa joustavuuden hallinnon kanssa ja varmistaa, että resurssit valmistellaan tehokkaasti ja vaatimustenmukaisuusvaatimukset täyttyvät. Tämä eteneminen kattaa vaiheet, jotka on luokiteltu määrittämällä valmisteluprosesseja, vastaamalla pyyntöihin ja hallitsemalla pyyntöjä ja valvomalla resurssien varaamista.

  • Alkuperäinen (manuaalinen): Kehittäjät määrittävät infrastruktuurin manuaalisesti IT- tai arkkitehtuuritiimien ohjeiden perusteella, mikä johtaa epäjohdonmukaisuuksiin ja viiveisiin. Ilman standardoituja prosesseja pyynnöt tarkistetaan manuaalisesti, mikä lisää virheriskiä. Tästä lähestymistavasta tulee kestämätön kysynnän kasvaessa, ja siilotetut toiminnot luovat tehottomuutta.
  • Toistettavissa (Koordinoitu): Organisaatio alkaa keskittää valmisteluprosesseja lippujärjestelmien avulla infrastruktuuripyyntöjen hallintaan. Vaikka manuaalisia hyväksyntöjä edellytetään edelleen, joitakin virheitä vähennetään, mutta pullonkauloja on edelleen. Tiimit aloittavat vakiotyökalujen käytön resurssien seurantaan, vaikka näkymä pysyy siilottuna ja projektikohtaisena.
  • Määritetty (paved): valmisteluprosessit muodostetaan koko organisaatiossa käyttämällä Infrastruktuuri koodina (IaC) -standardia, mallien ja työkalujen standardisointia. Pyynnöt käsitellään jäsennettyjen työnkulkujen kautta, mutta käyttöympäristötiimillä voi olla vaikeuksia kasvavan kysynnän kanssa. Keskitettyjen koontinäyttöjen avulla voit valvoa resurssien varaamista ja tarjota parempia merkityksellisiä tietoja suorituskyvystä.
  • Hallittu (automatisoitu): Valmistelusta tulee automatisoitu ja integroitu CI-/CD-putkiin, mikä minimoi manuaalisen työn ja varmistaa yhdenmukaiset käyttöönotot. Hallinto- ja yhteensopivuustarkistukset on upotettu työnkulkuihin. Automaattisten itsepalvelutoimintojen avulla käyttäjät voivat valmistella resursseja hallituissa parametreissa. Skaalaus on automatisoitu käyttömallien perusteella suorituskyvyn optimoimiseksi.
  • Optimointi (mukautuva): Valmistelusta tulee mukautuvaa ja se käyttää älykkäitä järjestelmiä infrastruktuuritarpeiden ennakoimiseen reaaliajassa. Tämä lähestymistapa varmistaa resurssien tehokkaan kohdentamisen ja samalla hallinnon ja vaatimustenmukaisuuden säilyttämisen. Järjestelmät käsittelevät pyyntöjä ennakoivasti ja tasapainottavat joustavuutta hallinnon avulla, kun taas suorituskyky ja kustannustehokkuus optimoidään ennakoivan analytiikan avulla.

Liitännät

Käyttöliittymät-ominaisuudessa tärkein huomioita on se, miten käyttäjät käyttävät ja käyttävät käyttöympäristön palveluita ja tuotteita. Sen kehitymisessä keskitytään standardien perustamiseen, käyttäjien autonomian lisäämiseen ja alustaominaisuuksien saumattomaan integroimiseen olemassa oleviin työnkulkuihin. Lähestymistapa kehittyy epäyhtenäisestä manuaalisesta prosessista omatoimiseen, integroituun järjestelmään, joka parantaa käyttäjäkokemusta ja toiminnallista tehokkuutta.

  • Alkuperäiset (mukautetut prosessit): Käyttäjät ovat vuorovaikutuksessa ympäristön kanssa erilaisten epäyhtenäisten mukautettujen prosessien kautta, jotka vastaavat välittömiin tarpeisiin mutta joista puuttuu standardointi. Teknikot määrittävät itsenäisesti ympäristöjä konsultoimalla työtovereita tai luottamalla henkilökohtaisiin käytäntöihin, ja he valitsevat työkaluja ja prosesseja sovelluksen toiminnan diagnosointiin ilman vakiintuneita ohjeita. Tiedon jakaminen on epävirallista. Tiedon valmistelupalvelut edellyttävät usein palveluntarjoajilta syvällistä tukea, koska muodolliset prosessit eivät rajoitu skaalautuvuuteen ja tehokkuuteen.
  • Toistettavissa (paikalliset standardit): Teknikot ja tiimit aloittavat epävirallisesti standardien määrittämisen tietämyksen jakamisen parantamiseksi, vaikka johdonmukaisuus on edelleen haaste, koska he ovat riippuvaisia yksittäisestä sitoumuksesta. Jotkin tiimit voivat käyttää ohjeita tai säilöjä määritysprosessien määrittämiseen, mutta nämä käytännöt poikkeavat ajan mittaan, mikä edellyttää toimia. Sovelluksen toiminnan diagnosointi muuttuu standardoidummaksi tiimeissä, ja devOps- tai IT-tiimeihin luotettuina ovat jotkin, jotta he voivat käyttää käyttöön otettuja resursseja. Vaikka paikalliset standardit nousevat esiin, ne pysyvät löyhästi määriteltyinä ja epäyhtenäisinä eri tiimeissä.
  • Defined (Standard Tooling): Käyttöliittymät muuttuvat yhtenäisemmiksi standardoitujen työkalujen ja dokumentoitujen käytäntöjen käyttöönoton myötä. Keskustiimit hallitsevat malleja ja dokumentaatiota niin kutsutuilla sivutetuilla teillä tai kultaisilla poluilla, jotka ohjaavat toimintojen valmistelua ja tarkkailua. Nämä työkalut ja prosessit vastaavat organisaation laajoihin tarpeisiin, vaikka asiantuntijatukea tarvitaan edelleen usein. Tiimit voivat muokata malleja, mutta muutoksia ei aina integroida takaisin keskitetysti, mikä voi aiheuttaa johdonmukaisuuden säilyttämisen tehottomuutta. Sovelluksen toiminnan vianmääritys noudattaa standardoituja käytäntöjä käyttöön otettujen resurssien käyttämiseen ja analysoimiseen, mikä lisää yhdenmukaisuutta eri tiimien välillä.
  • Managed (Self-Service Solutions): Alusta mahdollistaa laajemman käyttäjäautonomian tarjoamalla omatoimisia ratkaisuja mahdollisimman vähäisellä ylläpidtämistuella. Käyttäjillä on käytettävissään yhtenäiset ja helppokäyttöiset käyttöliittymät, joiden avulla he voivat löytää ja muokata malleja. Näin he voivat luoda käytettävyyttä parantavan käyttäjäkeskeisen ympäristön. Työkalut sovelluksen toiminnan diagnosointiin ja resurssien tarkkailuun tarjotaan pyydettäessä käyttöympäristön kautta, jolloin varmistetaan, että käyttäjillä on tarvitsemansa resurssit ilman raskasta riippuvuutta ulkoisista tiimeistä. Tietojen jakamista helpottaa mallien etsiminen ja muokkaaminen, mikä kasvattaa käyttöympäristön ominaisuuksien arvoa.
  • Optimointi (integroidut palvelut): Ympäristön ominaisuudet integroidaan saumattomasti tiimien jo käyttämiin työkaluihin ja prosesseihin, kuten komentorivikäyttöliittymät tai integroidut palvelut, mikä tekee niistä luonnollisen osan käyttäjien työnkulkuja. Jotkin ominaisuudet valmistellaan automaattisesti käyttäjien tarpeiden mukaan. Käyttöympäristö tarjoaa joustavia rakenneosia ylemmän tason käyttötapauksissa, jotka saattavat edellyttää syvempää mukauttamista. Käyttöympäristötiimit arvioivat jatkuvasti, mitkä ominaisuudet ovat tehokkaimpia, mikä ohjaa lisäinvestointeja käyttöympäristötarjonnan optimoinnissa. Ympäristö määrittää automaattisesti käyttöön otettujen sovellusten havaittavuuden, tarjoaa reaaliaikaisen pääsyn diagnostiikkatietoihin ja tehostaa sovellusten toiminnan valvonta- ja hallintaprosessia.

Mittarit ja palaute

Mittaukset ja palaute -ominaisuus sisältää mittarien keräämisen, analysoinnin ja palautteen sisällyttämisen käyttöympäristön suunnittelukäytäntöjen onnistumisen arvioimiseksi. Sen kypsyys näkyy siirtymällä ad hoc- ja epämuodollisista menetelmistä ennakoivaan, datapohjaiseen kulttuuriin, jossa palaute ja merkitykselliset tiedot on integroitu jatkuviin parannusprosesseihin, strategisten päätösten ja ympäristökehityksen ohjaamiseen.

  • Alkuperäinen (ad-hoc): Alkuvaiheessa mittaus- ja palauteprosessit ovat epäyhtenäisiä ja pirstaleita. Mittarit kerätään ilman selkeää tasausta organisaation tavoitteisiin, mikä johtaa epätäydellisiin ja epäluotettaviin tietoihin. Palaute kerätään epävirallisesti ja usein anekdoottisesti, ja sidosryhmien osallistaminen on vähäistä. Tällöin päätökset tehdään rajoitetun tiedon perusteella ja ympäristösuunnittelukäytäntöjen todellisen pääoman tuottoa on vaikea mitata. Palautteen ja tulosten dokumentaatio on vähäistä, ja oppimia ei yleensä tallenna tai jaeta.
  • Toistettavissa olevat (jäsennettyjen prosessien) perustason palautemekanismit, kuten kyselyt tai keskustelupalstat, on määritetty käyttäjäkokemusten järjestelmällisemmiksi kuvaamiseksi, mutta nämä prosessit vaihtelevat silti eri tiimeissä. Menestyksen mittaamisessa keskitytään usein toimintopohjaisiin mittauksiin, kuten käyttöönottoihin tai aikajaneihin, tarjoten merkityksellisiä tietoja suorituskyvystä, mutta ilman laajempaa, tulokseen perustuvaa perspektiiviä. Palaute on edelleen epämuodollista ja alhaalta ylöspäin, mutta se alkaa vaikuttaa suunnitteluun. Sidosryhmien sitouttaminen on edettävää, mutta se on silti rajallinen, ja prosessien ja palautteen alustava dokumentaatio luodaan, mutta sitä ei ole kattavasti tai johdonmukaisesti käytetty.
  • Määritetty (johdonmukainen): Palautekokoelmasta tulee entistä muodollisempi ja standardoitu, jolloin saadaan tarkempia merkityksellisiä tietoja käyttäjien tarpeista ja tärkeistä mittareista. Mittarit siirtyvät kohti tulospohjaisia mittauksia, kuten kehittäjän tuottavuutta, mutta niiden linkittäminen taloudelliseen suorituskykyyn on edelleen haasteellista. Palauteanalyysi on systemaattista ja käyttää sekä laadullisia että kvantitatiivisia menetelmiä ja vakiomittareita, kuten DORA (DevOps Research and Assessment) on joukko mittareita, jotka mittaavat ohjelmistojen toimitustehoa, mukaan lukien liidiaikaa, käyttöönottotaajuutta, palautus- ja vikaastetta koskeva aika) tai SPACE (Tyytyväisyys ja hyvinvointi, Suorituskyky, Toiminta, Viestintä ja yhteistyö, ja Tehokkuus on puitteet kehittäjien tuottavuuden mittaamiseen näissä viidessä ulottuvuudessa) ovat työllistetty. Säännöllisten tarkistusistuntojen avulla, joissa on toiminnallisia tiimejä, varmista aktiivinen sitoutuminen sidosryhmien kanssa. Kattavaa dokumentaatiota palauteprosesseista, tuloksista ja kokemuksista ylläpidetään ja jaetaan tiimien kesken.
  • Hallittu (merkitykselliset tiedot): Tässä vaiheessa palautemekanismit ja mittauskehykset ovat vankkoja ja keskittyvät strategisiin liiketoiminnan tuloksiin. Aineistopohjaiset merkitykselliset tiedot ohjaavat käyttöympäristön toimintaa, ja palaute on integroitu alustan kartoiin, mikä edistää jatkuvia parannuksia. Edistynyttä analytiikkaa käytetään arvioimaan ympäristön vaikutusta liiketoiminnan tuloksiin, kuten tulojen kasvuun, ja palaute korreloi suorituskykymittareita, jotta voidaan tunnistaa strategisen parantamisen avainalueet. Sidosryhmät eri puolilla organisaatiota ovat syvästi mukana palauteprosessissa ja tekevät jäsenneltyä yhteistyötä siilojen välttämiseksi. Reaaliaikainen dynaaminen dokumentaatio kuvastaa jatkuvaa palautetta ja opittuja asioita, jotka ovat kaikkien sidosryhmien käytettävissä.
  • Optimointi (ennakoiva): Palaute- ja mittausprosessit on integroitu tiiviisti organisaation kulttuuriin, mikä luo ennakoivan lähestymistavan tulevien haasteiden ja mahdollisuuksien mittaamiseen ja sopeuttamiseen. Ennakoivaa analytiikkaa ja kehittyneitä mittareita käytetään tulevien tarpeiden ja mahdollisuuksien ennustamiseen, minkä ansiosta käyttöympäristö voi kehityä jatkuvasti muuttuvien olosuhteiden vuoksi. Palaute on integroitu täysin jatkuvaan parannusjaksoon ja palautekulttuuri otetaan käyttöön organisaation kaikilla tasoilla. Dynaaminen, reaaliaikainen dokumentaatio kuvastaa jatkuvaa palautetta ja sitä päivitetään jatkuvasti. Näin varmistetaan, että opitut asiat jaetaan ja että ne ovat kaikkien sidosryhmien käytettävissä.