Раздел про Handover очень полезен

Статья правильная, все это надо передавать.

Но по опыту самым критичным становится "Decision Log" и передача обоснований в этом логе.
т.к. все остальное можно восстановить (реверс инженирингом, коммуникацией с разработчикам, чтением скриптов развертывания и т.п.) , а вот почему были приняты те или иные решения - эта информация обычно "исчезает" с уходом архитектора который принял это решение.

И не большой комментарий по орг чарт - формальный орг чарт легко находится в компании. А чаще нужна неформальная матрица коммуникаций (те контакты из смежных отделов - которые действительно полезны) - для передачи такой информации я  обычно просто смотрю от кого у меня больше полезных/писем/чатов/звонков.

в момент когда перестанете понимать юмор.

Согласен. Про decision log там есть)

есть, но по сравнению со всем остальным - очень мало, и в самом конце, а это самое важно : )

Пока нет, возможно, сделаем через месяц на хабр публикацию

а сайт сделать, например, мультиязычным??

Ссылочку киньте если сделаете)

обязательно. Перевод на русский вышел для предыдущей моей статьи: https://habr.com/ru/company/epam_systems/blog/538018/

1. А для кого эта статья? Т.е. кто идет по этому чеклисту - новый архитектор (и что делать, если половины пунктов нет) или старый архитектор (а нафига ему надо)?
2. А этот чеклист - для продукта, для компании, для проекта? А то там много разных вариантов тогда будет.
3. По моему опыту - нужен еще "реальный" орг.чарт а не официальный:  как реально идет информация, кто реально влияет на решения и т.п.
И список важных контактных лиц (который с оргчартом обычно никак не связан). Эти документы могут быть еще и разными для разных проектов и продуктов
4. Нет картинки про "продуктовую архитектуру", которая не всегда связана с системной архитектурой, а для SA иногда и важнее.
5. Нет картинки про допустимые "кирпичики" (3d party products etc) для новых проектов-продуктов. Типа того же радара.

Вообще тут очень много артефактов, которые скорее в сторону System Architecture, а не Solution.
Это, конечно, близкие должности, но лучше бы описать в начале статьи "а что такое SolutionArch в данной статье"

1. Я писал для обоих - что надо передать или что надо запросить
2. Для проекта или группы проектов
3. С этим согласен - коллеги выше, что нужна матрица коммуникаций
4. Что именно имеется ввиду под архитектурой продукта?
5. Согласен

1. Так это разные вещи. Если "передать" - то это про "текущую документацию по проекту для SA", то, что вообще постоянно должно быть (хотя обычно нет, значит не очень и должно). Если принять, то это скорее "что нужно при онбординге выяснить SA".
И это, подозреваю, разные чеклисты (во втором случае многое еще про текущие проблемы и состояния)
2. Проекты про что? Если про интеграцию, то там еще и куча продуктов. Если это внедрение одного продукта, то там продуктовые проекты и проекты по внедрению сильно отличаются.
3. Матрица коммуникаций - это тоже немножко не то.
4. Внутри какого-нибудь SAP (или 1C) пара десятков разных продуктов, при этом для системной архитектуры там все одинаковое, а вот продуктовое - сильно разное. И нужно рисовать соотношение этих продуктов (и я не знаю, какая стандартная диаграмма для этого подойдет).

А, и нет главного документа "планы по развитию". Для передачи дел он чуть ли не важнейший.

там же последний пункт - Roadmap, не?

Не очень понимаю. Почему разные чеклисты? В процессе KT же участвуют двое - один передает, другой принимает.

2. Проекты про разработку продукта, да, это нигде не написано, я согласен

1. Roadmap продукта? Или по всем проектам? А в тексте вообще про планы бизнеса.
Но интересно зачастую "Projects/Products Tech/Business Debts" и как именно этот долг будем выплачивать. Но Roadmap бизнеса тоже интересен.

Хм. Обычно если приходит новый SA, то старый SA уже недоступен )

это печальная ситуация) в EPAM стараются делаются трансфер, когда доступны оба. Получается не всегда конечно

А зачем вообще тогда делают передачу?