Схаваны кошт «хуткага праграмнага забеспячэння»

Схаваны кошт «хуткага праграмнага забеспячэння»

Амаль у кожнай арганізацыі надыходзіць момант, калі нехта кажа: «Нам проста трэба нешта хутка». Гэта можа быць невялікі ўнутраны інструмент, панэль паказчыкаў, сістэма працоўных працэсаў або просты кліенцкі партал. Намер звычайна разумны: зрабіць нешта невялікае, вырашыць тэрміновую праблему і рухацца далей.

Аднак тое, што пачынаецца як хуткае рашэнне, часта становіцца пастаяннай інфраструктурай. Менавіта тут і пачынаецца схаваны кошт.

Розніца паміж прататыпам і вытворчым праграмным забеспячэннем

Прататыпнае праграмнае забеспячэнне існуе, каб праверыць ідэю. Яго мэта — хуткасць. Яно дазваляе камандам эксперыментаваць, правяраць гіпотэзы і вызначаць, ці жыццяздольная канцэпцыя. У многіх выпадках прататыпы наўмысна робяць лёгкімі, бо іх задача — проста даказаць, што нешта можа працаваць.

Вытворчае праграмнае забеспячэнне зусім іншае. Вытворчыя сістэмы павінны вытрымліваць змены, маштабаванне і праверкі. Яны павінны быць бяспечнымі, падтрымоўванымі, назіральнымі і ўстойлівымі. Яны павінны інтэгравацца з іншымі сістэмамі і падтрымліваць доўгатэрміновыя аперацыйныя працэсы паміж камандамі і падраздзяленнямі.

Сапраўдная праблема пачынаецца, калі прататып ціха становіцца вытворчай сістэмай. Гэта адбываецца значна часцей, чым арганізацыі ўяўляюць. Невялікі ўнутраны скрыпт становіцца інструментам, ад якога залежаць усе. Простая база даных вырастае ў асноўную сістэму аперацыйных даных. Хуткая панэль паказчыкаў становіцца платформай, на якую кіраўніцтва абапіраецца пры прыняцці рашэнняў.

Тое, што ніколі не было спраектавана несці нагрузку, раптам нясе ўсю арганізацыю.

Чаму кароткія шляхі становяцца пастаяннай інфраструктурай

Праграмнае забеспячэнне мае ўнікальную рысу ў параўнанні з большасцю іншых інструментаў. Як толькі людзі пачынаюць ім карыстацца, замяніць яго становіцца цяжка. Вакол яго фармуюцца працэсы, унутры назапашваюцца даныя, а каманды пачынаюць залежаць ад яго ў штодзённых аперацыях.

Нават калі сістэма першапачаткова задумвалася як часовая, яе замена пазней здаецца рызыкоўнай. Замест правільнай перабудовы арганізацыі пачынаюць латкаць сістэму, пашыраць яе і дадаваць усё больш скрыптоў і функцый вакол першапачатковага падмурку.

З часам сістэма вырастае ў нешта вялікае, крохкае і складанае для разумення. Тое, што пачыналася як хуткае рашэнне, павольна становіцца пастаяннай інфраструктурай, ад якой залежыць арганізацыя.

Тэхнічны доўг — гэта аперацыйная рызыка

Тэхнічны доўг часта абмяркоўваюць як нязручнасць для распрацоўшчыкаў, але насамрэч гэта аперацыйная рызыка. Калі сістэмам не хапае структуры і архітэктурнага планавання, нават простыя змены могуць выклікаць нечаканыя пабочныя эфекты.

Уразлівасці бяспекі становіцца цяжэй выявіць і выправіць. Увод новых інжынераў становіцца павольным і дарагім, бо разуменне сістэмы патрабуе праходу праз гады неструктураванага росту. Інтэграцыі становяцца крохкімі, а надзейнасць пачынае зніжацца.

Арганізацыя фактычна пачынае плаціць «працэнты» за кожную змену. Задачы, якія раней займалі дні, пачынаюць займаць тыдні, а праца, якую раней выконваў адзін інжынер, цяпер можа патрабаваць цэлай каманды. Кошт не праяўляецца адразу. Ён павольна назапашваецца з часам, пакуль сістэма не даходзіць да стану, калі змяняць яе становіцца надзвычай цяжка.

Чаму ранняя архітэктура зніжае кошт

Існуе распаўсюджаная памылка, што архітэктура запавольвае праекты. Насамрэч добрая архітэктура зніжае доўгатэрміновы кошт і рызыку, бо закладвае выразны падмурак да таго, як узрасце складанасць.

Архітэктура не азначае празмернай інжынерыі. Яна проста азначае свядомыя рашэнні пра межы сістэмы, уласнасць на даныя, мадэлі бяспекі, пашыральнасць і аперацыйны маніторынг.

Добра структураваная сістэма дазваляе камандам рухацца хутчэй пазней, бо падмурак падтрымлівае змены, а не супраціўляецца ім. Калі архітэктуры няма, кожная новая змена становіцца «раскопкамі», дзе інжынеры павінны асцярожна абыходзіць крохкі код перад тым, як нешта дадаць.

Чаму вашаму ІІ патрэбнае кіраванне

Рост праграмнага забеспячэння, згенераванага ІІ, паскорыў гэтую праблему. Інструменты ІІ могуць вельмі хутка ствараць працоўны код, робячы прататыпаванне хутчэйшым, чым калі-небудзь.

Аднак ІІ не нясе доўгатэрміновай адказнасці за сістэму, якую ён генеруе. Без архітэктурнага нагляду сістэмы, згенераваныя ІІ, часта ствараюць фрагментаваныя кодавыя базы з некалькімі рэалізацыямі адной і той жа логікі, неаднастайнымі шаблонамі бяспекі, дубляванымі сэрвісамі і пастаянна пашыранай паверхняй атакі.

У выніку атрымліваецца праграмнае забеспячэнне, якое працуе сёння, але заўтра становіцца ўсё цяжэйшым у кіраванні. ІІ — вельмі магутны інструмент, але, як і любы магутны інструмент, ён патрабуе кіравання. Архітэктура дае гэтае кіраванне і гарантуе, што хуткасць не ахвяруе структурай.

Сапраўдны кошт «хуткага»

«Хуткае» праграмнае забеспячэнне рэдка бывае танным. Кошт проста прыходзіць пазней, схаваны ў падтрымцы, нестабільнасці, рызыках бяспекі і аперацыйнай складанасці.

Арганізацыі, якія ставяцца да архітэктуры як да стратэгічнай дысцыпліны, будуюць сістэмы, што служаць даўжэй, развіваюцца хутчэй і нясуць значна меншую аперацыйную рызыку. У праграмным забеспячэнні, як і ў будаўніцтве, менавіта падмурак вызначае тэрмін жыцця канструкцыі.

PrimeCRM