Täna leiab turult erinevaid tehnoloogiaid ja lähenemisviise rohkem kui keegi kokku lugeda jõuab, kusjuures enamik neist on igati head. Aga nii, nagu ei saa hästi töötavat autot kokku panna erinevate markide kõige võimsamatest detailidest, ei saa IT-lahendusi luua kõike turul pakutavat kasutades. Õigemini saab – ja nagu ka Frankensteini-auto võib loodu korra isegi elule turgatada – kuid pikaajaliselt on võimatu midagi sellist töös hoida.
IT-vaatest tähendab see, et kui iga töötaja tuleb majja oma tehnoloogiaga, mis talle enim meeldib ja mida ta kõige paremini oskab, tekib varem või hiljem koht, kus keegi ei saa aru, mida ja kuidas tehakse. Niisugust olukorda aitab ära hoida mõistlik standardiseerimine ehk see, kui pannakse paika kuidas, miks ja mil viisil midagi tehakse. Mida selgemini ja ühtsemalt tehniline personal alusloogikat mõistab, seda hallatavamaks ja paremini ühilduvaks muutuvad iga konkreetse töötaja loodud lahendused.
Standardiseerimise juures on hea pidada meeles, et loogika ja hallatavuse taga ajamine ei saa jääda innovatsioonile jalgu. Oluline on leida tasakaal uute asjadega kaasajooksmise ja ajale jalgujäämise vahel.
Legacy ehk juba jutumärkides aegunud süsteem või tehnoloogia ei pruugi küll paljudele meeldida, kuid mõne uue lahenduse igapäevane rakendamine n-ö värvib varem või hiljem tiimi nurka. Samas ei saa standardiseeritud tehnoloogiaportfell jääda tulemuste saavutamisele jalgu: ühel hetkel ei suuda tehnoloogia teha seda, mida täna vaja või ei leia tööturult inimesi, kes nende lahendustega töötada sooviks.
Mõistliku lähenemisega on aga võimalik saavutada üsnagi hea kuldne kesktee. Üks standardiseerimise peamised eesmärke on hoida erinevate kasutusel olevate tehnoloogiate hulk mõistlik – et 20 arendajat ei teeks asju 20 erineval moel – aga kuskil pole kirjas, et 20 arendajat ei võiks teha asju viiel erineval moel. Miski ei keela asju mõne aja tagant orgaanilise valdkonna arengu käigus välja vahetada. Oluline, et neid samme tehtaks läbimõeldult ja ühiselt, mitte hoogtöö korras ega põlve otsas nokitsedes.
Kui ideaalses maailmas muutuvad standardid ajas orgaaniliselt, pole patt tunnistada, et standardiseerimisel on mingi hetk tehtud vale valik või aeg on küps teadlikuks muutuseks. See on igati okei ja enamasti ka õige lähenemine. Küll aga tuleb meeles pidada, et standardeid ei saa muuta iga paari päeva tagant. Tehnoloogiad, millega end seotakse, jäävad ettevõtet saatma tükiks ajaks, seega tasub pigem võtta aega ja erinevaid mõtteid testida, enne kui millelegi täielikult pühendutakse.
Standardiseerimine ei tähenda üksnes seda, et tiimid kasutavad sama programmeerimiskeelt või mingeid kindlaid raamistikke. See on oluline osa laiemast protsessist, kuid sellest üksi ei ole suurt kasu, kui kõik muu jääb tähelepanuta. Seetõttu kuuluvad mõistliku standardiseerimise juurde ka turvateemad, parimad praktikad, koodistandardid, dokumenteerimisreeglid ja kõik muud väikesed asjad, mis mõjutavad tiimi ja ettevõtet laiemalt.
Kui kõik töötajad teavad, kuidas läheneda küberturvalisusele või milliste reeglite järgi dokumenteerida oma kirjutatud koodi, võib järsku tekkida meeletus koguses võimalusi efektiivsemaks asjaajamiseks. Näiteks erinevate tarkvaraliste tükkide ristkasutamise läbi – kui kõik on tehtud erimoodi, ei saa ühest lahendusest teise lihtsalt 20 koodirida üle tõsta – või kasvõi seeläbi, et uus töötaja suudab end kõikidesse erinevatesse lahendustesse oluliselt kiiremini sisse elada. Kui ta mõistab, mis loogika alusel on üles ehitatud üks asi, mõistab ta, mis loogika järgi on üles ehitatud kõik asjad.
Standardiseerimisele mõistlikult lähenedes võidavad lõpuks kõik. Võidab ettevõte, kus asjad hakkavad äkitselt oluliselt loogilisemalt toimuma; võidavad töötajad, kes ei ole enam aheldatud kunagi valitud nišitehnoloogia külge; võidavad lõppkliendid, kes saavad kiiremini paremini toimivaid lahendusi ning võidavad kõik, kes kunagi mistahes põhjusel loodud tehnoloogiate kapoti alla vaatama peavad.