• Делай сразу хорошо – плохо само получится.

• Виды реструктуризации на текущий момент.

  • Динамическая

  • Обычный механизм реструктуризации

  • Оптимизированный механизм реструктуризации.

• Не надо прогибаться под изменчивый мир? Хотели как лучше, а получилось

• Сколько длится конвертация базы 1C на 8.2 в 8.3 на 5 терабайтах?

• Большой архитектурный просчет 1С или Как жить на 1С с базой больше 5 терабайт?

• Осторожно двери закрываются.

Делай сразу хорошо – плохо само получится

В современном мире модно что‑то постоянно менять — потому что:

• Новые формы налоговой отчетности повысят контроль и «собираемость налогов».

• Новые требования бизнеса повысят «прибыль и капитализацию в будущем»

• Нужно быстро доделать проект, который начала другая команда.

• Аудиторам нужна другая отчетность, а не как в прошлом году.

• И вообще «5 лет ездить на одной машине, а пользоваться телефоном 2 года» — моветон.

Я думаю каждый может накидать примеров, но их объединяет одно — через год это из «важно и срочно» перейдет в готовность Х% и категорию «важно, но не срочно», потому что … будут новые изменения. А далее судьба задачи зависит от запятой в «закрыть нельзя закончить» и общей корпоративной культуры.

Вроде в результате эволюции должны выживать проверенные решения и Best practice, но «давайте сделаем это по‑быстрому, а потом оптимизируем» приводит лишь к выживанию того, что мы называем Legacy. Legacy становится фундаментом к которому привязывают разные другие системы, процессы и поменять его еще та задача.

Зато плодятся средства разработки функционала, генераторы кода, целые отделы DevOps, автотесты — все, для того чтобы успеть реализовать функционал, пока он не потерял актуальность. И чем более гибко система адаптируется к изменениям, тем меньше бизнес советуется с ИТ. Зачем? Успели в прошлый раз успеют и в этот, все что не успеют дожмем через agile и бонус дадим.

За agile software development и бонусами теряется вопрос проработки архитектуры. Он как бы там есть, но всем мешает agile teaches us the true meaning of architecture потому что

“Architecture represents the significant design decisions that shape a system, where significant is measured by cost of change.”

В итоге в гонке за лидером морковкой, побеждает компромисс, который успешно догоняет всех уже через 5 — 10 лет, а иногда после выплаты бонусов. Довольно общих слов — посмотрим, как это выглядит на практике в ПО с жизненным циклом более 10 лет — платформе 1С. Да здесь изложено именно про платформу, а не конфигурации на ней. Платформа Платформа (1c.ru) это как движок для игр, в которые играют люди. Игры могут быть разных жанров, а движок\фундамент один ‑поэтому ответственность архитектора гораздо выше.  

Виды реструктуризации на текущий момент

1С представляет собой ORM систему, где добавление реквизита в объект метаданных через конфигуратор платформа обрабатывает сама. т. е. определяет\создает таблицы, в которые нужно добавить колонки, дополнительные поля индексов и многое другое. Реквизит можно сделать составным типом (например ссылка, строка, число), и даже сменить тип — платформа все сконвертирует сама.

С точки зрения разработчика 1С все реализовано красиво и относительно надежно, можно вообще не думать, что творится внутри СУБД при реструктуризации. Все визуально, даже формы, которые сохраняют и читают реквизит не потребуют написания кода — просто положи реквизит на форму. Видно, что архитектуру функционала быстрой разработки в этой части хорошо прорабатывали. Функционал разработчика и конструктор интерфейса получились красивыми, гибкими и доступными. Мне даже трудно это с чем то сравнить, например, SAP в этой части и рядом не стоял, хотя денег у него больше

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

1С предлагает три вида реструктуризации\обновления.

Динамическая

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

Плюсы понятны — например можно оперативно исправить собственную ошибку, которая прорвалась через DevOps без остановки работы всех пользователей.

Минус только один — код у клиента не подгрузится пока он не зайдет в 1С заново

