Интересная статья про место архитектора с точки зрения объективных глобальных процессов.
Для тех кто пытается понять что архитектору делать, куда ему развиваться и идти ли в архитекторы.
Тезисы на подумать из статьи:
1) Согласно закону Мура ИТ замедляется в настоящее время. Взрывной рост прекращается, идёт переход к горизонтальному развитию.
Именно это время оптимально для архитектора, здесь он нужнее всего и боле выгоден.

2) Идея о роли архитектора - его задача реализовать схему Шеннона (алгебру Буля) к архитектурным описаниям.
Это значит преобразовать архитектурные описания в уравнения.
А раз есть уравнения, то можно провести автоматический рефакторинг/упрощение.
Вот это и есть автоматизация архитектуры.

3) Agile и т.п.

Гибкие методологии разработки, на мой взгляд, главный гвоздь в крышку гроба архитекторов.

Командам, которым для разработки программы достаточно фреймворка можно отказаться от архитектора.

(имеется в виду фреймворк в который заложено много паттернов проектирования)
Водопад - эффективная схема времён дорогих компьютеров и дешёвых программистов.
Эджайл - это схема заменяющая архитекторов на техлидов и тимлидов.

4) Программисты - "психические тормозы". Бизнес - психические "разгонщики".
Бизнес+программисты = продуктивная шиза в эджайле. Шиза разруливается посредником в коллективе, тем же архитектором.

5)

Естественным развитием гибких методик разработки стал архитектурный подход Domain Driven Design (DDD)

...

и ввёл понятие "Единого язык

Собственно СППР1 и была основана на попытках свести к единому языку общений всей команды.

https://habr.com/ru/companies/oleg-bunin/articles/735032/

Записки в формате черновика от участника нашего чата.

Сказ о том, как одна команда монстра сопровождала
+ –
Данная статья родилась в муках сопровождения одного интересного субъекта.
Монстр, кто он...
Какие монстр породил проблемы
Решено, дракона надо приручить...
 
Монстр
Монстром будем называть конфигурацию ЕРП с двумя встроенными отраслевыми продуктами, Модуль CRM и Модуль PM. Также к монстру прилагаются доработки, выполненные различными командами в разное время, разбросанные по самой типовой конфигурации и по 70 расширениям.
Насколько удалось выяснить, такой роли, как архитектор, в процессе создания Монстра не было, поэтому использовались разные подходы доработок, например: 
- одно расширение, один разработчик;
- одно расширение, одна подсистема;
- Новые метаданные создавались частично в расширениях, частично в основной конфигурации..
Какие монстр породил проблемы..
Итак, сей продукт мне приходилось поддерживать около трех лет. В процессе поддержки вылезли следующие проблемы:
1. Формы.
Одна и та же форма могла быть захвачена в нескольких расширениях. Например форма справочника Ресурсные спецификации редактировалась в 6 расширениях. Для примера, чтобы внести правки, понадобилось выяснить, а где у нас сделана "вот эта кнопка", что она делает, кто имеет к ней доступ и т.п., ответить с ходу не представлялось возможным. Плюс ко всему, кнопка могла быть выведена на форму программно, а могла быть добавлена мышкой. Код добавления кнопки мог быть в самой форме в расширении, а мог присутствовать в переопределяемом общем модуле...
Форма в расширении, при изменении формы поставщика в основной конфигурации, автоматически не обновляется. Нужно обновлять ее вручную. И таких форм может оказаться не одна, и не две, после обновления основной конфигурации.
 
