Tehnoloogiaplatvormi valiku varjatud ohud: juhend tehnoloogiajuhtidele

Ettevõtete tehnoloogiaprojektide ebaõnnestumise määr on üsna hämmastav, kuna ligikaudu 70% neist ei ole edukad halva tehnoloogia valiku tõttu. Tehnoloogiajuhid on tavaliselt huvitatud uutest arhitektuuridest ja uusimatest tööriistadest, kuid sellised otsused toovad sageli kaasa suure tehnilise võla ja kuluka süsteemi ümberkirjutamise. Kõige levinumad vead on etteaimatavad: keskendumine moes olevatele tehnoloogiatele, mitte äri vajadustele, hoolduse vajaduse ignoreerimine ja meeskonna teadmistele mittevastava tööriista valimine. Sellised eksimused põhjustavad kulukaid täiustusi, jõudluse pudelikaelu ja arendustiimide motivatsiooni langust. Analüüsis esitatakse reaalsed juhtumid, kus projektid ebaõnnestusid tehnoloogia valikuga seotud halbade otsuste tõttu, ning selgitatakse tehnoloogia ebaõnnestumise põhjuseid. Praktiliste juhtumiuuringute abil pakume praktilisi raamistikke, mis aitavad tehnoloogiajuhtidel teha teadlikke otsuseid, mis teenivad ettevõtte eesmärke, kasutavad ära meeskonna tugevusi ja võimaldavad jätkusuutlikku kasvu.

Tehnoloogiajuhid satuvad korduvalt äratuntavatesse lõksudesse, mis õõnestavad nende valikuid. Uued tehnoloogiad on arutlusteema, mis tavaliselt varjutab pikaajaliste mõjude visiooni ja praktilise rakendamise küsimused. Tehniline võlg on kumulatiivne, kuna puudub hoiatus, et organisatsioon on sattunud kulukate ja ebatõhusate süsteemide finantslõksu, mis takistavad äri kasvu asemel seda toetamast.

Trendikate tehnoloogiate võlu

CTO-d valivad regulaarselt tehnoloogiaid, mis on tööstuses populaarsed, mitte neid, mis on strateegiliselt vajalikud. Selline stiil tekitab suuri lõhesid äri vajaduste ja tehniliste võimaluste vahel. Uute struktuuride atraktiivsus kipub asendama praktilised hindamisstandardid. Sotsiaalne kinnitus osutub kahjulikuks asenduseks tõenditel põhinevale otsuste tegemisele. Organisatsioonid järgivad uusimaid tehnoloogiaid, kuna neil on surve olla trendikad nagu kõik teisedki ja kuna selline algatus on ambitsioonikas ja ahvatlev. Sellise karjamentaliteedi tagajärjeks on keerukate lahenduste kasutuselevõtt, mis nõuavad palju töö ümberkorraldamist ja lisakulutusi hooldusele.

Sõnatu hoolduse kokkuvõte

Organisatsioonid ei näe sageli tehnoloogiainvesteeringute tervikpilti selles mõttes, et esialgne arendus ei ole lõpp. Ettevõtte tarkvara analüüs näitab, et suurte koodibaaside puhul võtab hooldus umbes 75 protsenti kogu tööst. See pidev koormus hõlmab järgmist:

• Testimine
• Veakontroll ja veaparandamine
• Jõudluse optimeerimine
• Ühilduvuse testimine
• Refaktoreerimine
• Klienditeenindus
• Dokumentatsioon

Tarkvara tellimused tekitavad uusi kulusid. Kuigi alguses ei ole see kulukas, tekivad pikemas perspektiivis kulud, eriti meeskondade laienemisel ja vajadusel osta rohkem litsentse. Premium-funktsioonidel, tugiteenustel ja salvestusruumi uuendustel on tavaliselt varjatud kulud, mis ei olnud uurimise ajal ilmne.

Meeskonna võimete ebakõla

Meeskonna oskuste ühtlustamine on üks olulisemaid aspekte, mida tehnoloogia valimisel ei tohi unustada. Uute struktuuride arendamisel kalduvad organisatsioonid valima raamistikke, ilma et hindaksid nende arendajaid, et mõista, kui palju kogemusi neil on rakendamise ja hoolduse õige protsessi osas. Meeskonnad, kes arendavad tehnoloogiatega, millega nad ei ole hästi tuttavad, peavad tegelema järgmiste küsimustega:

• Järsk õppekõver
• Aeglasemad arendusetsüklid
• Kõrgem defektide määr
• Halva kvaliteediga rakendamine