Динамическая реструктуризация рекомендуется опытным убившим этим хотя бы одну базу данным процессом. Иначе говоря — не рекомендуется, ведь если поменять что‑то кроме кода (например добавить параметр сеанса либо изменить роль ) базу можно сделать неработоспособной в зависимости от релиза. Ее конечно можно восстановить методами Динамическое обновление — это зло? (infostart.ru), но лучше восстановить бэкап, который НЕ забыли сделать, чтобы не замедлять работу пользователей. В документации об этом режиме написано довольно кратко Глава 2. Работа с конфигурацией:: Руководство разработчика:: 1С:Предприятие 8.3.23. Документация (1c.ru) , да и что тут писать — Вы сами можете придумать ситуацию, когда подмена кода на ходу даст интересный эффект. У одного пользователя работает старый код, у другого новый и если они пишут в базу эффект будет удивительным.

Обычный механизм реструктуризации

Если Вы верны традиционным ценностям — стабильность, надежность, предсказуемость и т. д.

Вы можете использовать «Обычный механизм» который требует не только завершить работу всех пользователей, но и

«В данном режиме реструктуризация всегда выполняется через создание копии каждой изменяемой таблицы с последующим преобразованием каждой строки данных в конфигураторе или на стороне сервере (в зависимости от настроек выполнения реструктуризации).»

Раньше он был надежным настолько, что делал все в одной транзакции судя по раздуванию Transaction log, что со временем начинало бесить и раздражать. Ведь администратор СУБД знает что можно это делать по другому, а не плюс 200% дополнительного пространства на диске. Сейчас по наблюдениям с длинной транзакции стало лучше, но принцип остался прежним.

Поэтому для тех, кто любит погорячее в 1С придумали.

Оптимизированный механизм реструктуризации

Как пишет 1С:

«В данном режиме происходит попытка выполнить максимальное количество действий на стороне СУБД, а также выполнить модификацию существующих данных и индексов вместо создания копии и переноса данных с обработкой. В данном режиме большинство действий выполняется на стороне сервера системы „1С:Предприятие“.

Иными словами использовать Alter table и подобные операции.

Несмотря на то что он появился в 2017 году, использует Java, а способ его активации скрыт в conf.cfg за следующими заклинаниями и не выведен в интерфейс:

ConfLocation=C:\Program Files\1cv8\conf

UpdateDBCfg=v2

JavaHome=C:\Program Files\Java\jre1.8.0_191

#Задание максимального размера доступной памяти для JAVA-процесса

JavaOpts=-Xmx3072m

И это не зря — свежие ошибки https://bugboard.v8.1c.ru/error/000 134 532, которые не дают провести реструктуризацию исправили только в 8.3.22.1750 релизе. И такой подход к эксплуатации намекает, что в широкие массы выводить это пока страшно.

Ключевой момент в том, что фундаментально он не решает проблему с реструктуризацией больших объемов. Ведь при смене релиза с 8.2 на 8.3 недостаточно просто добавить колонки, еще идет обработка информации под новую структуру данных (заполнение колонок значениями), практически по всем типам метаданных. И эта часть не оптимизирована

Получился в итоге компромиссный вариант Оптимизация реструктуризации базы данных | 1С:Зазеркалье (1c.ru) , и самое грустное, что не очень надежный.

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

В релизе 8.3.23.1739 на определенных операциях в этом механизме видно непопадание в индексы 1С с понятными последствиями.

Не надо прогибаться под изменчивый мир? Хотели как лучше, а получилось…

Как видно в 1С были благие намерения — дать разработчику с помощью визуального ORM делать любые виды реструктуризации просто и надежно. Иными словами — красивый функционал. Но не учли главное — когда объект метаданных близок к терабайту со своими индексами, тут работают уже другие принципы.

Простое добавление колонки с индексом, приведет к блокировкам таблицы на уровне СУБД, а постобработки данных таблицы (даже без копирования ) без распараллеливания будут идти очень долго.

В итоге красивый функционал, на большом объеме данных уже живет не красиво. Добавим еще данных, и он будет просто не нужен.

Знакомая ситуация? Когда функционал это главное?

И на это у 1С есть ответ с множеством компромиссов и ограничений Глава 2. Работа с конфигурацией:: Фоновое обновление конфигурации базы данных:: 1С:Предприятие 8.3.23. Документация (1c.ru)

Я не буду в него углубляться, потому что это очередная попытка решить проблему роста данных без фундаментального изменения архитектуры хранения данных в 1С.

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

• При росте объемов данных.

• При росте объемов вычислений.

• При маштабировании на узлы.

• При работе в нештатной ситуации.

• Переносимость на разные архитектуры и далее по Вашему списку.

