Архитектура информационной системы (ИС) — фундаментальная организация системы, воплощённая в её компонентах, их связях друг с другом и с окружением, а также принципы, определяющие её проектирование и развитие (ISO/IEC/IEEE 42010:2022). Для системного аналитика эта тема отвечает на вопрос: как связать бизнес-цели, прикладную структуру решения и инфраструктуру так, чтобы требования не «рассыпались» по уровням. На проекте вы чаще всего работаете с архитектурой конкретного решения в границах scope, а не с корпоративным ландшафтом всего предприятия — но логика трёх уровней одинакова.

1. Суть темы

В практике анализа и проектирования выделяют три взаимосвязанных уровня:

  • Бизнес-архитектура (Business Architecture) — зачем и как организация создаёт ценность.
  • Системная архитектура (System / Application / Solution Architecture) — что делает ИС и из каких прикладных компонентов состоит.
  • Техническая архитектура (Technical / Infrastructure Architecture) — на чём система работает и как обеспечиваются нефункциональные характеристики.

Термины в индустрии не унифицированы: в TOGAF «application architecture» соответствует прикладному уровню, в Zachman — колонке «System», в вакансиях «solution architect» и «system architect» часто описывают один и тот же слой. В этой базе под архитектурой ИС понимается описание конкретной системы или решения; корпоративная архитектура (Enterprise Architecture, EA) охватывает ландшафт приложений и технологий организации целиком. Границы вашего проекта задаёт 02.01.04 Определение границ решения (Scope Modelling).

Стандарт ISO/IEC/IEEE 42010 задаёт не только определение, но и каркас описания архитектуры (architecture description, AD): заинтересованные стороны (stakeholders), их проблемы и интересы (concerns), точки зрения (viewpoints), представления (views) и соответствия между представлениями (correspondences) — правила согласованности фрагментов AD для разных аудиторий. Одна и та же система описывается по-разному для заказчика, разработчика и эксплуатации; correspondences связывают, например, компонент в SRS с узлом на deployment diagram. Детали viewpoints, correspondences и нотаций — в 06.03.04 Взаимосвязи и точки зрения (Viewpoints).

flowchart TD
    BA["Бизнес-архитектура\n(Цели, процессы, KPI)"] --> SA["Системная архитектура\n(Приложения, данные, API)"]
    SA --> TA["Техническая архитектура\n(Серверы, сети, middleware)"]
    TA -.-> SA
    SA -.-> BA

Рис. Поток решений сверху вниз и обратная связь снизу вверх: технические ограничения влияют на прикладной дизайн, изменения приложений — на достижимость бизнес-целей.

Архитектура и детальное проектирование

Архитектурное решение меняет структуру, границы или принципы системы и дорого откатывается: выбор декомпозиции (монолит vs сервисы), стиля интеграции (синхрон vs события), владения данными компонентом, уровня абстракции C4 (context / container). Такие решения фиксируйте в ADR (10.01.13 Шаблон архитектурного решения (ADR)).

Детальное проектирование уточняет уже принятую структуру: поля API, алгоритмы, экранные формы, SQL-схемы, sequence для одного сценария. Это зона 03.02.01 Диаграмма прецедентов (Use Case Diagram), 03.02.03 Диаграмма последовательности (Sequence Diagram), 03.03.02 Логическая и физическая модель данных — не дублируйте их на уровне «архитектуры».

Практический критерий для SA: если изменение затрагивает состав компонентов, контракты между ними или трассировку к требованию — это архитектура; если только реализацию внутри компонента — детальный дизайн. C4 Container Diagram и context diagram — архитектура; Component Diagram с классами и методами — обычно уже детализация для разработки.

2. Ключевые понятия

Бизнес-архитектура

Описывает бизнес-модель, цели, KPI (02.01.02 Цели, KPI и критерии успеха (SMART, GQM)), процессы, продукты и организационные роли. На этом уровне фиксируются бизнес-требования (02.03.01 Классификация требований (БТ, ФТ, НФТ)), которые затем детализируются на системном и техническом уровнях. Типовые нотации: BPMN (03.04.01 BPMN 2.0 - введение и основы), цепочки создания ценности (03.04.04 Цепочка создания ценности (VAD) и EPC), мотивационный (06.03.01 Мотивационный слой) и бизнес-слои ArchiMate (06.03.02 Бизнес-слой). Глубокое моделирование capability map и value stream — зона бизнес-архитектора и BA; системному аналитику достаточно понимать связь «цель → процесс → информационная потребность».