Некоторые формы в расширении после путешествия через несколько платформ (в процессе сопровождения расширения прошли от 8.3.16.хххх до 8.3.21.ххх) начали "странно себя вести". В одном случае клиентский сеанс просто падал при попытке открытия определенного справочника. В другом случае в общий модуль, куда передавался контекст формы, приходил неверный тип данных в одном из реквизитов контекста. В обоих случаях помогло только полное удаление формы в расширении и повторное ее создание.
2. Данные в расширениях
В расширениях присутствовали объекты с данными. Часто требовалось в одном расширении обращаться к справочникам/документам/регистрам другого расширения. Думаю, не нужно расписывать, какие это может вызывать неудобства.
Забегу вперед, скажу, что решено было перенести в процессе сопровождения данные из расширений в основную конфигурацию, при этом:
При переносе нескольких справочников из расширения в основную конфигурацию возникла однажды платформенная ошибка "Найдены дублирующиеся записи в менеджере баз данных...". Применить обновление основной конфигурации с новым справочником не получалось. С помощью выгрузки конфигурации и расширения в файлы были проверены идентификаторы объектов метаданных, одинаковых идентификаторов не нашлось. Проверены имена объектов, тот же результат. Опыты на копии показали, что помогает полное удаление расширения и добавление его заново. А у нас в расширении есть данные.... Повезло, что данных в расширении было мало, удалось выкрутиться.

При попытке переноса объекта с данными в другом случае, все прошло гладко, но в процессе проверки на копии вылезла "магия": "Обращение к несуществующей константе". Ошибка выскакивала при открытии любого справочника. В расширении осталась константа. Обращения к этой константе были только в этом же расширении. Здесь обошлось, потому-что "магия" не помешала быстро перенести остальные объекты с данными из этого расширения и удалить его. После удаления расширения ушла и ошибка.

Следующий перенос справочника. Расширение отключено после переноса. Платформенная ошибка: Ошибка SDBL:

Поле Fldххх таблицы Documentххх не может принимать значение NULL

Для сторонников подхода "Архитектура как код" есть своя среда и,развиваемся Сбером, платформа. Вышел сводный, так сказать, пояснительный материал.
Кто ищет альтернативу подходу СППР можно ознакомиться. Напоминаю, что есть альтернативы
1) Как в СППР. Вот, кстати, как его кратко назвать? Парсинг конечного ПО в специализированную среду хранения кода и метаданных?
2) Архитектура через шаблон - активно развивается некоторыми крупными компаниями.

В связи с востребованностью повторю ответ Евгения Чекушкина на вопрос тех кто СППР с git пытается подружить https://t.me/SPPR_1C/9113

В копилку материалов (что-то не вижу было ли ранее опубликовано в нашем канале, поиск по названию не нашёл)
Использование 1С:СППР при разработке 1С:ERP
https://www.youtube.com/watch?v=uHPQ_sy0-uQ&t=1s

Понятие "Механизмы" в СППР.
Предлагается рассматривать его как аналог "API" в других средах разработки, в котором разработчик объявляет как будет обработан объект (документ).
В контексте 1С "обработан" - это значит разнесён по регистрам.
В контексте подхода к разработке это "библиотечный" подход - при котором в конфигурацию закладываются механизмы, позволяющие обрабатывать даже ещё не существующие объекты (документы).
Т.е. разработчик механизма заранее учитывает, что разработчика других доработок конфигурации могут создать свои объекты, но механизм первого разработчика опознает и примет к проведению любой новый объект на основе "API"-описания.
Говорят на таком подходе построена 1С ЗУП.
Для большей детализации рекомендуется смотреть презентацию 1С "Механизм проведения в концепции модульности "Механизм проведения в концепции модульности"

Инсайд
Один из участников нашего чата сообщает, что у него в наличии почти готовый функционал загрузки профилей пользователей в СППР.
Работает на основе Microsoft TFS - запускает базу, потом запускает обработку, перехватывает xml и скармливает его СППР.
Если выскажете интерес к функционалу, разработчик чат читает и может вам ответить публично или в частном порядке.

Статья на неИТшном ресурсе, но от ИТшника, явно работавшего на нашем уровне - внедренцем сложных учётных систем.
Общий посыл статьи: ИТ правильно поступает, когда за норму берёт отказ пользователям (заказчикам) в модификации,
модификация на длительном отрезке времени невыгодна и убивает систему.
Это можно смотреть в контексте того, что приоритет за архитектурной вдумчивой и долгой проработкой изменений. А лучше отказать.
https://aftershock.news/?q=node/989974&full