Проработка уже этих вопросов сильно поменяет концепцию функционала. Например, стоит наложить ограничения и отказаться от смены типа реквизита (число \ строка) на уровне платформы 1С и Вы уже можете упростить архитектуру реструктуризации кардинально. Тем более на больших объемах это работать не будет, всегда есть другие варианты.

Про архитектуру порой так сложно и абстрактно пишут Architectural pattern — Wikipedia, что ее проработка видится где‑то в крупных компаниях, с технадзором, реестром отечественного ПО и прочей мотивацией, где есть кого и за что посадить. При этом чтение Patterns и AntiPatterns не приводит к пониманию Best Practice, потому что это не математика, где все можно привести к строгой структуре.

Это как по скелету решать — волк это будет или собака? Вроде почти одно и тоже, но один человеку друг, а другой и не друг и не враг, а так.

На самом деле достаточно начать с себя.

Перечня открытых вопросов \ разрезов для анализа — перечень которых индивидуален для каждого приложения, но они определяют какой должна БЫТЬ программа в разных обстоятельствах,и где нужно заложить задел на маштабирование.

Если взять управление данными при росте объемов в 1С, можно накидать следующее:

• Максимальные объемы (лимиты) с возможностью обслуживания штатными средствами 1C (переиндексация, удаление помеченных объектов сейчас укладываются за сутки только на сравнительно небольших базах).

• Маштабирование при росте объемов данных (текущее состояние такое Язык мой враг мой).

• Удаление архивных данных (текущее состояние такое 1С БодиПозитив / Хабр (habr.com)).

• Обмен данными между приложениями. (текущий механизм планов обмена работает без распараллеливания).

• Изменение структуры таблиц, реструктуризация.

• Универсальность и специфика взаимодействия с различными СУБД. Сейчас 1С поддерживает Postgres, MS SQL, Oracle но жизнь уже требует другие варианты.

Как задать правильные вопросы?

Просто надо сместить фокус от того, как СДЕЛАТЬ нужный функционал, и перевести внимание на вопросы более высокого уровня общие для данного класса программ. Например, обработка ошибок должна быть в любой программе, и там много вариантов логгирования, режимов трассировки, отладки (особенно в режиме параллельной обработки данных через фоновые задания)

Решение этих вопросов нужно заложить еще в начале проектирования. Необязательно все это реализовывать сразу, но в архитектуре это уже должно быть заложено как закладывается в кузове авто возможность поставить более\менее мощный двигатель, полный привод или трансформация багажника. Наберите «платформа MQB» и Вы поймете о чем речь Volkswagen Group MQB — Википедия (wikipedia.org)

Чем оканчивается создание функционала, и откладывания на потом решения этих открытых вопросов ‑можно увидеть в 1С на подсистеме реструктуризации. Хотя конец тут это только начало. Подобные проблемы есть повсеместно и у других производителей ПО, по причинам указанным выше, и это не какие‑то in‑house самоделки, а вполне коммерческие продукты типа SAP.

Сколько длится конвертация базы 1C  на 8.2 в 8.3 на 5 терабайтах?

С конвертацией конфигурации 1С с 8.2 в 8.3 без режима совместимости с 8.2 все столкнутся рано или поздно. И эта реструктуризация отличается от обычных изменений\добавлений метаданных — тотальным влиянием почти по всем метаданным 1С. То есть ее нельзя разделить на части.

Формально отличия для программиста 1С 8.2 против 8.3 укладываются в небольшую статью на ИТС Перевод конфигураций на платформу «1С:Предприятие 8.3» без режима совместимости с версией 8.2:: Платформа, механизмы и технологии:: Методическая поддержка для разработчиков и администраторов 1С:Предприятия 8 (1c.ru) .

Конечно в кластере серверов 8.3 много переработали в части администрирования и маштабирования, но это не отвечает на вопрос: Почему нельзя было сделать обратную совместимость на уровне языка 8.3?

Внутренняя структура хранения на уровне полей, при конвертации 8.2 в 8.3, меняется существенно, это нормально для данной идеологии ORM. Есть хорошие статьи Размещение данных 1С:Предприятия. Таблицы и поля:: Администраторам:: Методическая поддержка для разработчиков и администраторов 1С:Предприятия 8 (1c.ru) . К сожалению, новые поля почему‑то не документированы, например в основной таблицы регистра бухгалтерии _AccRg.

Перечислять, что меняет 1С внутри при конвертации в 8.3 нет смысла — Вы можете увидеть это при пробной конвертации через СУБД, просто отобрав таблицы с суффиксом NG NO(временное название новой таблицы при реструктуризации).

