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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

1. Существующая платформа (например, Bitrix)

2. SaaS

3. Коммерческое программное обеспечение

4. Собственная разработка (наименее предпочтительный вариант)

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

5. Хостинг у поставщика

6. Platform as a Service (PaaS)

7. Контейнеры

8. Виртуальные машины

9. Физические серверы (наименее предпочтительный вариант)

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

10. Облачная инфраструктура (IaaS)

11. On-premises (наименее предпочтительный вариант)

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

• Назначить ответственных за данные (data stewards), которые будут управлять качеством, правами собственности и политиками доступа.
• Внедрить рамочную систему управления данными, охватывающую версионирование, сроки хранения и правила архивирования.       
• Использовать единые стандарты метаданных для обеспечения совместимости и предотвращения изолированного хранения информации (data silos).

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

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

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

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

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

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

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

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

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