Juhtkond võib olla tehniline ja ülehinnata tehniliste spetsifikatsioonide maksumust ning alahinnata koolituse maksumust, uute töötajate sisseelamise keerukust ja tootlikkuse kaotust. Meeskonna võimekusele mittevastavad tööriistad viivad halva kasutuselevõtu ja madala investeeringutasuvuseni. Mõelge Ruby on Rails valikule: seda valitakse sageli selle arendamise kiiruse, lihtsuse ja laia valiku raamatukogude tõttu, mis aitavad kiiret prototüüpimist. Need eelised realiseeruvad aga ainult siis, kui meeskonnad juba omavad Ruby alaseid teadmisi. Õppekõver peab olema kooskõlas arendajate erialateadmistega, et tootlikkuses ei tekiks pudelikaelu. Sunduslik oskuste täiendamine projekti keskel võib saavutatud edu hävitada.

Kui tehnoloogiaprojektid ebaõnnestuvad, analüüsisime erinevate tööstusharude ja erineva suurusega ettevõtete juhtumeid, et mõista põhjuseid. Mõlemad organisatsioonid seisid silmitsi tõsiste tehniliste probleemidega, mis võivad olla otseselt seotud tehnoloogiaplatvormi valikuga. Põhjuseks osutusid ootamatult sarnased tegurid: liiga keerulised arhitektuurid, jõudlusprobleemid ja skaleeritavuse probleemid. Käesolevas jaotises tuuakse välja kolm illustratiivset juhtumit, kus steki otsused ei ole kooskõlas tootevajaduste või meeskonna võimekusega.

Mikroteenuste keerukus lihtsates rakendustes

Üks SaaS-startup kannatas mikroteenuste enneaegse kasutuselevõtu tõttu. Üle 18 kuu jooksul oli ettevõte loonud mitmesuguseid erinevaid tehnoloogiaid, mis viisid aruteluni killustatud süsteemi üle, kus omandiõigus vahetas pidevalt omanikke meeskonna liikmete vahel. Esialgu tundus see süsteem olevat geniaalne, jagades rakendused väiksemateks rakendusteks, mis on teoreetiliselt skaleeritavad. Siiski muutis süsteemi kaootiliseks asjatundlike või tähelepanelike meeskonnaliikmete puudumine, kes oleksid suutnud platvormi tõhusalt juhtida. Oluline viga oli keeruka arhitektuuri kasutuselevõtt enne toote nõuete väljatöötamist. Mikroteenused on üks viis keerukusega toimetulekuks, kuid see ei ole tasuta privileeg. Mikroteenuste lähenemine ei soodustanud kasvu, vaid osutus pigem takistuseks tootele, mis vajas kiiret iteratsiooni, mitte hajutatud süsteemide lisakulusid. Teataval hetkel ei suutnud ettevõte platvormi piirangute tõttu lisada uusi välju ja kasutada mõningaid API-triggereid, mis viis põhiliste funktsioonide riketeni. Kompleksne lahendus jäeti täielikult kõrvale, kuna meeskonnaliikmed olid pettunud ja asusid kasutama tabelarvutustabeleid ülemäära keeruka tehnoloogia asemel.

Mängurakenduste jõudluse piirangud

Üks mängufirma testis React Native'i, et luua kõrge jõudlusega mobiilimäng, kuid see tekitas graafikamahukate kogemuste puhul ületamatuid tehnilisi raskusi. Kuigi React Native'il on platvormiülese arendamise eelised, puudusid sellel sisuliselt jõudlusvõimalused, et toetada väga keerukaid mängunõudeid. Arendusmeeskond avastas, et JavaScripti niidi jõudlus oli halvenenud. Hoolimata sellest, et React Native väidab suutvat pakkuda vähemalt 60 kaadrit sekundis, kaotas rakendus keeruliste animatsioonide ja interaktsioonide kasutamisel pidevalt kaadreid. Jõudluse diagnostika näitas, et iga protsess, mis nõudis rohkem kui 100 ms, tekitas kasutajale viivituse. Need piirangud olid katastroofilised mängudele, mis vajasid keerulisemat füüsikat või renderdamist. Meeskond püüdis optimeerida natiivseid mooduleid, kuid tööriista ja vajaduste põhiline ebakõla püsis endiselt. Kuigi React Native võimaldab arendada platvormiüleseid rakendusi, kasutades ainult ühte koodibaasi, kaotas see oma tähtsuse, kui lõpptoode ei suutnud isegi minimaalseid jõudlusstandardeid täita.

Finantstarkvara andmebaaside skaleerimise haavatavused

Finantstehnoloogia rakendus käivitati vanema monoliitse SQL-andmebaasiga ja alguses töötas see hästi. Kuid tehingute mahu kasvades ei suutnud süsteem enam toimida ega skaleeruda. Viivitus ja viivitused kogumitöötluses muutsid reaalajas analüüsi praktiliselt võimatuks. CTO peamine viga oli see, et ta ei ennustanud finantsandmete töötlemise skaleerimisvajadusi. Andmebaasi disain ei ole loodud toetama järgmist:

