Технический долг — термин, используемый разработчиками для обозначения компромиссов, — начинает влиять на выбор ИТ-решений в области искусственного интеллекта, машинного обучения и всех других технологий, находящихся между ними. О том, как ИТ-команды могут уменьшить его влияние на организацию, на портале InformationWeek рассказывает Пьер Дебуа, основатель консалтинговой компании Zimana.

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

Во многих случаях руководителям приходится сталкиваться с техническим долгом еще до внедрения новой технологии. Технический долг — это стоимость принятых компромиссных решений по поддержке текущих систем для продолжения их работу или для достижения иной бюджетной цели. Этот долг возникает в ряде случаев, например, из-за определенного решения в рамках проекта по разработке ПО или в стремлении сэкономить средства на отсрочке модернизации устаревшей системы. Например, при разработке приложений запуск более простой версии продукта приведет к тому, что в ней будут упущены некоторые функции, что создаст технический долг, который необходимо будет устранить путем добавления новых функций. Иногда технический долг возникает из-за «кажущейся» экономией по сравнению с технически лучшим выбором на долгосрочную перспективу.

Технический долг — актуальная тема для руководителей, поскольку с запуском каждого корпоративного решения число потенциальных причин его возникновения увеличивается. Сегодня компании внедряют решения на основе МО, ИИ и облачных технологий, чтобы заменить многие устаревшие системы, которые в настоящее время управляют сервисами и процессами. При этом технический долг, связанный со старыми системами, проявляется в виде скрытых операционных затрат, которые растут с течением времени и требуют устранения.

Возникновение «долга данных»

Многие технологические преобразования определяются выбором решений по управлению данными — в той же степени, что и выбором ПО. Возьмем, к примеру, регулирование конфиденциальности данных. Для соблюдения требований конфиденциальности необходимо определить порядок хранения данных в системах. Управление данными должно показывать, как соблюдаются эти требования.

Более того, в ИТ появилась новая разновидность технического долга — «долг данных» (data debt). Это накопление компромиссов в управлении данными. Долг данных обычно возникает там, где данные лежат в основе операций, например, при контроле качества или анализе угроз в области кибербезопасности. Как и технический долг, он связан с задержкой инвестиций в обслуживание или управление цифровыми активами, в данном случае операционными данными.

У долга данных есть заметное отличие от технического долга в плане компромиссов. Если технический долг — это зонтичный термин, скорее относящийся к технологиям, используемым для предоставления продуктов и услуг, то долг данных — это зонтичный термин, относящийся к способам взаимодействия с данными и охватывающий изолированность данных, дублирование наблюдений и несоответствие источников. Развитие МО и нынешнее активное внедрение ИИ усложняют предотвращение потенциальных рисков, связанных с неэффективным управлением данными.

По мере роста инвестиций в ИИ ИТ-менеджеры будут все чаще сталкиваться с проблемами долга данных. Большие языковые модели (LLM) с открытым исходным кодом, такие как фреймворк LangChain и недавно запущенная система Llama2, позволяют создавать модели и приложения ИИ с меньшим количеством параметров и, соответственно, меньшим размером, чем обучающая модель, используемая в ChatGPT. LLM с открытым исходным кодом обеспечивают более управляемую разработку ИИ для ИИ-приложений, работающих с проприетарными данными. Это обеспечивает бóльшую прозрачность обучающих и тестовых данных, устраняя зависимость от доступа к данным со сторонних серверов и API, который может изменять и нарушать работу модели.

Управление внутренней ИИ-платформой также снимает проблемы, связанные с использованием данных. Многие ИИ-платформы разрабатываются с использованием векторных баз данных, применяемых для индексирования неструктурированных данных и документов. Векторные базы контролируют представления данных — наборы данных, созданные из неструктурированных данных с помощью LLM. Они разработаны специально для облегчения доступа к документам при обучении и тестировании моделей. Однако предприятие, планирующее модель, вполне может использовать документы, хранящиеся в старых средах. В результате в ходе перспективных разработок часто выявляются ситуации с долгом данных, поскольку доступ к данным осуществляется из старых хранилищ.

Как минимизировать технический долг

Одним из ключевых шагов является создание механизма обсуждения ИТ-командами технологий с заинтересованными сторонами. Это может означать проведение постоянного рассмотрения текущих технологий, их рабочего состояния и возможных планов по модернизации, обновлению или замене. Это позволяет документировать политику, соглашения и процессы в организации и улучшить общее понимание того, как со временем выявлять возможности для сокращения технического долга.

Используйте обзорные совещания, чтобы довести до сведения заинтересованных сторон, когда в последний раз проводилось обслуживание кода критически важных программных систем. После таких брифингов часто назначают аудит управления данными в связи с рефакторингом кода, переписыванием кода или постепенным улучшением кода с течением времени. Аудит — это возможность собрать исходную информацию о последнем рассмотрении данных в технологическом стеке или алгоритмическом процессе. Получив эту информацию, команда может выработать политику, соглашения и процессы, которые позволят наилучшим образом сократить долг или быстро устранить другие технические препятствия.

При изучении технологии совместная команда должна определить, какие процессы потребляют (или впустую расходуют) больше всего времени. Это поможет выявить потенциальные узкие места еще до их возникновения и спланировать соответствующую работу.

При разработке новых функций в ПО или модели данных следует обратить внимание на особенности технического долга. Для создания и реализации этих функций может потребоваться устранения части этого долга.

Выбор функций может также повлиять на решения об использовании исторических данных, заставив задуматься о том, действительно ли эти данные необходимы. Один из вопросов, который могут задать себе команды, заключается в следующем: какая информация изменилась с момента принятия решения об использовании данных? Изменениям подвержено практически все, что связано с технологиями, — от функций до поведения пользователей, поэтому некоторые старые решения могут оказаться не столь ценными сегодня, как в момент их принятия.

В этом случае команды могут задаться вопросом, имеет ли смысл доступ заинтересованных сторон к историческим данных. Как далеко должен распространяться регулярный доступ — на шесть месяцев? Год? Три года? Затем можно обратиться к методам и инструментам, которые часто используются аналитиками и заинтересованными сторонами. Некоторые инструменты и хранилища данных, возможно, действительно нуждаются в обновлении, в то время как другие могут оставаться полезными при незначительном обновлении функций и плагинов.

Некоторым аналитикам и менеджерам может быть достаточно нескольких исторических ключевых показателей, представленных в Excel или Google Sheet. В других случаях Markdown-документ, содержащий код на языках R и Python, обеспечит обновление показателей, предоставляемых через API. Грамотный выбор инструмента может выявить и другие проблемы технического долга и долга данных в масштабах предприятия.

Решение проблемы технического долга становится все более актуальным в наши дни. Помимо возросших возможностей для его возникновения, непростой задачей может оказаться изыскание необходимых навыков для поиска операционной эффективности и реализации соответствующих решений.

В ближайшем будущем необходимость сокращения технического долга будет оставаться актуальной для многих ИТ-команд и ИТ-директоров. Особенно с учетом того, что кадровая волатильность в технологической отрасли привела к тому, что многие корпоративные команды не могут справиться ни с какими задачами, не говоря уже о проектах по сокращению технического долга.

Однако независимо от источника, размера и последствий технического долга ИТ-команды должны управлять им и сокращать его. При высоком уровне заинтересованности в поиске лучших практик и решений команды могут взять на себя технологическое лидерство и предпринять взвешенные шаги, которые снижают влияние технического долга на изменение технологических стеков, стоящих за наиболее критичными сценариями использования. Результатом станут рациональные технологические решения, которые в долгосрочной перспективе сделают бизнес более экономически эффективным.