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

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

Архитектурные принципы служат базовыми ориентирами, соединяющими высокоуровневую стратегию с комплексными проектными решениями, формирующими IT -решения.

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

Что такое архитектурные принципы

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

Ключевые преимущества архитектурных принципов

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

Роли архитектурных принципов

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

Структура и компоненты

Каждый архитектурный принцип должен включать три ключевых элемента:

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

Обеспечение эффективности

Чтобы архитектурные принципы приносили реальную пользу, они должны соответствовать следующим требованиям:

• Ограниченное количество: Оптимально — не более 20 принципов.
• Ориентация на будущее: Принципы должны задавать долгосрочное направление и сохранять гибкость.
• Поддержка со стороны руководства: Принятие и соблюдение принципов обеспечивается за счет участия топ-менеджмента.
• Ясность и однозначность: Принципы должны быть понятны и не вызывать различий в трактовке.
• Периодический пересмотр, но редкие изменения: Принципы остаются стабильными даже при смене технологий.
• Написаны простым языком: Формулировки должны быть доступны как для технических специалистов, так и для бизнес-аудитории.

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

А что делать, если у нас еще нет четко сформулированной стратегии в области бизнеса и технологий? 

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

Примеры архитектурных принципов

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

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

Вовлечение на раннем этапе

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

Использование существующих решений

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

Выбор максимально возможного уровня абстракции

• Формулировка: При выборе или проектировании решений, а также при определении среды их размещения, следует отдавать предпочтение максимально возможному уровню абстракции. Например, предпочтительнее использовать модели Software as a Service (SaaS), чем разрабатывать собственное ПО, и выбирать размещение у поставщика, а не on-premises.

Рекомендуемая иерархия выбора:

Выбор приложения:

1. Существующая платформа (например, Bitrix)
2. SaaS
3. Коммерческое программное обеспечение
4. Собственная разработка (наименее предпочтительный вариант)

Модель хостинга:

1. Хостинг у поставщика
2. Platform as a Service (PaaS)
3. Контейнеры
4. Виртуальные машины
5. Физические серверы (наименее предпочтительный вариант)

Местоположение размещения:

1. Облачная инфраструктура (IaaS)
2. On-premises (наименее предпочтительный вариант)

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

Последствия:

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

Превосходство программных решений

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

Веб-браузер — основной клиент

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

Предоставление возможностей самообслуживания

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

Покупать, а не разрабатывать

• Формулировка: Везде, где это возможно, следует отдавать предпочтение готовым коммерческим решениям или моделям Software as a Service (SaaS) вместо разработки собственного программного обеспечения.
• Обоснование: Коммерческие решения обеспечивают более быстрое получение ценности, сниженные затраты на сопровождение и поддержку со стороны поставщика, что в итоге уменьшает совокупную стоимость владения (TCO).
• Последствия: Перед началом собственной разработки необходимо тщательно оценить доступные на рынке решения. В контрактах должны быть четко прописаны требования к безопасности, соответствию нормам и ответственности поставщика. Внутренние ресурсы разработки следует направлять на проекты, которые обеспечивают уникальные конкурентные или стратегические преимущества.

Безопасность и конфиденциальность данных по умолчанию

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

Управление данными и обеспечение их качества

• Формулировка: Данные должны рассматриваться как стратегический актив, для работы с которым необходимо внедрять стандартизированные процессы сбора, хранения, обмена и управления жизненным циклом. Каждый внедряемый IT продукт должен обеспечивать поставку своих данных и продуктовых метрик успешности в централизованный репозиторий данных
• Обоснование: Качественные и грамотно управляемые данные являются основой для точной отчетности, обоснованного принятия решений и устойчивого функционирования организации.
• Последствия: Назначить ответственных за данные (data stewards), которые будут управлять качеством, правами собственности и политиками доступа. Внедрить рамочную систему управления данными, охватывающую версионирование, сроки хранения и правила архивирования. Использовать единые стандарты метаданных для обеспечения совместимости и предотвращения изолированного хранения информации (data silos).

Взаимодействие и интеграции на основе стандартов

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

Использование стандартизированных технологических стеков и фреймворков

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

Продолжение в части №2.