Информационная архитектура: как спроектировать структуру данных и систем

Информационная архитектура (Information Architecture, IA) — это дисциплина организации информации в сложных системах: какие данные существуют, как они связаны, как движутся между системами, как ими управляют. Это фундамент, на котором строятся приложения, аналитика и пользовательские интерфейсы.

Термин используется в двух контекстах: UX-IA (как организовать контент для удобства поиска — Розенфельд, Морвиль) и Enterprise IA (как спроектировать архитектуру данных и информационных систем организации). В этой статье разберём оба подхода — они тесно связаны.

О чём эта статья

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

• Что такое IA в обоих контекстах (UX и Enterprise) и чем они отличаются
• Принципы организации информации — от Розенфельда/Морвиля до современных подходов
• Моделирование данных — концептуальная, логическая, физическая модели
• Архитектура данных в Enterprise — мастер-данные, справочники, Data Governance
• Интеграция систем — как данные перемещаются между системами
• Методы исследования пользователей и требований (Card Sorting, Tree Testing)
• Типичные ошибки и как их избежать

Для кого статья: системные и бизнес-аналитики, data-архитекторы, UX-исследователи, product-менеджеры, разработчики баз данных, enterprise-архитекторы.

Источники: классические работы — Луис Розенфельд и Питер Морвиль («Information Architecture for the World Wide Web»), Hasso Plattner («Data Model Patterns»), David Hay («Enterprise Model Patterns»), DAMA DMBOK (Data Management Body of Knowledge), плюс практический опыт из реальных проектов.

Аналитика спроса: «информационная архитектура» — 3 419 показов/мес в Яндекс, «information architecture» — 253, «архитектура информационных систем» — связанный высокочастотный запрос.

Что такое информационная архитектура

Два мира IA

UX-информационная архитектура (классическая школа Розенфельда):

«Структурирование, организация и маркировка контента для поддержки поиска и управления информацией» — Луис Розенфельд, Питер Морвиль

Фокус: как пользователь находит информацию на сайте, в приложении, в библиотеке. Примеры: структура разделов Wikipedia, навигация в интернет-магазине, организация документации.

Enterprise-информационная архитектура:

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

Фокус: как организация управляет данными как активом. Примеры: модели данных ERP, справочники клиентов, data flow между CRM и аналитикой.

Сравнение подходов

В этой статье разберём оба подхода — они часто нужны вместе. UX-архитектор думает «какие категории видит пользователь», data-архитектор думает «откуда эти категории берутся в БД».

UX-информационная архитектура: организация контента

Четыре системы организации (Розенфельд/Морвиль)

В книге «Information Architecture for the World Wide Web» (1998, 4-е издание 2015) авторы выделяют четыре системы:

1. Организация (Organization Systems) — как группировать информацию.

2. Навигация (Navigation Systems) — как пользователь перемещается.

• Глобальная навигация — главное меню, доступное со всех страниц
• Локальная навигация — в пределах раздела (хлебные крошки, подменю)
• Контекстуальная навигация — ссылки внутри контента
• Дополнительная навигация — карта сайта, поиск, индекс

3. Поиск (Search Systems) — для случаев, когда навигация не помогает.

• Индексирование (что и как индексируем)
• Алгоритмы ранжирования (по релевантности, по дате, по популярности)
• Фасетный поиск (фильтры на странице результатов)
• Автодополнение и исправление опечаток

4. Маркировка (Labeling Systems) — как называть элементы.

• Точность: название отражает содержимое («Новости», а не «Раздел 1»)
• Последовательность: одинаковые правила для одинаковых вещей
• Контекстуальность: учёт языка и уровня подготовки пользователя

Принципы организации информации

Авторы выделяют 8 принципов, проверенных практикой:

