Компаниите харчат прекалено много пари, за да поддържат унаследени системи
(снимка: CC0 Public Domain)
За някои големи предприятия техническият дълг*, натрупан в продължение на много години, остава една от най-сериозните пречки пред дигиталната трансформация. Това може да включва постоянна поддръжка на остарели системи, сливания и придобивания или лоши практики за разработка на софтуер.
Анкета сред близо 500 европейски специалисти в ИТ сектора показва, че много от предприятията са посветили повече от една четвърт от своите ИТ бюджети за справяне с техническия дълг – в сравнение с около една трета за иновации и изграждане на нови възможности и близо 40% за изпълнение на текущите операции.
Проблемът е още по-силно изразен при корпоративните компании. Те изразходват приблизително 4 от всеки 10 долара от своите ИТ бюджети за технически дълг, според проучването, данни от което публикува, отбелязва ComputerWeekly.
Изследването е дело на OutSystems, доставчик на платформи за т.нар. „приложения с малко код”. С други думи, казват от OutSystems, едва около 30% или даже по-малко от ИТ бюджета са налични за поддържане на текущите операции и за иновации възможности.
Въпреки че причините за техническия дълг са многобройни, първите два фактора, цитирани от респондентите, са огромният брой езици и рамки за разработване, които пречат на усилията за модернизация. Не по-малко съществен проблем е текучеството в развойните екипи.
Наред с това не са редки случаите, когато разработчиците отлагат поправянето на грешки, за да спазят крайните срокове за текущи проекти. Бъговете се натрупват лавинообразно с течение на времето. Това потапя компанията в омагьосана спирала на постоянно нарастващ технически дълг.
Според експерти, проблемите с остарелите езици и рамки за разработване са по-остри при пазарите, които са по-отдавна развити в технологично отношение. По-„младите” пазари имат по-малко проблеми с остарелите системи и езици за програмиране.
„Почти всяка по-голяма компания би имала технически дълг и този факт лъсна с настъпването на пандемията”, казва Марк Уизър, вицепрезидент на Outsystems за Азиатско-тихоокеанския регион. „Изведнъж ИТ отделите трябваше да дигитализират всичко много бързо и да създадат интерфейси за клиенти, които не са съществували преди. И те трябваше да направят това с ограничен бюджет. Тогава се видя къде отиват парите – колко много се харчи, просто за да се поддържат унаследени системи”.
И така, близо седем от десет компании в проучването казват, че техническият дълг е ограничил капацитета им за иновации. Малко над 60% от компаниите съобщават, че техническият дълг води до значително забавяне на тяхното функциониране. 64% заявяват, че това ще окаже голямо влияние върху бъдещия им бизнес.
Като се има предвид големината и сложността на техническия дълг, респондентите са били запитани и относно способността им да решат проблема сега и в бъдеще. Повечето от мениджърите са уверени в успеха на настоящите и предстоящите си усилия за справяне с проблема.
Според анализаторите обаче тази оптимистична картина може и да не е толкова обещаваща, колкото изглежда на пръв поглед. Възможно е немалко мениджъри да подценяват тенденцията и техническият дълг да се влошава с течение на времето.
Измежду средствата за справяне с проблема с най-висок приоритет се оказват намаляването на текучеството и на броя на езиците за разработване. От значение е и справянето с неправилни архитектурни решения и въздействието на променящите се управленски или регулаторни изисквания.
Като едно от най-съществените средства за справяне с техническия дълг се сочи роботизираното автоматизиране на процеси (RPA). В подкаст за ролята на техническия дълг в периода след пандемията Брайън Хопкинс, вицепрезидент и главен анализатор във Forrester Research, наскоро посочи, че техническият дълг не бива да се отписва, за да се въведе RPA.
Позовавайки се на пример за авиокомпания, внедрила RPA, за да автоматизира човешката работа по обработване на нарастващия брой отмени в пика на пандемията, Хопкинс казва, че компанията е успяла да „пренавие” техническия си дълг само за седем дена.
* присъщата цена на допълнителната работа и преработване, които се налагат от избора на лесно (ограничено) технологично решение.
Framework – платформа ??
Каса бира ??
Framework в контекста на софтуерната разработка не е коректно да се превежда като рамка, според мен.
На този етап аз не знам за точен превод, затова в индустрията се ползва оригиналната дума като привнесена чуждица – фреймуърк.
Ако някой измисли добър превод, има една каса бира от мен.
Иначе, проблемът с т.нар. технически дълг е далеч по-дълбок и сериозен от описаното в статията.
От една страна, старите езици за програмиране и екосистемите от библиотеки, и помощни инструменти, са далеч по-добре развити, имат далеч по-малко грешки (бъгове) и са далеч по-добре документирани.
От друга страна, новите езици и техните екосистеми пасват по-добре на съвременните проблеми, които (се опитваме да) решаваме. Те, всъщност, така и възникват до голяма степен – нови проблеми изискват нови инструменти.
Тези нови инструменти, обаче, страдат от много повече грешки, много често дори от липса на библиотеки; или има множество библиотекиза едно и също нещо, всичките в ранен етап на разработка, като не се знае коя ще оцелее / коя ще се развива по-бързо и ще се изчистват повече грешки.
Т.е. с новите инструменти има далеч по-голям риск при избора на самия инструмент, както и на библиотеките, които да бъдат използвани.
По тази причина, техническият дълг се появява, както от вътрешната разработка, така и през външните зависимости на проектите.
Адът на зависимостите в NodeJS проектите (dependency hell) е един такъв типичен пример, но далеч не е единствен.
Rust е много интересен език с изключителен потенциал, но там възниква проблемът с множество библиотеки, предоставящи една и съща функционалност – и всичките са в процес на развитие, без да знаеш коя и кога ще бъде зарязана. Като добавим и, че Mozilla практически се отказаха от развиването на проекта, става трудно човек да се довери на тази екосистема.