Во многих программах по разработке автономных дронов вопросы безопасности данных рассматриваются на поздней стадии обсуждения соответствия нормативным требованиям. На практике же до этого момента редко доходят.
Процесс формирования программы начинается гораздо раньше, зачастую еще до того, как система успевает доказать свою эффективность. ИТ-анализ затягивается дольше, чем ожидалось. Появляются дополнительные требования. Юридический и закупочный отделы начинают задавать вопросы о том, где работает система, как обрабатываются данные и кто контролирует доступ. Затем изменение политики или сенсационная новость вносят новую неопределенность, и акцент незаметно смещается с наращивания темпов на управление рисками.
На данном этапе ничего не сломалось. Но прогресс уже замедлился. Именно здесь безопасность данных перестает быть просто контрольным списком и начинает оказывать структурное влияние. Она определяет, как принимаются решения, насколько быстро могут действовать команды и насколько уверенно может расширяться программа.
Сложность заключается не в какой-либо одной проблеме, а в том, как эти проблемы накладываются друг на друга.
Процесс становится первым узким местом.
Первый уровень проявляется в виде процесса. В каждом предприятии проводится проверка ИТ-безопасности, и ожидается, что каждое развертывание пройдет через нее. В отрыве от контекста это управляемо. На практике же процесс расширяется. Руководители проектов вынуждены координировать действия с ИТ-отделом, поставщиками и внутренними заинтересованными сторонами, которым требуются различные формы обеспечения безопасности. Документация растет. Вопросы множатся. Сроки увеличиваются.
То, что начинается как шаг, постепенно становится центром внимания. В этот момент программа начинает терять темп. Система может быть готова, но слишком много энергии уходит на управление самим процессом. Команды, которые продолжают двигаться вперед, - это те, кто сдерживает этот процесс. Они сокращают ручной труд, где это возможно, напрямую привлекают своих партнеров-разработчиков программного обеспечения и параллельно продолжают создавать остальную часть программы.
Пока продолжается анализ, уточняются сценарии использования, разрабатываются рабочие процессы и согласовывается действия заинтересованных сторон. Именно этот баланс позволяет программе двигаться вперед, и как только этот этап будет улажен, начнет формироваться следующая задача.
Решения о развертывании определяют программу.
Разговор смещается с вопроса о безопасности системы на вопрос о способе ее развертывания. Именно здесь решения начинают приобретать большее значение. Выбор между облачным, частным облаком, локальным развертыванием и изолированной инфраструктурой выходит на первый план. Сначала это кажется лишь техническими предпочтениями. Со временем их влияние становится структурным.
Модель развертывания начинает определять принцип работы программы. Облачный подход позволяет командам быстро адаптироваться, объединять несколько площадок и предоставлять распределенным заинтересованным сторонам доступ без существенных ограничений. Он поддерживает централизованные операции и снижает необходимость постоянного участия ИТ-специалистов после первоначальной настройки.
Локальный подход обеспечивает больший контроль, но вводит ограничения, которые становятся очевидными по мере роста программы. Координация между несколькими площадками становится более сложной. Удаленный доступ требует большей структурированности. Интеграции сужаются. Постоянное владение ИТ-инфраструктурой становится частью системы.
Эти компромиссы напрямую влияют на то, насколько далеко и как быстро может расшириться программа. Это становится особенно важным на ранних этапах. Прежде чем программа продемонстрирует достаточную ценность, более сложные архитектуры потребуют больших внутренних вложений. Бюджет, ИТ-ресурсы и организационная согласованность - все это вступает в игру одновременно.
Технология может быть готова. Но структура, необходимая для её поддержки, кажется более громоздкой, чем та, которую может выдержать программа. Масштабируемые программы, как правило, развиваются по-другому. Они начинаются с моделей, которые позволяют им развиваться, учиться и демонстрировать свою ценность. По мере того, как система доказывает свою эффективность, они развивают архитектуру в соответствии с ней. Безопасность растёт вместе с программой, что приводит к увеличению уровня сложности.
Геополитика вносит структурную неопределенность.
Помимо процессов и архитектуры, на принятие решений начинает влиять сама окружающая среда. Геополитические сдвиги меняют подход предприятий к данным и инфраструктуре. Дискуссия вышла за рамки вопроса о том, где хранятся данные, и перешла к вопросу о том, кто в конечном итоге контролирует систему. Во многих средах растет ожидание того, что критически важная инфраструктура должна оставаться локально привязанной и устойчивой к внешним воздействиям.
В то же время неопределенность в отношении оборудования продолжает влиять на планирование. Изменения в политике, сдвиги на рынке и противоречивые точки зрения затрудняют принятие уверенных долгосрочных решений. Команды начинают искать ясность в отношении того, что останется неизменным через несколько лет, прежде чем принимать решения, которые необходимо принять сегодня.
Такая ясность редко достигается так, как они ожидают. Что остается неизменным, так это структура самой программы. Аппаратное обеспечение будет меняться. Циклы замены неизбежны. То, что определяет, переживет ли программа эти изменения, - это все, что построено вокруг аппаратного обеспечения. Интеграции, рабочие процессы, операционные процессы и команды, которые зависят от системы, определяют ее долгосрочную ценность.
Эти элементы накапливаются со временем. Когда они построены на правильном фундаменте, оборудование становится частью более крупной системы. Оно может меняться, не заставляя все остальное перезапускаться. Именно здесь происходит сдвиг. Команды перестают ждать определенности. Они начинают строить с учетом адаптивности.
Масштабирование зависит от прохождения через все три этапа.
В совокупности эти факторы объясняют, почему многие программы по внедрению дронов испытывают трудности с масштабированием. Редко всё сводится к одной проблеме. Процесс отнимает время. Архитектура добавляет веса. Геополитические факторы вносят неопределенность. Каждый слой основывается на предыдущем.
Прогресс определяется не наличием этих проблем, а тем, как команды их преодолевают. Наиболее эффективные программы поддерживают динамику по всем трем направлениям. Они управляют процессом, не будучи им поглощенными. Они согласовывают архитектуру со стадией своего развития. Они принимают решения, которые позволяют программе адаптироваться к меняющейся среде.
Пока одни команды делают паузу, другие продолжают развиваться. Они совершенствуют рабочие процессы, интегрируют системы и развивают операционную зрелость, которая накапливается со временем. Разрыв между ними недолго остается небольшим.
Решение, определяющее масштаб
Безопасность данных будет и впредь влиять на то, как создаются программы по разработке беспилотных летательных аппаратов. Но это не обязательно должно определять темпы их развития.
Ограничения реальны. Компромиссы стали яснее, чем раньше. Путь вперед становится все более понятным. Остается лишь принять решение: позволить неопределенности задавать темп или продолжать развиваться, пока система продолжает эволюционировать.