Общие проблемы, с которыми сталкиваются при приеме Додафа и как их преодолеть

Понять препятствия для усыновления DODAF

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

Сложность рамок

DODAF охватывает более 50 моделей (называемых точками зрения), каждая из которых служит определенной аналитической цели. Для команд, новых для корпоративной архитектуры, навигация по этим точкам зрения, их взаимосвязи и требования к данным могут ощущаться подавляющими. Рамочная основа требует полного понимания таких понятий, как операционные взгляды (OV), системные взгляды (SV) и технические стандарты представления (TV), каждая со своим собственным набором подчиненных продуктов. Эта крутая кривая обучения часто приводит к путанице в отношении того, какие точки зрения необходимы для данной программы, что приводит к раздутым, недостаточно используемым артефактам или неполным представлениям, которые не соответствуют целям программы.

Коренные причины сложности

Стратегии, чтобы приручить сложность

  1. Принять процесс выбора точки зрения.] Вместо того, чтобы пытаться создать все точки зрения, определите минимальный жизнеспособный набор, привязанный непосредственно к воротам программных решений. Например, программе в ранней разработке системы могут потребоваться только OV-1, OV-2, OV-5 (Модель операционной активности) и SV-1. Расширяйте только тогда, когда этого требует анализ.
  2. Использовать заранее определенные шаблоны и шаблоны.] Использование руководящих документов Министерства обороны США, таких как Мета-модель DODAF (DM2) и Интегрированная архитектурная структура (IAF), для стандартизации повторяющихся элементов. Создание многоразовых шаблонов точек зрения для общих типов систем (например, командно-контрольная, логистика).
  3. Предоставьте четкий словарь данных заранее. Установите общий словарь для архитектурных элементов до начала моделирования. Выровняйтесь с DM2, но адаптируйте его к домену организации. Это позволяет избежать общей ловушки нескольких команд, использующих синонимы, которые нарушают интеграцию данных позже.
  4. Инвестируйте в обучение, которое охватывает как DODAF, так и выбранный инструмент архитектуры. Избегайте обучения общих поставщиков. Вместо этого объедините принципы DODAF с практическими упражнениями с использованием вашей конкретной среды. Рассмотрите возможность партнерства с такими организациями, как Институт разработки программного обеспечения (SEI) или аккредитованные консультанты по оборонной архитектуре для специализированных семинаров.

Отсутствие квалифицированного персонала

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

Размеры разрыва навыков

Создание и поддержание потенциала

  1. Создать многоуровневую учебную программу.] Разработать три уровня обучения: Осведомленность (для руководства и заинтересованных сторон), Практикующий (для членов команды, которые будут создавать и поддерживать точки зрения) и Advanced (для архитекторов, которые будут вести разработку и интегрировать в рамках программ).
  2. Создайте внутренние центры передового опыта (CoE.] Объедините своих самых опытных архитекторов DODAF в небольшую консультативную команду, которая поддерживает несколько программ. CoE разрабатывает многоразовые активы, проводит экспертные обзоры и наставляет новых архитекторов. Со временем они становятся хранилищем организационных знаний.
  3. Партнер с оборонными академическими программами. Многие университеты предлагают курсы по корпоративной архитектуре для обороны. В Военно-морской аспирантуре США и Институте программной инженерии Карнеги-Меллона есть соответствующие программы. Сотрудники спонсора посещают или принимают модули на месте.
  4. Переходная подготовка с смежных ролей.] Системные инженеры, аналитики данных и специалисты по приобретению уже обладают частичными навыками. Перекрестная подготовка их в DODAF, начиная с точек зрения, которые согласуются с их существующим опытом (например, системные инженеры начинают с SV-1 и SV-2, аналитики начинают с OV-5).

Сопротивление переменам

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

Общие формы сопротивления