1. Принцип объекта (Principle of Objects): контент должен быть организован как набор дискретных объектов с атрибутами, а не как «поток текста».
2. Принцип выбора (Principle of Choices): предоставляйте пользователю явный выбор (категории, фильтры), не заставляйте гадать.
3. Принцип раскрытия (Principle of Disclosure): показывайте информацию постепенно, по уровням детализации.
4. Принцип исключений (Principle of Exceptions): выделяйте необычные случаи из общего правила.
5. Принцип прогресса (Principle of Front Doors): учтите, что пользователи могут зайти на любую страницу (из поиска, по ссылке) — не только через главную.
6. Принцип множественной классификации (Principle of Multiple Classification): один объект может принадлежать нескольким категориям (фасеты).
7. Принцип фокусированного внимания (Principle of Focused Attention): меньше вариантов = меньше когнитивной нагрузки.
8. Принцип согласованности (Principle of Consistency): единый стиль и терминология на всех страницах.

Пример UX-IA: интернет-магазин

Плохая организация:

Главная
├── О нас
├── Каталог (всё в одной куче)
├── Акции
├── Помощь
└── Контакты

Хорошая организация (фасетная + иерархия):

Главная
├── Каталог
│   ├── По категориям
│   │   ├── Электроника → Смартфоны, Ноутбуки...
│   │   ├── Одежда → Мужская, Женская...
│   │   └── Дом и сад
│   ├── По бренду
│   ├── По цене
│   └── Новинки / Хиты / Распродажа
├── Бренды (A-Z)
├── Помощь
│   ├── Доставка и оплата
│   ├── Возврат
│   └── Часто задаваемые вопросы
├── О компании
└── Контакты

Ключевые решения:

• Каталог организован множественно: по категориям, по бренду, по цене, по новизне
• «Бренды» отдельно от «Каталога» — потому что у пользователя может быть конкретный запрос «iPhone 15»
• «Помощь» вынесена отдельно и не в одном меню с «О нас» (разные цели)

Методы UX-исследования для IA

Card Sorting (сортировка карточек)

Что это: дайте пользователям набор карточек с названиями (категории, фичи, разделы) и попросите сгруппировать их по своему усмотрению.

Открытая сортировка: пользователи сами создают категории → понимаете, как они мыслят.

Закрытая сортировка: категории заданы → понимаете, какие объекты куда класть.

Инструменты: OptimalSort, UXtweak, UserTesting, или карточки + ручка для офлайн-теста.

Когда применять:

• Проектирование новой IA с нуля
• Реструктуризация существующей IA
• Аудит текущей IA после жалоб пользователей

Типичный результат: дерево категорий, которое становится основой для sitemap.

Tree Testing (тестирование дерева)

Что это: дайте пользователям задачу («Найдите размерную сетку кроссовок») и только навигационную структуру (без визуального оформления). Смотрите, сколько людей находят правильный путь.

Что измеряете:

• Success rate — % людей, нашедших правильный ответ
• Directness — насколько прямой путь (меньше шагов = лучше)
• Time on task — сколько времени уходит

Инструменты: Treejack (Optimal Workshop), UXtweak.

Когда применять:

• После Card Sorting для проверки итоговой структуры
• Регулярно на существующем сайте для выявления проблемных мест

User Journey Mapping (карта пути пользователя)

Что это: визуализация типичного пути пользователя от первого контакта до цели.

Пример: путь «Купить кроссовки онлайн»:

1. Google: «лучшие кроссовки для бега»
2. → Главная страница магазина (через рекламу)
3. → Каталог → Обувь → Бег
4. → Фильтр по бренду и размеру
5. → Карточка товара
6. → Добавить в корзину
7. → Корзина → Оформление
8. → Выбор доставки
9. → Оплата
10. → Подтверждение

Зачем: понимаете, на каких шагах пользователь может «потеряться», и проектируете IA для снижения friction.

Enterprise-информационная архитектура: данные как актив

Что входит в Enterprise IA

1. Моделирование данных (Data Modeling)

Описание сущностей, их атрибутов и связей. Три уровня:

Концептуальная модель — что есть в бизнесе, без привязки к технологиям:

Клиент — делает — Заказы
Клиент — пишет — Отзывы
Заказ — содержит — Товары
Заказ — оплачивается — Платежи

Логическая модель — структура с типами данных, но без конкретной СУБД:

TABLE clients (
  id BIGINT PRIMARY KEY,
  name VARCHAR(200),
  email VARCHAR(200) UNIQUE,
  created_at TIMESTAMP
)

