я лучше в свой блог)

Я точно помню что термин Architect Elevator и его понимание появилось давно (года 3-4 это уже точно).
но почему-то одноименная книга Георга Хопа https://www.amazon.com/gp/product/1492077542/ref=as_li_tl датируется 2020 годом.
Он где-то раньше про это уже писал? (или амазон врет и книга вышла раньше?)

Architect Elevator пришел от Фаулера еще лет 20 назад

Ссылка есть? а то что я нашел https://martinfowler.com/articles/architect-elevator.html - ссылается на Хопа, но в 2017-м

разобрался, это было уже в книге "37 Things One Architect Knows About IT Transformation" (2016)

Отдать тз на аутсорс

Здравствуйте архитекторы! Нужен ваш опыт: в нашей компании используют несколько систем: Salesforce, Infusionsoft, GoToWebinar, сайт на WP и пр. Наш отдел маркетинга решил их подружить между собой, а потом залить их в DWH и строить по ним дэшборды. Попросили меня, ETL-разработчика проработать стратегию. Я не имею опыта в реализации других решений, кроме как Comon storage integration. Какие ещё способы реализации существуют? Какие инструменты могут понадобиться? В компании есть аккаунт на Amazon AWS, сервисы RDS и Airflow уже подняли.
Буду очень благодарен любой помощи!

Может войсчат? Печатать не надо и рассказывается легче

Сильно)
Но цель скорее самим научиться писать ТЗ

вам в первую очередь нужно ответить на вопрос о том, как вы будете данные из этих систем пересекать: что будет "да, один и тот же человек/клиент", а что "ну хрен знает, похоже, но не точно". Это не про технику и технологии, а про бизнес в первую очередь

Пересечение должно быть точным, системы дублируют друг друга(точнее должны дублировать 100%, как сейчас - хз, предстоит разобраться)

ну типа совпадение фио и др (больше ничего нет) — это точное или не точное? :)

Основным маркером служит эмеил. Какие имена, география и прочее и как это донасыщать - обсуждаем)

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

я не знаю что у вас за бизнес, но схлопывать по одному критерию — это очень плохая идея почти в любом сценарии. Но может вы ничем и не рискуете)

1. Если требование ставит вопрос о том, что система как-то себя ведёт (делает что-то) - это считается функциональным требованием.
2. Если требование описывает качество поведения - то это стоит относить к специфичесому разделу.
3. Если мы говорим о качественных (хороших) требованиях, и встаёт вопрос о пограничной ситуации (например:
Автомобиль должен двигаться со скоростью не  более 100 км/ч, в течение не менее 20 часов.)
То в умных книжках рекомендуется разделять на разные требования.
Если такое требование можно определить по нескольким основаниям класисфикации - скорее всего там несколько требований, и по-хорошему их надо разделить.

Я кстати видел такой вариант, когда ТЗ пишется на спринт)
Т.е. сначала разрабатывается какой-то концепт, а потом по ТЗ на спринт контрактуется. Правда длина спринта была 4 недели.

так они еще стори нормально не написали / не порубили

Я тоже видел, и это такой трэш

Ну хз, вроде было норм