Преодоление организационного сопротивления

  1. Безопасное видимое спонсорство руководителей.] Сопротивление испаряется быстрее всего, когда старшие руководители последовательно сообщают о бизнес-кейсе и демонстрируют личную приверженность. Пусть исполнительный директор программы или флагманский офицер упоминают DODAF на совещаниях всех рук и связывают его с успехом миссии. Свяжите цели принятия с ежегодными обзорами эффективности для ключевых менеджеров.
  2. Демонстрируйте ранние ощутимые победы. Используйте пилотную программу, чтобы показать быстрое сокращение избыточности или более быстрый цикл принятия решений. Например, если пилотная архитектура показывает, что две ранее разделенные усилия по разработке разделяют 60% одних и тех же интерфейсов, документируйте, что экономия и трансляция это. Истории успеха нейтрализуют скептиков более эффективно, чем любые политические записки.
  3. Интегрируйте DODAF с существующими рабочими процессами, а не заменяйте их. Карты артефактов DODAF в обязательные доставляемые вехи в системе приобретения защиты (например, элементы технического обзора системной инженерии). Избегайте создания отдельной платы «обзор архитектуры»; вместо этого вплетайте обзоры архитектуры в существующие обзоры дизайна и процессы шлюза.
  4. Создать «безопасную песочницу» для экспериментов. Разрешить командам создавать модели DODAF на некритическом проекте в течение нескольких месяцев без штрафа за неполные или несовершенные артефакты. Это снижает страх неудачи и поощряет обучение.После периода песочницы оценивать извлеченные уроки и постепенно повышать ожидания качества.
  5. Используйте стимулы, а не мандаты. Признайте команды, которые производят высококачественные архитектуры с наградами, дополнительными бюджетами обучения или общественным признанием.

Качество и согласованность данных

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

Общие проблемы данных

Учреждение управления данными

  1. Формируйте архитектурную плату данных. Хартии небольшой группы (перекрестной программы) для определения и поддержания контролируемого словаря, единиц измерения и допустимых форматов данных.Совет утверждает все дополнения или изменения в таксономии и обеспечивает согласование с DM2.
  2. Внедрить автоматизированные проверки валидации. Используйте такие инструменты, как Sparx Enterprise Architect или IBM Rational Rhapsody, с пользовательскими правилами проверки, которые маркируют несоответствия (например, если в OV-5 нет соответствующих систем в SV-1, пометьте его).
  3. Создать единый источник репозитория истинности. Хранить все данные архитектуры в общем репозитории (например, облачный инструмент с контролем версий). Предотвратить локальные копии, которые могут расходиться.Установить регулярный график синхронизации, если необходимо использовать несколько инструментов.
  4. Проводить периодические архитектурные аудиты. Каждую четверть отбирайте подмножество точек зрения и проверяйте перекрестные ссылки. Используйте результаты аудита для обновления обучения и улучшения правил управления.

Интеграция с существующими процессами проектирования и приобретения систем

DODAF часто используется в организациях, которые уже имеют зрелые процессы проектирования систем (SE) и приобретения (например, серии DoD 5000). Эти процессы имеют свои собственные требования к документации, обзорные ворота и терминологию. Когда точки зрения DODAF рассматриваются как дополнительная деятельность, а не встраиваются в деятельность SE, возникают дублирование и путаница. Инженеры могут быть вынуждены обновлять одну и ту же информацию в нескольких местах, что приводит к выгоранию.

Неудачи общей интеграции

