Привет, Хабр! Я Ирина Хромая, работаю в ИТ 8 лет, из них более 4 лет – в роли системного аналитика.
Как известно, успех проекта напрямую зависит от соответствия первоначальной бизнес-цели и итогового результата реализации. И одним из первых этапов достижения желаемой цели является проектирование ИС.
В данной статье рассмотрим возможные плюсы и минусы участия аналитика в проектировании ИС. На что он влияет и с чего можно начать свой путь развития в проектировании ИС.
И хочется начать с проблем, с которыми сталкиваются многие на своих проектах. Проблем, которые вытекают одна из другой.
Топ самых частых проблем на проекте
Несоответствие итогового продукта изначальным требованиям
На мой взгляд, это самая частая проблема, с которой сталкиваются многие команды.
Отсутствие гибкости системы
Из этой проблемы возникают сложности при поддержке и доработке системы. При реализации по неоптимальному решению, при необходимости доработки процесса может понадобится реализация новых решений.
Отсутствие возможности повторного использования реализованного решения
Это критично для микросервисной архитектуры.
Увеличение сроков реализации
Вытекает из вышеперечисленных проблем и влечет за собой увеличение стоимости проекта.
Минимизируем проблемы
Поможет нам в решении данной задачи правильно проработанное архитектурное решение (в дальнейшем АР).
В АР включает в себя выбор технологий, определение требований, создание диаграмм и планирование процесса.
И, как раз, ключевые цели, за которые отвечает АР должны помочь нам максимально нивелировать наши проблемы.
А именно к этим целям относятся:
Соответствие требованиям
Обеспечение масштабируемости
Безопасность
Производительность
Устойчивость
Кто отвечает за подготовку АР в команде/на проекте?
Отвечая на этот вопрос, мы провели небольшой опрос среди аналитиков в рамках нашей компании и получили следующие показатели:
Теперь хочу немного раскрыть обе эти роли. И начнем с архитектора ИТ.
Сейчас выделяют несколько видов, но я остановлюсь на архитекторе решений.
Основные функции архитектора решений:
Проектирование решения
Выбор правильных/оптимальных технологий
Описание структуры и поведения системы
И перейдем к роли аналитика.
Основные функции аналитика:
Сбор требований к системе
Проектирование решения поставленной задачи
Перевод на технический язык бизнес‑потребно сти/задачи.
И у обеих этих ролей можно выделить общую функцию – и это ПРОЕКТИРОВАНИЕ РЕШЕНИЯ.
Таким образом, как мы уже рассмотрели по нашему опросу и основным функциям этих ролей – у нас есть 2 роли, по сути, взаимозаменяемые на этапе проектирования решения по поставленной потребности. Но почему у нас все еще могут возникать проблемы, которые мы озвучили в начале?
Причин, на самом деле, может быть огромное множество. По моему опыту и опыту общения с коллегами я выделила основные и наиболее встречающиеся, связанные с процессом подготовки архитектурного решения. И они очень сильно связаны между собой.
Почему возникают проблемы на проекте?
Высокая загруженность сотрудников – много задач/сжатые сроки.
Недостаточное погружение в процессы – эта причина так же может быть со стороны обеих ролей.
Недостаточное описание исходной проблемы – одна из самых распространенных проблем, которая мешает/не позволяет полноценно погрузиться в детали проектируемого процесса.
Подгонка требования под решение или решения под требование – когда у специалиста не хватает времени/внимания/опыта, а иногда и желания. И решение прорабатывается «в лоб» – как написано в задаче, так и спроектировали.
Плохая коммуникация между ключевыми фигурами проекта.
Предлагаю рассмотреть на небольшом абстрактном примере проблемы, которые могут возникнуть на этапе проектирования решения и причины которые к этому приводят.
Пример возникновения проблем и их причины
Допустим, стояла задача реализовать новый процесс сбора заявок с клиентских фронтов с типом NEW. Процесс должен так же предусматривать работу с поданными заявками из интерфейса сотрудников, хранение реестра всех поданных заявок и передавать данные по заявкам в смежные системы.
Самая первая проблема, с которой мы можем столкнуться по причине недостаточного погружения в проблему – дублирование функционала. А именно, если мы не будем достаточно погружаться в уже существующие процессы и поставленные требования, то самым очевидным решением будет является реализация нового микросервиса.
Допустим, мы все же погрузились в существующие процессы перед проектированием и узнали, что уже существует микросервис, который уже умеет принимать и обрабатывать заявки с клиентских фронтов, но только в типом OLD.
И следующая проблема, с которой мы можем столкнуться – это вынести в отдельный микросервис реестр для хранения данных по новому типу заявок, потому что это не реализовано в текущем микросервисе, а у нас есть в этом потребность.
Так же подобная проблема может произойти, если в целом таким образом будут поставлены бизнес-требования и решение будет подгоняться под них.
При проектировании данного процесса важно понимать итоговый результат, который ожидает увидеть бизнес-заказчик, но не с точки зрения технического решения, а с точки зрения корректной работы бизнес процесса.
И правильным решением по данной задаче будет являться доработка текущего микросервиса и логики работы с новым типом заявок.
И после разбора примера предлагаю рассмотреть способы для улучшения процесса проработки АР.
Что можно сделать для улучшения качества решений?
Начнем с вариантов проработки АР:
Аналитик и архитектор работают в одной команде — в данном случае аналитик выступает главным консультантом по работе текущих процессов, чем способствует правильному проектированию решений.
Когда архитектор прорабатывает решение — в данном случае аналитик получает АР на этапе системного анализа для дальнейшей постановки задач на команду.
Когда аналитик готовит решение — после этого АР может проходить этап согласования с отдельно выделенным архитектором или архитектурным комитетом или просто заинтересованным кругом лиц по проекту.
Когда вся команда задействована в проработке решения — это может быть как в виде исключения при проработке срочной задачи, так и на постоянной основе.
Теперь рассмотрим, что мы можем улучить в проработке АР, в вариантах, когда мы участвуем.
Я участвую в проработке АР, как улучшить?
Выполнить сбор полных требований и определение итоговых целей задачи проекта перед проработкой решения – критерием полного сбора требований как раз выступает единое понимание у всех участников проекта по итоговому результату.
Погрузить архитектора в бизнес процесс/передать бизнес смысл, если он есть в команде/на проекте.
Определить масштабы проекта/системы – для того что бы изначально заложить в АР дальнейшее масштабирование и возможность/необходимость переиспользования решения.
Определить взаимодействие с внешними системами.
Определить типы интеграции – это так же важно при участии нескольких систем/команд в доработке/реализации задачи. У всех должно быть понимание, как по ожидаемому итогу, так и по сроку реализации.
Определить и обозначить потенциально узкие места процесса – необходимо как можно раньше подсветить риски при реализации того или иного архитектурного решения для нивелирования проблем на начальных этапах.
Я не участвую в проработке АР, с чего начать?
Проводить ревью требований и АР при поступлении задачи.
Необходимо своевременно давать обратную связь по полученным артефактам.
Определить и обозначить риски предложенного решения — вы большепогружены в процессы и знаете о нюансах процессов, так проще и быстрее что‑то изменить даже в уже согласованных АР и БТ, чем переделывать реализацию.
Не бояться задавать вопросы всем участникам процесса — всегда всем говорю, что вопросы — это главный инструмент аналитика, даже если вам кажется, что все понятно.
Наладить взаимодействие с командами смежных сервисов, с которыми вы будете реализовывать общий проект/задачу — что бы у всех было единое понимание по итоговому результату реализации проекта, а так же по срокам.
И наладить взаимодействие с архитектором — это ваш главный помощник по поставленной задаче и архитектурному решению.
Полезные советы для тех, кто хочет начать свое развитие в архитектуре
Начать можно и нужно с изучения основ архитектуры решений.
Больше общайтесь с другими архитекторами и не только в рамках своей компании.
Узнавайте о новых трендах и технологиях в мире ИТ.
Пробуйте применять полученные знания в своих задач — практика самый лучший опыт который можно получить.
И могу посоветовать несколько полезных книг, с которых так же можно начать свое погружение в эту тему:
Создание микросервисов, Сэм Ньюмен — в этой книге можно найти практические рекомендации по проектированию микросервисной архитектуры. Книга в целом поможет разобраться в микросервисах.
Архитектура корпоративных программных приложения, Мартин Фаулер — книга больше посвящена особенностям корпоративных приложений, но так же в ней можно найти краткие примеры по решению различных архитектурных проблем.
Микросервисы. Паттерны разработки и рефакторинга, Ричардсон Крис — так же много полезного о микросервисной архитектуре.