Seitse märki, et tarkvaraarhitektuur pidurdab äri kasvu_

Tarkvaraarhitektuuri käsitletakse vahel ettevõttesisese tehnilise küsimusena. Tegelikult määrab see, kui kiiresti saab ettevõte tuua turule uue pakkumise, siseneda uude riiki, täita regulatsiooni, integreerida omandatud ettevõtte või taastuda intsidendist.

Arhitektuur ei ole hea seetõttu, et kasutab moodsat raamistikku. See on hea siis, kui toetab organisatsiooni tänaseid ja tõenäolisi tulevasi otsuseid vastuvõetava kulu ja riskiga.

Järgmised märgid viitavad sellele, et süsteem võib äri piirata.

1. Väike ärimuudatus nõuab suurt projekti

Hinnastusreegel, kinnitusetapp või uus kliendiväli ei peaks alati nõudma muudatusi paljudes meeskondades ja kuude kaupa koordineerimist.

Kui näiliselt väikestest soovidest saavad suured projektid, on levinud põhjused:

• ärireeglid on hajutatud mitme süsteemi vahel;
• komponendid on tihedalt seotud;
• andmed ja loogika on dubleeritud;
• omand on ebaselge;
• reliisid sõltuvad käsitsi sammudest;
• muudatust ei saa turvaliselt tervikuna testida.

Probleem ei ole selles, et iga muudatus peaks olema lihtne. Mõni ärimuudatus ongi keeruline. Ohumärk on korduv ebakõla soovitud tulemuse suuruse ja tarkvara muutmise kulu vahel.

Mõõtke kogu läbimisaega kokkulepitud äriotsusest toodanguni. Kui suurem osa ajast kulub ootamisele, koordineerimisele ja seoseta valdkondade uuesti testimisele, tasub uurida nii arhitektuuri kui tarnesüsteemi.

2. Reliisid on harvad, suured ja pingelised

Suured reliisid koondavad riski. Need ühendavad palju muudatusi, muudavad vigade põhjuse leidmise raskeks ning tekitavad surve juurutamist edasi lükata, kuni kõik on "valmis".

Sümptomid on:

• pikad reliisikülmutused;
• mahukad käsitsi kontrollnimekirjad;
• nädalavahetuse juurutused paljude spetsialistidega;
• usaldusväärse tagasipööramise puudumine;
• testimine, mis algab alles pärast integratsiooni;
• ärikasutajate hirm hiliseid parandusi küsida;
• mitme kuu töö korraga reliisimine.

Vastus ei ole lihtsalt sagedamini juurutada. Esmalt tuleb uurida, miks väike muudatus ei saa turvaliselt läbida ehitamist, testimist ja toodangusse paigaldamist. Vajalikud võivad olla automaattestid, juurutusautomaatika, jälgitavus ja selgemad komponentide piirid.

Läbimõeldud arhitektuur võimaldab organisatsioonil avaldada väikese kasuliku muudatuse ilma kogu ettevõtet mobiliseerimata.

3. Uuele turule sisenemine nõuab toote kopeerimist

Rahvusvaheline kasv paljastab sageli esimesel turul nähtamatuks jäänud eeldused: valuuta, keel, maksud, regulatsioon, hinnastus, aruandlus ja kohalikud integratsioonid.

Ohumärk on eraldi koodibaasi või tugevalt dubleeritud seadistuse loomine iga riigi või kliendi jaoks. Kopeerimine võib teise turu puhul tunduda kiire, kuid iga hilisem täiendus tuleb korrata, testida ja variantide vahel koordineerida.

Jälgige järgmisi tunnuseid:

• turuspetsiifilised tingimused on laiali kogu koodis;
• teenused või andmebaasid on kopeeritud;
• reliise tuleb käsitsi sünkroniseerida;
• funktsionaalsus on olemas ainult mõnel turul;
• keegi ei oska selgitada milline erinevus on tahtlik;
• jagatud käitumise muutmist hakatakse kartma.

Lahendus ei ole tingimata üks universaalne süsteem. Mõni turg vajabki erinevat võimekust. Arhitektuuriline eesmärk on eraldada stabiilsed ühised mõisted selgest kohalikust variatsioonist, et erinevust hallataks, mitte ei kopeeritaks.

4. Üks komponent või meeskond kontrollib kõiki tegevuskavasid

Süsteemis on struktuurne pudelikael, kui enamik algatusi sõltub ühest teenusest, andmebaasist, spetsialistist või meeskonnast.

See võib väljenduda nii:

• iga projekt ootab sama integratsioonimeeskonna taga;
• ühte andmebaasi muudavad paljud tooted;
• keskse platvormi backlog on pikem kui kõigil teistel;
• iga oluline otsus vajab ühte arhitekti;
• meeskonnad saavad funktsionaalsust ehitada, kuid mitte iseseisvalt reliisida;
• ühe valdkonna intsident peatab seoseta arenduse.

Pudelikaela inimeste lisamine võib ajutiselt aidata, kuid sügavam küsimus on, miks nii palju tööd peab sellest läbi liikuma. Stabiilsed liidesed, selgem omand, iseteeninduslikud võimekused ja seoseta vastutuste eraldamine võivad sõltuvust vähendada.

Ärge tükeldage süsteemi ainult selleks, et arhitektuurijoonis näeks hajutatud välja. Eemaldage pudelikaelad, millel on mõõdetav äriline mõju.

5. Toodangu käitumist on raske selgitada

Kui klient teatab tarkvara mitte-oodatud käitumisest, kas organisatsioon suudab kindlaks teha, mis juhtus, millist reeglit rakendati ja milliseid andmeid kasutati?

