КАК ПРЕОДОЛЕТЬ РАЗРЫВ МЕЖДУ РАЗВИТИЕМ И ОПЕРАЦИЯМИ. ПРИМЕР KESSEL RUN

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

Но, несмотря на разговоры, изменения не происходят. Военная структура остается такой же, какой она была в середине 20-го века, оптимизированной под промышленные методы, ныне уходящие в прошлое.

Легко просто сетовать на летаргию в Министерстве обороны США. Новые компании, стремящиеся выйти на военный подряд, подчеркивают оболванивание своих конкурентов, предполагая, что сосредоточенность унаследованной оборонной промышленности на оборудовании является ключевым фактором, сдерживающим Соединенные Штаты.

Недовольные бывшие чиновники выступают по телевидению и говорят о том, что Соединенные Штаты теряют свое преимущество или проигрывают Китаю, обрушивая критику на безликую бюрократию и заявляя, что она должна «работать лучше».

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

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

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

• во-первых, начинайте с простого, сосредоточившись на четких операционных задачах или проблемах;
• во-вторых, структурируйте организации, чтобы избежать искусственных «долин смерти»;
• и в-третьих, убедитесь, что команда может выполнять все аспекты DevSecOps, стимулируя добродетельные циклы обучения и быстрых улучшений.

Все эти три принципа предполагают необходимость значительных организационных изменений. Военные руководители уже научились использовать DevSecOps в качестве громкого слова, повторяя, что сочетание разработки и эксплуатации программного обеспечения является критически важным для будущих усилий в области программного обеспечения. Но их устраивают организационные структуры, которые оставляют зияющую пропасть между разработкой возможностей и оперативными силами, тем самым укрепляя исторический разрыв между «Dev» и «Ops». Эта структурная раздвоенность препятствует именно тем изменениям, которых требуют лидеры. Чтобы исправить ситуацию, Министерство обороны должно отказаться от исторически сложившейся практики, в которой приоритет отдается инновационному туризму, а не структурным изменениям. Будущие силы, использующие программное обеспечение, не появятся в результате ношения балахонов в организации индустриальной эпохи — они появятся в результате реорганизации, оптимизированной для DevSecOps.

Придерживаться узких рамок устава

ПЕРВЫЙ ПРИНЦИП заключается в том, чтобы —

• сохранять четкую направленность на решение одной военной задачи.

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

Выбор Министерства обороны на сегодняшний день продемонстрировал отсутствие целенаправленности и непонимание того, что создает эффективную цифровую модернизацию. Усилия по обмену данными часто теряются за координационными группами из 150 человек и запутанными названиями, такими как «Объединенное вседоменное командование и управление».

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

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

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

Я возглавлял одну из таких команд, Kessel Run ВВС — эксперимент по созданию современного программного обеспечения для эксплуатации самолетов. Эксперимент этот длится уже шестой год. Его уроки могут быть полезны для других команд.

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

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

В отличие от этого, в течение последних двух лет Kessel Run интенсивно фокусировалась на очень узкой оперативной проблеме: предоставлении программного обеспечения 609-му Центру воздушно-космических операций для создания и выполнения приказов о воздушных задачах и воздушном контроле. Мы сочли необходимым иметь узкий круг задач и четкий набор пользователей.

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

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

Альтернатива заключается в том, чтобы сосредоточиться на конкретных военных проблемах.

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

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

Эта идея была сформулирована системным теоретиком Джоном Галлом:

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

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

Нужная структура для достижения результатов

Сужение масштаба постановки задачи также способствует реализации ВТОРОГО ПРИНЦИПА:

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

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

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

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

Управления программ должны быть частью решения, а не препятствием, которое нужно обойти.

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

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

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

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

• Министерство обороны должно поощрять выполнение ПРОГРАММ, а не планов.

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

Приведение организаций в соответствие с DevSecOps

• DevSecOps — это набор методов разработки программного обеспечения, который объединяет разработку программного обеспечения (Dev), безопасность (Sec) и операции с информационными технологиями (Ops) для обеспечения безопасности результата и сокращения жизненного цикла разработки.

Это подводит нас к третьему принципу организационной структуры —

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

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

В случае программ, которые предоставляют возможности через сети — например, Kessel Run —  подразделением DevSecOps должен являться сам программный офис, который управляет всей цепочкой  к производству и операционной облачной средой для программного обеспечения. Команды, управляющие сетью, исправляющие программное обеспечение и обеспечивающие его доступность, должны быть согласованы с командой разработчиков, а не с какой-то отделенной командой или надзорными чиновниками.

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

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

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

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

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

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

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

В высших эшелонах вооруженных сил существует разрыв между закупками и операциями. В ВВС одно главное командование управляет разработками (Air Force Materiel Command), а отдельные главные командования управляют операциями (Air Combat Command и оперативные командования, такие как Тихоокеанские ВВС).

Такое различие было полезно для аппаратных систем, таких как B-29, но теперь службам необходимы объединенные подразделения разработки и оперативной поддержки для программных возможностей. В противном случае преимущества DevSecOps никогда не будут реализованы, поскольку первый командир, отвечающий за команды разработчиков и операторов, — это четырехзвездный генерал в Пентагоне.

Заключение

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

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

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

В эпоху самолета B-29 конструкторский потенциал создавался на основе взаимозаменяемых болтов, заклепок и калибров из листового металла. В цифровую эпоху эти физические строительные блоки уступают место безграничным комбинациям блоков кода, веб-сервисов и системных интерфейсов.

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

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

28/07/2022

Источник: War On The Rocks

Авторы: БРАЙАН БИЧКОФСКИ И ДЭН ПЭТТ

Брайан Бичкофски — бывший командир Kessel Run (отряд 12 Центра управления жизненным циклом ВВС), который он возглавлял с апреля 2020 года по апрель 2022 года. До этого он был управляющим директором в компании Third Sector Capital Parters, Inc. 

Дэн Пэтт — старший научный сотрудник Гудзоновского института, бывший сотрудник DARPA и бывший генеральный директор компании Vecna Robotics.

Kessel Run Shows How to Bridge the Gap Between Development and Operations

Last Updated on 30.07.2022 by iskova