Сегодня нельзя не заметить наметившейся тенденции к чрезмерной специализации в ИТ-отделах и ее негативных последствий.
Бездумное увлечение специализированными платформенными предложениями от поставщиков (хотя это в первую очередь организационная проблема) привело к значительному дублированию функций в архитектуре предприятий.
Конечно, бизнес, предоставляющий специализированные платформы для ИТ-решений, может извлечь выгоду из узкой специализации. Все остальные виды бизнеса нуждаются в изменении ситуации.
Переход от изолированности к более эффективному сотрудничеству
Традиционная разработка программных приложений, инженерия данных и искусственный интеллект/машинное обучение (ИИ/МО) сегодня образуют крупные разрозненные структуры.
Хотя изначально предполагалось, что различные ИТ-задачи в значительной степени отличаются друг от друга, преследуя различные цели, бизнес требует бесперебойного обмена данными и интеграции между приложениями и моделями ИИ/МО.
Нам необходимо перейти от изолированных задач к интегрированным системам.
Инженеры в каждой области фактически зависят от множества совместных практик, требующих общего языка и единой методологии. Конвейеры данных должны поддерживать вывод моделей в режиме реального времени; прикладное ПО — динамически обрабатывать потоки данных; модели ИИ/МО — органично вписываться в работающие приложения.
Такое междоменное взаимодействие переопределит изолированные роли инженеров в каждой области и позволит выйти за рамки ментальных ограничений какой-либо одной дисциплины.
Работая в сфере здравоохранения, я столкнулся с той же проблемой чрезмерной специализации. Врачи (например, кардиологи, неврологи) часто фокусируются на конкретных органах или системах. Такая чрезмерная специализация, хотя и способствует совершенствованию методов лечения определенных заболеваний, приводит к фрагментарному подходу, не учитывающему общее состояние здоровья пациентов. В результате становится невозможно получить полезную, всестороннюю консультацию.
Правда, в последние годы в здравоохранении наметился серьезный сдвиг — от разрозненного мышления к более интегрированному, комплексному подходу. Эта тенденция демонстрирует преимущества междисциплинарного сотрудничества, объединяющего знания разных специальностей для улучшения результатов лечения пациентов.
Нам срочно требуется такое же переосмысление в области ИТ-инженерии.
Связующие нити: общедисциплинарные принципы
Можно выделить несколько ключевых принципов, в равной степени важных для инженеров данных, разработчиков ПО и специалистов в области ИИ/МО.
Очевидные общие черты — владение навыками программирования, алгоритмический подход в мышлении и решении задач, а также корректное обращение со структурами данных. Эти принципы создают общую для всех ИТ-инженеров основу.
Рассмотрим еще несколько точек соприкосновения.
Модульность и возможность повторного использования
Модульность уже много лет является краеугольным камнем архитектуры программного обеспечения.
В инженерии данных этот принцип не менее важен. Хорошо спроектированный конвейер данных должен быть модульным, чтобы поддерживать преобразования многоразовых данных и легко настраиваемые компоненты. Если при разработке приложений мы научились мыслить в рамках (микро-)сервисов, способствующих созданию целостной системы, то при создании конвейеров данных нам все еще не хватает такого же мастерства. Вместо этого нередко приходится слышать необоснованное утверждение, что инженерия данных — это не инженерия программного обеспечения.
Опубликованная Google научная работа «Скрытый технический долг в системах машинного обучения» ясно показывает, что сама модель — лишь малая часть общего сервиса ИИ/МО, который необходимо разработать. Большая часть этого сервиса, чтобы быть органично интегрированной в архитектуру предприятия, требует ноу-хау в области программного обеспечения и инженерии данных. Например, инженерия признаков фактически является инженерией данных для моделей ИИ/МО и имеет много общего с традиционной ETL-обработкой для хранилищ данных (ETL — extract, transform, load; извлечение, преобразование, загрузка данных).
Если все три дисциплины будут стремиться к модульной архитектуре, проще будет интегрировать разрозненные системы и повторно использовать компоненты в разных структурах.
Контроль версий и управление жизненным циклом
При разработке программного обеспечения контроль версий необходим для управления изменениями. Этот же принцип в равной степени применим к работе с данными и моделями ИИ/МО. Версионирование данных обеспечивает командам возможность отслеживать изменения, сохранять историю и гарантировать воспроизводимость. Отслеживание экспериментов и управление жизненным циклом моделей ИИ/МО позволяет предотвратить нарушение процессов или неожиданное поведение обновлений в производстве.
Строгий подход к контролю версий во всех областях обеспечивает необходимый уровень синхронизации систем, особенно в динамичных средах, где данные, код и модели постоянно меняются. Эта потребность нашла отражение в развитии таких дисциплин, как DevOps (developer operations — разработка и эксплуатация ПО), MLOps (machine learning operations — развертывание и поддержание моделей МО) и DataOps (data operations — тестирование и развертывание ПО в области аналитики данных). Все три дисциплины направлены на быстрое создание высококачественных программных продуктов.
Однако эти дублирующие друг друга дисциплины приводят к ненужному управлению проектами и перегрузке рабочего процесса. Мы поддерживаем три отдельные, чрезмерно специализированные версии принципиально схожих процессов. Единый подход, позволяющий преодолеть их изолированность, значительно снизит их сложность и повысит эффективность.
Обработка в реальном времени и оперативность
Рост потребности в обработке данных с малой задержкой делает традиционные системы пакетной обработки недостаточно эффективными. Современные пользователи ожидают мгновенного предоставления информации. Этот переход к оперативному реагированию в режиме реального времени требует нового уровня интеграции.
Для инженеров данных обработка в реальном времени означает переосмысление традиционных ETL-конвейеров и переход к архитектурам, ориентированным на события, в которых данные поступают по мере их создания. Инженеры ПО должны разрабатывать системы, способные обрабатывать потоки данных в реальном времени, часто интегрируя выводы ИИ/МО для обеспечения персонализированных или контекстно-зависимых ответов. Что же касается инженеров ИИ/МО, то речь идет о создании моделей, которые работают с минимальной задержкой.
К сожалению, мы пока слишком далеки от объединения пакетной и потоковой обработки.
Сила абстракции позволяет создавать межфункциональные системы
Одним из самых мощных инструментов, позволяющих избежать дублирования функциональности, является абстракция.
В каждой области были созданы свои абстракции, например в разработке приложений — это UX-принципы, такие как модель-представление-контроллер (Model-View-Controller, MVC) и бэкенд-для-фронтенда (Backend-for-Frontend, BFF); в инженерии данных — оркестровка ETL-конвейеров, в ИИ/МО — слои в нейронных сетях.
Создавая системы на основе общих абстракций, мы формируем язык, понятный для всех дисциплин.
Возьмем для примера абстракцию «данные как продукт» и посмотрим, как она может служить общим языком. Для инженера данных это четко определенный набор признаков, созданный приложениями для раскрытия и передачи информации потребителям. Для специалиста по ИИ/МО — набор функций, подготовленный для обучения модели. Для разработчика ПО — что-то вроде конечной точки API, обеспечивающей надежный ввод данных для функциональности приложения. Создавая и потребляя данные как продукт, каждая команда говорит на одном языке, что способствует лучшему взаимопониманию.
Операционные системы (ОС) традиционно являются базовой инфраструктурой, которая обеспечивает фундаментальные абстракции, одинаково эффективные для всех конкретных приложений. Прежде чем создавать новые фундаментальные абстракции в качестве специализированных инструментов в рамках отдельной дисциплины, следует дважды подумать, не лучше ли их охватить инфраструктурным компонентом, например в виде расширения ОС.
Использование циклов обратной связи
По мере стирания границ между дисциплинами возникает необходимость в обратной связи.
Данные, программное обеспечение и системы ИИ/МО больше не являются статичными; они постоянно развиваются благодаря отзывам пользователей и аналитическим выводам. Это еще больше сокращает разрыв между разработкой и производством, позволяя системам совершенствоваться и адаптироваться с течением времени. Дисциплина, направленная на создание таких циклов обратной связи, называется наблюдаемостью.
В инженерии данных наблюдаемость проявляется в мониторинге потока данных, позволяющем постоянно сотрудничать для повышения точности и надежности. Для разработчиков ПО это может означать сбор информации об использовании приложения в реальном времени и отзывов пользователей для улучшения функциональности и пользовательского опыта. В области ИИ/МО циклы обратной связи критически важны для повторного обучения моделей на основе новых данных, обеспечивающего актуальность и точность прогнозов.
Тщательно продуманный цикл обратной связи гарантирует постоянную оптимизацию всех систем. Такие циклы позволяют осуществлять межфункциональное обучение, когда знания из одной области напрямую используются для улучшения другой, создавая эффективный цикл совершенствования и адаптации.
Оптимизация рекрутинга
Растущая специализация отражает эволюцию, необходимую для решения проблем, связанных с усложнением современных систем.
Хотя специализированные дисциплины могут принести значительную пользу, их чрезмерно пересекающиеся области приводят к проблемам координации и интеграции. Организации, которым удастся гармонизировать эти сквозные отрасли благодаря использованию принципов разумной архитектуры, культуры сотрудничества и единых стратегий, получат конкурентное преимущество.
Нам не нужны узкоспециализированные инженеры для каждого отдельного аспекта корпоративной архитектуры. Мы не добьемся успеха, если несколько корпоративных архитекторов будут обладать достаточным опытом для управления междисциплинарными аспектами. Мощные абстракции не появляются, если жить и мыслить изолированно. Необходимо поощрять инженеров к нестандартному мышлению и пониманию преимуществ эволюционных архитектур на уровне предприятия.
Все инженеры, а не только архитекторы, должны следовать надежным принципам корпоративной архитектуры. Поэтому убедитесь, что ваши ИТ-инженеры обладают обширными знаниями в области архитектуры.
Не ищите узкоспециализированного инженера DevOps, владеющего всеми новейшими инструментами. Ищите ИТ-инженера, который много знает о разработке программного обеспечения и понимает, как быстро запускать ПО в производство, сохраняя при этом высочайшее качество.
На пути к единому инженерному мышлению
Поскольку мы проектируем будущее, становится ясно, что успех зависит от объединения разрозненных дисциплин там, где это необходимо. Инженеры данных, разработчики ПО и специалисты в области ИИ/МО должны придерживаться единого инженерного мышления, используя общие принципы и практики для создания систем, отвечающих сквозным требованиям бизнеса.
Я твердо верю, что будущее инженерного дела — это совместный труд. Работая в рамках общей структуры – модульности, контроля версий, реагирования практически в режиме реального времени и абстракции — мы закладываем основу для создания интегрированных систем. Цель не в том, чтобы стереть различия между областями, а в том, чтобы использовать их уникальные сильные стороны для выхода за рамки ограничений какой-либо одной дисциплины.
Успех будет сопутствовать тем, кто сможет преодолевать барьеры, применять межфункциональные принципы и целостно подходить к создаваемым системам. Разрабатывая эти общие направления, мы не только повышаем эффективность каждой области, но и обеспечиваем более широкое внедрение инноваций и гибкость. Будущее взаимосвязано, и путь к его построению начинается с принятия общих принципов в области ИТ-инженерии.
Читайте также:
- Насколько эффективен промпт-инжиниринг в разработке ПО?
- Использование ИИ для скрейпинга почти всех сайтов в 2025 году
- Использование LLM в реальном мире
Читайте нас в Telegram, VK и Дзен
Перевод статьи Bernd Wessely: Engineering the Future: Common Threads in Data, Software, and Artificial Intelligence