Halb seletatavus ilmneb siis, kui:

• logides puudub tähenduslik ärikontekst;
• andmemuudatusi ei saa jälitada;
• reeglid on dubleeritud;
• keskkonnad käituvad erinevalt;
• intsidendid lahendatakse põhjuse mõistmise asemel taaskäivitamisega;
• ainult üks kogenud inimene suudab sündmuse taastada;
• meeskonnad ei saa mõõta, kas reliis tulemust parandas.

See on nii tegevuslik kui arhitektuuriline probleem. Ilma jälgitavuseta ei saa ettevõte päris kasutusest turvaliselt õppida. Iga muudatus sisaldab rohkem teadmatust, intsidendist taastumine aeglustub ja vastavuse tõendamine muutub kalliks.

Kasulik jälgitavus seob tehnilised sündmused äriprotsessidega. See peab aitama vastata mitte ainult "Kas server töötab?", vaid ka "Kas kliendi teekond lõppes õigesti?"

6. Andmeid ei saa usaldada ega taaskasutada

Kasv sõltub usaldusväärsest infost operatsioonide, automatiseerimise, aruandluse ja otsuste jaoks. Arhitektuur muutub piiranguks siis, kui samal mõistel on mitu vastuolulist definitsiooni või puudub vastutav omanik.

Ohumärgid on:

• sama näitaja kohta erineva kogusummaga aruanded;
• korduv käsitsi kooskõlastamine;
• integratsioonid, mis loevad otse operatiivandmebaasist;
• oluliste väljade ebaühtlane täitmine;
• andmemuudatuste ajaloo puudumine;
• analüütika sõltuvus dokumenteerimata väljavõtetest;
• uued tooted ei saa olemasolevaid kliendi- või tehinguandmeid turvaliselt kasutada.

Tehnoloogia üksi ei paranda ebaselgeid ärilisi definitsioone. Andmete moderniseerimine vajab omandit, kvaliteedireegleid, päritolu ja teadlikke liideseid.

Alustage suure väärtusega ärivoost. Määrake vajalikud andmed, nende autoriteetne allikas, kvaliteediootused ja tarbijad. Vältige suurt platvormiprogrammi, mis püüab enne ühe kasuliku tulemuse tarnimist puhastada kogu organisatsiooni andmed.

7. Süsteemi käitamine tõrjub selle muutmise välja

Küps süsteem vajab hooldust, kuid tasakaal on halb siis, kui suurem osa inseneride võimekusest kulub intsidentidele, käsitööle, toetuseta sõltuvustele ja habrastele reliisidele.

Jälgige trende:

• tugitegevusele kuluv aeg kasvab ilma kasutajate arvu kasvuta;
• sama tüüpi vigu parandatakse korduvalt;
• uuendusi lükatakse edasi, kuni neist saab hädaolukord;
• taristukulu kasvab kasutusest kiiremini;
• arendajad kardavad kriitilist funktsionaalsust puudutada;
• intsidendid tõrjuvad tegevuskava töö korduvalt välja;
• põhjuste vähendamiseks pole reserveeritud võimekust.

See loob kuhjuva mõju. Kuna meeskonnal pole aega süsteemi parandada, muutub selle käitamine veel kallimaks ning muudatusteks jääb veel vähem aega.

Tehke tegevustöö nähtavaks ja liigitage selle põhjused. Korduvat käsitööd tuleb käsitleda toote- ja arhitektuuritööna, mitte vältimatu ärikuluna.

Diagnoosige enne lahenduse määramist

Need märgid ei õigusta automaatselt ümberkirjutust, mikroteenuseid või uut pilveplatvormi. Samad sümptomid võivad tuleneda ka ebaselgest tooteomandist, nõrgast testimisest, puuduvatest oskustest või ülekoormatud otsustusprotsessist.

Kasulik hinnang ühendab:

• ärimuudatuste implementeerimis- ja juurutamisajad;
• toodangu- ja intsidendiandmed;
• arhitektuuri ja sõltuvuste kaardi;
• intervjuud kasutajate ja inseneridega;
• hiljuti veninud algatuste ülevaate;
• väikesed eksperimendid kõrgeima riskiga valdkondades.

Eesmärk on leida piirang ja väikseim usutav sekkumine.

Parandage arhitektuuri äriliste tulemuste kaudu

Arhitektuuri moderniseerimist on lihtsam rahastada ja juhtida, kui see seotakse konkreetse tulemusega.

Näited:

• võimaldada üks uus turg toodet kopeerimata;
• vähendada hinnastusreegli muutmine kuudelt päevadele;
• võimaldada ühel meeskonnal iseseisvalt reliisida;
• luua ühe reguleeritud töövoo jälitatavus;
• eemaldada kõige sagedasemast intsidendist käsitsi taastamine;
• pensionile saata üks toetuseta kõrge riskiga komponent.

Igal tulemusel peab olema mõõdetav lähtepunkt ja toodangust saadav tõend. See takistab lõputul "moderniseerimisprogrammil" äriväärtusest eemalduda.

Ärge oodake kriisini

Arhitektuur muutub harva üleöö nähtavaks piiranguks. Signaalid ilmuvad esmalt pikemate ajahinnangute, suuremate reliisikoosolekute, rohkemate erandite ja kasvava võtmeisikusõltuvusena.

Vaadake neid signaale regulaarselt üle koos äri- ja tehniliste juhtidega. Eesmärk ei ole hoida süsteemi igavesti täiuslikuna. Eesmärk on märgata, millal muudatuse kulu ja risk hakkavad kasvama kiiremini, kui äri suudab taluda, ning sekkuda ajal, mil parandamine on veel valik, mitte hädaolukord.