• Horisontaalne skaalamine
• Koormuse tasakaalustamise meetodid
• Tehingute tippmaht

Jõudlus halvenes märkimisväärselt ja päringu vastamise aeg pikenes minutiteks. See halvenemine oli katastroofiline rakendustes, kus tehingute kiirus on kasutaja jaoks väga oluline, ning finantsrakendustes. Pärast põhjalikku tehnilist hindamist on ettevõte üle läinud hajutatud andmebaasile, millel on HTAP (hübriidne tehingute/analüüsi töötlemise) arhitektuur. See muudatus võimaldab töödelda tuhandeid tehinguid sekundis madala latentsusega ja samal ajal teha reaalajas analüüsi.

Juhtumiuuringutes täheldati kolme tüüpi vigu, mis põhjustasid tehnoloogiaplatvormi rikkeid. Kõik need vead viitavad organisatsioonide tehnoloogia valiku ja rakendamise lähenemisviiside tõsistele lahknevustele.

Äri- ja tehnoloogia keerukuse ebakõla

Üks levinumaid vigu tehnoloogiaplatvormi valikul on see, kui organisatsioonid saavad kunstlikult keeruka arhitektuuri, mis ei vasta äri vajadustele. Enamik ettevõtteid esitab mitu kihti ja allsüsteemi, millest igaüks peaks olema oma valdkonnas parim, kuid kogu süsteem on aeglane, ebausaldusväärne ja kallis. Selle praktika tulemus on:

• Suure arvu kihtide tõttu aeglasemad rakendused
• Mitme ülemineku tõttu keeruline
• Ebausaldusväärne, kuna igal kihil on erinevad rikkeviisid

Kliendipõhiste ettevõtete puhul tähendab see, et iga halb tehnoloogilise lahenduse valik mõjutab otseselt kliendikogemust, põhjustades aeglast laadimist ja katkestusi, mis omakorda suurendab klientide lahkumist.

Tehniline võlg ja refaktoreerimine

Vigase tehnoloogia varajane investeerimine põhjustab tehnilist võlga, mida on üha raskem lahendada. Tegelikult suunatakse enamik ettevõtete IT-eelarvest tarkvara hooldusele ja toele, mitte innovatsioonile. Kui organisatsioonid on problemaatilistesse lahendustesse palju investeerinud, võib uppunud kulude eksiarvamus takistada muutuste tegemist. Refaktoreerimine peab olema väärtuslik ja keskenduma tegelike vajaduste rahuldamisele, mitte spekulatsioonidele. Suuremahuline ümberkujundamine, mida ei ole võimalik tavapäraste arendusprotsesside raames teostada, on paljude organisatsioonide jaoks väljakutse. Põhielementide ümberkujundamine hõlmab tavaliselt ressursside eemaldamist ja uuesti loomist, mis seab ohtu olulised äriandmed.

Dokumentatsiooni ja uute töötajate sisseelamise nõrgad küljed

Ettevõtte ebaõnnestumised ja puudused dokumentatsioonis põhjustavad suuri varjatud kulusid, kuna nõrkade dokumentatsioonitavade korral on tööleasumise protsess vajalikust pikem. Paljud inseneriosakonnad jäävad kvaliteetse sisemise dokumentatsiooni koostamisel maha, kuid ebajärjekindluse hind on palju kõrgem kui dokumentatsiooni protsessidesse integreerimise kulud. Uued meeskonnaliikmed raiskavad palju aega vastuste otsimisele ja taasavastamisele või teevad vigu, mida saaks vältida, kui teave oleks nõuetekohaselt dokumenteeritud. Selline olukord põhjustab suurt tootlikkuse langust, mille tõttu mõned arendajad ei suuda nädalaid või isegi kuid tõhusalt töötada.

Et vältida valikupüüniseid, on oluline minna kaugemale moesõnade vältimisest. See nõuab, et mõtleksite hoolikalt läbi, mida te loote, kes seda loob ja kuidas teie süsteem kasvab ja areneb.

Määratlege toote ulatus

Enne tööriistade võrdlemist määrake kindlaks toote eesmärk ja eeldatav eluiga. Kas tegemist on kiiresti areneva ja lühiajaliste eesmärkidega MVP-ga? Või platvormiga, mille eeldatav kasv on järkjärguline viie aasta jooksul? Arvestage ka arenguga. Kui teete integratsioone, analüüse või lisate kasutajarolle, valige selline stack, mida saab nendes stsenaariumites kasutada ilma kogu stacki ümber ehitamata.

