Что такое архитектура ИТ-решения и зачем она нужна: руководство для бизнеса и разработчиков

Коротко. Архитектура решения это набор решений, которые дорого менять потом: как система делится на части, как части разговаривают, где лежат данные и кто за них отвечает. Выбор стиля, монолит или микросервисы, вторичен и следует из ограничений: сколько у вас людей, как часто нужно выпускать изменения и что будет при отказе. Главная ошибка не в выборе стиля, а в том, что решения принимаются по ходу и нигде не записываются, поэтому через год никто не может объяснить, почему сделано так.

Рядом: архитектура AI-систем, своя разработка или готовое решение и чем консалтинг отличается от аутсорса.

Четыре слоя, на которые архитектуру принято делить

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

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

Термины простым языком

Короткий словарь, чтобы дальше читать без сносок.

• IT-стратегия. Ответ на вопрос, что мы будем делать с технологиями и почему именно это, увязанный с целями бизнеса. Не список закупок.
• Архитектура предприятия. Карта всего ландшафта: процессы, данные, приложения, инфраструктура и связи между ними. Нужна там, где систем много и они пересекаются.
• Монолит. Приложение, развёртываемое целиком. Начать проще всего, менять по частям нельзя.
• Микросервисы. Набор самостоятельных служб, каждая со своей ответственностью и своим выпуском. Гибкость покупается за счёт сложности эксплуатации.
• Событийная архитектура. Части обмениваются не вызовами, а сообщениями о произошедшем. Хороша для реакции в реальном времени, тяжела в отладке.
• Масштабируемость. Способность выдержать рост, добавляя ресурсы. Вертикально это увеличить машину, горизонтально это добавить машин; второе дешевле в пределе и дороже на старте.
• IaaS, PaaS, SaaS. Три степени готовности облачной услуги. В первой вы управляете операционной системой, во второй только своим кодом, в третьей просто пользуетесь готовым.
• Гибридное размещение. Часть систем у себя, часть в облаке. Обычный выбор там, где часть данных нельзя выносить наружу по закону или по договору.
• Стоимость владения. Не цена разработки, а сумма за срок жизни: лицензии, эксплуатация, поддержка, обучение и переделки. Решения, дешёвые на старте, часто дороги здесь.

Как выбирается стиль

Лучшего стиля нет, есть подходящий к ограничениям. Ниже то, что реально определяет выбор.

Частый рабочий ответ это сочетание: ядро монолитом, отдельные нагруженные части службами, обмен событиями там, где связанность мешает. Смешивать стили нормально; ненормально выбирать микросервисы потому, что так принято, не имея людей на их эксплуатацию.

Что на самом деле ломается

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

• Нет источника истины по данным. Один показатель считается в двух местах по-разному, и спор о том, чья цифра верна, съедает больше времени, чем любая техническая задача.
• Связанность через базу. Две системы пишут в одну таблицу, и изменение в одной ломает другую без всякого предупреждения, потому что договора между ними нет.
• Решения не записаны. Через год никто не помнит, почему выбрано так, и команда либо боится трогать, либо переделывает заново то, что уже обсуждали.
• Нефункциональные требования не заданы. Никто не сказал, сколько система должна выдерживать и как быстро восстанавливаться, поэтому проверить её невозможно, а узнать предел получится только в худший день.
• Нет пути отката. Выпуск можно поставить, но нельзя снять, и поэтому его боятся ставить.

Три вещи, которые стоит завести, даже если больше ничего

1. Записи об архитектурных решениях. Короткий документ на каждое серьёзное решение: что решили, какие были варианты, почему выбрали этот и при каких условиях решение надо пересмотреть. Занимает полстраницы и снимает половину будущих споров.
2. Схема из нескольких уровней детализации. Подход C4 удобен тем, что даёт отдельную картинку для разговора с заказчиком и отдельную для разработчика, вместо одной схемы, непонятной обоим.
3. Описание интерфейсов в машиночитаемом виде, например OpenAPI для веб-интерфейсов. Договор, который можно проверить автоматически, перестаёт расходиться с реальностью.

Как выбирается архитектура под конкретную организацию

Перед схемами идут вопросы, и их немного.

• Какая цель на ближайшие год-три и какое число должно измениться.
• Кто будет это эксплуатировать. Своя команда, подрядчик, или пока никто. Это ограничение решает больше, чем предпочтения в технологиях.
• Какие требования приходят извне: персональные данные, медицинские сведения, финансовые операции, отраслевые нормы. Они меняют не детали, а структуру.
• Что уже построено и что из этого стоит сохранить. Модернизация почти всегда дешевле замены, и почти всегда её недооценивают.
• Каким будет рост и в чём он измеряется: пользователи, объём данных, число стран, число языков.

Чем измерять, что архитектура хорошая

Не процентами из отчётов, а тем, что можно снять у себя.

• Время от готового изменения до его выхода в работу.
• Время восстановления после отказа и знает ли кто-нибудь порядок действий без подсказки.
• Доля выпусков, которые пришлось откатить, и была ли такая возможность.
• Сколько мест придётся тронуть для типового изменения. Растёт со временем это признак того, что границы размылись.
• Может ли новый человек объяснить систему по документам через неделю работы.

Как работаю я

Практика с 2004 года, работа с .NET и MS SQL с того же времени, с AI-системами с 2023 года, проекты для заказчиков в 14 странах. Я независимый архитектор и не получаю ничего от поставщиков за рекомендацию, поэтому вывод «оставить действующую платформу» для меня допустимый результат.

Работаю и со стартапами, которым нужна система, переживающая рост, и со средним бизнесом, модернизирующим унаследованное, и с регулируемыми отраслями, где ограничения приходят снаружи и архитектура следует из них. Формат прозрачный: почасово или фиксированным объёмом, на ваш выбор.

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