Роль системного аналитика при проектировании архитектурных решений

Вернуться назад

Привет, Хабр! Я Ирина Хромая, работаю в ИТ 8 лет, из них более 4 лет – в роли системного аналитика.

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

В данной статье рассмотрим возможные плюсы и минусы участия аналитика в проектировании ИС. На что он влияет и с чего можно начать свой путь развития в проектировании ИС.

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

Топ самых частых проблем на проекте

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

  На мой взгляд, это самая частая проблема, с которой сталкиваются многие команды.

• • Отсутствие гибкости системы

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

• • Отсутствие возможности повторного использования реализованного решения

  Это критично для микросервисной архитектуры.

• • Увеличение сроков реализации

  Вытекает из вышеперечисленных проблем и влечет за собой увеличение стоимости проекта.

Минимизируем проблемы

Поможет нам в решении данной задачи правильно проработанное архитектурное решение (в дальнейшем АР).

В АР включает в себя выбор технологий, определение требований, создание диаграмм и планирование процесса.

И, как раз, ключевые цели, за которые отвечает АР должны помочь нам максимально нивелировать наши проблемы.

А именно к этим целям относятся:

• • Соответствие требованиям
• • Обеспечение масштабируемости
• • Безопасность
• • Производительность
• • Устойчивость

Кто отвечает за подготовку АР в команде/на проекте?

Отвечая на этот вопрос, мы провели небольшой опрос среди аналитиков в рамках нашей компании и получили следующие показатели:

Теперь хочу немного раскрыть обе эти роли. И начнем с архитектора ИТ.

Сейчас выделяют несколько видов, но я остановлюсь на архитекторе решений.

Основные функции архитектора решений:

• • Проектирование решения
• • Выбор правильных/оптимальных технологий
• • Описание структуры и поведения системы

И перейдем к роли аналитика.

Основные функции аналитика:

• • Сбор требований к системе
• • Проектирование решения поставленной задачи
• • Перевод на технический язык бизнес‑потребно сти/задачи.

И у обеих этих ролей можно выделить общую функцию – и это ПРОЕКТИРОВАНИЕ РЕШЕНИЯ.

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

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

Почему возникают проблемы на проекте?

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

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

Пример возникновения проблем и их причины

Допустим, стояла задача реализовать новый процесс сбора заявок с клиентских фронтов с типом NEW. Процесс должен так же предусматривать работу с поданными заявками из интерфейса сотрудников, хранение реестра всех поданных заявок и передавать данные по заявкам в смежные системы.

Самая первая проблема, с которой мы можем столкнуться по причине недостаточного погружения в проблему – дублирование функционала. А именно, если мы не будем достаточно погружаться в уже существующие процессы и поставленные требования, то самым очевидным решением будет является реализация нового микросервиса.

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

И следующая проблема, с которой мы можем столкнуться – это вынести в отдельный микросервис реестр для хранения данных по новому типу заявок, потому что это не реализовано в текущем микросервисе, а у нас есть в этом потребность.

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

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

И правильным решением по данной задаче будет являться доработка текущего микросервиса и логики работы с новым типом заявок.

И после разбора примера предлагаю рассмотреть способы для улучшения процесса проработки АР.

Что можно сделать для улучшения качества решений?

Начнем с вариантов проработки АР:

• • Аналитик и архитектор работают в одной команде — в данном случае аналитик выступает главным консультантом по работе текущих процессов, чем способствует правильному проектированию решений.

• • Когда архитектор прорабатывает решение — в данном случае аналитик получает АР на этапе системного анализа для дальнейшей постановки задач на команду.

• • Когда аналитик готовит решение — после этого АР может проходить этап согласования с отдельно выделенным архитектором или архитектурным комитетом или просто заинтересованным кругом лиц по проекту.

• • Когда вся команда задействована в проработке решения — это может быть как в виде исключения при проработке срочной задачи, так и на постоянной основе.

Теперь рассмотрим, что мы можем улучить в проработке АР, в вариантах, когда мы участвуем.

Я участвую в проработке АР, как улучшить?

• • Выполнить сбор полных требований и определение итоговых целей задачи проекта перед проработкой решения – критерием полного сбора требований как раз выступает единое понимание у всех участников проекта по итоговому результату.
• • Погрузить архитектора в бизнес процесс/передать бизнес смысл, если он есть в команде/на проекте.
• • Определить масштабы проекта/системы – для того что бы изначально заложить в АР дальнейшее масштабирование и возможность/необходимость переиспользования решения.
• • Определить взаимодействие с внешними системами.
• • Определить типы интеграции – это так же важно при участии нескольких систем/команд в доработке/реализации задачи. У всех должно быть понимание, как по ожидаемому итогу, так и по сроку реализации.
• • Определить и обозначить потенциально узкие места процесса – необходимо как можно раньше подсветить риски при реализации того или иного архитектурного решения для нивелирования проблем на начальных этапах.

Я не участвую в проработке АР, с чего начать?

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

Полезные советы для тех, кто хочет начать свое развитие в архитектуре

• • Начать можно и нужно с изучения основ архитектуры решений.
• • Больше общайтесь с другими архитекторами и не только в рамках своей компании.
• • Узнавайте о новых трендах и технологиях в мире ИТ.
• • Пробуйте применять полученные знания в своих задач — практика самый лучший опыт который можно получить.

И могу посоветовать несколько полезных книг, с которых так же можно начать свое погружение в эту тему:

1. 1. Создание микросервисов, Сэм Ньюмен — в этой книге можно найти практические рекомендации по проектированию микросервисной архитектуры. Книга в целом поможет разобраться в микросервисах.
2. 2. Архитектура корпоративных программных приложения, Мартин Фаулер — книга больше посвящена особенностям корпоративных приложений, но так же в ней можно найти краткие примеры по решению различных архитектурных проблем.
3. 3. Микросервисы. Паттерны разработки и рефакторинга, Ричардсон Крис — так же много полезного о микросервисной архитектуре.