• Lühiajaliste toodete puhul tagavad kiire arengusüsteemid (nt MEAN või Firebase) kiiruse ja paindlikkuse.
• Pikaajaliste süsteemide puhul keskenduge modulaarse ja hooldatava arhitektuuri loomisele, mida ei ole vaja oluliselt ümber kirjutada.

Paberil võib stack tunduda ideaalne, kuid kui keegi teie meeskonnast ei suuda tootmises midagi debuggida ega isegi stacki paremaks toimimiseks häälestada, muutub see koormaks.

• Valige tehnoloogiad, millega teie insenerid on juba tuttavad, juhul kui on vaja kiiresti tulemusi saavutada.
• Planeerige ette tulevikuga ühilduva stacki kasutamine, kuid arvestage aega koodi auditeerimiseks, uute töötajate sisseõppeks ja koolitamiseks.

Arvestage väliste nõuetega

Stacki valikud ei toimu vaakumis. Nõuetele vastavus, eelarve ja integratsioonivajadused on muuhulgas reaalsed vajadused, mis peaksid kajastuma kõigil teie arhitektuuri tasanditel. Vastavus ja turvalisus: finantstehnoloogia või tervishoiu valdkonnas veenduge, et teie tarkvarakomplekt on auditeerimisprotokollide jaoks sobiv, rollipõhine juurdepääsukontroll ja alati ülespoole ühilduv krüpteerimine. Eelarve: arvestage litsentside, infrastruktuuri, hallatavate teenuste ja muude varjatud kuludega, nagu kolmandate osapoolte API kasutamine või isegi lukustamine. Integreerimine: Teie süsteem võib rikkuda, kui see ei integreeru teiste süsteemidega. Koguge andmevoogu üles ja alla.

Mõõtke pikaajalist jätkusuutlikkust

Mis on praegu jätkusuutlik, võib homme olla nõrk. Otsi:

• Stabiilsed uuendused: ebastabiilsed uuendused või kogukonna toetuse puudumine võivad muutuda takistuseks
• Hästi dokumenteeritud ja väljakujunenud ökosüsteem: see lihtsustab kasutuselevõttu ja vähendab sõltuvust ettevõttesisestest ekspertidest
• Operatsiooniline lihtsus: kui teie stack vajab tweezingut või devops-hooldust, ei pruugi see väikesele meeskonnale sobida.

Jõudlus ja operatsiooniline keerukus

Staki valik tähendab kompromissi:

• Skaalautuvusmudel: Kas saate horisontaalselt skaalautuda, lisades rohkem instantsi, või olete piiratud vertikaalse skaalautumisega monoliidiga?
• Jõudlus koormuse all: Mõned stackid sobivad paremini samaaegsete ja kergete tehingute tegemiseks (nt Node.js) või raskete tehingute tegemiseks raskete tehinguprotsessoritega (nt Spring Boot)?
• Operatsiooni keerukus: Kas teie meeskond töötab ja hooldab usaldusväärselt või on tegemist mingi tasuvuspiiril oleva ajutise lahendusega?

Tehke sellised otsused, mis soodustavad kasvu ja ei tekita tehnilist võlga.

Tulevikukindlat lahendust ei ole olemas, kuid on olemas paindlikumad lahendused. Õige otsus on kooskõlas teie äri visiooni, toote missiooni, meeskonna pädevuste ja mastaabi nõuetega. See võimaldab kiiret kasvu praegusel ajal ega ole tulevikus takistuseks. Kõige tõhusamad tehnoloogiajuhid ei vali lihtsalt tööriistu. Nad loovad püsivaid süsteeme.

Tehnoloogiaplatvormi loomine on üks olulisemaid otsuseid, mida tehnoloogiajuhid oma karjääri jooksul teevad. Kui see on tehtud õigesti, muudab see platvormi skaleeritavaks, jõudluseks ja kiiremaks. Valesti tehtuna põhjustab see tehnilist võlga, innovatsiooni stagnatsiooni ja töötajate frustratsiooni. Olge ettevaatlik, et alguses ei teeks otsuseid, mis takistavad teid tulevikus. Mõelge enne, kui tegutsete, planeerige ja investeerige lahendusse, mis kasvab koos teiega. Kõik seisneb kompromissis järgmiste asjade vahel:

• Lühiajalised nõudmised ja pikaajalised perspektiivid
• Meeskonna oskused ja äri vajadused
• Uuenduslikkus ja jätkusuutlikkus

Tehnoloogiajuhid saavad võtta vastu strateegilisi otsuseid, mis soodustavad organisatsiooni arengut, selle asemel et seda takistada, vältides takistusi ja kasutades strateegilisi raamistikke.