Вот здесь статья про то как парадигмы кодирования, как они "испортили" программирование.
Но самое интересное в комментариях, например вот этот

"apevzner
25 мая в 20:00

Стиль, одним из основателей которого был Дейкстра, называется "структурным программированием", потому что следование ему придаёт коду определенную структуру, состоящую из простых блоков (циклы, операторы ветвления, присваивания, вызовы процедур и т.п.). При этом разнообразие типов таких блоков невелико и блоки исполняются последовательно, имея одну входную и одну выходную точку.

Это делает код пригодным для анализа, ручного и автоматизированного"

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

Здесь новая статья про представляемую как аналог СППР систему ERP-tools от Дениса Ермолаева.
Приводится простой алгоритм работы в системе и планы по её развитию.

Интересно глянуть на проблемы, которые автор назвал пока как нерешенные им:

1. Мечтаю понять, как добавить новые элементы графической схемы к платформенным объектам, например, кружок как «начало». Тогда можно будет рисовать схемы в формате а-ля bpmn 2.0 прямо в 1С. Если есть у кого знакомые, кто дорабатывают Платформу – попросите добавить элементы из библиотеки bpmn 2.0 и тогда и ERP-Tools и СППР будет использоваться для отрисовки схем.

2. Интеграция с ЯндексТрекер готова, но не могу придумать сценарий использования заявок в ЯТ и их досками. Не понимаю. Работа в «тонком клиенте 1С» на порядок приятнее чем в web-версиях трекеров.

3. Мобильное приложения для Заявок. Также не могу придумать, какой объем информации из заявки туда выводить, какие манипуляции можно передать туда.

Можно здесь провести интеллектуальный штурм и пособить автору подсказками от своего блестящего ума или опыта.

Не стесняйтесь ставить под публикациями пальцы вверх или вниз или иные смайлики.
Эта обратная связь сильно поможет нашупывать интересные сообществу темы.
Нет реакции - трудно понять стоит ли продолжать в том же направлении.
Другими словами, управляйте тем что хотите видеть в канале.

Вот этот продукт заявлен как расширение к СППР. Описывает архитектуру бизнеса, ИС, конфигураций, интеграции. Основная нотация С4, но можно отрисовывать и в bpmn. Вызывает уважение что автор свой продукт описал в своем продукте.

Достаточно полное описание методики работы с СППР и git от Раруса

СППР сейчас у в релизе 2.0.14.15 (март 2025)
И слухи что 1С готовит более новое платформенное решение СППР.
Ранее были слухи, что от СППР уходят в сторону системы Управления Проектами.
У кого есть информация свежее и надёжнее?

С 1 июля 2025 СППР будет стоить уже 11100р

Идеи в разработку и на размышление, что можно было бы иметь в СППР:
Функционал конвертации блок-схем в код с помощью LLM.
Типа нарисовали в СППР блок-схему, а она переводится в код.
Примерно как здесь, но, конечно, сложнее

К обсуждению в чате на днях о работе с требованиями в СППР:
Похоже, в скором будущем, человек, работающий с требованиями,
будет называться не консультант или аналитик,
а промпт-инженер.
Статья

Минутка юмора из жизни отдыхающих безработных.
Только что мне писала эйчар, обращающаяся ко мне "Кирилл",
хотя я вовсе не Кирилл.
В ответ на обещание называть её "Кирой", хотя она вовсе не то самое,
мне был прислан скрин ТГ эйчара, где мой профиль виден не то что "Кирилл",
а даже "Кирилл уголь".
Никогда меня ещё так изящно негром не обзывали.
Вот почему я так долго ищу работу!
Ведь запрашиваю я доход не как у негра!
Поскольку в чате СППР много опытных аналитиков,
прошу в качестве разминки ума, дать объяснение,
каким таким макаром можно некоего ИТ-Прохора назвать нечаянно углём.

Фактически, когда мы задаём правила для ИИ, документируем и кодифицируем их
(промптируем - наверное это так надо по современному называть),
то, де-факто, мы задаём архитектурные стандарты,
по которым затем работает кодинг и тестирование (идёт исполнение).
Как вам такая мысль?
Где место этим архитектурным стандартам (промптам) в СППР?

Вот здесь предложено решение по описанию bpmn-схем в "родных" bpmn 1C.
Как плюс заявляется, что к узлам схемы можно привязывать объекты (документы) 1С.
Фактически это конкурент 1СДокументооборот в части описания БП и их привязки к документам конфигураций.
Или конкурент описанию БП в СППР.
Из минусов можно выделить что предложено исключительно графическое решение, а не "математическое".
Это значит, что обратный ход - отрисовка схемы по связям документов невозможен
и при существенном изменении БП можно влипнуть в проблему согласованности ветвей массива БП,
т.к. человеку это не под силу отследить, даже команде человеков.
Итак, ваше мнение, стоит вкладываться в создание таких продуктов
или это тупиковый путь?

Интересное решение по управлению правами доступа
с автоматическим подбором прав.
https://infostart.ru/marketplace/1987840/
Проверка прав на основе БСП (чтобы это значило?), создание "кэша" для расчета прав....
Есть мысли можно ли к блоку "Права и роли" в СППР привязать подобное?
Хотя бы для фиксации рассчитанных ролей и профилей в специальных объектах СППР?
Всё-таки описание системы прав дело достаточно трудоёмкое, в СППР никак не автоматизированное,
а особенно в части согласования прав, видимости объектов и т.п.

