Об изготовлении программ и ежиках в тумане

Государству я попытался подсказать что делать. Мой опыт - в статье про "предцифровую горячку" здесь же примерно года полтора назад. Если бы я всерьез рассчитывал на реакцию государства, то настаивал бы на тех рекомендациях. но думаю, что 2-3 группы разработчиков белее реально.
А центы сертификации мне не нравятся: т.к. они быстро превратятся в еще одну кормушку для кормежки чиновников.

Почему я говорю про Центр сертификации (естественно не государственный и не имеющий право запрешать/разрешать)?

1) Работы много. Чтобы проверить качество, надо иметь свою систему тестирования, независимую от разработчика. Надо уметь проверять качество и адекватность не только кода, но и документации. Надо проверять все интерфейсы на стандартность взаимодействия. И так для каждой новой версии.

2) Чем будут зарабатывать себе на хлеб 2-3 команды разработчиков? У меня нет вариантов. Разве что им будут платят за то, что они такие хорошие , но тогда надо сначала эту "хорошесть" показать/доказать, а для этого нужно много поработать и деньги (catch 22).

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

Добавлю, что стандартизация open source - это малая часть того, что надо сделать для выхода из тумана.

Алексей, можете привести экономические расчёты предполагаемой модели разработки для разного количества людей, вовлечённых в разработку - от микро до макро уровня?

Отлично! "Agile - это палка для слепого, это технология от бедности и от отчаяния"

Все перечисленные странности - 20+ летней давности.

Почему архитектуру делает "Конструктор"? "описание системы задает архитектуру системы, только не нарисованную, действующую - живую" - вот есть такая -https://bpm.com/blogs/executable-architecture-of-software-defined-enterprises

"вот есть такая -https://bpm.com/blogs/executable-architecture-of-software-defined-enterprises"

Посмотрел статью. Интересный подход к частной задаче (Enterprise Management System). Вы предлагаете собрать IT систему по бизнес архитектуре из микросервисов.

Вопрос: А как вы будете решать основные проблемы (не наблюдаемость, сложные и противоречивые настройки/конфигурации, несовместимость, отсутствие стабильных интерфейсов, отсутствие адекватной документации)?

Слова сказаны хорошие, но вот решения за ними я не вижу.

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

Это было первое возражение, теперь второе и главное. Вы предлагаете (насколько я понял) связать верхней архитектурой набор микросервисов/подсистем. Но если при этом не озаботится устройством и правилами построения самими подсистемами, то мы получим красивую обертку над кучей частей, собранных из говна и палок. Полагаю, что и все система будет скорее г., чем конфеткой.

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

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