TABLE orders (
  id BIGINT PRIMARY KEY,
  client_id BIGINT REFERENCES clients(id),
  total DECIMAL(10,2),
  status VARCHAR(50),
  created_at TIMESTAMP
)

Физическая модель — конкретная реализация в выбранной СУБД:

CREATE TABLE orders_2026 PARTITION OF orders
FOR VALUES FROM ('2026-01-01') TO ('2027-01-01');

CREATE INDEX idx_orders_client_status 
ON orders (client_id, status) 
INCLUDE (total, created_at);

2. Мастер-данные (Master Data Management, MDM)

Единый «источник правды» для ключевых сущностей: клиенты, продукты, сотрудники, поставщики.

Проблема без MDM:

• CRM хранит клиента с адресом «Москва, ул. Ленина 5»
• ERP хранит «г. Москва, ул. Ленина, д. 5»
• Marketing хранит «Ленина 5, Москва»
• Аналитика считает их тремя разными клиентами

Решение MDM:

• Единый справочник «Клиент» с золотой записью (golden record)
• Все системы синхронизируются с мастер-справочником
• Алгоритмы дедупликации и матчинга

3. Data Governance (управление данными)

Политики, процессы и роли для управления данными:

4. Data Integration (интеграция данных)

Как данные перемещаются между системами:

Подходы к интеграции:

Архитектурные паттерны для данных

Data Warehouse (DWH)

Хранилище, оптимизированное для аналитических запросов. Схемы: звезда (star), снежинка (snowflake), data vault.

Когда применять: регулярная аналитика, BI-отчёты, исторические данные.

Технологии: ClickHouse, Greenplum, Snowflake, BigQuery, Redshift.

Data Lake

Хранилище сырых данных в исходном формате (JSON, Parquet, изображения).

Когда применять: ML/AI, исследовательский анализ, когда схема заранее неизвестна.

Технологии: S3, HDFS, MinIO + Spark/Hive.

Data Lakehouse

Гибрид Data Warehouse и Data Lake — аналитика + гибкость.

Технологии: Apache Iceberg, Delta Lake, Apache Hudi.

Data Mesh

Децентрализованная архитектура данных: каждая бизнес-домен владеет своими данными как продуктом.

Когда применять: крупные организации (1000+ сотрудников), федеративная структура, mature data-культура.

Концепция: вместо центральной команды данных — data domains под управлением domain-команд.

Принципы хорошей информационной архитектуры

1. Single Source of Truth (SSOT)

Каждая сущность имеет одного владельца и одно место хранения. Остальные системы получают данные от владельца.

Пример: справочник сотрудников — в HR-системе. Все остальные системы (CRM, ERP, Wiki) получают данные через API HR, не хранят свою копию.

2. Data Ownership

Каждый справочник имеет владельца (часто — бизнес-роль, не IT-роль).

Пример: справочник клиентов — владелец «Директор по продажам», справочник продуктов — «Директор по продукту», справочник сотрудников — «HR-директор».

Владелец отвечает за качество, актуальность, политики использования.

3. Стандартизация

Единые правила именования, форматов, классификации.

Примеры стандартов:

• Naming conventions: клиент пишется как customer (не client, не user, не klient)
• Единицы измерения: все суммы в рублях, все даты в ISO 8601
• Классификация стран: ISO 3166, классификация валют — ISO 4217
• Адреса: ФИАС (для РФ), Google Address Format API

4. Immutable Events (неизменяемые события)

Когда данные меняются — не перезаписывать, а создавать новое событие.

Пример: заказ не «изменяет статус с «создан» на «оплачен»», а получает новое событие «оплачен». История сохраняется.

Технологии: Event Sourcing (см. нашу статью о Event-Driven Architecture).

5. Мастер-данные отдельно от транзакционных

Мастер-данные (клиенты, продукты, сотрудники) — меняются редко, должны быть высокого качества.

Транзакционные данные (заказы, платежи, движения товаров) — создаются постоянно, объёмные.

Архитектурное правило: мастер-данные выносятся в отдельные системы (MDM), к ним обращаются все остальные.

Процесс проектирования IA

Шаг 1. Бизнес-цели

Прежде чем рисовать модели — поймите, что бизнес хочет от данных:

