Архитектура информационных систем
Ключевые тезисы
- Архитектура — это модель, описывающая, из чего состоит система, как её элементы взаимодействуют и на какой среде она работает.
- Основные блоки архитектуры: структура (элементы), поведение (бизнес-логика и взаимодействие) и среда (инфраструктура).
- Архитектура тесно связана с нефункциональными требованиями (производительность, безопасность, масштабируемость и т.д.).
- Требования влияют на архитектуру, а архитектура накладывает ограничения и открывает возможности для реализации требований.
- Аналитик должен уметь оценивать архитектуру, задавая вопросы об изменениях, масштабировании, надёжности, параллельной разработке и объяснимости.
- Взаимодействие с архитектором строится на передаче собранных бизнес-требований, функциональных и нефункциональных требований, ограничений и видения развития системы.
Что такое архитектура?
Архитектура информационной системы — это модель, описывающая три ключевых аспекта:
- Структура (элементы): Из чего состоит система (фронтенд, бэкенд, база данных, сервисы).
- Поведение (бизнес-логика): Что система должна делать и как её элементы взаимодействуют между собой (логика работы, протоколы коммуникации).
- Среда (инфраструктура/ландшафт): Где и на чём работает система (железо, сети, ОС, языки программирования, среды выполнения).
Цель архитектуры — зафиксировать эти элементы и их взаимосвязи для эффективного удовлетворения потребностей, поддержки и развития системы с учётом неизбежных изменений.
Составные элементы архитектуры (с точки зрения аналитика)
- Frontend: Представление данных (веб, мобильное, десктоп-приложение).
- Backend: Обработка данных и бизнес-логика (сервер, паттерны проектирования, языки).
- База данных (БД): Хранение данных (реляционные, нереляционные, колоночные и др.).
- API (интерфейсы): Набор правил и протоколов для взаимодействия между компонентами (синхронные, асинхронные, событийные).
- Бизнес-логика: "Мозги" системы — то, зачем и что должно получиться в итоге.
- Инфраструктура: "Сердце и мышцы" — железо и базовые технологии, обеспечивающие работу.
Пример: Шикарный алгоритм, запущенный на древнем "Пентиуме", будет работать неприемлемо медленно.
Свойства (качества) архитектуры
Свойства, важные для бизнеса и пользователей:
- Функциональная полнота: Система делает всё, что нужно.
- Производительность: Система работает быстро.
- Надёжность: Система работает стабильно, не падает.
- Доступность: Система доступна пользователям, когда нужна.
- Безопасность: Данные защищены от утечек и несанкционированного доступа.
Свойства, важные для разработки и аналитиков:
- Масштабируемость: Систему можно наращивать под увеличивающуюся нагрузку (пользователи, данные).
- Поддерживаемость: В систему можно относительно легко вносить изменения и добавлять новый функционал.
- Простота: Архитектура не избыточно сложна для решаемых задач.
- Стоимость владения: Затраты (время, деньги, труд) на поддержку и развитие системы.
- Соответствие требованиям: Выполнены все функциональные и нефункциональные требования.
Эти свойства напрямую связаны с нефункциональными требованиями к системе.
Взаимовлияние требований и архитектуры
Требования → Архитектура: Нефункциональные требования (производительность, безопасность) и функциональные требования определяют выбор паттернов (микросервисы, монолит), технологий и структур кода.
Пример: Требование к обработке данных в реальном времени может повлиять на выбор базы данных (например, Redis) или необходимость использования асинхронного брокера сообщений.
Архитектура → Требования: Существующая архитектура накладывает ограничения на то, что можно реализовать, но также может открывать новые возможности.
- Ограничение: Монолит сложно адаптировать для A/B-тестирования; реляционная БД неудобна для хранения неструктурированных JSON.
- Возможность: Наличие кэша (Redis) позволяет быстро показывать данные о лояльности клиента; событийная шина (Kafka) упрощает создание отчётности.
Как аналитику оценить архитектуру?
Задавайте вопросы по пяти ключевым направлениям:
- Изменение требований: Насколько сложно/дорого будет внедрять новые фичи или продукты?
- Масштабирование: Что будет, если нагрузка на систему резко возрастёт? Можно ли просто "докрутить" мощности?
- Надёжность: Что произойдёт, если сломается один из компонентов? Упадёт ли вся система?
- Параллельная разработка: Могут ли несколько команд работать над разным функционалом одновременно, не мешая друг другу?
- Объяснимость: Могут ли технические специалисты внятно объяснить, как работает система, или всё держится на "исторически сложилось"?
Взаимодействие аналитика с архитектором
Алгоритм подготовки:
- Собрать бизнес- и пользовательские требования (что за система, зачем).
- Собрать функциональные требования (что должна делать система).
- Собрать нефункциональные требования (как должна делать: производительность, безопасность и т.д.).
- Выявить ограничения (бюджет, сроки, стек технологий, компетенции команды, регуляторные нормы).
- Сформировать видение развития системы (планы на будущее, чтобы заложить возможности для роста).
Передача и обсуждение: Аналитик передаёт собранную информацию архитектору. Важно участвовать в обсуждении архитектурных решений, так как они влияют на задачи аналитика. Аналитик выступает связующим звеном, переводя требования бизнеса и предлагая компромиссы между желаемым и технически возможным. Решения нужно фиксировать.
Если архитектором стали вы (аналитик)
- Смиритесь с многозадачностью.
- Соберите три столпа: функциональные требования, нефункциональные требования, ограничения.
- Выберите паттерн: В сомнении выбирайте монолит (проще для небольших систем, потом легче разделить на микросервисы, чем наоборот).
- Выберите стек технологий исходя из компетенций команды:
- Бэкенд/Фронтенд: Используйте то, что знает команда (например, Django со встроенными шаблонами, если нет отдельного фронтенд-разработчика).
- База данных: В 90% случаев подойдёт реляционная БД (например, PostgreSQL).
- Инфраструктура: Используйте готовые облачные решения для развёртывания.
- Зафиксируйте архитектуру (хотя бы квадратиками и стрелочками).
- Проверьте архитектуру на минимальную достаточность и задайте себе ключевые вопросы (см. выше).
- Проконсультируйтесь с самым опытным разработчиком в команде, чтобы убедиться в реализуемости и получить советы по оптимизации.
Выводы
Архитектура — это фундамент ИТ-системы, определяющий её возможности, ограничения и стоимость развития. Понимание основ архитектуры позволяет аналитику не только грамотно формулировать требования, но и конструктивно взаимодействовать с архитекторами и разработчиками, оценивать предлагаемые решения и вносить свой вклад в создание эффективных и поддерживаемых систем.