По итогам доклада "СППР – технология применения, недостающая функциональность. Основные альтернативы – "Архитектура как код" и "Шаблон архитектуры"" на Инфостарте 2024 май-июнь 2023 года

19.06.24

Архитектура - Архитектура решений

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

За двадцать минут, отведённых на доклад, с пулеметной, как казалось, скоростью надо было изложить несколько ключевых тезисов по опыту использования СППР. Теперь, спустя некоторое время, в более спокойном режиме можно проанализировать, что же происходит в мире СППР.

Прежде, посмотрим на картинке, как выглядит упрощённо процесс работы в СППР, и сделаем изложение на её основе:

 

 

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

Однозначно, главный недостаток - это очень высокая степень трудоёмкости при работе с СППР.

Использование СПППР на проекте и в сопровождении само по себе очень сильно поможет навести порядок в работе командной цепочки: аналитик-консультант-архитектор-программист-тестировщик-руководитель проекта. Но какой ценой!

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

Для мэппинга необходимо, чтобы из кода ПО был выделен список метаданных и список процессов пользовательского уровня. Выделять метаданные 1С СППР умеет, а вот процессы (функции) нет. Именно на этом и происходят затраты времени командой – ей приходится вытаскивать из ПО список процессов (функций), по сути восстанавливать метамодель ПО. Это можно сделать вручную, но долго. Весь труд может отправить в корзину выход нового релиза.

Вследствие этого, за проблемой первой очереди – трудоёмкости, второй недостаток - в СППР не хватает функциональности. И, самое главное, функциональности по извлечению процессов из кода конфигурации. Собственно трудоёмкость и вызывается недостатком функциональности СППР по автоматическому извлечению функций из кода. Такая вот тавтология.

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

Указанное в настоящей статье не единственный недостающий функционал в СППР, в самом докладе изложен перечень must have в СППР, без которого СППР не будет адекватным запросам рынка продуктом.

Тем не менее, практика использования СППР идёт уже более 10 лет, и многие успели реализовать тот или иной недостающий функционал. На основе различных готовых наработок можно через интеграцию резко повысить эффективность СППР.

При подготовке доклада мне пришлось провести исследование на основе предоставленных мне материалов и открытых данных ряда продуктов и методик, некоторые стоит выделить особо. Все важные детали приведены в докладе, здесь же выделим буквально по одному ключевому функционалу отдельных разработок.

Сначала стоит обратить внимание на блок «Бизнес-процессы», где особенно не хватает функционала отрисовки бизнес-процессов и их увязки с метаданными и функциями конфигурации. Здесь в лидеры вырывается BIA Technologies c ПО «Sunrise BPM для СППР». По их изложению они сделали свой движок, который может заменить импортные решения и реализовать привязку к объектам конфигурации. Также заявлено, что в разработке функционал отрисовки процессов из шаблонов.

Вслед за этим, смотрим на разработку Евгения Чекушкина «Управление сборкой GLI. Расширение для конфигурации 1С:СППР и процессы СППР в нотации EPC». Её сильная сторона не в отрисовке в EPC, а в том, что реализована связь от Требования к коду в Gitlab. Под Требование создаются информационные базы данных и кластеры, управляемые через СППР для создания ветви разработки, а под каждую БД ведётся ветка разработки кода в gitlab. Таким образом, получается сквозной контроль от Требования к коду разработки.

В итоге, интегрировав Sunrise BPM и Управление сборкой GLI к СППР, можно получить в руки куда более мощный инструмент для аналитиков (отрисовка) и разработчиков и руководителя проектов (привязка кода к требованию заказчика для объяснения, что именно сделано на проекте исходя из каких требований).

Далее следует упомянуть не столько ПО, сколько методологию «Архитектура как код», которая продвигается в РФ Романом Пионтиком и его сообществом, что уже выразилось в создании фреймворка SEAF + DocHub. По этой методологии вводится понятие «карточек элементов», с помощью которых описывается архитектура бизнеса и архитектура ИС. Это, в частности, карточки «Манифест» (аналог метаданного в 1С) и «Контракт» (аналог связи, процесса (функции) в 1С).

Идеология «карточек» это то, чего очень не хватает методологии СППР. Если реализовать «карточки» в явном виде в СППР, то очень многие функции, включая отрисовку бизнес-процессов и автоматическое создание списка процессов из кода, могут быть реализованы весьма просто, и позволят проводить интеграцию с SEAF Пионтика.

Интересна также функциональность DocHub для управления проектной документацией, архитектурными описаниями и для визуализации бизнес-процессов и функциональности ПО, в т.ч. для управления разработкой. Это реализация подхода к методологии «Архитектура как код» (АаС). Здесь «код» понимается не как простыни текста, которые пишет программист, а как числовое и символьное выражение объектов как карточек с реквизитами и в формате yaml.

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

К интересным фактам можно отнести то, что уже лет 20 существует российская разработка «Дракон» (создатель Тышов, докладчик на Инфостарте Араптанов), которая, по сути, предлагала то, что сейчас озвучивается как современная мейнстримовая методика «Архитектура как код». В «Драконе» есть и отрисовка бизнеса от KPI и бизнес-процессов, и графическое представление кода (функционала), выраженные как единый процесс.

Но…. «Дракон» почему-то не получил широкого распространения. На мой взгляд, по той причине, что «Архитектура как код» имеет лучшую методологическую основу в виде «карточек», а «Дракон» сосредоточился на концепции кода внутри функциональных обозначений графических схем, которая не всегда положительно встречается сообществом разработчиков (код – как текстовое значение реквизита узла графической схемы).