Для тех кто делает доработки в СППР
Здесь заявляется что MCP-сервер по знаниям 1С уже реализован.
То есть уже можно применять LLM в среде 1С на основе анализа кода и метаданных 1С.

Интересно было бы почитать этот доклад:
Особенно в части приложения к СППР - как архитектуру туда отторгать от архитектора.

Алексей Лустин Инфостарт, Директор по развитию
Доклад: Отторгаемые знания архитектора 1С как сервис

Я расскажу о том, что такое база знаний архитектора 1С, которую можно и нужно обогащать каждый день вместе с командой, чтобы в итоге получить «граф-знаний» про ваш ИТ ландшафт – от заказчиков до инфраструктуры – чтобы переиспользовать его в процессах ИТ производства.
Поговорим про:
аббревиатуры MCP, RAG, OpenCipher и Zed;
как их связать с «процессом проектирования прикладных решений» и «процессом надзора за корневыми причинами инцидентов».
И, конечно же, посмотрим, при чем тут «Метаданные 1С», «Технологический журнал 1С» и другие части экосистемы 1С.

Мысль про конец фреймворков корпоративной архитектуры с просторов интернета
в связи с наступлением эры ИИ:

(кратко: статичные конструкции на основе алгоритмической последовательности уступят динамическим описаниям)

🪦 Фреймворки корпоративной архитектуры R.I.P. ТОГАФ. Захман. ВЭД. ДОДАФ. Все это по-прежнему под отсылкой. Все еще защищено. Но ни один из них не выдерживает контакта с предприятиями, использующими искусственный интеллект. Потому что мир, для которого они были построены Линейным, Предсказуемым, Управляемым комитетом, исчез.

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

📉 Статичные чертежи не успевают за ними.
📍 Слайды по системе управления вас не спасут.
🧠 Организациям с искусственным интеллектом не нужна документация — им нужны рефлексы.

Так что же приходит на смену всем этим фреймворкам?
➡️ Динамическое моделирование намерений
➡️ Наблюдаемость в режиме реального времени
➡️ Автономное соответствие требованиям
➡️ Архитекторы как оркестраторы

🔗 Только что опубликовано: «Смерть фреймворков корпоративной архитектуры: что будет дальше в эпоху искусственного интеллекта».

Это не просто критика. Это план для мира после плана.
👇 Читайте ее, не соглашайтесь с ней, воруйте у нее - но не игнорируйте ее.
Потому что будущее уже наступило, и оно не ждет одобрения руководства.

#AINative #FutureOfEA #MaverickArchitecture #DeathOfTOGAF #LivingSystems

Технология как работать с git и конфигуратором без хранилища и EDT.
Тоже можно было бы прикрутить к СППР

Кто смотрел курс от 1С
"Методика поддержки и сопровождения прикладных решений на базе платформы 1С:Предприятие 8"
Есть ли там что-то полезное для применения в СППР?

Вот вам ниже цитата-ещё мысль с просторов интернета о различиях
старого формата архитектора/архитектуры и архитектора с ИИ

От понимания такого подхода зависит то, какой надо строить "СППР"

Краткая выжимка:
Архитектор с ИИ проектирует поведение системы, а не что она делает.

Если вы архитектор, это ваш момент
Мир переходит от API к агентам, от безотказной работы к неопределенности
И самые ценные архитекторы сегодня учатся управлять ИИ

Большинство проектов ИИ поставляются без реальной архитектуры
Не потому что нам все равно
Но поскольку роль архитектора ИИ становится все более актуальной,
И во многих организациях он по-прежнему отсутствует, неправильно понят или неправильно назначен.

Встречайте архитектора искусственного интеллекта

Чем эта роль отличается от роли архитекторов, которых мы знаем уже десятилетиями?

Давайте разберем это

🔸 Традиционный архитектор
Строит детерминированные системы
Мыслите в терминах API, инфраструктуры, потоков данных и времени безотказной работы

🔸 Архитектор ИИ
Строит вероятностные системы
Мыслит в терминах LLM, агентов, памяти, циклов оценки и сетей безопасности

Так что же на самом деле меняется?

✅ Формирует поведение системы, а не только то, что она делает
✅ Проектирует циклы оценки, логику отката и системы обратной связи, а не только конвейеры CI/CD
✅ Сопоставляет подсказки, память, использование инструментов и риски галлюцинаций, а не только схемы данных
✅ Организует рассуждения, поиск и надежность, а не только диаграммы

Проще говоря, эта роль гарантирует, что системы ИИ не просто работают
Они ведут себя предсказуемо, регулярно и безопасно в реальном мире.

Это поднимает большие вопросы.

• Должны ли ваши нынешние архитекторы перейти на эту должность?
• Или вы пригласите кого-то, кто уже это делал?
• Что сломается, если никто так не думает?

Мы уже это видели.
Агенты запущены без цикла оценки, без отката, без памяти
Полезный один раз, потом сломанный или опасный на следующий день

Это не просто еще один вариант использования.
Ему нужен свой собственный план.

Ваша организация уже разрабатывает систему для этой роли?
Или все еще относиться к ИИ как к плагину

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