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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

• Соответствие требованиям

• Обеспечение масштабируемости

• Безопасность

• Производительность

• Устойчивость

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

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

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

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

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

• Проектирование решения

• Выбор правильных/оптимальных технологий

• Описание структуры и поведения системы

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

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

• Сбор требований к системе

• Проектирование решения поставленной задачи

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

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

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

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

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

• Высокая загруженность сотрудников – много задач/сжатые сроки.

• Недостаточное погружение в процессы – эта причина так же может быть со стороны обеих ролей.

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

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

• Плохая коммуникация между ключевыми фигурами проекта.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

• Выполнить сбор полных требований и определение итоговых целей задачи проекта перед проработкой решения – критерием полного сбора требований как раз выступает единое понимание у всех участников проекта по итоговому результату.

• Погрузить архитектора в бизнес процесс/передать бизнес смысл, если он есть в команде/на проекте.

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

• Определить взаимодействие с внешними системами.

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

• Определить и обозначить потенциально узкие места процесса – необходимо как можно раньше подсветить риски при реализации того или иного архитектурного решения для нивелирования проблем на начальных этапах.

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

• Проводить ревью требований и АР при поступлении задачи.

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

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

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

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

• И наладить взаимодействие с архитектором — это ваш главный помощник по поставленной задаче и архитектурному решению.

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

• Начать можно и нужно с изучения основ архитектуры решений.

• Больше общайтесь с другими архитекторами и не только в рамках своей компании.

• Узнавайте о новых трендах и технологиях в мире ИТ.

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

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

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

2. Архитектура корпоративных программных приложения, Мартин Фаулер — книга больше посвящена особенностям корпоративных приложений, но так же в ней можно найти краткие примеры по решению различных архитектурных проблем.

3. Микросервисы. Паттерны разработки и рефакторинга, Ричардсон Крис — так же много полезного о микросервисной архитектуре.