Организация команд в современных организациях на пути к машинному обучению для достижения быстрого потока.

В настоящее время машинное обучение (ML) находится в ярости во всем мире. Многие компании внедряют ML (или AI, или расширенную аналитику, или принятие решений на основе данных) в своих текущих бизнес-процессах. В этой организации много усилий уходит на набор талантов машинного обучения, формирование команд, определение сферы деятельности команды. Как и многие технологические организации, эти организации также производят приложения-монолиты, например, одну платформу, которая включает в себя оркестровку рабочих процессов, управление моделями, управление функциями, код приложений машинного обучения и т. д. Когда такая организация понимает, что у нее есть десять разных команд с семью разными архитектурами, они осознают, что в такой ситуации нельзя ни масштабировать, ни разумно. Поддерживать платформу дороже, что затрудняет копирование дизайна в другом месте. Его сложнее обновлять, что, в свою очередь, влияет на скорость доставки. Прервать очень сложно, что снижает боевой дух команды. Это также позволяет сильно полагаться на племенные знания, что делает команду чувствительной к мобильности.

Очевидно, что ломать монолиты — это путь. Однако, если это не будет сделано тщательно, команды могут скрыть эти проблемы из поля зрения, но в конечном итоге проблемы проявятся в какой-то момент цикла поставки.

Поскольку приложение машинного обучения (в частности, в производстве) — это особый тип программной системы, я изучил принципы, принятые современными технологическими компаниями в отношении того, как они справляются с проектированием микросервисов. Я узнал, что многие принимают фреймворк, предложенный в книге Team Topology. Большинство обсуждений, которые я нашел в книге и других дополнительных материалах, относятся к веб-сервисам, облачным технологиям и т. д. В этой статье я адаптирую их предложение, чтобы оно подходило большему количеству организаций, управляющих приложениями ML.

Топология команды

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

Командная топология продвигает идею программного обеспечения для команд. Это вытекает из Закона Конвея, который гласит, что организация будет разрабатывать системный дизайн в соответствии со структурой коммуникаций организации. Если система разработана без учета структуры организационной коммуникации, команды будут создавать сложные в управлении системы. Книга выступает за обратный обратный закон Конвея — принятие структуры команды, которая соответствует ожидаемому дизайну системы.

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

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

Команды для машинного обучения

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

Потоковые команды машинного обучения

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

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

Команды подсистемы данных/инфраструктуры

Несмотря на то, что данные и инфраструктура — это совершенно разные компоненты, с точки зрения команды машинного обучения это специализированные команды, и их легко можно рассматривать как команды подсистем. С точки зрения команд, ориентированных на данные, может быть команда озера/хранилища/сетки данных, команда каталога данных, группа управления данными и т. д., и среди других ролей могут быть такие специалисты, как эксперты по предметным данным и инженеры платформы данных. Что касается групп, ориентированных на инфраструктуру, то это могут быть группы политики администрирования облачных вычислений (в случае многооблачной организации), группы решения VPN, группы управления идентификацией и т. д., а также могут состоять такие специалисты, как архитекторы облачных решений, сетевые инженеры. , эксперты по безопасности и т. д. Эти команды могут поддерживать некоторые или все типы команд. Наличие таких команд гарантирует, что усилия по обработке данных или политике управления инфраструктурой не должны разрабатываться/исследоваться в командах машинного обучения, а количество специалистов, которые должны быть наняты в организации, может быть снижено.

Команды платформы машинного обучения

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

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

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

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

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

Есть еще несколько важных вопросов:

  1. Сколько сквозных платформ необходимо поставить?
  2. Должна ли одна команда управлять одной платформой, несколькими платформами или подсистемой платформы?
  3. Как из десятков или сотен комбинаций технологических стеков команда выбирает выигрышную комбинацию?

Мы рассмотрим этот важный, но более глубокий вопрос в другой статье.

Команды поддержки машинного обучения

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

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

Сколько должно быть таких команд? Мы считаем, что их не должно быть много, и большинство из них должны формироваться временно лидами в организации при возникновении конкретной ситуации.

Примечания

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