graph TD
    Strategy["Стратегия и видение"] --> BA["Бизнес-архитектура"]
    BA --> BP["Бизнес-процессы (VAD, EPC, BPMN)"]
    BA --> Goals["Цели и KPI"]
    BP --> Info["Информационные потоки → системный уровень"]

Стрелка от процессов к информационным потокам показывает переход к системной архитектуре: какие данные нужны процессу и какие системы их обеспечивают.

Системная архитектура

Определяет логическую структуру ИС: подсистемы, модули, сервисы, потоки данных, интерфейсы. Это основной уровень работы системного аналитика. Ключевые аспекты:

Нотации: UML (компоненты, развёртывание), ArchiMate прикладной слой (06.03.03 Прикладной и технологический слои), 06.03.05 C4-модель как альтернатива для описания контейнеров и компонентов. Современные паттерны — модульные и компонуемые архитектуры, микросервисы, event-driven — см. 03.06.01 Архитектурные паттерны распределённых систем и 03.05.06 Event-Driven Architecture.

Кто за какой слой AD отвечает на вашем проекте — см. 00.01 Кто такой аналитик (роли BA, SA, FA) и 00.02 Бизнес-анализ vs Системный анализ vs Требования; в таблице ниже — типичное распределение артефактов и concerns, а не дублирование ролевой модели.

Техническая архитектура

Физическая реализация: серверы, сети, ОС, контейнеры, middleware, зоны безопасности, резервирование. Обеспечивает нефункциональные требования (НФТ) (08.02 Нефункциональные требования (НФТ) — классификация и стандарты): производительность, доступность, масштабируемость. Безопасность и приватность — сквозной concern всех уровней, не только НФТ в TA; см. 08.07 Основы кибербезопасности для системного аналитика. Моделируется диаграммами развёртывания UML, технологическим слоем ArchiMate, схемами инфраструктуры (07.08 Контейнеризация и оркестрация (Docker, Kubernetes) — на уровне понимания, не проектирования).

Сравнительная таблица

ХарактеристикаБизнес-архитектураСистемная архитектураТехническая архитектура
Основной вопросЗачем? Какие процессы?Что делает система? Из чего состоит?На чём работает? Как обеспечены НФТ?
Ключевые элементыЦели, оргструктура, процессы, продуктыМодули, сервисы, БД, API, контракты интеграцииСерверы, сети, ОС, middleware, контейнеры
Типичные артефактыБизнес-модель, карта способностей, VADДиаграмма компонентов, ER-модель, OpenAPIДиаграмма развёртывания, сетевая схема
Стандарты и нотацииBPMN, ArchiMate (мотивац. и бизнес-слои), VADUML, ArchiMate (прикладной), C4, ERDUML (развёртывание), ArchiMate (технологический)
Типичные concerns аудиторииЦенность, процессы, KPIФункции, границы, интеграция, данныеПроизводительность, отказоустойчивость, размещение

3. Как применяется в работе аналитика

Порядок работы в блоке системной архитектуры

На проекте системную архитектуру обычно выстраивают по цепочке — каждый шаг детализируется в соседней статье раздела 03.01:

  1. Контекст — кто и что взаимодействует с системой, границы scope → 03.01.02 Моделирование контекста системы (Context Diagram).
  2. Декомпозиция — из каких подсистем и модулей состоит решение → 03.01.03 Декомпозиция системы на подсистемы и модули.
  3. Интерфейсы — контракты между компонентами и внешними системами → 03.01.04 Интерфейсы и интеграционные взаимодействия.

Поведение и данные уточняют уже принятую структуру в 03.02.01 Диаграмма прецедентов (Use Case Diagram) и 03.03.01 ER-диаграммы (сущность-связь) — не подменяйте ими шаги 1–3.

Сквозной пример: интернет-магазин

Один бизнес-требование через три уровня:

УровеньЭлементСвязь с требованием
БизнесЦель: +20% онлайн-продаж за год; KPI: конверсия, средний чекБизнес-требование BT-001
СистемныйПодсистемы: каталог, корзина, оплата; интеграция с платёжным шлюзом (03.05.03 Спецификации контрактов (OpenAPI, AsyncAPI, Protobuf)) и службой доставки (03.05.04 Асинхронное взаимодействие (очереди, Kafka, Events))ФТ: «Клиент оплачивает заказ картой за ≤ 3 шага» → компонент «Оплата»
ТехническийКластер PostgreSQL, балансировщик, Redis-кэш сессий; NFR: отклик API ≤ 200 мс при 1000 RPSНФТ из 08.02 Нефункциональные требования (НФТ) — классификация и стандарты → выбор инфраструктуры

