«Ну ты же компьютерщик!» — многим из ИТ-сферы знакома эта фраза из прошлого. Ей обосновывали, почему именно вы должны сделать почти всё: от настройки принтера до разработки и тестирования систем.

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

На практике это порождает новую версию старой фразы: «Ты же архитектор? Вот и придумай, как это сделать, собери требования, спроектируй данные и проверь, чтобы влезло в бюджет».

В этой статье я разберу роли этапа проектирования ИТ-решений и покажу инструмент для формирования команды, которая совместной работой обеспечивает качественные требования. Иными словами, постараюсь ответить на вопрос: как побороть разрозненность требований через чёткое распределение ролей и ответственности.

Важное уточнение

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

Материал изложен верхнеуровнево, без углубления в детали каждой роли или сравнения с различными стандартами. Речь пойдет не о практике наполнения артефактов (например, о классификации требований), а о типовых ролях, объектах проектирования и зонах ответственности — на концептуальном уровне. Схемы в статье приведены в нотации ArchiMate.

Для кого эта статья

Материал будет полезен:

• ИТ-методологам и руководителям проектов и подразделений проектирования;

• специалистам по ИТ-кадрам;

• самим участникам проектирования - для прояснения своих границы и зон ответственности.

Проектирование ИТ-решений

Проектирование в производственном цикле - это стартовая фаза, которая превращает бизнес-инициативу в готовый набор артефактов для разработчиков. На входе — запрос заказчика, на выходе — четкие инструкции к реализации.

Этот процесс должен работать через общий пул задач, результат которых — взаимосвязанные артефакты. Каждый участник, в рамках своей зоны ответственности, выполняет свою часть работы, опираясь на результаты коллег. Он формализует их и передает дальше по цепочке.

Отмечу, что этот процесс — не обязательно строгая последовательность. Это может быть итерационная и командная работа, где этапы параллелятся и уточняются по мере проработки.

Если посмотреть на жизненный цикл инициативы от идеи до эксплуатации, верхнеуровнево (по каскадной модели) и упрощённо это выглядит так:

А если заглянуть внутрь этапа «Спроектировать решение», мы увидим его внутреннюю логику, упрощённо так:

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

В упрощенном виде этот процесс можно изобразить так:

Кто проектирует?

За проектирование ИТ-решений отвечают два «семейства» ролей: аналитики и архитекторы. Каждое из них дробится на множество специализаций, и именно здесь начинается главная путаница: кто за что отвечает?

Даже приведенная выше последовательность этапов у многих вызывает споры. Для руководителей и заказчиков она часто неочевидна, не говоря уже о тонкостях задач каждого участника.

На мой взгляд, основной состав ролей проектирования ИТ-решений следующий:

• корпоративный архитектор (enterprise architect): стратег, обеспечивает соответствие решения бизнес-целям компании и архитектурным принципам. Смотрит на всё "с высоты птичьего полёта";

• архитектор решений (solution architect): главный инженер, отвечает за целостность решения и сводит воедино все его части — от бизнес-логики до технологий;

• бизнес-архитектор (business architect): переводчик с языка бизнеса, описывает бизнес-способности, процессы и то, как компания создает ценность;

• архитектор данных (data architect): хранитель активов, проектирует как данные хранятся, защищаются, используются и перемещаются в рамках решения;

• интеграционный архитектор (intagration architect): связист, проектирует "мостики" для взаимодействия между различными системами и приложениями;

• системный архитектор (system architect): конкретизатор, определяет из каких конкретных компонентов (железо, системное ПО) будет состоять решение;

• архитектор приложений (software architect): конструктор приложений, проектирует их внутреннее устройство, модули, API и функциональность (включая задачи функционального архитектора));

• технологический/инфраструктурный архитектор (infrastructure architect): строитель фундамента, отвечает за серверы, сети, облака и другую платформу для работы решения;

• архитектор информационной безопасности: встраивает безопасность в каждый слой решения, оценивает риски и проектирует защитные механизмы;