С другой стороны, если внимательно почитаете материалы по Dochub, то заметите, что там подход АаС предлагается для описания архитектуры бизнеса и архитектуры информационных систем, но как обязательный для описания функциональности ПО не заявляется. «Дракон» же реализовал методологию следования кода ПО за описанием бизнес-процессов и требований в графическом виде. В нём код разбивается на функции, как это описано графически в иерархическом дереве процессов. Фактически это означает, что разработка должна вестись строго в рамках архитектурного описания от архитектора, а не по воле программиста. Вот это и встречает неположительную реакцию разработчиков.

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

Особенность «монолита» в том, что есть код, который укладывается в иерархическое дерево описания функций, и это код, задающий функции пользовательского уровня. И есть код, который укладывается в отдельные, не всегда иерархические деревья. Это «сервисный» код, который реализует функциональность, не интересующую пользователя, но ему необходимую. Например, функционал «Реализация» это пользовательский уровень и ветвь одного дерева. А функционал «Вывод динамического списка в окне выбора» - это сервисный код, пользователю он нужен, но обычно никогда не заявляется как требование. Последнее часто является платформенным кодом (функционалом), но бывает и кодом на уровне конфигурации. В итоге, архитектурное описание выглядит графически как «лес» деревьев, где, как минимум, одно дерево растёт перпендикулярно другим деревьям. Программисту трудно уложиться в требования такого архитектурного леса. Но, может, это должно стать обязательным, иначе как контролировать архитектуру ПО и соответствие ей кода? Деревья можно извлечь реверс-инжинирингом, и это не будет классическим деревом вызовов или AST-деревом.

В беседе с Романом Пионтиком был затронут этот вопрос, и он высказал мнение, что считает неактуальным жёстко регламентировать написание кода через архитектурный подход. После моего доклада также слушатели поднимали вопрос «зачем тащить код в СППР».

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

На этом фоне, возможно, будет интересным решение от Александра Сазонова, который готовит выпуск своего продукта, получившего рабочее название «СППР+» и доклад по нему на осенней конференции Инфостарт 2024.

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

Презентация из доклада и видео выступления доступны через Инфостарт.

СППР AaC Архитектура DocHub SEAF Sunrise BPM

См. также

Архитектура решений Платформа 1С v8.3 Конфигурации 1cv8 Бесплатно (free)

В данной статье мы рассмотрим панель системы 1С: Аналитика - План фактный анализ реализации работ заказчикам и вывод о конфигурации 1С: ERP Управление строительной организацией.

24.04.2024    755    0    Koder_Line    1    

1

Архитектура решений Пользователь Платформа 1С v8.3 Конфигурации 1cv8 Строительство Бесплатно (free)

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

22.03.2024    598    0    Koder_Line    0    

1

Архитектура решений Пользователь Платформа 1С v8.3 1С:ERP Управление предприятием 2 Бесплатно (free)

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

22.02.2024    4572    0    Koder_Line    1    

4

Архитектура решений Пользователь Платформа 1С v8.3 Конфигурации 1cv8 Бухгалтерский учет Управленческий учет Бесплатно (free)

Здравствуйте! В данной статье мы рассмотрим описание системы ТОиР и область ее применения, функциональные возможности и структуру 1С:ТОиР Управление ремонтами и обслуживанием оборудования. В современных условиях динамичных рыночных процессов и стремительного развития технологий, эффективное управление техническим обслуживанием, ремонтом и оборудованием становится ключевым фактором для обеспечения бесперебойной работы предприятий различных сфер деятельности. В этом контексте, система «Техническое Обслуживание, Ремонт и Оборудование» (ТОиР) на базе платформы 1С: Предприятие выступает как неотъемлемый инструмент для эффективного управления всем жизненным циклом технических средств.

24.11.2023    2500    0    Koder_Line    0    

0

Архитектура решений Программист Бесплатно (free)

Рассмотрим применение архитектурной проверки задач в процессе разработки.

30.10.2023    4662    0    ivanov660    10    

33

Архитектура решений Пользователь Платформа 1С v8.3 Конфигурации 1cv8 Управленческий учет Бесплатно (free)

В августе 2023 года увидел свет новый релиз 3.0.7.1 системы 1С:ТОИР КОРП. Третья, наиболее прогрессивная редакция решения для управления ремонтами и обслуживанием оборудования на платформе «1С:Предприятие», активно развивается, обогащаясь новым функционалом и раскрывая всё более широкие возможности для пользователей, которые стремятся повысить эффективность управления активами. Что изменилось в системе с выходом нового релиза?

01.09.2023    1411    0    Desnol_Soft    0    

2

Архитектура решений Пользователь Руководитель проекта Платформа 1С v8.3 Конфигурации 1cv8 Управленческий учет Бесплатно (free)

В августе 2023 года команда разработчиков «Деснол Софт» завершила разработку модуля интеграции 1С:ТОИР КОРП, ред. 3.0 с системой Renga цифрового комплекса 1С:BIM 6D. 1С:BIM 6D — это российский интегрированный программный комплекс для цифровизации предприятий строительной отрасли в соответствии с технологией информационного моделирования (ТИМ / BIM — Building Information Modeling). Он включает в себя BIM-систему Renga, а также ряд отраслевых решений «1С», позволяющих работать с информационной моделью на всех этапах жизненного цикла строительных объектов.

16.08.2023    637    0    Desnol_Soft    0    

2

Архитектура решений Платформа 1С v8.3 1С:Управление торговлей 11 1С:Управление нашей фирмой 3.0 Бесплатно (free)

В данной статье мы сравним конфигурации 1С: УНФ и 1С: УТ, их возможности учета финансовых операций на предприятии, налогового учета и управления персоналом.

14.08.2023    2859    0    Koder_Line    8    

2
Оставьте свое сообщение