AG Archtecture
ИТ-аудит и решение задач
Enterprise & Solution Architecture
Что такое архитектура ИТ-решения и для чего она нужна компании
Архитектура ИТ-решения — это совокупность ключевых решений о структуре системы, ее компонентах, способах взаимодействия, технологиях, ограничениях и принципах, которые обеспечивают достижение бизнес-целей и нефункциональных требований (надежность, масштабируемость, безопасность, стоимость и т. д.). Архитектура ИТ-решения это основа и правила построения системы\сервиса, которые определяют, как решение будет работать сегодня и развиваться завтра.
Для чего архитектура ИТ-решения нужна компании:
- Выравнивание с бизнес-целями: помогает строить систему под конкретные KPI, продуктовые метрики либо проектные ограничения содержания, сроков и бюджеа;
- Снижение рисков: выявляет узкие места и компромиссы заранее (производительность, отказоустойчивость, безопасность);
- Управление стоимостью: дает прогноз TCO, облачных расходов, затрат на разработку, поддержку и развитие
- Масштабируемость и эволюция: облегчает добавление новых функций и интеграций;
- Коммуникация и прозрачность: единый язык между бизнесом, разработкой, безопасностью, эксплуатацией, закупками и подрядчиками в рамках развития системы\сервиса;
- Управление техническим долгом: фиксация отклонений от архитектурного решения и возможные последствия;
- Предотвращает лишние интеграции и дублирование функций;
- Вводит в контекст изменений ИТ-ландшафта смежные команды разработки;
Что прорабатывается в рамках архитектуры решения:
- Контекст и заинтересованные стороны: каких пользователей затрагивает, какие связи между системами меняются, появляются новые, бюджетные ограничения;
- Функциональный охват и границы системы\сервиса: что входит в содержание изменений;
- Нефункциональные требования: доступность (SLA), производительность, RTO/RPO, масштабируемость, безопасность;
- Интеграционная архитектура: синхронные/асинхронные взаимодействия, описаний условий контрактов;
- Данные: источники данных, сущности в мастер системах и системах потребителях, связи между сущностями в разных системах;
- Безопасность: аутентификация/авторизация, управление секретами, шифрование, сегментация сети;
- Инфраструктура и развертывание: облако/он‑премиз, регионы, политики бэкапирования и восстановления при авариях;
- Дорожная карта: целевое состояние (to‑be), текущее (as‑is), переходные этапы и релизы.
Плюсы и минусы разработки\доработки решения без архитектуры ИТ-решения и с архитектурой ИТ-решения:
Без архитектуры (разработчики импровизируют по ходу)
Плюсы
- Быстрый старт: можно показать результат уже завтра.
- Меньше согласований и документов.
- Хорошо для экспериментов и одноразовых прототипов.
- Дешево на первом шаге.
Минусы
- Часто приходится переделывать: решения не стыкуются, всплывают «скрытые» ограничения.
- Растет технический долг: патчи, костыли, хаос интеграций.
- Непредсказуемые сроки и стоимость: сложно планировать релизы и бюджет.
- Плохая масштабируемость и надежность: работает «на десять пользователей», но падает под нагрузкой.
- Риски безопасности и регуляторных требований: легко упустить требования.
- Зависимость от конкретных людей: знания в головах, не в документах.
- Труднее сопровождать и развивать: любая мелочь — как мини‑проект.
С архитектурой (когда есть план, принципы и ключевые решения)
Плюсы
- Предсказуемость: понятные сроки, риски, бюджет.
- Меньше переделок: ключевые решения приняты заранее.
- Масштабируемость и отказоустойчивость закладываются с самого начала.
- Соответствие безопасности и законам.
- Легче подключать новые команды и интеграции.
- Понятная эксплуатация: мониторинг, уведомления и оперативное реагрирование.
- Прозрачная стоимость владения (TCO).
Минусы
- Медленнее старт: нужно время на проработку.
- Риск «перепроектирования»: можно сделать слишком сложно.
- Больше дисциплины и артефактов (кажется бюрократией).
- Стоимость работы архитектора/аналитики на входе.
- Когда уместно строить решение без архитектуры:
- Быстрые багфиксы, небольшие доработки в одном сервисе.
- Пробные гипотезы, прототипы, которые не жалко выбросить.
- Соло‑команда, короткий жизненный цикл решения.
- Когда следует предварительно проработать архитектуру решения:
- Любые изменения, затрагивающие данные и интеграции между системами.
- Рост нагрузки, требования к SLA/безопасности/регуляторные требования.
- Много команд и поставщиков, долгоживущие продукты и платформы.
- Выбор базовых технологий, баз данных, целевых SLO.
Какими скиллами должен владеть архитектор ИТ решений:
1. Бизнес-мышление
- Понимать цели бизнеса и потребности пользователей.
- Переводить бизнес-задачи в требования к ИТ-решению.
- Оценивать стоимость, сроки, риски и ожидаемый эффект.
- Понимать, какие функции действительно нужны, а какие избыточны.
- Говорить с руководителями на языке результатов, а не только технологий.
2. Системное мышление
- Видеть решение целиком: приложения, данные, интеграции, инфраструктуру, безопасность и поддержку.
- Понимать взаимосвязи между системами.
- Определять границы решения и зоны ответственности команд.
- Предвидеть последствия архитектурных решений.
- Проектировать не только текущее состояние, но и развитие системы.
3. Технические знания Архитектору необязательно быть лучшим специалистом во всех областях, но он должен хорошо ориентироваться в основных направлениях:
- Backend и frontend-разработка.
- Базы данных и хранилища данных.
- API и интеграции.
- Очереди, брокеры сообщений и событийные системы.
- Облачные и локальные инфраструктуры.
- Сети, балансировка и отказоустойчивость.
- Контейнеры и оркестрация.
- CI/CD и Infrastructure as Code.
- Мониторинг, логирование и трассировка.
- Микросервисная и монолитная архитектура.
- Управление конфигурациями и секретами.
4. Проектирование архитектуры
- Создавать логическую и физическую архитектуру решения.
- Выбирать подходящие архитектурные стили и паттерны.
- Проектировать взаимодействие компонентов.
- Определять модели данных и владение данными.
- Продумывать сценарии отказа и восстановления.
- Проектировать миграции и переход от текущего состояния к целевому.
- Описывать архитектуру с помощью C4, UML, BPMN или простых понятных схем.
5. Интеграции
- Проектировать взаимодействие между системами.
- Выбирать синхронный или асинхронный обмен.
- Определять форматы сообщений и контракты API.
- Учитывать повторную доставку, идемпотентность и обработку ошибок.
- Планировать версионирование API.
- Предотвращать дублирование и рассинхронизацию данных.
6. Нефункциональные требования
Архитектор должен заранее ответить на вопросы:
- Сколько пользователей и запросов выдержит система?
- Какая допустимая задержка ответа?
- Какую доступность нужно обеспечить?
- Что произойдет при отказе компонента?
- Как быстро система должна восстановиться?
- Какие данные необходимо защищать?
- Сколько будет стоить эксплуатация?
- Насколько просто систему сопровождать и изменять?
Ключевые темы: производительность, масштабируемость, доступность, надежность, безопасность, сопровождаемость и стоимость.
7. Информационная безопасность
- Понимать аутентификацию и авторизацию.
- Проектировать управление ролями и доступами.
- Учитывать шифрование данных и управление секретами.
- Предусматривать аудит и журналирование действий.
- Знать основные угрозы и уязвимости.
- Учитывать требования законодательства и стандартов.
- Взаимодействовать со специалистами по информационной безопасности.
8. Облака и инфраструктура
- Понимать принципы работы облаков и локальных дата-центров.
- Учитывать зоны доступности, резервирование и аварийное восстановление.
- Оценивать ресурсы и стоимость инфраструктуры.
- Понимать сетевую архитектуру.
- Планировать масштабирование.
- Учитывать ограничения конкретного провайдера или оборудования.
9. Коммуникация
Архитектор постоянно взаимодействует с:
- Заказчиком и бизнесом.
- Product Manager или Product Owner.
- Бизнес- и системными аналитиками.
- Руководителями разработки.
- Разработчиками.
- QA-инженерами.
- DevOps и SRE.
- Специалистами по данным.
- Информационной безопасностью.
- Инфраструктурными командами.
- Службой поддержки и эксплуатации.
- Вендорами и интеграторами.
- Финансами, закупками и юристами.
Поэтому важны:
- умение слушать и задавать уточняющие вопросы;
- способность объяснять сложное простыми словами;
- умение договариваться;
- управление конфликтами и компромиссами;
- фиксация договоренностей.
10. Принятие решений
- Сравнивать несколько вариантов решения.
- Описывать преимущества и недостатки каждого варианта.
- Принимать решения при неполной информации.
- Понимать компромиссы между скоростью, качеством, стоимостью и риском.
- Фиксировать важные решения в ADR.
- Объяснять, почему выбран именно этот вариант.
11. Управление рискамиАрхитектор должен заранее выявлять риски:
- зависимость от одного поставщика;
- низкая производительность;
- сложная миграция;
- недостаточная безопасность;
- отсутствие резервного сценария;
- высокая стоимость владения;
- нехватка компетенций в команде;
- сложность сопровождения;
- несогласованные изменения в интеграциях.
Важно не только найти риск, но и предложить способ его уменьшить: прототип, нагрузочное тестирование, резервный вариант, поэтапное внедрение или технический эксперимент.
12. ДокументированиеНеобходимый минимум:
- схема контекста;
- схема компонентов или контейнеров;
- карта интеграций;
- модель данных;
- описание ключевых сценариев;
- список нефункциональных требований;
- архитектурные решения и ограничения;
- план развертывания;
- план резервирования и восстановления;
- список рисков и допущений;
- дорожная карта перехода.
Документация должна быть понятной и актуальной. Большой документ сам по себе не является признаком хорошей архитектуры.
13. Личные качества
- Ответственность за последствия решений.
- Любознательность и готовность постоянно учиться.
- Умение работать с неопределенностью.
- Внимательность к деталям без потери общего видения.
- Умение признавать ошибки и менять решение при появлении новых данных.
- Способность сохранять баланс между идеальной и практически реализуемой архитектурой.
Архитектор ИТ-решений полезен компании тем, что помогает связать бизнес-цели с работающей и устойчивой ИТ-системой. Он заранее продумывает, как решение будет создано, интегрировано, защищено, масштабировано и поддерживаться.
Какие выгоды компания получает от ИТ-Архитектора и чем он полезен для компании:
- Экономит деньги в будущем. Помогает не выбирать избыточные технологии, избегать дублирования систем и дорогостоящих переделок.
- Снижает технические риски. Заранее выявляет слабые места: возможные сбои, проблемы с производительностью, безопасностью, интеграциями и данными.
- Ускоряет разработку. Команды получают понятный план, границы ответственности и правила взаимодействия.
- Делает сроки и стоимость предсказуемее. Архитектор оценивает сложность решения, зависимости, инфраструктуру и возможные дополнительные расходы.
- Обеспечивает масштабируемость. Система проектируется так, чтобы выдерживать рост пользователей, данных и нагрузки.
- Повышает надежность. Продумываются резервирование, восстановление после сбоев, мониторинг и действия при инцидентах.
- Укрепляет безопасность. Требования к доступам, защите данных, аудиту и соответствию законодательству учитываются до запуска, а не после проблем.
- Упрощает интеграции. Определяются API, форматы данных, правила обмена и ответственность систем.
- Сохраняет знания компании. Архитектурные решения фиксируются в документации, поэтому компания меньше зависит от отдельных сотрудников.
- Помогает развивать систему. Видно, как добавить новые функции, подключить партнеров или заменить отдельные компоненты.
- Создает единое понимание между участниками. Бизнес, разработка, безопасность, инфраструктура, поддержка и поставщики работают по общей модели.