Важно другое — сейчас нет готовых инструментов, которые могут сделать реструктуризацию базы 1C большого объема 2–5 терабайт за разумное время.

По сути способа три:

1. Создать новую базу в формате 1с 8.3 и перенести туда данные, например, планами обмена. Проблема этого способа — нет готовых инструментов БСП для параллельной!!! загрузки данных, хотя бы из большого регистра сведений.

2. Обычная Реструктуризация — средствами 8.3. Проблема этого способа в том, что на базе 5 терабайт он занимает 6 дней, на базе 2 терабайта 2–3 дня . Оптимизированным режимом мне до конца довести это не удалось из — за ошибок (смотрите выше). В любом случае это не влезет в технологические окна, кроме новогодних праздников в некоторых компаниях.

3. Свернуть базу до разумных размеров и использовать типовой способ реструктуризации. Но свертка это нестандартный процесс 1С БодиПозитив.

Любой другой способ подразумевает решение собственной разработки из комбинации разных способов, а мы не этого мы ожидаем от платформы.

Как подготовить конфигурацию к реструктуризации? это тема отдельной статьи. Если у Вас бухгалтерия 3.0 это просто, если Бухгалтерия 2.0 уже все сложнее. Все зависит от библиотеки стандартных подсистем, переход на в 8.3 перешел в версии 2.2 Редакция 2.2 БСП (1c.ru)

Причина длительной реструктуризации простая — каждый объект метаданных в 1С обрабатывается при реструктуризации отдельно без распараллеливания операций. Например реструктуризация большого регистра будет идти перекладкой по 1000 записей в таблицу _infoRgNG последовательно. Посмотрите на этот Top таблиц и вы поймете, что все это вытянется в бесконечность.

Метаданные по типам тоже реструктуризируются последовательно Справочники, Документы, Регистры. Это оправданно, поскольку важна ссылочная целостность, но мы понимаем, что Регистры друг на друга не ссылаются (это не ссылочный тип) и их можно реструктуризировать параллельно (разные регистры). А для больших регистров параллельная обработка данных просто необходима, иначе ожидание будет пропорционально размеру самого большого

В таких обстоятельствах можно только сделать следующие подготовительные действия.

Подготовить базу \ оборудование так же как описано в статье Как великану в стране 1С пересесть на слона , включая очистку итогов (чтобы не тратить двойное время на конвертацию и пересчет). К этому можно добавить только два пункта:

• Если Вы использовали разумное разделение по File group (ms sql) \ Table spaces (Oracle), то 1С все это проигнорирует и новые таблицы с суффиксом NG таблицы создаст в пространстве по умолчанию (Primary). Как следствие понадобится двойное дисковое пространство и терабайтные файлы операционной системы, с которыми трудно работать. Это общая проблема для любой реструктуризации 1С. Выхода два либо искать еще дополнительно 5ТБ либо сделать перемещение таблиц в Primary с нужными размерами файлов заранее средствами СУБД.

• Так же можно сэкономить место удалив часть индексов (почти половина размера базы), которые не используются при реструктуризации, но восстанавливаются. Это можно делать только если Вы знаете, что индекс не используется и восстановится после реструктуризации, в противном случае будет замедление реструктуризации и работа системы впоследствии, без нужных индексов. Например, если регистр сведений имеет поле _SimpleKey, то у него можно оставить кластерный индекс и индекс по _SimpleKey — этот регистр система пересоздаст и остальные индексы тоже. Не очевидное условие? Поэтому нужно понимать, что делаете. Иногда проще найти удвоенное дисковое пространство для конвертации, чем делать такое.

Обладая данными знаниями, можно прийти к заключению, что свертка базы перед реструктуризацией — это самый оптимальный способ, поскольку:

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

Б) Вы сразу решаете проблемы с временем реструктуризации и впишетесь в технологические окна.

В) Сократите накладные расходы на содержание базы в будущем.

Вкладывайтесь в свои решения свертки и будет Вам счастье. Пример как это можно делать оптимально 1С БодиПозитив.

Большой архитектурный просчет 1С или Как жить на 1С с базой больше 5 терабайт?

Выше был озвучен перечень «открытых вопросов \ разрезов для анализа » которые нужно было рассмотреть при проектировании платформы 1С, и как то предусмотреть в архитектуре.

На текущий момент имеем:

