Сегодня мы рассмотрим роль Solution-архитектора в проектах по разработке приложений. Это одна из возможных ролей. Напоминаю, что есть три разновидности (Solution, Technical и Enterprise).
Часто можно встретить в проектах именно "Архитектора решения", иногда называют "Архитектора продукта". Дело в том, что любое проектируемое приложение сложнее Hello World будет в современном мире написано на классах, отдельных компонентах, модулях, микро сервисах и т.п. При этом ,что в монолитном приложении, что в облачном решении, что в обычном клиент-серверном приложении все возможности в голове удержать невозможно. И как минимум потребуется техническая документация.
Техническая документация.
Документацией можно назвать банальное описание возможностей, которое прочитает и поймет одинаково и пользователь, и специалист поддержки. Оно будет написано настолько просто, что какой-либо полезной информации из него будет сложно получить. Часто можно встретить описание подобное такому:
"Это окно с платежами. В нем вы можете увидеть платежи. Кнопка Просмотр - посмотреть данные платежа. Кнопка Редактировать - изменить платеж. Кнопка Удалить - уберет платеж из системы."
К сожалению все чаще вижу такое отношение в новых продуктах. У разработчиков исчезло желание донести истину с первых строк и избавить от повторных обращений в поддержку. Чтобы документация в вашем проекте была приятной для чтения и полезной для понимания, к документации должны выставляться требования. Для этого часто архитектор выставляет требования к содержанию. Очерчивает границу минимальных и необходимых данных. Требует выполнения и выполняет контроль на промежуточных этапах и при приеме решения и его описания.
Многие могут подумать, что это работа не архитектора, а тестировщика. Не совсем так. Тестировщик может проверить, то, что описал разработчик. Внести корректировки, но при этом он не станет говорить, что документация не полная. А разработчик захочет сэкономить на описании и уделить больше времени разработке. Поэтому архитектор в данном случае орган контроля и его слово должно иметь вес.
Проектирование.
С документацией разобрались. Но это только одна небольшая часть работы Solution-Архитектора. Вторым очень интересным направлением будет конечно же Проектирование самого решения. Прежде всего необходимо провести анализ существующей архитектуры смежных приложений. Собрать информацию о всех интеграциях, используемых технологиях, способах взаимодействия, их консолидация. Затем анализ постановки написанной бизнес-аналитиком. Обычно это выжимка из слов конечного потребителя - пользователя предполагаемого решения. Обсуждение подробностей и имеющихся возможностей программ с системным-аналитиком. И собрав информацию обо всём окружении - архитектор садится и начинает рассуждать и обрисовывать несколько вариантов. Обычно стараются предложить 3 варианта:
- Наилучший, дорогой, на современных технологиях, с возможностями роста и развития.
- Оптимальный, где цена средняя, не требует сложных манипуляций, резкого движения к новым технологиям, но оставляя возможности роста.
- Минимально допустимый. Дешевый вариант, где часть функционала можно сделать силами компании, без привлечения внешних подрядчиков. Возможно часть функционала после GAP-анализа останется вовсе без автоматизации.
Далее все эти варианты обсуждаются поэтапно, сначала внутри команды разработки, затем с руководством. Если есть корректировки на каждом из этапов - они обсуждаются и вносятся в предлагаемое решение. Далее производится выбор варианта.
Дорожная карта и участие в проекте.
На этом работа Solution-архитектора не заканчивается. Теперь ему необходимо по выбранному решению и имеющейся стартовой информации, описать дорожную карту. В этом документе подробно расписывается путь по шагам, как из существующей конфигурации дойти до желаемой и примерные сроки. На этом этапе важно найти понимания ото всех, чтобы не было удивлений, почему те или иные технологии требуют привлечения новых компетенций или использования сторонних компаний. Дорожную карту также доводят до сведения команды и руководства. Получив все согласования, подключается проектный отдел, который на основе консолидированной информации составляет проектный план, расписывает срок, а если потребуется - заключает договора, покупает лицензии, или ПО. Также проектный менеджер контролирует привлечение человеческих ресурсов. Но архитектор не уходит на совсем. Он также является участником проекта и может вносить корректировки, если видит предстоящие трудности.
Эпилог.
Время прошло, проект завершается, документация в порядке. Уже можно и отдохнуть, но нет. Проектный отдел отчитается лишь о том, что запланированные средства потрачены не в пустую. Но внутри компании до сих пор не все знаю о нововведениях. И совершенно точно не ждут в нем подвоха. К моменту завершения проекта и перевода его в промышленную эксплуатацию - Архитектор, оформляет всю техническую документацию. Аккумулируя знания аналитиков, разработчиков, тестировщиков, свои. Учитывает все материалы используемые при показах пользователям и составляет пакет документов, который обычно называют "Проектная ИТ-документация", иногда называют "Архитектурная документация".
После этого Архитектор действительно завершил свою работу и может переходить к следующим проектам!
--
Спасибо, что дочитали до конца. Надеюсь, было познавательно. В будущем мы рассмотрим еще не мало подробностей о работе ИТ Архитектора.
До новых встреч!