Есть такой подход "шаблон архитектуры". Что-то вроде аналога СППР, если кто не хочет связываться с этой концепцией (СППР) или кому попроще.
Потерял ссылку на крупное предприятие с описанием его подхода по этой методике.
Кто сталкивался и помнит название? Дайте знать или ссылку.
Это точно не «Корпоративный шаблон 1С:ERP «Шерпа» от Газпромнефти.
Та помнится от металлургов или что-то близкое к ним.

Готовлю доклад на Инфостарт (утро 1 июня 11.20)
"СППР – технология применения, недостающая функциональность, основные альтернативы – «Архитектура как код» и «Шаблон архитектуры»"
Рассматриваю там порядка 10 ПО/методик развивающих функционал СППР,
которые обсуждались в чате канала или в оффлайн общении с пользователями чата.
Цель рассмотрения - показать как доработки ложатся на типовой процесс СППР,
весь ли его исполняют, что ещё необходимо.
Думаю, поможет многим сделать выбор среди инструментов или скорректировать свой процесс работы в СППР.
Также рассматриваю что именно является ключевой проблемой СППР
и какие именно доработки позволят сделать продукт с wow-эффектом
и/или конкурентным преимуществом.
Т.е. в каком направлении копать, вести разработку функционала.
Если есть какие-то вопросы или мысли к докладу - прошу высказаться в чате.

В этой статье КРОК раскрывает как используется СППР в их эко-системе проектного внедрения корпоративных продуктов 1С.
Ранее про СППР в КРОК излагалось в этой статье.

Дайджест статьи:
1. В основе методологии лежит Oracle AIM скорректированная под 34й ГОСТ и адаптированная с учётом опыта внедрений 1С.
2. СППР (адаптированная) в основном рабочее место для Консультанта, которым моделируются (декомпозируются) Процессы.
3. Опора в методологии на процессный подход (бизнес-процессы), а не функциональные требования к системе.
4. Ключевой объект в СППР - Каталог Бизнес-процессов - на основе которого проектируются Функции (функции де-факто подчиняются бизнес-процессам).

Интересный момент, в начале статьи приведены 9 характерных проблем на проектах.
Кто сможет, прочитав статью, ответить на вопрос
как КРОК с помощью описанной методологии,
решает проблемы 7 "Проектное рабство" и 9 (даже не знаю как её сформулировать),
или СППР в КРОК победило "проектное рабство" и Добби КРОК теперь свободен и может ставить условия заказчику?

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

Пока в чате идёт дискуссия что есть DocHub и как его с 1С соединить.
Станислав Султанов даёт на Инфостарте практику
"Мастер-класс по применению DocHub в 1С, или Создаем единое место правды по архитектуре ваших приложений"
Слоган "место правды" может стать локальным мемом в нашем 1С-сообществе :)))

Вендор и производитель IT-инфраструктуры, пользовательского и телеком - оборудования YADRO в поиске инженеров 1С в департамент внутренней разработки.

Помимо доработки готовых решений и их обслуживания, нужно будет писать программы “с чистого листа”, готовить базовые элементы регламентов тестирования, писать тест-сценарии и многое другое в зависимости от выбранной тобой вакансии.

От кандидатов ребята ждут опыта, готовности работать над сложными и, конечно, интересными задачами, на некоторые позиции будет плюсом сертификат 1С. Команда YADRO предлагает гибридный формат работы, профессиональную и открытую команду, хорошую мотивацию.

Выбирай вакансию и скорее отправляй резюме:
• Старший программист 1С
• Инженер инфраструктуры (DevOps)
• Инженер по тестированию 1С

Инфостарт начался . Доклад в 12.30. Сейчас преддокладный мандраж.

Оффтопик
Знаменитый огненный танец Инфостарта

Информация от Александра Сазонова по его проекту СППР+

Коллеги, добрый вечер!

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

По qr-коду можно перейти на сайт проекта.
Кто хочет потестировать функционал, обращайтесь.

По итогам Инфостарта май-июнь 2024...
Доклад Романа Пионтика по подходу "Архитектура как код" на фреймворке SEAF
Роман является лидером в РФ в практической реализации методологии АаС
А вот как подход АаС на практике соединить с фреймворком SEAF об этом рассказывает Станислав Султанов.
Станислав реализовал связь SEAF (Dochub) с СППР 1С.
Получается сейчас лидерство за реализацией современного подхода в блоке 1С за Султановым.
Он в своём мастер-классе на Инфостарте предметно показывает как в СППР работать с описанием КОРПОРАТИВНОЙ архитектуры ИС и процессов
и при поддержке Романа Пионтика создаёт описание как Архитектор 2.0 на уровне организации с подведением к функциям и метаданным конфигурации 1С (ЕРП).

Вдогонку к предыдущему посту...
Всё новое - хорошо забытое старое.
В своё время к этому подходу и реализации была близка система "Дракон" (Тышов, Араптанов) (ей вроде лет 20 , как минимум?).
Если внимательно её изучите, то можете увидеть много знакомых вещей.
Что же не хватило Дракону?
На мой взгляд - более чёткой методологии, которая лучше выражена в подходе АаС.
Это те самые "карточки".
Почему "карточки" должны войти в основу технологии и СППР и других систем описания архитектур ИТ и бизнеса - об этом и многом другом в моём докладе на Инфостарт.

По итогам Инфостарта опубликована статья
"СППР – технология применения, недостающая функциональность. Основные альтернативы – "Архитектура как код" и "Шаблон архитектуры""
Можно ли, окружив СППР доработками, повысить её эффективность?
Есть ли такие доработки в готовом виде на рынке?
Дисклеймер: данная статья не повторяет доклад, а лишь излагает мысли и акценты, которые докладчику показались прошедшими мимо слушателей.

За доклады Инфостарта можно проголосовать постфактум для обратной связи авторам.
Вот здесь https://event.infostart.ru/analysis_pm2024/video/
Отмечайте звёздочками понравившиеся доклады.
Ваша поддержка авторам очень важна и помогает корректировать подготовку к докладам и оценку их значимости для сообщества.

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

Эта статья для тех, кто размышляет стоит ли в СППР реализовать управление кодом.
В статье интересная мысль - что разделение на монолиты и микросервисы слишком примитивно и не помогает в определении архитектуры приложений, а лишь запутывает.
https://habr.com/ru/articles/825532/

В продолжение вчерашнего поста.
Статья с идеей (вновь возникшей в который раз) хранить код в бинарном виде, как бы уже в виде синтаксического дерева (не АСТ).
Инструменты для построения синтаксического дерева есть. 1С в пролёте. Пока.
Это к вопросу на докладе Инфостарт "зачем тащить в СППР код".
Ну вот, возможный вариант ответа - не код, а пропарсенный особым образом код.
Опять же diff`ы может проще создавать.
И от бинарного формата один шаг до XML.
И ссылки на реальный опыт создания мультиязыкового IDE

И, бинго, в этом комменте собственно описывается прототип формализации кода в графическом виде фактически,
а на самом деле в формате современных no/low code систем.
Привет Дракону, который до этого не дошёл. Но сколько же здравых идей было зарыто в этом Драконе, это делает честь создателю.
А раз есть формализация кода, значит, возможно предварительное архитектурное описание.
Вот вам основа для управления кодом через архитектуру.
Вот ответ на вопрос зачем "тащить код" в СППР.