• Какие решения принимаются на основе данных?
• Какие отчёты нужны регулярно?
• Какие KPI отслеживаются?
• Какие регуляторные требования (GDPR, 152-ФЗ, PCI DSS)?

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

Шаг 2. Инвентаризация существующих данных

• Какие системы хранят данные?
• Какие сущности в каждой системе?
• Какие данные пересекаются между системами (дубли)?
• Какие потоки данных уже есть?

Артефакт: карта источников данных (data source map).

Шаг 3. Концептуальная модель

Описываем сущности бизнеса и связи между ними. Без привязки к системам.

Инструменты: draw.io, Lucidchart, ER-диаграммы в PlantUML.

Пример концептуальной модели для e-commerce:

Клиент (Customer)
  ├─ Контактные данные
  ├─ Адреса доставки
  └─ История заказов

Товар (Product)
  ├─ Название, описание
  ├─ Категория
  ├─ Цена
  └─ Наличие на складе

Заказ (Order)
  ├─ Клиент
  ├─ Список товаров
  ├─ Сумма
  └─ Статус (создан, оплачен, доставлен, возвращён)

Платёж (Payment)
  ├─ Заказ
  ├─ Способ оплаты
  └─ Статус

Доставка (Shipment)
  ├─ Заказ
  ├─ Адрес
  └─ Трек-номер

Шаг 4. Логическая модель

Превращаем концептуальную модель в таблицы с типами данных.

Инструменты: DBeaver, dbdiagram.io, ERwin, PowerDesigner, PlantUML.

Пример:

Customer (
  id: BIGINT PK,
  email: VARCHAR(200) UNIQUE,
  full_name: VARCHAR(300),
  phone: VARCHAR(50),
  created_at: TIMESTAMP,
  updated_at: TIMESTAMP
)

CustomerAddress (
  id: BIGINT PK,
  customer_id: BIGINT FK → Customer,
  address_line: VARCHAR(500),
  city: VARCHAR(100),
  postal_code: VARCHAR(20),
  country_code: CHAR(3) FK → Country,
  is_default: BOOLEAN
)

Product (
  id: BIGINT PK,
  sku: VARCHAR(50) UNIQUE,
  name: VARCHAR(300),
  category_id: BIGINT FK → Category,
  price: DECIMAL(10,2),
  stock_quantity: INT,
  is_active: BOOLEAN
)

Order (
  id: BIGINT PK,
  customer_id: BIGINT FK → Customer,
  status: ENUM('created','paid','shipped','delivered','cancelled'),
  total: DECIMAL(12,2),
  created_at: TIMESTAMP,
  paid_at: TIMESTAMP NULLABLE
)

OrderItem (
  id: BIGINT PK,
  order_id: BIGINT FK → Order,
  product_id: BIGINT FK → Product,
  quantity: INT,
  unit_price: DECIMAL(10,2)
)

Шаг 5. Физическая модель

Адаптация под конкретную СУБД:

• Типы данных с учётом диапазонов
• Индексы под основные запросы
• Партиционирование больших таблиц
• Денормализация для производительности
• Шардирование при горизонтальном масштабировании

Подробнее о шардировании и индексах — в статье «System Design».

Шаг 6. Валидация с пользователями

Прежде чем заливать модель в БД — проверьте её с реальными пользователями (аналитиками, разработчиками, продуктовой командой):

• Все ли сущности и связи учтены?
• Нет ли дублирования?
• Покрывает ли модель основные запросы?

Инструменты для информационной архитектуры

UX-IA

Enterprise-IA / Data Modeling

Типичные ошибки информационной архитектуры

1. Модель «с потолка»

Архитектор рисует модель данных исходя из своих представлений о бизнесе, не проверяя с реальными пользователями. Результат: модель «правильная», но не отвечает на вопросы бизнеса.

Решение: интервью с владельцами данных, валидация модели с аналитиками.

2. Преждевременная денормализация

Денормализация «для производительности» до того, как измерены реальные запросы. Результат: данные разъехались, обновление в 10 местах.

Решение: нормализация сначала, денормализация — на основе профилирования реальных запросов.

3. God Entity (сущность-бог)

Одна таблица object с 50 полями разных типов (товары, клиенты, заказы — всё в одной). Результат: невозможно нормально индексировать, рост NULL-полей.

