Роскошный архитектурный минимум для аналитика: понимать систему в целом и не бояться «богов»-архитекторов
Я — системный аналитик. В моей жизни так повелось: чего боюсь, в то и попадаю. В начале своего пути столкнулась с проектом, где работали «настоящие» архитекторы решений. Глядя на них, я думала: «Они боги! Знают и понимают так много… ВАУ!». Они одновременно и привлекали, и пугали. С ними было легко, потому что они внушали доверие: нет нерешаемых задач, нужно просто подумать. И в то же время объёмно — от глубины их знаний захватывало дух.
Недавно мне раскрыли тайну: архитектор — это не тот, кто знает всё, а тот, кому доверяют построить систему для решения бизнес-задачи. И я поняла, что в начале пути меня привлекали их спокойствие и уверенность. А всё остальное — опыт, знание технологий — это hard skills, которые можно наработать для решения этой задачи.
В статье хочу осветить границу между анализом и архитектурой и показать, каким минимальным набором знаний в этой области должен обладать аналитик, чтобы не просто передавать требования, а активно влиять на качество конечного продукта.
Кто такой архитектор и почему это не всегда должность?
Прежде всего, стоит понять: «архитектор» — это роль, а (не всегда) запись в трудовой книжке. Если в вашей команде нет выделенного человека на этой должности, это не значит, что его у вас нет, как и архитектуры. Обязательно есть тот, кто понимает картину в целом и чувствует ответственность за техническое решение.
Отсутствие формальной роли ≠ отсутствие архитектуры.
Наличие архитектуры можно заметить по нескольким признакам:
Есть четкое понимание общих принципов и направлений развития проекта. Все участники команды видят, куда идет проект, и какое направление выбрано для развития функционала и инфраструктуры.
Различные элементы системы построены по единому стилю и стандартам. Есть единообразие в именовании сущностей, структуре каталогов, выборе библиотек и паттернов проектирования.
Решения принимаются осознанно и последовательно, основываясь на критериях устойчивости, производительности, масштабируемости и поддержки. Даже если формально решения принимает ведущий разработчик или менеджер проекта, именно эта последовательность и обоснованность свидетельствуют о наличии архитектуры.
Наличие базовых документов или артефактов, отражающих выбранную архитектуру: схема потоков данных, описания компонентов, принципы интеграции, документированные требовани�� к нефункциональным характеристикам (производительности, безопасности и др.).
Принятые стандарты качества и практики контроля качества существуют: unit-тесты, code review, continuous integration и deployment. Эти механизмы направлены на поддержание высокого уровня качества и управляемости системы.
Система демонстрирует стабильность и предсказуемость при внесении изменений. Новые функции интегрируются плавно, не вызывая каскадных последствий и нарушений работоспособности существующих элементов.
Используются проверенные и адекватные проекту технологии, которые соответствуют масштабу и задачам системы. Нет случайных экспериментов с технологиями или необдуманных решений.
Если какая-то часть из этих признаков есть, значит, что архитектура всё-таки присутствует, даже при отсутствия официальной позиции архитектора. Ведь часто бывает, что обязанности архитектора берут на себя опытные разработчики, тим-лиды или менеджеры проектов, обладающие необходимыми компетенциями и видением общего направления развития проекта.
Системный аналитик также может брать на себя обязанности архитектора: много коммуникаций, ответственности и необходимости видеть картину целиком. Чаще всего это солюшен архитектор или архитектура решений. Архитектура решений направлена на построение конкретного решения для конкретной задачи или проекта: помогает найти варианты реализации бизнес-идеи с помощью IT-систем, выбрать технологии, спроектировать интеграции. Это работа на стыке бизнеса и технологий, где soft skills и умение принимать решения на основе множества требований и рисков часто важнее, чем глубокий бэкграунд в разработке. Разработка корпоративных приложений, выбор подходящей CRM-системы, автоматизация бизнес-процессов, облачная миграция. интеграция систем — это всё к архитектора решений.
Системный аналитик и архитектор решений — две важные роли в ИТ-проектах, каждая из которых решает специфический круг задач, хотя они тесно переплетаются в процессе разработки сложных систем.
Некоторое сравнение позиций даю ниже, но стоит учесть что все очень субъективно и зависит от предметной области, компании и проекта:
Системный аналитик | Архитектор решений и иные вариации |
Область ответственности | |
Фокусируется преимущественно на анализе потребностей бизнеса, преобразовании этих потребностей в функциональные и нефункциональные требования, управлении изменениями и взаимодействии с бизнесом и командами разработчиков. Основная цель — чёткое формулирование задач для разработчиков и обеспечение согласованности результатов с ожиданиями бизнеса. | Ответственен за разработку технического решения, которое обеспечит выполнение сформулированных требований и оптимальное функционирование системы. Включает в себя выбор технологических платформ, инструментов, подходов к интеграции, управление техническими рисками и контроль качества технических решений. |
Типичные задачи | |
Сбор и анализ требований от бизнеса. Формулировка функциональных и нефункциональных требований. Создание документации и моделей системы (UML-диаграммы, flowcharts, use cases). Координация взаимодействия между заказчиком и технической командой. Управление изменениями и разрешение конфликтов требований. | Проектирование архитектуры системы. Выбор оптимальных технологий и платформ. Определение стандартов разработки и принципов построения решений. Анализ альтернативных вариантов решений и принятие обоснованного выбора. Оценка риска изменений и создание рекомендаций по снижению потенциальных проблем. |
Методы и подходы | |
Применяет методы анализа, интервьюирования пользователей, моделирования процессов, составления прототипов и тестирования. Часто работает в тесной координации с бизнес-аналитиками и пользователями. | Занимается созданием концептов архитектуры, разработкой диаграмм и схем системы, выбором инструментов и технологий, проведением оценки производительности и эффективности решений. Важно также умение оценивать влияние различных факторов на устойчивость и гибкость системы. |
Технические навыки | |
Необходимы хорошие навыки владения методологиями сбора и анализа требований, понимание особенностей бизнес-процессов, способность грамотно составлять документацию и общаться с разными участниками проекта. | Требует глубокого понимания технологий, включая языки программирования, базы данных, сетевые протоколы, облачные сервисы и инструменты DevOps. Умение анализировать производительность и управлять техническим долгом тоже входит в перечень необходимых компетенций. |
Итоговая цель | |
Гарантирует точное понимание бизнес-потребностей и правильное отражение их в проекте. | Обеспечивает эффективное и устойчивое техническое исполнение этих требований, выбирая наилучшие технологические решения |
Таким образом, обе роли дополняют друг друга, обеспечивая полное покрытие цикла разработки сложной информационной системы. Системный аналитик отвечает за правильную постановку задачи, а архитектор решений реализует её наиболее эффективным способом.
Примечание. Стоит отметить, что архитектор это все таки более технический специалист, который понимает некоторые пласты устройства системы. Но конечные результаты и идеи принимает все-таки не он, а лицо принимающие решение. В целом это специалист ответственный за развитие и стратегию компании в целом, который оплачивает все работы, который понимает чуть больше и шире контекста.
Зачем аналитику всё это? Как архитектура даёт понимание целостности
Ответственен ли аналитик за архитектуру? Я считаю, что да.
По крайней мере, я всегда воспитывала в себе эту позицию. Делать плохо можно и без меня, а чтобы сделать хорошо, лучше подсветить проблемы и обсудить их с командой.
Представьте, что вы строите дом без архитектурного плана. Каждый подрядчик делает свою часть работы блестяще, но в итоге фундамент не выдерживает стены, а коммуникации невозможно провести. Так же и с IT-системами.
Знание основ архитектуры дает аналитику то самое понимание целостности (integrity) системы. Это позволяет:
№1. Видеть систему как единый организм
Подобно тому, как в антикризисном менеджменте изучают предприятие как систему взаимосвязанных процессов, архитектурный взгляд позволяет увидеть, как разные компоненты IT-системы работают вместе для достижения общей цели. Без архитектурного взгляда аналитик видит лишь отдельные фрагменты пазла. Он работает над отдельными элементами системы, но не способен оценить их влияние на общую картину. Это как пытаться построить дом, зная лишь назначение отдельных комнат, но не имея общего плана здания.
№2. Снижать риски на ранних этапах
Понимание архитектурных принципов помогает задавать правильные вопросы и выявлять потенциальные проблемы до того, как они превратятся в дорогостоящие ошибки в разработке.
Аналитики, понимающие архитектуру, способны выявить возможные проблемы ещё на этапе сбора требований. Например, неправильно выбранная интеграция может вызвать серьёзные трудности в будущем, и только опытный аналитик сможет предупредить команду заранее.
№3. Говорить с разработкой на одном языке
Когда аналитик понимает базовые концепции, диалог с командой становится в разы продуктивнее. Вместо абстрактных «хотелок» появляются конкретные, обсуждаемые требования.
Когда аналитик владеет базовыми концепциями архитектуры, он перестаёт говорить расплывчатые формулировки вроде «Эта штука должна работать быстро». Вместо этого он задает точные вопросы: «Какой механизм аутентификации использовать?» или «Что произойдет, если нагрузка увеличится вдвое?»
№4. Контролировать нефункциональные требования (НФТ)
Производительность, масштабируемость, безопасность — это не просто слова. Это характеристики, которые закладываются на архитектурном уровне. Аналитик должен понимать, как бизнес-требования влияют на них.
Архитектурный минимум для аналитика
Нет нужды углубляться в тонкости программирования или становиться архитектором. Однако владение несколькими ключевыми аспектами позволит вам уверенно ориентироваться в проекте и эффективно общаться с командой разработчиков. Есть базовый набор представлений, который поможет в работе.
№1. Контекст системы (System Context Diagram)
Самый высокий уровень абстракции. Здесь отображаются внешние акторы (пользователи, партнеры, клиенты) и взаимодействия системы с другими системами. Этот уровень помогает понять, откуда поступают требования и кто заинтересован в изменениях.
Пример: вы разрабатываете онлайн-магазин. Ваш System Context Diagram покажет пользователей, поставщиков товаров, платежные сервисы и логистические компании.
Это самый верхний уровень. Кто и что находится за пределами вашей системы?
Внешние акторы: пользователи, администраторы и другие роли, взаимодействующие с системой.
Внешние системы: с какими другими сервисами, API, базами данных ваша система общается?
Границы: где заканчивается ваша система и начинается чужая зона ответственности?
Это даёт общий ландшафт и помогает понять, откуда приходят требования и на кого повлияют ваши изменения.
№2. Компоненты и контейнеры (Components & Containers)
Здесь вы видите внутреннюю структуру системы: компоненты («авторизация», «каталог товаров») и контейнеры (веб-сервер, базы данных, мобильные приложения). Важно понимать, какие части системы затрагиваются изменениями и как они зависят друг от друга.
Пример: добавляя новую функцию оплаты картой, аналитик должен знать, какие компоненты будут задействованы (авторизационный модуль, платёжный шлюз) и как это отразится на производительности системы.
Как система устроена внутри?
Компоненты: логические строительные блоки системы (например, «сервис авторизации», «модуль отчётов», «платёжный шлюз»). Это группировка функциональности по бизнес-задачам.
Контейнеры: в чём эти компоненты «живут» и исполняются? Это может быть веб-приложение, мобильное приложение, микросервис, база данных.
Понимание этой структуры помогает аналитику оценить, какие части системы затронет новая фича.
№3. Взаимодействия и потоки данных (Interactions & Data Flow)
Этот уровень показывает, как компоненты обмениваются информацией и выполняют операции. Чем чётче схема потоков данных, тем проще объяснить команде разработчиков, как новые требования повлияют на систему.
Пример: процесс оформления заказа включает взаимодействие нескольких модулей: корзины, каталога товаров, модуля расчёта стоимости и модуля обработки платежей.
Как компоненты общаются между собой и с внешним миром?
Интерфейсы: API, протоколы обмена (REST, gRPC, очереди сообщений).
Потоки данных: как информация движется по системе для выполнения бизнес-процесса (например, от оформления заказа до его доставки).
Умение нарисовать высокоуровневую схему такого потока — бесценный навык для аналитика.
№4. Представление о данных (Logical Data Model)
Хотя аналитику необязательно проектировать базу данных, понимание базовых сущностей и связей между ними существенно облегчает разработку функциональных требований.
Пример: основная сущность - клиент, товар, заказ. Эти элементы соединяются определёнными отношениями, влияющими на функциональность системы. Аналитику не обязательно проектировать структуру БД, но важно понимать:
Ключевые сущности: какие основные понятия есть в вашей предметной области (Клиент, Заказ, Товар).
Связи между ними: как эти сущности связаны друг с другом.
Это помогает обеспечить логическую целостность данных при проектировании новых функций.
5. Нефункциональные требования (НФТ)
Эти качества определяют, как система ведет себя в реальных условиях эксплуатации. К таким характеристикам относятся производительность, устойчивость, безопасность и удобство использования.
Пример: требование о том, что сайт должен выдерживать нагрузку в миллион запросов в сутки, напрямую связано с выбором архитектуры серверов и механизмов кеширования.
Это качество системы. Их можно условно разделить на три группы:
Операционные (Runtime Quality): производительность, доступность, надёжность, масштабируемость.
Структурные (Design Quality): поддерживаемость, расширяемость, портируемость (переносимость).
Сквозные (Cross-cutting Quality): безопасность, удобство использования (usability).
Аналитик должен уметь выявлять эти требования у бизнеса и понимать, что они напрямую влияют на архитектурные решения.
Вопрос о том, кто может стать архитектором, вызывает немало споров и обсуждений в профессиональной среде. Давайте рассмотрим наиболее распространённые мнения и аргументы.
Чтобы эффективно взаимодействовать с архитектором решений, аналитик должен обладать определённым набором навыков и качеств. Вот ключевые компетенции, необходимые для успешного сотрудничества:
6. Базовые технические знания
Должен понимать общие концепции, используемые архитекторами решений. Например:
Принципы построения архитектуры ПО (микросервисы, монолитные системы, клиент-серверные модели).
Основы работы с базами данных (SQL vs NoSQL, схемы хранения данных).
Понятия масштабируемости, производительности и надежности.
Основные технологии и стандарты интеграции (API, REST, SOAP, GraphQL).
Эти знания позволяют говорить на одном языке с архитектором и быстрее находить взаимопонимание.
7. Софт требования
А) Способность представлять общую картину.
Эффективный аналитик способен видеть систему не только как набор отдельных модулей, но и как единое целое. Это включает понимание взаимозависимостей между различными частями системы, способности предвидеть последствия изменений и умения рассматривать проблему комплексно.
Б) Коммуникативные навыки.
Основой успешной совместной работы является ясное и конструктивное общение. Хороший аналитик умеет ясно выражать мысли, аргументированно защищать свои предложения и внимательно выслушивать точку зрения архитектора. Сюда входят:
Четкое изложение требований и ожиданий бизнеса.
Способность разъяснять сложные моменты простым языком.
Готовность вести переговоры и разрешать конфликты мнений.
Понимание границ ответственности
Важно осознавать границы своей зоны ответственности и уважительно относиться к ролям коллег. Аналитик не пытается навязывать собственные взгляды на технические решения, а наоборот — сотрудничает с архитектором, предлагая возможные сценарии и оценивая влияние требований на проект.
В) Эмпатия и адаптивность. Хорошее сотрудничество строится на понимании нужд и взглядов партнёра. Эмпатичный аналитик учитывает видение архитектора, стремится понять причины принятия тех или иных технических решений и готов идти навстречу компромиссам.
Кроме того, аналитик должен быстро приспосабливаться к изменениям в проекте, оперативно реагировать на новые вводные и гибко подходить к решению возникающих вопросов.
Г) Критическое мышление и аналитические способности
Анализируя запросы бизнеса, аналитик должен выявлять скрытые проблемы, противоречия и ограничения, влияющие на архитектурные решения. Это позволяет заранее предупредить возникновение трудностей и снизить риски проекта.
Д) Организация совместной работы
Регулярные совместные сессии планирования, обсуждений и согласования требований способствуют эффективной работе. Аналитик организует такие мероприятия, инициирует обсуждение неясных аспектов и поддерживает прозрачность коммуникаций.
Е) Готовность учиться новому
Поскольку современные технологии развиваются стремительно, аналитику полезно периодически обновлять свои знания и интересоваться новыми трендами в области проектирования и архитектуры. Это позволит лучше понимать аргументы архитектора и предлагать более качественные рекомендации бизнесу.
Заключение: от страха к партнёрству
Возвращаясь к моему опыту, я поняла, что архитектор — это не небожитель, а партнёр. Его главные инструменты — не только технологии, но и умение договариваться, убеждать, фасилитировать встречи и играть в «зум»: то смотреть на картину в целом, то погружаться в детали.
Аналитику не нужно становиться архитектором. Владение минимальным набором архитектурных знаний превращает аналитика из пассивного наблюдателя в активного участника процесса проектирования. Понимание этого «минимального набора» превращает его из простого транслятора требований в полноценного участника проектирования системы. Это позволяет нам вместе строить надёжные и полезные продукты, а не «дома», которые развалятся при первом же ветре.
А как выстроен процесс у вас в компании? Насколько глубоко аналитики погружены в архитектуру? Делитесь своим опытом в комментариях.