Kai augimas pradeda jaustis kaip trintis

MedTech programinė įranga retai genda iš karto. Pasikeisti tampa sunkiau.

Sistemoms augant, funkcijos, kurios turėtų būti paprastos, užtrunka ilgiau nei tikėtasi. Komandos dvejoja prieš atlikdamos atnaujinimus.

Sprendimai stringa, nes pakeitimo poveikis neaiškus.

Tuo pačiu metu tokios įmonės kaip „Amazon“, „Google“ ir „Microsoft“ toliau plečia savo platformas, nuolat leisdamos naujinimus.

MedTech sistemos sulėtėja, nes tampa sudėtingesnės. „Big Tech“ sistemos to nedaro.

Skirtumas nėra inovacijų tempas. Taip kuriamos sistemos.

Tai, kas atrodo kaip kryžminė trintis, dažnai turi paprastesnę priežastį.

Paprastai tai yra architektūra.

Tai yra artėjančio „Orthogonal“ internetinio seminaro „Cloud-Native Architecture for MedTech“ (ko galite išmokti iš „Amazon“) akcentas. Sesijos metu nagrinėjama, kodėl platformos lėtėja plečiantis ir kas skiria komandas, kurios nuolat juda, nuo tų, kurios palaipsniui praranda pagreitį.

Neseniai vykusiame pokalbyje, kuriame buvo peržiūrėtas internetinis seminaras, CTO Larkin Lowrey paaiškino, kodėl daugelis MedTech platformų auga lėtesnės ir rizikingesnės.

Tikroji monolitinių sistemų kaina

Larkinas apibūdino, kas atsitinka, kai sistemos auga be aiškių ribų.

Laikui bėgant kodų bazės tampa glaudžiai tarpusavyje susijusios. Inžinieriai tai vadina „spagečių kodu“, kai pokyčiai vienoje srityje tyliai veikia daugelį kitų. Dėl to kiekvienas atnaujinimas sukelia daugiau netikrumo, nei tikėtasi.

Tas netikrumas pasireiškia taip, kaip vadovai atpažįsta:

• Net mažiems pakeitimams reikalingas didesnis koordinavimas
• Lėtesni atleidimo ciklai
• Padidėjusi rizika diegiant naujinimus

Sistema tampa jautri. Sulėtėjimas vienoje srityje gali sumažinti našumą kitur. Vieno komponento defektas gali turėti platesnių pasekmių, nei tikėtasi.

Tuo metu funkcijų pridėjimas nebėra iššūkis. Ką nors pakeisti saugiai yra.

Kaip modulinė architektūra keičia vykdymo tempą

Larkinas siūlo paprastą būdą pagalvoti apie alternatyvą.

Kai keli žmonės dirba su ta pačia dėlionės dalimi, pažanga sulėtėja. Kai darbas suskirstytas į aiškias dalis, daugiau žmonių gali prisidėti be trukdžių.

Modulinė architektūra tą patį principą taiko programinei įrangai.

Tai leidžia komandoms:

• Judėkite lygiagrečiai be nuolatinio koordinavimo
• Apriboti pokyčių poveikį
• Masto plėtra nedidinant pažeidžiamumo

Rezultatas – ne tik švaresnės sistemos. Tai keičia kasdienį komandų darbą, ypač augant sistemai.

Architektūra kaip reguliavimo greičio svirtis

Reguliuojamose aplinkose architektūra taip pat lemia, kaip greitai komandos gali dirbti.

Viena iš praktiškesnių įžvalgų, kuriomis dalijosi Larkinas, yra tai, kaip modulinės sistemos leidžia komandoms atskirti programinę įrangą pagal rizikos lygį. Jei maža platformos dalis kelia didžiausią susirūpinimą, ji neturi diktuoti viso kito tempo.

„Mes neleidžiame tiems 5 % sulėtinti kitų 95 %.

Tai ypač aktualu prijungtiems įrenginiams ir SaMD platformoms. Kai didelės rizikos funkcionalumas yra izoliuotas, komandos gali greičiau dirbti su mažesnės rizikos komponentais, nepakenkiant kontrolei ten, kur tai svarbiausia.

Vietoj to, kad atitiktis sulėtintų plėtrą visame pasaulyje, ji tampa tikslingesnė ir lengviau valdoma.

Kodėl debesys verčia pereiti nuo valdymo prie atsparumo

Debesų infrastruktūra nustato kitokį apribojimą.

Tradicinėje aplinkoje komandos patvirtino fiksuotą konfigūraciją ir stengėsi ją nepakeisti. Debesyje ta prielaida nebegalioja. Infrastruktūra nuolat atnaujinama, dažnai be tiesioginio matomumo.

Larkinas apibūdina perėjimą nuo momentinio patvirtinimo prie nuolatinio užtikrinimo.

Tam reikia kitokio požiūrio:

• Tikėtis pokyčių, o ne bandyti jiems užkirsti kelią
• Kurti sistemas, kurios gali toleruoti kintamumą
• Nuolat stebėkite ir prireikus reaguokite