Решение: чёткое разграничение сущностей. Если нужно «что-то общее» — наследование или отдельные таблицы с FK.

4. Игнорирование истории

Данные меняются, но хранится только текущее состояние. «Клиент раньше жил в Москве, а сейчас в Питере» — невозможно восстановить.

Решение: SCD (Slowly Changing Dimensions) — типы 2 (полная история), 3 (текущее + предыдущее), 6 (комбинация).

5. PII без защиты

Персональные данные (ФИО, email, телефон, паспорт) хранятся как обычные поля, без шифрования, без маскирования в логах.

Решение: PII-каталог, шифрование at rest и in transit, маскирование в логах, регулярные аудиты.

6. Нет владельца данных

Справочник клиентов «общий», никто конкретно не отвечает за его качество. Через год — 30% дублей, 50% устаревших контактов.

Решение: назначить data owner для каждого справочника (бизнес-роль, не IT).

7. ER-диаграммы, которые никто не обновляет

Красивая модель в Visio, но реальная БД уже совсем другая. Документация вводит в заблуждение.

Решение: документация как код — генерировать из реальной БД автоматически.

Ресурсы для углублённого изучения

Книги по UX-IA:

• «Information Architecture for the World Wide Web» Луис Розенфельд, Питер Морвиль — библия UX-IA
• «Don't Make Me Think» Стив Круг — UX-дизайн и навигация
• «The Elements of User Experience» Джесси Гарретт — общая картина UX
• «Universal Principles of Design» Уильям Лидвелл — паттерны проектирования

Книги по Data Modeling / Enterprise IA:

• «Data Model Patterns» Hasso Plattner — каталог моделей для разных отраслей
• «Enterprise Model Patterns» David Hay — полный каталог корпоративных моделей
• «DAMA DMBOK» (Data Management Association) — стандарт управления данными
• «Designing Data-Intensive Applications» Мартин Клеппман — современные подходы

Стандарты:

• ISO/IEC 11179 — стандарт метаданных
• ISO 8000 — качество данных
• GDPR / 152-ФЗ — защита персональных данных

Инструменты:

• Card Sorting: OptimalSort, UXtweak
• Tree Testing: Treejack
• Моделирование: dbdiagram.io, PlantUML, Mermaid
• Data Governance: Collibra, Alation (enterprise), OpenMetadata (open source)

Заключение

Информационная архитектура — это фундамент, на котором стоит всё остальное. Плохая IA убивает UX (пользователь не находит), аналитику (BI-система не может посчитать), разработку (каждое изменение ломает три системы) и регуляторику (PII в открытом доступе).

Принципы эффективной IA:

1. Начинайте с бизнес-целей. Модель данных без понимания, кто и как её использует — бесполезна.
2. Single Source of Truth для ключевых сущностей. Один мастер-справочник, остальные системы получают данные от него.
3. Data Ownership. У каждого справочника есть владелец, который отвечает за качество.
4. Нормализация сначала, денормализация по необходимости. Не оптимизируйте то, что не измерено.
5. Документация как код. Генерируйте ER-диаграммы из реальной БД.
6. UX-IA и Enterprise IA — две стороны одной медали. Пользователь не найдёт то, чего нет в данных.
7. Защищайте PII с первого дня. GDPR/152-ФЗ накладывают серьёзные требования.

С чего начать прямо сейчас:

• Если UX-проект: проведите Card Sorting с 5–10 пользователями
• Если Enterprise-проект: нарисуйте концептуальную модель ключевых сущностей на 1 странице
• В обоих случаях: назначьте data owner для топ-5 справочников

Что дальше

Связанные статьи на сайте:

• System Design: проектирование систем — как проектировать системы с учётом данных
• C4 Model: документируем архитектуру — как описывать архитектуру на разных уровнях
• Архитектурные концепции — паттерны для архитектуры данных
• Анализ требований к системе — как собирать требования для IA
• Use Cases по Коберну — как описывать функциональные требования
• Enterprise Architecture — место IA в общей архитектуре предприятия
• Event-Driven Architecture — событийная интеграция данных
• Кэширование: паттерны и стратегии — как ускорять работу с данными