Зачем закреплять архитектурные принципы в компании: часть 2

Продолжение статьи Архитектурные принципы для технологического надзора: часть 1

12. Использование современных методов аутентификации и централизованного управления идентификацией

• Формулировка: Все новые веб-приложения, включая решения в формате SaaS, должны быть интегрированы с системой управления идентификацией. Это обеспечивает единую точку входа (SSO), многофакторную аутентификацию (MFA) и применение политик условного доступа. Аутентификация через Active Directory (AD)/LDAP допустима только для legacy систем.
  Обоснование: Централизуя процессы аутентификации на базе современной платформы управления идентификацией, организация получает унифицированный доступ пользователей, стабильное применение политик безопасности и автоматическое отключение доступа. Поддержка современных протоколов (например, SAML, OAuth, OpenID Connect) упрощает пользовательский опыт и значительно снижает риски безопасности за счет сквозного применения MFA и политик условного доступа.
  Последствия:
• Технологические требования: Все новые веб-приложения должны поддерживать современные стандарты аутентификации и идентификации (SAML, OAuth или OpenID Connect).
• Управление безопасностью: Команды безопасности и архитектуры предприятия должны проверять соответствие новых приложений требованиям SSO, MFA и условного доступа до их внедрения.
• Унаследованные системы: Использование AD/LDAP допустимо только при невозможности интеграции с современными механизмами. Такие случаи должны быть задокументированы и одобрены.
• Управление жизненным циклом пользователей: Централизованная система позволяет эффективно и последовательно управлять доступом.       
• Снижение рисков: Централизация управления идентификацией уменьшает поверхность атак, усиливает контроль доступа и способствует выполнению нормативных требований.

13. Планирование защиты данных и восстановления после сбоев с самого начала

• Формулировка: Все новые решения должны включать полноценную стратегию по защите данных и восстановлению после сбоев (Disaster Recovery, DR), начиная с ранних этапов проектирования, бюджетирования и реализации.
  Обоснование: Отсутствие планирования резервного копирования, защиты данных и DR-мероприятий подвергает Компанию существенным операционным и финансовым рискам, особенно по мере роста критичности системы. Грамотно реализованный план DR обеспечивает целостность и доступность данных, а также соответствие законодательным и нормативным требованиям. Учет этих требований на ранних стадиях позволяет избежать неожиданных затрат в будущем — например, потребности в резервировании хранилищ и больших объемов данных могут удвоить стоимость решений, если не учтены заранее. 
  Последствия:
• Проектирование и бюджетирование: Планирование резервного копирования и DR должно быть заложено в архитектуру и бюджеты проекта с самого начала. Это включает затраты на оборудование, ПО и операционные расходы для создания надежной DR-инфраструктуры.       
• Управление и утверждение: Любой новый запрос на внедрение системы должен сопровождаться планом по резервному копированию и DR, прошедшим согласование архитектурного или управляющего совета. Решения без документированного плана не допускаются к вводу в эксплуатацию.  
• Тестирование и проверка: Регулярно проводить тесты процедур резервного копирования, восстановления и переключения в рамках DR, чтобы гарантировать достижение заданных параметров восстановления (RTO, RPO).      
• Соответствие и аудит: Документировать процессы резервного копирования и DR для прохождения проверок и демонстрации устойчивости организации.     
• Управление исключениями: Если система не считается критичной и не требует расширенных DR-мер, бизнес должен обосновать это, указав допустимые риски при отсутствии полноценного резервного копирования.

14. Масштабируемость и производительность

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

15. Дизайн, ориентированный на бизнес

• Формулировка: Технологические решения и инициативы должны постоянно соотноситься с ключевыми стратегическими целями Компании.
  Обоснование: Инвестиции в технологии должны прямо или косвенно способствовать достижению целей бизнеса — будь то повышение удовлетворенности клиентов, оптимизация операционных процессов или ускорение научных исследований.
  Последствия: 
• Встраивать обратную связь от пользователей и вовлекать стейкхолдеров в процесс проектирования решений.       
• Оценивать предлагаемые решения по их измеримому вкладу в бизнес (экономия затрат, снижение рисков, рост доходов и др.).      
• Поддерживать гибкие и итеративные подходы (agile), чтобы оперативно проверять и внедрять новые идеи.

16. Поддержка непрерывного улучшения и ответственных инноваций

• Формулировка: Поощрение постоянного обучения, экспериментирования и организация циклов обратной связи для развития технологий и практик. 
  Обоснование: Культура непрерывного улучшения в сочетании с управлением рисками позволит Компании оставаться адаптивной, конкурентоспособной и защищенной от неконтролируемых угроз. Эффективное использование новых технологий требует как готовности к экспериментам, так и наличия структурированного управления. 
  Последствия: 
• Выделять ресурсы (время и бюджет) на исследования, пилотные проекты и proof-of-concept инициативы для изучения новых технологий и подходов.      
• Разрабатывать и применять четкие критерии оценки новых идей с учетом возврата инвестиций (ROI), стратегического соответствия, безопасности и нормативных требований.
• Делиться как успехами, так и неудачами внутри организации для ускорения обучения и развития.     
• Вовлекать архитектурные, безопасностные и управляющие комитеты на ранних этапах, чтобы выявлять риски, планировать их минимизацию и сохранять стратегическое выравнивание.      
• Регулярно обновлять архитектурные принципы и стандарты, опираясь на полученные уроки из инновационных инициатив.

17. Надлежащая проверка при капитальных технологических закупках

• Формулировка: Закупка технологий, связанных со значительными капитальными или операционными затратами, должна проходить процесс надлежащей проверки (due diligence), чтобы убедиться, что выбранное решение соответствует функциональным и нефункциональным требованиям организации и предлагается по конкурентной цене.
  Обоснование: В условиях ограниченных финансовых и операционных ресурсов важно гарантировать, что приобретаемое решение соответствует потребностям бизнеса и бюджетным ограничениям. Проведение due diligence помогает защитить ресурсы организации и снижает риск внедрения неэффективных или несовместимых решений.
  Последствия: 
• Формирование требований: При необходимости следует четко зафиксировать как функциональные (бизнес), так и нефункциональные (ИТ/архитектурные) требования. Эти требования должны разрабатываться совместно бизнесом и ИТ, чтобы охватить весь спектр потребностей и ограничений.     
• Проведение RFP: При значительном масштабе или стоимости закупки необходимо инициировать процесс запроса предложений (RFP) с участием нескольких поставщиков. RFP должен содержать четкий набор требований и инструкции, по которым поставщики смогут представить, как их решение им соответствует, а также предоставить детальную коммерческую часть.
• Оценка и документация: Необходимо задокументировать процесс оценки и выбора поставщика, включая таблицы оценки, критерии рецензирования и обоснование итогового решения.     
• Тестирование на приемку: По возможности, провести приемочные испытания (acceptance testing), чтобы проверить, соответствует ли решение заявленным требованиям до оформления заказа.   
• Исключения по принципу единственного поставщика: Использование подхода «единственный поставщик» должно быть строго обосновано и применяться только в случаях реального отсутствия альтернативных решений на рынке.   
• Утверждение органом управления: Все капитальные закупки технологий должны проходить рассмотрение и утверждение соответствующим комитетом или советом (например, Архитектурным советом или ИТ-стратегическим комитетом). Это обеспечивает соответствие архитектурным и безопасностным стандартам, способствует прозрачности и дает возможность задать вопросы или оспорить предложения.

18. Практичность важнее идеала

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

Заключение

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

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

План внедрения:

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

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