Eksperimenteerimine vs standardiseerimine tehnoloogias
Innovatsiooni ja usaldusväärsuse vahelise pinge lahknemine määrab tänapäevaste tehnoloogiaorganisatsioonide edu. Kuigi katsetamine soodustab läbimurdeid tõestamata ideede ja tekkivate tööriistade testimise kaudu, pakub standardiseerimine olulisi kaitsepiirdeid, mis tagavad turvalisuse, kulutõhususe ja sujuva koostöö erinevate insenerimeeskondade vahel kiiresti arenevas digimaastikul.
Esiletused
Eksperimenteerimine tuvastab potentsiaali, standardiseerimine aga väärtust.
Liigne katsetamine viib tehnilise killustatuseni.
Standardimine võimaldab automatiseeritud turvanõuetele vastavust suures mahus.
Innovatiivsed ettevõtted kasutavad riskide maandamiseks nn eksperimentaaleelarveid.
Mis on Eksperimenteerimine?
Uute tehnoloogiate, arhitektuuride ja töövoogude testimise praktika konkurentsieeliste avastamiseks ja ainulaadsete probleemide lahendamiseks.
Sageli hõlmab see kontseptsiooni tõestust (PoC-sid), et kontrollida, kas uus tööriist suudab oma turunduslubadusi täita.
Tavaliselt toimub see isoleeritud „liivakastides” või laborikeskkondades, et vältida kontrollimata koodi mõju reaalajas kasutajatele.
Soodustab „kiiresti ebaõnnestumise” kultuuri, kus ebaõnnestunud katsetest õppimist hinnatakse sama palju kui verstaposti saavutamist.
Kasutab tavaliselt avatud lähtekoodiga projektide alfa- või beetaversioone, et olla valdkonna trendidest ees.
Nõuab spetsiaalset „innovatsiooniaega“, kus arendajad saavad vabalt uurida tööriistu väljaspool ettevõtte ametlikku tehnoloogiaplatvormi.
Mis on Standardimine?
Heakskiidetud tööriistade, protokollide ja parimate tavade komplekti loomine järjepidevuse ja operatiivse tipptaseme tagamiseks.
Vähendab inseneride „kognitiivset koormust”, piirates erinevate süsteemide arvu, mida nad peavad omandama.
Võimaldab nn kuldseid teid – eelnevalt kinnitatud malle, mis võimaldavad meeskondadel juurutada uusi teenuseid sisseehitatud turvalisuse ja jälgimisega.
Vähendab märkimisväärselt litsentsimis- ja pilvekulusid, koondades kasutamise väheste kontrollitud ja suuremahuliste pakkujate kätte.
Sujuvamaks muudab värbamis- ja sisseelamisprotsessi, kuna uued töötajad peavad õppima vaid kindlat dokumenteeritud ökosüsteemi.
Parandab süsteemi koostalitlusvõimet, tagades, et kõik sisemised teenused suhtlevad samade protokollide ja andmevormingute abil.
Võrdlustabel
Funktsioon
Eksperimenteerimine
Standardimine
Peamine eesmärk
Avastus ja innovatsioon
Tõhusus ja stabiilsus
Riskitaluvus
Kõrge; aktsepteerib ebaõnnestumist
Madal; seab esikohale tööaja
Kulude haldamine
Muutlik ja ettearvamatu
Optimeeritud ja prognoositav
Muutuste kiirus
Kiire ja sagedane
Aeglane ja tahtlik
Õppimiskõver
Pidev ja järsk
Algne, aga järjepidev
Otsustaja
Individuaalsed kaastöölised
Arhitektid või tehnoloogiajuhid
Skaala mõju
Võib viia killustumiseni
Vähendab tööhõõrdumist
Üksikasjalik võrdlus
Sõjavõitlus agility ja korra vahel
Eksperimenteerimine toimib kasvu mootorina, võimaldades meeskondadel oma tegevust muuta, kui uus raamistik pakub paremat jõudlust või arendajakogemust. Ilma standardiseerimiseta võib ettevõte aga kiiresti sattuda nn vari-IT olukorra juurde, kus iga meeskond kasutab erinevat andmebaasi, muutes globaalse hoolduse võimatuks ülesandeks. Õige tasakaalu leidmine hõlmab vabaduse lubamist avastamisfaasis, samal ajal kui projekti tootmiskeskkonda jõudes jõustatakse ranged reeglid.
Tehnoloogia leviku majanduslik mõju
Iga eksperimentaalses etapis lisatud unikaalne tööriist kannab endas varjatud „hooldusmaksu“, mis aja jooksul kuhjub. Kuigi meeskond võib täna nišiteegi abil paar tundi kokku hoida, maksab organisatsioon selle hiljem kinni killustatud turvapaikade ja keerukate integratsioonide kaudu. Standardiseerimine lahendab selle probleemi mastaabisäästu loomisega, kus ühte turvavärskendust või jõudluse kohandamist saab korraga rakendada kogu ettevõttes.
Arendajakogemus ja läbipõlemine
Insenerid ihkavad sageli katsetamisega kaasnevat mitmekesisust, kuna see hoiab nende oskused teravana ja töö kaasahaaravana. Seevastu liigne standardiseerimine võib tunduda „sundsärkina“, mis lämmatab loovust ja suunab tipptalendid paindlikumate konkurentide juurde. Edukaimad organisatsioonid käsitlevad oma standardeid „elavate dokumentidena“, mida regulaarselt uuendatakse edukate katsete põhjal, tagades tehnoloogiavaldkonna arengu ilma kaootiliseks muutumata.
Töökindlus tootmiskeskkonnas
Kui kriitiline süsteem peaks kell 3 öösel rivist välja minema, võimaldab standardiseerimine igal valveinseneril sekkuda ja arhitektuuri mõista. Puhtalt eksperimenteerivas maailmas võib see insener kokku puutuda spetsiaalselt loodud keele või arusaamatu andmebaasiga, mida ta pole varem näinud. Tootmiskeskkonna standardiseerimisega tagavad ettevõtted, et kõrge riskiga toimingud on prognoositavad, jälgitavad ja neist on lihtne taastuda.
Plussid ja miinused
Eksperimenteerimine
Eelised
+Avab läbimurdeid
+Meelitab ligi tipptalente
+Kiirem probleemide lahendamine
+Tulevikukindel äri
Kinnitatud
−Kõrgem rikke määr
−Fragmenteeritud andmed
−Koondamise kulud
−Turvaaugud
Standardimine
Eelised
+Ennustatav jõudlus
+Madalamad tegevuskulud
+Lihtsustatud turvalisus
+Lihtsam koostöö
Kinnitatud
−Aeglasem innovatsioon
−Vananemise oht
−Jäigad protsessid
−Talendi frustratsioon
Tavalised eksiarvamused
Müüt
Standardiseerimine on igasuguse loovuse vaenlane.
Tõelisus
Tegelikult kõrvaldab standardiseerimine „igavad” probleemid, näiteks kuidas andmeid juurutada või logida, mis vabastab arendajad, et nad saaksid oma loomingulist energiat rohkem kulutada ainulaadsete äriprobleemide lahendamisele.
Müüt
Eksperimenteerimine on mõeldud ainult sügavalt varastatud tehnoloogiahiiglastele.
Tõelisus
Väiksemad idufirmad peavad sageli rohkem katsetama, kuna neil puuduvad väljakujunenud radade järgimiseks vajalikud ressursid; nende jaoks on edukas eksperiment sageli ainus viis olemasoleva ettevõtte tegevuse häirimiseks.
Müüt
Kui standard on kord paika pandud, ei tohiks seda enam kunagi muuta.
Tõelisus
Standardid, mis ei arene, muutuvad „pärandvõlaks“. Edukad organisatsioonid vaatavad oma standardid üle iga 6–12 kuu tagant, et lisada uusimate katsete parimaid tulemusi.
Müüt
Saate iga tehnilise probleemi lahendamise standardiseerida.
Tõelisus
Standardimine toimib kõige paremini teadaolevate probleemide puhul. Täiesti uue turu või uudse tehnilise takistuse korral võib vanade standardite range järgimine tegelikult takistada ellujäämiseks vajalikku „karbist väljas“ mõtlemist.
Sageli küsitud küsimused
Kuidas otsustame, millised katsed peaksid saama ettevõtte standarditeks?
Levinud raamistik on „Tehnoloogiaradar“. Tööriista käivitatakse hindamis- või proovifaasis; kui see osutub mitme meeskonna lõikes järjepidevalt usaldusväärsemaks, kiiremaks või odavamaks, ilma et see tekitaks integratsiooniprobleeme, edutatakse see staatusesse „Kasutuselevõtt“, millest saab ametlik ettevõtte standard.
Milline on „kahe pitsa meeskonna“ lähenemine eksperimenteerimisele?
Amazoni poolt populariseeritud meetod hõlmab meeskondade hoidmist piisavalt väikestena, et neid kahe pitsaga toita saaks. Neile meeskondadele antakse autonoomia katsetada oma lokaliseeritud tööriistade ja töövoogudega, eeldusel, et nad järgivad mõningaid „globaalseid standardeid”, nagu API-vormingud ja turvaprotokollid, et tagada nende suhtlus teiste meeskondadega.
Kui palju innovatsiooniaega peaks tehnoloogiameeskonnal realistlikult olema?
Kuigi kuulus reegel „Google 20%” on populaarne võrdlusalus, leiavad enamik tänapäevaseid tehnoloogiajuhte, et 5–10% sprindist on jätkusuutlikum. See võimaldab korraldada „avastussprinte” või „häkatone”, kus arendajad saavad uue tehnoloogiaga katsetada ilma peamist tootearendusplaani rööpast välja viimata või kriitilisi tähtaegu ületamata.
Kas standardiseerimine võib tegelikult viia turvaaukude tekkeni?
Jah, seda tuntakse kui „monokultuuri“ riski. Kui iga teie ettevõtte teenus kasutab ühe teegi täpselt sama versiooni, võib selle teegi äsja avastatud ärakasutamine potentsiaalselt kogu teie infrastruktuuri korraga alla viia. Seetõttu on teatav mitmekesisus pinus – kontrollitud eksperimenteerimine – tegelikult turvafunktsioon.
Mis on suurim märk sellest, et meie tehnoloogiapakk on liiga killustatud?
Kõige ilmsemaks sümptomiks on see, kui uuel arendajal kulub kohaliku keskkonna seadistamiseks rohkem kui nädal või kui „lihtsad” meeskondadevahelised projektid nõuavad nädalatepikkust läbirääkimist ainuüksi andmete jagamise viisi väljaselgitamiseks. Kui teil on viis erinevat viisi kasutajate autentimise haldamiseks viies erinevas rakenduses, on teil killustatuse probleem.
Kas standardiseerimine raskendab spetsialiseerunud ekspertide palkamist?
Tegelikult võib see asja lihtsamaks teha. Standardiseerides populaarseid ja hästi toetatud tehnoloogiaid (nagu React või PostgreSQL), saate ligipääsu palju suuremale kandidaatide ringile. Kui katsetate liiga palju niši- või kohandatud keeltega, ei pruugi te pärast algsete arendajate lahkumist leida kedagi vajalike oskustega.
Kas on võimalik katsetada standardiseeritud protsessidega?
Absoluutselt. Katset saab läbi viia mitte ainult tarkvara, vaid ka töövoo peal. Näiteks võib meeskond kuu aega katsetada paarisprogrammeerimist, et näha, kas see vähendab vigu. Kui andmed näitavad, et see toimib, saab selle protsessi standardiseerida kogu ülejäänud osakonnas.
Kuidas mõjutavad pilveteenuse pakkujad eksperimenteerimise ja standardiseerimise tasakaalu?
Pilveplatvormid nagu AWS ja Azure pakuvad tohutut hulka hallatud teenuseid, mis hõlbustavad kohest katsetamist. Samas tekitavad need ka sõltuvust tarnijast. Pikaajaline standardiseerimisstrateegia hõlmab sageli selliste teenuste valimist, mis on kas avatud lähtekoodiga või millel on lihtsad migreerimisviisid, et vältida sõltuvust ühe pakkuja hinnakujundusest.
Otsus
Eksperimenteerimine on konkurentsis püsimiseks ja „järgmise suure asja“ leidmiseks varases arendusfaasis ülioluline. Pikaajalise ellujäämise ja skaleerimise tagamiseks peab aga standardiseerimine lõpuks võimust võtma, et tagada süsteemi hallatavus, turvalisus ja kulutõhusus.