На обсуждение и мозговой штурм по "модной" теме "Архитектура как код" , н уи как бы тут с СППР связать её.
https://infostart.ru/1c/articles/2031119/

Говорят в этой презентации 1С на партнёрке высказаны интересные тезисы
(называется примерно так"Управление проектами и 1С Консалтинг на корпоративном рынке", расположение примерно здесь https://regevent.1c.ru/sem0923/ 2023год):
1. СППР - "православный" продукт для управления проектами, т.е. рекомендуемый
2. 1С-Документооборот тоже "православный" инструмент для управления проектами (Я ранее говорил, что ДО в паре с другой конфигурацией, особенно с ЕРП - мощная вещь для управления бизнес-процессами. Хотя в видео, скорее всего, речь всего лишь о функционале "Управление проектами" в ДО)
3. Там доклад Лоншакова про использование СППР на проекте
4. Рекомендуют не вести все проекты в единой СППР, а на каждый проект своя СППР
5. СППР используется как мастер-система по НСИ (внутренняя доработка 1С)
6. План счетов и хозоперации тоже загнали в СППР
7. Разработка по agile (внутри водопада) в СППР с двухнедельными релизами
8. СППР используется не с конфигуратором, а с git и EDT
9. На содержание СППР нужно 4-5 человек (1-2 разработчика, архитектор-фанат-СППР, техарх, администратор). Ик!
10. Затраты на работу в СППР больше на 30%. Но это неточно...
В общем, у кого есть доступ - посмотрите, и скажите нам здесь, верно ли передана информация или это лишь неподтверждённые слухи и кривой пересказ?

Сделал сводку из чата - материал от участницы нашего чата на тему
"А про различия в подходах к проектировании и разработке (реальные, а не теоретические) можете рассказать?"
( контексте различия продуктовой разработки и проектной в СППР)
-----------------------------------------------------------------------------------------------------------
Ну ладно. Сначала лирика, чтобы в контекст погрузится.
Первое отличие и крупное - нет заказчика, есть рынок (гибридные случаи, когда продукт делается под заказчика а потом адаптируется под рынок - про такое нет близкого опыта). Вместо директора проекта - владелец продукта, вместо РП - продакт-менеджер. Тут чудес нету - если на проектах деньги должны получить с заказчика и не уйти в минус, то по продуктам деньги должны поступать с рынка и не ниже определенной границы (там план с точкой безубыточности и пр). Фантазия продакт-оунера базируется на таких вещах, как маркетинг, обратная связь, ну и такая больная тема, как метрики. Насколько капризнее пользователи, чем заказчик? Ну, например, самая частая причина провала продукта и закрытия его разработки после двух-трех спринтов - он не нужен никому. В воображении продакта всё супер, касдев показал интерес, но, например, гипотеза не подтвердилась, или это была настолько очевидная тема, что уже конкуренты подсуетились и вышли чуть раньше/лучше. Конечно, с проектом и заказчиком тоже смена команды может быть, но это больше когда уже профакапили, а не то, что после двух месяцев мирной работы им другой франч декольте показал.
Так что на счет стабильности и переделки...
Во-первых, дорожная карта, выпуски релизов... это хорошо. Но если mvp не начнет приносить хоть какой-то минимально-граничный доход (ещё не прибыль!), то дорожная карта начнет перекраиваться - под результаты A/B-тестов, под результаты опроса, под более быстрые фичи, под урезание костов и пр. Тут даже личный опыт - участие в выпуске образовательного продукта. Спланировали программу на полгода, авторы работают. Но обратная связь от первой платной когорты плюс расширенное исследование рынка подоспело - и последние темы пошли под нож, теперь быстро и оперативно надо новые спринты, переориентировать авторов и пр... а люди уже учатся.
Во-вторых, чтобы продукт окупался быстрее, маркетинговая подготовка начинается до его разработки. Поэтому есть дедлайны, которому должна быть выпущен mvp или определенная стабильная версия, особенно если под неё уже либо предзаказ, либо бета-когорта из потенциальных покупателей собрана. Далее так же - сопровождение или маркетологи требуют к определенным датам новые релизы, эскалация и претензии в случае нарушения сроков, что они не выполнили план, потому что разработка не успела/сделала навоз и пр... Разницы между дедлайном у заказчика и дедлайном по продукту я особо не заметила, разве что гнобит команду не несколько стейкхолдеров крупной фирмы, а толпа недовольных (в т.ч. в чатах и каналах) плюс обратная связь от продажников.
Поэтому, ИМХО, очень много у продукта как у проекта: есть и проекты-конфетки, и продукты-пирожки, и провалы с адочком может быть и там, и там.
Второе отличие, крупное - продукт не имеет конечного срока и может развиваться без конца (теоретически), но на практике - жизненный цикл бывает очень коротким. Эл.магазин у одного оператора фискальных данных прожил очень мало, а сил туда вложили прилично. После неуспеха команду расформировали, и все что-то разбежались.

Что там ещё было... Перенос остатков - это приходится учитывать, если продукт решили зарефакторить или устроить ребрендинг. Особенно актуально для сервисов, задействующих бигдату. Например, система рекомендаций. Они держаться на анализе накопленных данных, смена формата хранения или источников - боль, приходится придумывать переходные моменты, временные решения, пользоваться чужими сервисами (это про интеграцию ещё, кстати). Подтвержденные ошибки... Самое смешное, что было недавно - сервис электронной библиотеки, в конце года решил наградить топ самых читающих, а отдел рекомендаций обнаружил, что весь год из-за некачественного сделанного антибот-службы самые читающие пользователи их системой игнорировались. И метрики по ним поэтому в... глубоко, в общем. А метрики - главное для систем, которые не продаются обособленно, а в составе других продуктов или сервисов. Потому про подтвержденные ошибки тоже не совсем радужно. Про четкость ошибок... Тут даже мой личный опыт - от отдела сопровождения приходит жалоба студента, я её разбираю и либо делаю заявку (на корректировку продукта), либо пишу обоснование и отправляю специалисту по сопровождению. Не понимаю, чем это отличается от хелп-деска и линий поддержки.
--------------------------------------------------------------------------------
Теперь про СППР, дабы не выгнали за флуд
Если смотреть демо-базу, изменения во второй редакции, курс Филиппова, наблюдение за продактами и личный опыт ведения в СППР разной степени модификации как проекты (90%), так и подобие внутренних продуктов (10%), то пока выявила такие отличия:

- требования/идеи. Для продукта это действительно больше идеи. Которые не обязательно по СМАРТ и не обязательно отвечают критериям однозначности. Их связь с гипотезами (целевыми задачами) простая и не замороченная. И трассируемость не так важна. Требования же... если взять самый строгий пример, то требуют однозначных формулировок, атомарности, связки с бизнес-требованиями (бизнес-целями, да ещё в иерархии целей), бизнес-процессами (тоже в иерархии), согласования с заказчиком и сквозным протаскиванием до релизов и ПСИ - с указанием, что в релиз вошли изменения вот этого модуля для реализации именно этого требования, вот именно этим шагом в ПиМИ мы проверяем реализацию требования. С идеями явно попроще, и потому схема в СППР простая. Поэтому идеи обычно переименовывают обратно в требования и накручивают дополнительный функционал.

- целевые задачи, этапы. При проектной разработке цели заказчика и проектной команды различаются. Для заказчика - получить продукт, закрывающий потребности, для исполнителя - получить прибыль от своей работы (а продукт - это типа побочка, результат работы, отдаваемый в чужие руки заказчику). Цели команды продуктовой разработки в большинстве своем совпадают, словно заказчик и исполнитель в одном командном лице. СППР сделана для продукта, и потому целевые задачи и этапы должны быть связаны с этапами развития продукта. Частый пример интегратора - попытка в целевые задачи поместить свои цели, а в этапы - этапы проекта исполнителя. Приходится объяснять, что тогда у них все требования/идеи будут привязаны к одной целевой задаче "обследование заказчика" (условно), а в целевую задачу "разработка функционала" требования уже не придут и пр. И, повторюсь, как раз этому способствует, что в демо-базе пример по этапам или целям СППР как продуктовой разработки, и потому наивные и не окунувшиеся глубоко часто пытаются сделать так же (на курсе есть предупреждение).

- проект/конфигурация. Самое больное! Для продукта объединение понятно - проект по изготовлению продукта, т.е. конкретной конфигурации. Все идеи относятся к этой конфигурации и пр. Что делать с проектом, когда конфигурация (и не одна) выбирается после сбора требований и отрисовки бизнес-процессов, когда требования (например, по НСИ) могут относится ко всем конфигурациям проекта... выкручиваемся или ломаем СППР

- бизнес-процессы. Для продукта нет необходимости отрисовывать бизнес-процесс вне продукта и держать связку АS IS и TO BE (даже если "было плохо, стало лучше", то зачем плохое помнить?) И потому для бизнес-процессов в СППР очень-очень мало... а они часто нужны, и не просто как схема для услады глаз, а в декларативном описании - чтобы привязать функциональные и нефункциональные требования, функциональные разрывы (тоже чуждое для продукта понятие), функции...

Свежие данные по портрету 1сника, сколько он зарабатывает и чего он хочет. https://infostart.ru/1c/articles/2035974/

На заметку
Почему я рекомендую в СППР и рисовании схем IDEF0 и работе с НСИ и дизайном лимит в виде числа 7.
(1С в Руководстве по СППР рекомендует 6 - это не принципиально но под число 7 есть научное обоснование)
Далее цитата с просторов интернета из комментария в Хабре)