• Маштабирование при росте объемов: Маштабирование 1С понимает по другому, дистанцируясь от СУБД — достаточно почитать Масштабируемость (1c.ru) . Как работать с большими таблицами в 1С без сторонних средств — вопрос открытый. А ведь по сути 1С это генератор запросов для СУБД, и при его использовании нужно понимать последствия для СУБД Концепция ORM Как двигатель прогресса — выдержит ли ее Ваша СУБД .

• Удаление архивных данных: Обработки в типовых конфигурациях не предназначены для больших объемов: ORM 1C не поддерживает на уровне СУБД ни партицирование, ни шардинг. т. е. вы даже быстро удалить архивные данные не сможете, а про быстрый перенос извлечение из архива уже речи нет.

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

Вы думаете, что это влияет только на смену версии платформы 8.2–8.3, которая происходит раз в 10 лет?

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

• Вы Не можете записать N документов\справочников\или других значений ссылочного типа одной операцией, поскольку метод.Записать() всегда работает на один объект. К чему это приводит видно тут Концепция ORM как двигатель прогресса — выявит слабое место Вашей СУБД.

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

• Вы Не можете записать наборы записей в регистры по нескольким регистраторам одной операцией, поскольку метод.Записать() работает только для одного регистратора. Обходные варианты есть, но это антипаттерн Язык мой враг мой.

• Вы Не можете отследить судьбу фоновых заданий, потому что разработчики предусмотрели хранение истории только 1000 заданий. Когда Вам нужно обработать 1 миллион операций, фоновыми заданиями с пакетом по 1000 операций — вы уже исчерпаете лимит. Конечно, Вы можете доделать свою подсистему управления фоновыми заданиями, как и многое другое. У некоторых несколько миллионов в день это нормальный объем.

• Вы Не можете быстро синхронизировать биржевые котировки, потому что они в типовом варианте планы обмена 1с обрабатывают загрузку последовательно. Обычно их 60 — 100 тысяч в день. Как следствие общую базу справочников (master data management) можно реализовать только на половину.

• При росте объемов запросы будут работать все медленней, потому что нужна Партицированная дисциплина программиста в 1С / Хабр (habr.com).

• Из регистров — только оборотные РегистрыНакопления с агрегатами, архитектурно оптимизированы под параллельную запись в несколько потоков.

• Реализация метода.Записать() Compare by statements любому разработчику даст несколько идей на рефакторинг.

Это я все про штатные средства конечно, «нестандартными» средствами можно все сгладить, а пользователь за красивым интерфейсом (функционалом) будет счастлив в неведении.

Когда в фундаменте что‑то не предусмотрено возникают «оптимизации» — достаточно посмотреть на «оптимизированный» механизм реструктуризации, реструктуризацию в фоновом режиме. Это выглядит как «сушка» бодибилдера, который еще не успел создать рельеф. Мышцы мы увидим, но конкурс он так не выиграет. Оптимизация как правило вишенка на торте, а не способ исправить проблему.

В итоге все эти проблемы приходится решать комбинацией сторонних средств, особым написанием кода или на уровне СУБД, а не ORM 1C.

• Удаление данных и архив Методика похудения для 1С — 100% (infostart.ru).

• Подстраиваем запрос под общие разделители 1С Миссия невыполнима. Общие реквизиты разделители против временных таблиц / Хабр (habr.com).

• Соблюдаем Партицированная дисциплина программиста в 1С / Хабр (habr.com).

• Убираем узкие места в СУБД чтобы не уперется в стену Delayed durability поможет вашему ORM увеличить производительность на 50% и более, если Вы только будете использовать … / Хабр (habr.com).

• Подстраиваем Postgres под особенности 1С Как эффективно настроить autovacuum в Postgres для 1С / Хабр (habr.com).

Иными словами — Вы не можете перейти на новую версию платформы штатными инструментами, когда база перешагнула 2 терабайта.

А ведь на момент создания платформы 1С 8.3 все инструменты для решения этих вопросов были. Минимум два варианта:

• Шардинг по периодам

• Партицирование по периодам

Да партицирование в MS SQL появилось в MS SQL 2005 , но в Oracle оно было уже с Oracle 8i c 1998 года т.е. можно было еще с версии 1С 8.2 это заложить, а в 1С 8.3 развить и улучшить.

