Конспект

YouTubeОбновленный курс "Системный аналитик". Урок 12: Введение в архитектуру системы.

Архитектура информационных систем

Ключевые тезисы

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

🏗️ Что такое архитектура?

Архитектура — это модель, представляющая, как устроена и как работает информационная система. Чёткого единого определения нет, но в основе всегда лежит описание трёх аспектов:

  1. Структура (элементы): Из чего состоит система (фронтенд, бэкенд, база данных, сервисы).
  2. Поведение (бизнес-логика): Что система должна делать и как её элементы взаимодействуют между собой (логика работы, протоколы коммуникации).
  3. Среда (инфраструктура/ландшафт): Где и на чём работает система (железо, сети, операционные системы, языки программирования).

Цель архитектуры — зафиксировать все необходимые элементы и их взаимосвязи так, чтобы система эффективно удовлетворяла потребности, могла развиваться и изменяться с минимальными затратами.

📦 Составные элементы системы (Структура)

С точки зрения аналитика, ключевые элементы архитектуры, с которыми приходится работать:

  1. Frontend: Интерфейс для представления данных (веб, мобильное, десктоп-приложение).
  2. Backend: Серверная часть, обрабатывающая логику (языки, паттерны проектирования).
  3. База данных (БД): Место хранения данных (реляционные, нереляционные, колоночные и др.).
  4. API (Программные интерфейсы): Набор правил и протоколов для взаимодействия между элементами (синхронные, асинхронные, событийные).
  5. Бизнес-логика: "Мозги" системы — то, что она должна делать для бизнеса (часто не отображается в схемах явно).
  6. Инфраструктура: "Сердце и мышцы" — железо и базовые технологии, обеспечивающие работу (облака, контейнеры, сети). С этим блоком аналитик взаимодействует реже.

Пример
Выбор технологий для каждого элемента влияет на возможности системы. Например, для высоких нагрузок лучше подходит колоночная БД (ClickHouse), а для неструктурированных данных — документоориентированная (MongoDB).

📊 Свойства хорошей архитектуры

Эти свойства показывают, насколько архитектура соответствует нефункциональным требованиям.

Что важно для бизнеса и пользователей (видимые свойства):

  • Функциональная полнота: Система делает всё, что нужно.
  • Производительность: Система работает быстро.
  • Надёжность: Система работает стабильно, не падает.
  • Доступность: Система доступна пользователям, когда нужна.
  • Безопасность: Данные защищены от утечек и атак.

Что важно для разработки и будущего (скрытые свойства):

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

🔄 Взаимовлияние требований и архитектуры

  • Требования → Архитектура: Нефункциональные требования (производительность, безопасность) напрямую влияют на выбор паттернов (микросервисы/монолит) и технологий (Redis для кэша, Kafka для асинхронной очереди).
  • Архитектура → Требования: Существующая архитектура может как ограничивать новые возможности (сложно добавить A/B-тестирование в монолит), так и открывать их (готовый кэш Redis можно использовать для программы лояльности).

❓ Как аналитику оценить архитектуру?

Нужно задавать вопросы по пяти ключевым направлениям:

  1. Изменение требований: Насколько сложно и дорого будет внедрять что-то новое?
  2. Масштабирование: Что будет, если нагрузка на систему резко возрастёт?
  3. Надёжность: Что произойдёт, если сломается один из компонентов? Упадёт ли вся система?
  4. Параллельная разработка: Могут ли несколько команд работать над разным функционалом одновременно?
  5. Объяснимость: Могут ли технические специалисты понятно объяснить, как работает система? (Фраза "исторически сложилось" — тревожный сигнал).

🤝 Взаимодействие аналитика с архитектором

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

  1. Собрать бизнес- и пользовательские требования (что и для кого делаем).
  2. Собрать функциональные требования (что должна делать система).
  3. Собрать нефункциональные требования (как должна работать: производительность, безопасность и т.д.).
  4. Выявить ограничения (бюджет, сроки, стек технологий команды, регуляторные требования типа ФЗ-152).
  5. Понять видение развития (какие возможности могут понадобиться в будущем).

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

🛠️ Если архитектором стали вы (аналитик)

Краткий гайд для вынужденного проектирования архитектуры:

  1. Смиритесь с расширением зоны ответственности.
  2. Соберите три столпа: функциональные требования, нефункциональные требования, ограничения (сроки, бюджет, команда).
  3. Выберите паттерн: В сомнении выбирайте монолит (проще для маленьких команд и связанного функционала).
  4. Выберите стек технологий исходя из компетенций команды (не экспериментируйте), для БД в 90% случаев подойдёт PostgreSQL, для развёртывания — готовые облачные решения.
  5. Зафиксируйте решение простыми квадратиками и стрелочками.
  6. Проверьте архитектуру на минимальную достаточность и задайте себе вопросы из списка выше (про масштабируемость, надёжность).
  7. Проконсультируйтесь с опытными разработчиками (бэкенд, фулстек), чтобы убедиться в реализуемости и получить советы по оптимизации.

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