Если бы люди не пытались сделать мир лучше, несмотря на летящие в них помидоры, то было бы в мире меньше всего хорошего.

Мы хотим попробовать, имеем право, стараемся. И будь что будет.

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

Нотификацию можно сделать множеством способов, например:
а) выбирать из базы и отображать в интерфейсе (форме с меню) напоминания о подошедшем сроке запланированных событий
б) отправлять email или СМС в момент наступления события для побуждения к дальнейшим действиям (менеджеру об оплате заказа)
в) запустить планировщик, выбирающий и отправляющий напоминалки или вызывающий сторонний сервис раз в 1-2-5 минут

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


Для интеграции обычно берется код, предоставленный поставщиком сервиса. Поставщик потом вызывает указанный ему URL и отчитывается о проделанной работе. Тут вообще проблем нет. Вот, например, как это выглядит при эмуляции мобилы в браузере: youtube
(вызывается форма оплаты Сбербанка в середине третьей минуты ролика)

Это не «лучше» или «хуже», это «другое».
Ответ также сильно зависит от целевой аудитории. Для пользователей Access и FoxPro здесь легче начать работать.
В сравнении с Axapta и 1С для несложных задач заметно легче будет само решение. Для сложных задач — будет значительно дешевле менее трудоемко.

В идеальном мире — да, логарифмическая. В Интеграле тоже логарифмическая.
Однако, с ростом сложности и объема системы в какой-то момент начинаются проблемы, и часто даже случается коллапс. Для привязки к конкретной метрике мы и говорим «не хуже линейной», имея в виду, что линия не будет пересечена.

Интеграл решает рутинные проблемы, на которые обычно не хватает времени, предотвращая часть причин коллапса.

Интеграл сам и есть фреймворк (т.е. его концепт, прототип).

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

Еще есть экспорт и импорт структуры и данных. То есть, можно набросать модель, выгрузить её и загрузить в другой экземпляр базы.

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

Нет языка.
Интерфейс свёрстан в HTML (css, js для оформления), программирование делается запросами Интеграла.

Сейчас это PHP и MySQL.

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

Я помогаю сейчас знакомому рекрутеру делать стартап для массового подбора персонала.
Там есть приличный бизнес-процесс, включающий переходы откликов кандидатов по статусам, планирование интервью, рассылку email и смс, работу с вакансиями (набор этапов, трёхуровневые специализации, скрипты, тайм-слоты встреч, права, и т.д. и т.п.) и сайтом Хэдхантер (HH). Фрейм HH написан отдельно, используется как сторонний сервис, внедренный в интерфейс, остальное — в Интеграле. Так вот, есть формы вакансии, отклика и прочие, состоящие из блоков, которые включаются/выключаются и совершают действия (вызывают запросы, запрашивают и сохраняют данные) в зависимости от статуса отклика или иного контекста. Приложение «ведет» пользователя, ограничивает, не дает спотыкаться.
Могу показать как это работает по скайпу, со всеми запросами, исходниками и формами. В целом, всё как в обычном приложении, но без python, php, nodejs.

Построителя workflow из кубиков пока нет. Пока нет.

Спасибо! Исправим.

Это не конструктор из кубиков, это конструктор самих кубиков. То есть, по вашим трем пунктам: разработчик всё это может сделать сам здесь же, в удобном ему виде.
Версии и тест-план с соответствующими скриптами можно хранить в этой базе, как в любой другой. Пульт управления придется сверстать, да, как в любой другой среде разработки.

Как я оговариваюсь в статье (пару раз), пока сервис не предлагает наработок по визуализации всего этого, а предоставляет чистое поле, как если бы вы взяли Python, PostgreSQL и Apache, но упрощает работу с базой данных и разворачивание самой среды.

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