Tai taikoma už debesies ribų. Jis taip pat rodomas mobiliosiose ir BYOD aplinkose, kur įrenginiai ir operacinės sistemos nuolat keičiasi.

Stabilumas nebėra dėl sistemos užšalimo. Jis gaunamas iš pastatų sistemų, kurios gali susidoroti su pokyčiais nesulūždamos.

Automatika sukuria nuoseklumą, o ne tik greitį

Automatika dažnai apibūdinama kaip būdas greičiau judėti. Praktiškai jo vertė lygiai taip pat priklauso nuo nuoseklumo.

Naudodamos infrastruktūrą, apibrėžtą kaip kodą, komandos gali tiksliai atkurti aplinką. Taip lengviau išbandyti, patvirtinti ir diagnozuoti problemas be spėlionių.

Organizacijoms, veikiančioms pagal teisės aktų nustatytą priežiūrą, šis nuoseklumas užtikrina patikimesnį patvirtinimą ir greitesnį problemų sprendimą, kai jos kyla.

Kai techninė skola tampa išlaidų daugikliu

Kai pristatymas sulėtėja, įprastas atsakas yra įtraukti daugiau inžinierių arba padidinti infrastruktūros pajėgumus.

Larkinas pabrėžia, kad tai gali užmaskuoti tikrąją problemą.

Sistemose su didelėmis techninėmis skolomis komandos daug laiko praleidžia dirbdamos su architektūra, o ne kurdamos naujas galimybes. Kūrėjai „kovoja su sistema“, o ne teikia vertę.

Rezultatas yra sudėtingų išlaidų problema:

• Didesnės komandos turi išlaikyti tą patį tempą
• Didesnės infrastruktūros išlaidos be proporcingos produkcijos
• Ilgesni terminai klientams skirtiems patobulinimams pateikti

Kai kuriais atvejais įmonės išleidžia nuo penkių iki dešimties kartų daugiau, kad pasiektų rezultatus, panašius į komandų, turinčių paprastesnę, švaresnę architektūrą, rezultatus.

Sutelkite dėmesį į tai, kas iš tikrųjų išskiria produktą

Vienas iš tiesioginių diskusijų aspektų yra tai, kur neleisti laiko.

Tokios galimybės kaip autentifikavimas, duomenų saugojimas ir stebėjimas nėra konkurencinio pranašumo šaltiniai. Debesijos paslaugų teikėjai jau tiekia juos dideliu mastu, užtikrindami didesnį saugumą ir patikimumą, nei dauguma komandų gali pasiekti viduje.

Patys statydami juos padidina sąnaudas ir sudėtingumą, nesuteikdami pridėtinės vertės.

Geresnis būdas yra pasikliauti valdomomis paslaugomis šiems pagrindiniams komponentams ir sutelkti vidines pastangas į tai, kas išskiria produktą, pvz., klinikinę logiką, darbo eigą ir vartotojo patirtį.

Kaip padidinti mastelį nepadidinant sudėtingumo

MedTech įmonės patiria spaudimą plėsti programinės įrangos galimybes, prijungti įrenginius ir dažniau teikti naujinimus.

Iššūkis yra tai padaryti nesulėtinant ir nedidinant rizikos.

Šiame internetiniame seminare nagrinėjama, kaip architektūros sprendimai įtakoja šį rezultatą. Tai parodo, kaip modulinės, debesyje naudojamos sistemos palaiko greitesnę iteraciją, sumažina nereikalingą koordinavimą ir padeda komandoms išlaikyti kontrolę reguliuojamoje aplinkoje.

Jei jūsų platformą vis sunkiau pakeisti, ši sesija padės suprasti, kodėl ir ką daryti toliau.

Prisijunkite prie webinaro

Jei jūsų komanda kuria SaMD, prijungtus įrenginius ar su programine įranga įgalintus medicininius sprendimus ir pastebės, kad plėtra lėtėja sistemoms augant, šioje sesijoje bus pateiktas efektyvesnis platformos struktūros kūrimo būdas.

Sužinosite, kaip:

• Naudokite modulinę architektūrą, kad sumažintumėte koordinavimo išlaidas ir paspartintumėte pristatymą
• Atskirkite didesnės rizikos funkcijas, kad nesulėtėtų likusios sistemos
• Pereikite nuo momentinio patvirtinimo prie nuolatinio užtikrinimo debesų aplinkoje
• Taikykite automatizavimą, kad sukurtumėte pakartojamas, išbandomas sistemas, atitinkančias reguliavimo poreikius
• Sutelkite vidines komandas į skirtingas galimybes ir naudokite debesyje valdomas paslaugas

Jei atrodo, kad jūsų planas yra sunkiau įgyvendinamas, nei turėtų būti, arba jei funkcijų pridėjimas laikui bėgant tampa brangesnis ir rizikingesnis, šis internetinis seminaras suteiks jums aiškesnį pagrindą judėti į priekį.