• бизнес-аналитик: исследователь потребностей, выясняет что нужно бизнесу и почему, фокусируется на стейкхолдерах и их целях, описывает бизнес-процессы автоматизации;

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

Как правило, на практике один человек часто совмещает несколько ролей. Главное — чтобы он делал это осознанно, "надевая разные ролевые шляпы", а не валил всё в кучу. Именно для этого нам нужно четкое понимание зон ответственности, основанное на объектах проектирования и уровне абстракции каждой роли.

Основа подхода: ArchiMate как карта для навигации

За основу взят язык ArchiMate и его метамодель. Почему именно он? Потому что он предоставляет готовую и логичную систему координат, раскладывая любое ИТ-решение на согласованные архитектурные слои. Именно это разделение на слои и позволяет обоснованно распределить роли, о которых говорилось выше.

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

• из слоя мотивации и бизнес-архитектуры: стейкхолдеры, цели, потоки ценности, бизнес-способности, роли, бизнес-процессы и события, бизнес-объекты;

• из слоя приложений, данных, интеграций: объекты данных, информационные потоки, информационное взаимодействие, приложения, функциональность, сервисы;

• из слоя инфраструктуры и технологической архитектуры: системное ПО, технологические функции, процессы, сервисы, узлы, девайсы, сети и локации.

Визуальное представление этой метамодели может выглядеть так:

Этот список — не догма. Если в вашей практике есть критически важные сущности, отсутствующие в ArchiMate (например, специфические метрики или объекты), — смело добавляйте их в свою модель. Главное — сохранить принцип: у каждого объекта проектирования должен быть ответственный.

Практика

На основе выбранных объектов проектирования и состава ролей формируется матрица ответственности (например, RACI). В этой матрице фиксируется, какая роль за что отвечает в процессе проектирования каждого объекта:

• создаём матрицу RACI, в которой, например, по вертикали — объекты проектирования, по горизонтали — роли команды, на пересечении — степень ответственности;

• анализируем и дополняем команду: смотрим, какие клетки матрицы остаются пустыми, формируем обоснованные требования к недостающим компетенциям (например, если за "объекты данных" никто не отвечает — нужен архитектор данных)

ArchiMate в этом случае — это общая картина пазла, а объекты проектирования — отдельные элементы, которые должны быть собраны воедино разными участниками.

Например, заполненная матрица может выглядеть так:

Когда матрица ответственности готова, она становится основой для стандартизации работы команды. Мы можем определить конкретные форматы артефактов для каждой роли, которые в совокупности покроют все выбранные объекты проектирования. Для каждой роли подбирается наиболее подходящий инструмент (и методология): например, ArchiMate для архитекторов, BPMN для описания процессов бизнес-аналитиками, UML для системных аналитиков и так далее.

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

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

Решение этой задачи ложится на плечи руководителей и ИТ-методологов и является достаточно объемной работой. Возможно, на эту тему будет отдельная статья, но в целом про агрегацию требований я рассказывал здесь: https://habr.com/ru/articles/953794/

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

Такая визуализация не только проясняет процесс, но и закладывает основу для будущей автоматизации: она концептуально показывает, как можно организовать обмен данными между производственными системами для поддержания сквозной связанности артефактов на протяжении всего жизненного цикла.

Заключение

Эффективная команда проектирования — это сбалансированная система, где у каждого специалиста есть четкая зона ответственности в рамках общей архитектуры. Использование ArchiMate для выделения объектов проектирования и понимание сквозной природы требований помогает создать именно такую систему.

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

Качественное проектирование — это не просто этап, а стратегическая инвестиция в успех всего ИТ-цикла. Решение, спроектированное «без дыр», становится надежным фундаментом для эффективной разработки, планирования релизов, целенаправленного тестирования по четким критериям качества, управления проектами с предсказуемыми сроками и результатами.

Такой подход также улучшает управляемость цифровой трансформации и способствует построению устойчивой архитектуры (особенно при использовании специализированных средств, таких как архитектурный репозиторий).

Надеюсь, он поможет вам в процессе построения сильных команд проектировщиков и как следствие - в улучшении качества ИТ-продуктов.