Комментарии 7
Занимательная статья в которой разбрали подробно ваше исследование и размышления, и принятые решения в процессе развития системы. Читал с удовольствием.
Забавный способ документировать то практически безосновательное, что обычно невербально и интутитвно решает человек, выполняющий роль архитектора. Фактически, вышло ниочём.
Смотря что называть документированием. Если не записывать сами решения (в виде ADR или других артефактов), то можно считать, что архитектуры нет. Либо есть ее представление в голове архитектора, и еще по экземпляру разных представлений у каждого стейкхолдера. В практическом смысле это эквивалентно ее отсутствию.
А сам рабочий процесс получения решений, как он описан в статье, большинству потребителей архитектурного описания (документации) и в самом деле не нужен. Мы иллюстрируем сам структурированный процесс и нигде не утверждали, что он станет частью документации.
Конечно, как в любом в деле, в инженерном есть место интуиции. Однако, в девяти случаях из десяти нам хотелось бы слышать от архитектора рациональное объяснение, а не «зуб даю».
Отдавать принятие архитектурных решений на откуп аутсорсеру???
Двойка ИТ-директору "Спортмастера"!
Архитектурные решения взаимозависимы, их можно представить в виде дерева. Решения ближе к корню/стволу несут больше последствий (в т.ч. их изменение дороже), чем тем, что ближе к листьям (периферийных). Кроме того, в терминах TOGAF архитектурные решения относятся к разным доменам (обыкновенно - Business, Data, Application, Technology). Разумно, что ответственность за архитектурные решения в разных TOGAF-доменах, на разных уровнях дерева архитектурных решений распределена в оргструктуре компании или делегирована.
Если специализация аутсорсера не просто кодировать по спецификации, а знать заказчика, постоянно вести у него аналитику и проектирование - то генерация, обоснование, принятие такого рода решений аутсорсером естественно.
Нужно принимать во внимание потенциальный конфликт интересов "Заказчик - Аутсорсер". Аутсорсер может напринимать ТАКИХ архитектурных решений, что потом Заказчик окажется навсегда к нему привязан ))
Да, конечно. Решение о делегировании аутсорсеру какой-либо работы такое же компромиссное, как и большинство других архитектурных. In-house ограничен своим объемом и загруженностью, а аутсорс позволяет быстро масштабироваться. Получается, компромисс vendor lock-in против возможности быстро наращивать мощность дизайна/аналитик/разработки.
Для контроля за важными решениями, видимыми в ИТ-ландшафте, часто функционирует архитектурный совет/комитет/architecture board.
Изнанка архитектуры, или Менять нельзя оставить