Партицирование менее гибко чем шардинг, поскольку требует во всех индексах поле партицирования) иначе с партициями нельзя полноценно работать. Однако оно не требует дополнительных усилий со стороны программного кода – все берет на себя СУБД.  Возможности партицирования слишком зависят от СУБД, например , в MS SQL можно сделать truncate партиции, но нельзя ее просто «отстегнуть» в другую базу данных  с той же структурой таблиц.

Но даже при партицировании бонусом сразу получаем:

• Мгновенное удаление архивных данных через truncate.

• Возможность класть архивные данные на другие  диски (файлы) в рамках одного Instance СУБД.

• Возможность распараллеливания запросов по партициям на уровне СУБД.

• Обслуживание партиций – перестроение индексов отдельно по партициям.

Это уже не мало. При шардинге гибкость возрастает еще больше, так как это больше концепция чем конкретная реализация от производителя СУБД.

Да в чем проблема на первый взгляд? Платформа предоставляет разработчику 1С язык программирования и ORM вообще независимый от СУБД (На текущий момент MS SQL, Oracle, IBM DB2 , Postgres) , переписать нужное под капотом и все дела.

Есть важный нюанс – если Вы разработали структуру данных, библиотеку процедур или ORM, запустили в ее продуктив, значит несколько поколений разработчиков уже будут их использовать. За десять лет их сменится 5 поколений, ведь работу рекомендуется менять каждый 2 года, во избежание «профессионального выгорания». За это время,  они создадут столько проверенного и работающего кода, что при любом «code review» в глазах будет двоится классика «Работает не трогай». Поэтому на очередной приоритезации задач выберут интеграцию с chatGPT нежели партицирование и шардинг.

Осторожно двери закрываются

Если Вы хотите что бы Ваше приложение жило по принципам эволюции, нужно сразу заложить благоприятную среду при проектировании. Как минимум определиться с жизненным циклом. Вы удивитесь реакции заказчика, когда скажете: «через пять лет можете удалить приложение вместе с данным, все-равно переписывать». Просто попробуйте.

Можете не говорить, но инволюция все сделает за Вас – медленно и верно выведет всех из зоны комфорта при работе. Через 4 года придет 3-е поколение разработчиков, им опять скажут, что сроки «уже вчера», но кто скажет им «сделайте хорошо и на века хотябы на 10-15 лет»?

Почему-то при строительстве мостов, сроки эксплуатации на десятки лет, это нормальная практика, а при создании программ нет. Хорошо, что ИТ становится все дороже и дороже, может хоть это заставит задуматься «спонсоров проекта». ИТ в этом отношении больше ведомые, чем ведущие поскольку тут главное уложится в «проектный треугольник» - трузатраты, ресурсы, длительность. Агитировать заказчика за хорошие решения программист\архитектор, может, если у него есть у самого чувство прекрасного, а пока это не обязательное требование. 

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

Будет жалко если все упрется в подсистемы под капотом, двери закрываются, но еще не поздно.

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

Однако PostgresPro дает шанс сделать шардинг , если 1С будет сотрудничать в этом направлении. На последней конференции для разработчиков ответ 1С был  духе «рассматриваем, но планов пока нет». А жизнь преподносит сюрпризы - Oracle, MS SQL, IBM становятся токсичными для платформы:

А) во первых на них уже никогда (лет 10) нельзя положится в России, а на мировом рынке они легко могут тоже сделать с Китаем или другими странами.

Б) Реализация шардинга хотябы для PostgresPro заложит нужные архитектурные решения для других СУБД.

Отличное время для перемен План разработок — прозрачный шардинг (postgrespro.ru).

Конечно, большинство думает, что последствия ошибок при проектировании финансового ПО не такие страшные как в Boeing 737 Max . В авиации уже на уровне регуляторов заложены обязательные процедуры, но они сильно напрягали менеджмент с предсказуемым результатом. Программа это нематериальный актив, поэтому есть иллюзия, что все можно поменять.

Вам не кажется, что хорошо спроектированная архитектура это больше психологический, чем технический вопрос?

Важно не то, что мы знаем, а то что не знаем. Даже самый опытный Full stack разработчик, проходит только один путь и глубоко понимает только малую часть ИТ ноосферы. Однако к правильному решению можно прийти, только задав правильные вопросы, просто представьте, что программа это не код, а живой организм. Хорошая архитектура позволяет долго жить без больших реструктуризаций. Это большая и интересная тема — до новых встреч на нашем канале. t.me/Chat1CUnlimited