По-моему разговор ушел куда-то в сторону. Использование слова платформа в разных контекстах может быть разным. Обычным означает нижележащий фундаментальный уровень. В контексте современных IT-систем более удачное слово это экосистема. Оно позволяет однозначно отделить данный подход от рассширяемых систем вроде 1С.

По-моему разговор ушел куда-то в сторону. Использование слова платформа в разных контекстах может быть разным. Обычным означает нижележащий фундаментальный уровень. В контексте современных IT-систем более удачное слово это экосистема. Оно позволяет однозначно отделить данный подход от рассширяемых систем вроде 1С.

Да, и собственно изначально речь шла о том, что BPM-системы ригидны и не могут реагировать на изменения. Так вот, мне кажется, что если BPM-система построена именно по принципу таких платформ\микроядер\не микроядер, т.е. на основе некой функциональности, которая вызывает обработчики, то можно развивать такую систему эволюционно (у платформы и у обработчиков может и в идеале должен быть разный жизненный цикл развития).

Да, и собственно изначально речь шла о том, что BPM-системы ригидны и не могут реагировать на изменения. Так вот, мне кажется, что если BPM-система построена именно по принципу таких платформ\микроядер\не микроядер, т.е. на основе некой функциональности, которая вызывает обработчики, то можно развивать такую систему эволюционно (у платформы и у обработчиков может и в идеале должен быть разный жизненный цикл развития).

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

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

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

В общем ключевая идея, с которой я начал обсуждение, описана тут: https://mxsmirnov.com/2017/04/13/evolutionary-architecture/ Чтобы не играть в испорченный телефон))

Под ядром в статье имеется в виду совсем не microkernel, а скорее некоторый Фасад который будет постепенно рефакторится. Ведь речь идет об эволюционной архитектуре

Вообще понятие архитектуры уже вышло за рамки "принятия важных решений". Основная задача архитектора - отложить принятие важных решений на как можно более долгий срок. Тем самым обеспечив эволюционное развитие. Выбирая то или иное решение нужно всегда думать о том как оно будет изменено (planned obsolescence)

По мне так описанное в статье ядро отлично коррелирует с паттерном микроядра (The Microkernel architectural pattern applies to software systems that must be able to adapt to changing system requirements. It separates a minimal functional core from extended functionality and customer-specific parts. The microkernel also serves as a socket for plugging in these extensions and coordinating their collaboration. ) Но мы это уже обсудили, спорить не буду)

Я допустил некоторую неточность в формулировке. Здесь еще имеется в виду наличие базовой инфраструктуры (framework) на базе которого строится система. Но это не microkernel архитектура, а именно базовый framework платформы, его ключевые сервисы.

Да, поэтому я и заговорил про платформенный подход и инверсию управления. В этом случае разработка идет не от сервисов, которые потом оркеструются бизнес-процессом, а наоборот - от платформы реализации бизнес-функциональности (в случае коробочных BPMS - настраивамой, в случае кастомных - думаю максимально абстрактных, но реализующих ключевые business capabilities). А сервисы-обработчики разрабатываются позднее, заменяются один другим, развиваются и т.д.
Хотя соглашусь, что это также достаточно сложно, но более гибко

О процессах и идее микроядра: думаю, что дело не в платформе, а в подходе к дизайну. Часто создатель процесса считает своим долгом точно прорисовать все активностии. Потом такой процесс усложняется, т.к. реализация конкретного экзеспляра приносит что-то новое и очень скоро из модели процесса получается "схема старого телевизора" Это не всегда оправдано. Иногда лучше сделать некий "базовый" процесс - просто набор стадий, а детализацию работ внутри стадий оставить на потом. По-сути, мы говорим о таком процессе(скорее кейсе) как о базовом классе из которого можно наследовать конкретные детализации процесса для разных частных случаев. Реализацию такого процесса можно разбить по системам: основные вехи отслеживать в одной, а конкретные задачи делать в других. Но это, скорее, полезный "побочный эффект"