Comments 10
У меня сложилось впечатление, что середину поста случайно удалили... Да, в энтерпрайзе даже в проектах интеграции, не говоря уж про разработку:
1. Изначально невнятно поставленные цели и задачи.
2. Необходимость коммуникации с большим количеством стейкхолдеров.
3. Размывание ответственности за конечный результат в целом по проекту.
Какой совет архитектору то? Agile? Каждый директор-рак-лебедь-щука не знает точно куда ему тянуть свою часть, не говоря уже об общей картине. И тут архитектор говорит: "а давайте по чуть-чуть" и сразу всё наладилось? Они так и не сдвинутся с места (проверенно и не раз). И второе, что нас интересует - это CI-CD? Если б было так сказочно, то и архитектор не нужен. Коучей хватает, а вот заводы стоят.
Единственное, что верно подмечено - это ИБ. Все эти важные держатели стейков всегда забывают спросить безопасников. А те в свою очередь будут тешить своё ЧСВ, заявляясь нежданно в середине процесса и требуя всё переделать, остановить и сертифицировать.
По поводу Agile. На таких проектах интуитивно хочется уйти от Agile. Хочется сначала найти точки согласования. Но в моей практике удалось сдвинуть несколько проектов с десятками заинтересованных лиц. Как только люди чётко видят свою зону ответственности и ее наполнение, они успокаиваются и начинают быть конструктивными.
С CI-CD не совсем понял комментарий, почему архитектор не нужен. По опыту, как только CI/CD начинает быть регулярным (например, два раза в сутки) сразу становится легче взаимодействовать с заинтересованными лицами и узлы проекта начинают развязываться на глазах. Возможно, мне везло, но этот процесс всегда удавалось выстроить вопреки, а не благодаря заказчику.
Все вышеописанные проблемы архитектору мешают на начальной стадии. Если у вас уже деплой, то какие могут проблемы со стейкхолдерами и целями? У вас уже и архитектура готова и бэклог выстроен. Требования пусть хоть каждый час меняются - это уже проблема продакта и проджект менеджера. Смена архитектуры - функции времени и денег.
А вот что делать на старте без чёткого понимания куда нужно строить путь и без команды менеджмента? С набором эгоцентричных одиночек можно ломать, а не строить. Нулевой спринт и есть самая проблема - когда надо заложить основу. Потом уже можно жевать по ложечки за раз. Как заставить стадо собраться и сделать выбор? Какой набор инструментов и практик есть у архитектора в данной ситуации? Я ожидал прочитать именно про это...
Ещё одна из рекомендаций в случае множества стейкхолдеров - заручиться поддержкой руководителя. В случае разногласий между заинтересованными сторонами руководитель примет финальное решение, окончательное и не подлежащее обсуждению. В случае затягивания сроков руководитель простимулирует подчинённых. Проблема лишь в том, что руководители обычно очень занятые люди и едва ли могут уделять достаточно внимания всем проектам, происходящим в организации
Это точно. Мне, правда, только один раз удалось участвовать в проекте, где руководитель был прямо заинтересован в результате проекта. Было здорово. Обычно же есть какое-то головное подразделение со стороны заказчика, которое всеми правдами и неправдами выстраивает работу с другими участниками, в т.ч. ИБ, инфраструктурой. Причём у всех подразделений свои руководители, цели и задачи.
Ваши предложения по ситуации, когда одного руководителя нет? Вот пара примеров:
общая инфосистема 5 разных компаний - у каждой свой представитель в проекте и часть бюджета. Заказчика как бы и нет - законодатель обязал.
три компании являющиеся частью холдинга, требование идёт от материнской компании, но там чисто финансы и никакого понимания бизнеса. Они не хотят и не могут диктовать как строить ибо не знают что нужно строить.
франшизы - контроля над купившими бренд в чистом виде нет, и попытки продавить что то сразу упираются в иск о нечестной конкуренции.
общая инфосистема 5 разных компаний - у каждой свой представитель в проекте и часть бюджета. Заказчика как бы и нет - законодатель обязал.
Если законодатель обязывает - то он должен четко выставить требования к ИС. Если он их не выставил, то надо их с него истребовать (трактовка закона, как правило, за ФОИВ по компетенции). Когда требования к ИС понятны - совместно компании выбирают компетентного исполнителя, создают совместную рабочую группу с исполнителем для решения технических вопросов и вперёд. Исполнителя надо выбирать с условием, что он же будет сопровождать и развивать ИС
три компании являющиеся частью холдинга, требование идёт от материнской компании, но там чисто финансы и никакого понимания бизнеса. Они не хотят и не могут диктовать как строить ибо не знают что нужно строить.
Распространённая сейчас ситуация. "Кто не знает, в какую гавань ему плыть, для того не бывает попутного ветра." Исполнитель в данной ситуации сделать ничего путного не сможет. Практически гарантированно деньги улетят на ветер. Если у исполнителя вдруг найдётся специалист, который сможет решить такую задачу, то его надо срочно ставить руководителем данного холдинга.франшизы - контроля над купившими бренд в чистом виде нет, и попытки продавить что то сразу упираются в иск о нечестной конкуренции.
О системе контроля надо думать до продажи бренда. Попытки догнать ушедший поезд будут зависеть от конкретной ситуации. Ошибки при принятии управленческих решений верхнего уровня всегда ведут к большим потерям (затратам).
Всё правильно, вот только клиентов не выбирают. Во всяком случае, мне такой роскоши не предоставляют. Да и вообще, чем круче компания - тем сложнее клиенты. Поэтому приходиться придумывать какие-то трюки и хотелось бы услышать об опыте других в подобных ситуациях. Вот только этого то в статье и нет.
Это конечно интересно всё и в целом вроде вполне логшично всё, но о каких задачах, которые вы решаете идёт речь? Позвольте пробежаться галопом по европам....
В статье вы описываете выбраные решения, но какую конкретно задачу вы решаете не описано? Нет деталей, откуда тогда появились решения? Например в тот момент, когда вы дошли до темы БД Вы сразу описываете решение выбрать СУБД и взаимодействоать с ней посредством определённо ORM. Ближе к концу статьи вообще разговор пошел о DDD. У меня сложилось ощущения вырваного текста из некой истории.
Хотите облегчить жизнь архитекту? Подарите ему готовую документацию по новому проекту где уже (за него/неё) описаны все requirements, use cases и например волатильности как мимнимум. И вы будете приятно удивлены, увидев дикий восторг от того что было сэконмлено десятки а то и сотни часов митингов, встречь с клиентом или его представителями, анализа требований и хотелок и консультаций с бизнесс аналитиками. Если конечно у вас не простенький проект )))))
А вот разговор о СУБД и DDD это в самую последнюю очередь.
Как архитект вы сначала определяете "ЧТО" вы будете создавать, а только потом "КАК" вы это будете реализовывать. Потому что технические решения по использованию инструментов, фрэймворков и тем более их реализация с точки зрения архитектуры это zero value activity.
По этому я и пишу что не ясно что именно вы создаёте чтобы точно сказать, что описаные Вами сценарии и решения действительно облегчают жизнь архитектору а не наоборот.
Подарок прекрасен, я сам был бы ему так рад, так рад))), но, как видно из предыдущих комментариев, такой подарок -- редкость при решении сложных бизнес-задач. Как исполнитель, приступая к решению, мы только примерно знаем, "ЧТО" будем создавать.
Конкретно проекты, подвигшие меня на эту статью, -- это проекты с гос/окологос структурами (44-ФЗ, 223-ФЗ,..., усугубленные 248-ФЗ).
ORM/миграции -- вроде бы узкий вопрос. Но организация хранилищ данных в условиях постоянных изменений настолько важна, что я привел наше конкретное базовое решение, которое облегчает жизнь. Помимо Java-проектов у нас есть python-проекты, тут мы используем in-memory SQLite для тестирования, но отсутствие идемпотентных миграций особенно на ранних стадиях, на которых мы много работаем с заказчиком и многое меняем (сделал->увидел->понял-> много раз в цикле) очень неудобно, накапливается много ненужных миграций. Также инкрементные миграции -- значит всегда один ответственный за структуру БД, т.е. бутылочное горлышко. Для обхода этих ограничений в не-Java проектах мы даже выкрутили https://github.com/CourseOrchestra/2bass.
Подход DDD делает все элементы создаваемой системы, в первую очередь функциональные, прозрачными для участников, также упрощает документирование. В хаосе начала проекта это важно.
Понятно, что ORM (точнее, в общем случае, подход к организации работы с хранилищем данных) и DDD -- вопросы из разных областей. Но, с точки зрения важности для проекта, решения об их использовании находятся на одном уровне значимости.
Проект и тьма стейкхолдеров: как облегчить жизнь архитектору