Авторы многих известных книг, например, таких как Совершенный код, Чистый код и проч. ссылаются на исследования, согласно которым человеческие возможности весьма ограничены. Часто приводятся сведения о "магической" цифре 7, как предельному числу объектов, которые человек еще может держать в голове. Следствием этого являются рекомендации и даже регламенты, например, предельному количеству аргументов функции (!) или количеству непосредственных подчиненных одного начальника. Макконнелл в Совершенном коде выводит "Главный технический императив разработки - управление сложностью" исходя из того же принципа - ограниченности человеческого ресурса.
Хороший код от кода "с душком" тем и отличается, что минимизирует уровень сложности, необходимый для его понимания и сопровождения. Ту же цель преследуют подходы, например, предметно ориентированное проектирование (DDD), принципы, парадигмы, например, функциональная (ФП).

Из литературы могу также порекомендовать книгу Ум программиста Фелин Хермано. В ней также говорится о долговременной и кратковременной памяти, трудностях, с которыми сталкивается разработчик в своей деятельности.

Здесь на 6.40 о том как используется СППР в проекте АксиомаСофт на Ростехе
Проект с огромными параметрами, количеством пользователей 6000 в пилоте / 25000 в ожидании (см. подробнее данные проекта).
Про СППР там больше рамочно, но вы сможете прикинуть что в ней востребовано на крупных проектах
https://www.youtube.com/watch?v=oYh812yy3kQ

Интерес к СППР заметно ширится.
Даже на старом добром Mista открываются свеженькие обсуждения.
Вот здесь интересная мысль о необходимости в СППР матрицы трассировки требований
"Однако, программных продуктов, в которых была бы реализована матрица трассировки, за приемлемые деньги не возможно найти"
"Вот если бы в СППР сделали матрицу трассировки - это был бы очень востребованный продукт"
Вот здесь подробнее изложено что такое матрица трассировки. (Трассибилити, sic!)