Такая нить — основа 02.03.04 Трассировка требований (концепция); оформляйте её в 10.01.15 Шаблон матрицы трассировки: от BT через компонент до инфраструктурного объекта. Реализуемость NFR «200 мс / 1000 RPS» проверяет технический архитектор или инфраструктурная команда; если оценка не сходится — SA эскалирует на системный уровень (упрощение интеграций, кэш, декомпозиция) или на бизнес-уровень (пересмотр KPI).

Что фиксировать в артефактах

Архитектура — инструмент, а не самоцель. На проекте аналитик:

  1. Связывает уровни в документации — бизнес-раздел в BRD/Vision, системный — в SRS/FRD, технические ограничения — в NFR и ADR (04.01 Форматы документов (Vision&Scope, BRD, SRS, FRD)).
  2. Фиксирует архитектурные решения — 10.01.13 Шаблон архитектурного решения (ADR) для выбора между альтернативами (монолит vs микросервисы, синхрон vs async).
  3. Строит представления под аудиторию — context diagram для заинтересованных сторон, component/container diagram для разработки (viewpoints по 42010).
  4. Учитывает обратную связь — если инфраструктура не тянет NFR, эскалирует на системный уровень; если компонент не закрывает процесс — на бизнес-уровень.

Изменения архитектурных решений проходят через управление изменениями (02.05.02 Управление изменениями (Change Control Board)) и 02.05.05 Жизненный цикл требования.

Перспектива: ИИ как архитектурный компонент

ML-модели и LLM всё чаще становятся прикладными компонентами: пайплайны данных, inference-сервисы, RAG-контуры. Это не меняет логику трёх уровней, но добавляет concerns по данным, latency и governance. Детали — в 11.04 Архитектуры использования LLM в корпоративном контуре; здесь достаточно учитывать ИИ-компонент при декомпозиции системной архитектуры.

4. Типовые ошибки и ограничения

  • Смешение уровней — описывать серверы в BRD или KPI в диаграмме компонентов. Критерий: каждый фрагмент AD адресует concerns конкретной аудитории.
  • Путаница EA и solution scope — проектировать «архитектуру всей компании», когда scope — один сервис. Уточняйте границы до моделирования.
  • Подмена системной архитектуры стеком технологий — в AD перечисляют «REST + Kafka + PostgreSQL» вместо компонентов, контрактов и трассировки к требованиям; протоколы и спецификации детализируйте в 03.05.02 Синхронные протоколы (REST, gRPC, GraphQL) и 03.05.04 Асинхронное взаимодействие (очереди, Kafka, Events), на уровне SA — кто с кем и зачем.
  • Неявные контракты на стыках — интеграция между компонентами и внешними системами не описана: нет границ ответственности, форматов обмена, сценариев отказа. Риски на стыках растут без явного AD интерфейсов (03.01.04 Интерфейсы и интеграционные взаимодействия, 08.05 Управление рисками на этапе анализа).
  • Уход в детальный дизайн под видом архитектуры — sequence для каждого метода, ER с индексами и типами колонок до утверждения декомпозиции. Сначала context → containers → контракты; детали — после ADR.
  • Размытые границы ответственности — SA фиксирует системный уровень и эскалирует НФТ инфраструктурщикам, но не подменяет их sizing и топологию сети.

Связи с другими разделами базы

Источники и дополнительные материалы

Стандарты и официальные документы

  • ISO/IEC/IEEE 42010:2022 — Systems and software engineering — Architecture description. Каркас AD: stakeholders, concerns, viewpoints, views, correspondences. IEEE
  • The Open Group. TOGAF Standard, 10th Edition. — Фреймворк EA: бизнес-, прикладная и технологическая архитектура. The Open Group
  • The Open Group. ArchiMate 3.2 Specification. — Язык моделирования архитектуры предприятия. ArchiMate overview
  • The Open Group. BIZBOK Guide. — Обзор дисциплины бизнес-архитектуры. BIZBOK
  • SEBoK (Guide to the Systems Engineering Body of Knowledge), v2.14. — Системная инженерия и архитектура. SEBoK wiki
  • IIBA. BABOK Guide v3. — Связь стратегического анализа и проектирования решений. BABOK

Книги

  • Marc Lankhorst et al. Enterprise Architecture at Work: Modelling, Communication and Analysis. Springer, 4th ed. 2017. — ArchiMate и архитектурное моделирование.
  • Nick Rozanski, Eoin Woods. Software Systems Architecture: Working with Stakeholders Using Viewpoints and Perspectives. Addison-Wesley, 2nd ed. 2011. — Viewpoints для системной и технической архитектуры.