Стратегии бесшовной интеграции

  1. Карта точек зрения DODAF для технических обзоров систем (SETRs). Для каждого крупного обзора (SRR, SFR, PDR, CDR, TRR и т.д.) определите, какие точки зрения DODAF требуются для ввода или вывода. Например, в системном функциональном обзоре (SFR), SV-1 (описания интерфейса) и OV-5 (оперативные действия) должны быть в зрелом проекте.
  2. Принять подход, основанный на моделировании систем (MBSE), который объединяет модели DODAF и SE. Используйте единую среду моделирования (например, Cameo Systems Modeler, MagicDraw), которая поддерживает как SysML для профилей SE, так и DODAF. Это устраняет дублирование, поскольку одни и те же элементы (системы, функции, данные) используются в обоих контекстах просмотра. Деятельность OV-5 становится основой для системных функциональных потоков в SysML.
  3. Выравнивание форматов обмена данными. Требуйте, чтобы все инструменты SE экспортировали данные в форматах, совместимых с метамоделью DODAF (DM2). Используйте открытые стандарты, такие как XML Metadata Interchange (XMI) и Web Ontology Language (OWL). Избегайте проприетарных двоичных форматов, которые блокируют данные в один инструмент.
  4. Включите архитектуру в интегрированные генеральные графики (IMS). Относитесь к архитектурным артефактам как к критическим элементам пути с конкретными датами начала и окончания. Держите архитекторов подотчетными этим датам, так же как руководители аппаратного и программного обеспечения несут ответственность за свои результаты.

Толинг и технологические ограничения

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

Повторяющиеся головные боли Tooling

Выбор и оптимизация толинга

  1. Проведите тщательную оценку инструмента перед покупкой. Используйте структурированный процесс выбора, который включает в себя доказательство концепции с вашими фактическими данными (не демонстрационные примеры поставщиков). Оцените: поддержка всех необходимых точек зрения, соответствие DM2, возможности экспорта / импорта, производительность при нагрузке и статус сертификации MLS.
  2. Стандартизируйтесь на одном наборе инструментов на предприятии. Если нет веской причины (например, устаревшие инструменты, которые не могут быть перенесены), стандартизируйте, чтобы избежать проблем с совместимостью. Если несколько инструментов должны сосуществовать, определите центральный формат хранилища (например, магазин RDF) и потребуйте, чтобы каждый инструмент экспортировался в этот формат.
  3. Инвестируйте в пользовательские скрипты и плагины. Многие инструменты позволяют скриптингу (например, JavaScript, Python) автоматизировать повторяющиеся задачи, такие как генерация документов с точек зрения, проверка данных или создание пользовательских отчетов.
  4. План поддержки секретной среды. Если ваша организация работает на нескольких уровнях классификации, выберите инструмент, который предлагает (или может быть развернут) конфигурацию с воздушным зазором с контролируемыми механизмами передачи данных.Проконсультируйтесь с отделом безопасности заранее, чтобы убедиться, что инструмент соответствует требованиям безопасности DISA.

Поддержание долгосрочной устойчивости

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

Причины неустойчивости

Обеспечение долгосрочной жизнеспособности

  1. Рассматривайте архитектуру как капитальный актив. Включайте затраты на поддержание архитектуры в смету расходов жизненного цикла программы. Так же, как и на поддержание аппаратного обеспечения, бюджет на обновление моделей, лицензии на инструменты и обучение персонала каждый год.
  2. Реализуйте процесс управления изменениями, связанный с запросами на инженерные изменения (ECRs). Всякий раз, когда одобряется изменение системы (будь то аппаратное обеспечение, программное обеспечение или операционная концепция), архитектура должна обновляться одновременно. Назначьте конкретного архитектора в качестве «менеджера конфигурации» для базового уровня архитектуры.
  3. Создать культуру живой документации. Поощрять использование моделей архитектуры в качестве основного источника для анализа воздействия, торговых исследований и оценок готовности. Когда заинтересованные стороны видят, что модели активно используются для принятия решений, они будут требовать их обслуживания.
  4. План перехода на архитектурные роли. Перекрестный тренинг нескольких членов команды по обслуживанию архитектуры, а не только ведущего архитектора. Документируйте все процедуры моделирования, соглашения об именах и правила проверки в стандартной операционной процедуре (SOP). Это снижает влияние текучести кадров.
  5. Проводить ежегодные обзоры архитектуры. Планировать формальный обзор каждый год, где архитектура оценивается на актуальность, точность и полноту. Действия из обзора назначаются с крайними сроками, как и любой инженерный обзор.

Вывод: от усыновления до институционализации

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