Архитектура цифровых платформ. От настоящего к будущему - страница 15

Дело в том, что традиционно инструменты, обеспечивающие гибкую настройку и исполнение бизнес-процессов, их мониторинг, выставление и расчет КПЭ, имеют не самую высокую производительность, а потому нуждаются в дополнительных компонентах, упомянутую производительность повышающих. И это могут быть уже приведенные выше компоненты, применяемые одновременно и для обеспечения корректной автоматизации фронтальной составляющей продукта. А их (компонентов) распределенное исполнение, эластичное масштабирование и опции сегментации позволяют проводить тонкую настройку, адресно применимую для каждой составляющей автоматизации продукта. В свою очередь, для непосредственной автоматизации процессной составляющей продукта могут использоваться самые разные решения с открытым исходным кодом: Activiti, Camunda, Kogito и другие. Указанные инструменты активно применяются огромным количеством самых разных мировых корпораций, для них разработаны различные топологии развертывания, адекватные тем или иным вариантам использования.

Читатель может задать вопрос в лоб: «Неужели достаточно просто развернуть набор технологий, например приведенный автором, чтобы достичь современного платформенного подхода?» Ответ на подобный вопрос может быть только отрицательным: развертывание технологий является промежуточным и не определяющим, хоть и важным, этапом работы с цифровыми платформами. Более того, этот этап может быть применен и в случае следования парадигме SOA, и в случае применения «платформенного» подхода, разобранного в предыдущей главе, посвященной проблематике современных цифровых платформ. Что же отличает современный платформенный подход?

Во-первых, мы должны исходить из того, что платформа не существует сама по себе, она является средой создания и исполнения приложений. Платформа не является ни информационной системой, ни выделенным программным комплексом, по факту платформа является основой прикладной экосистемы организации. Отсюда может следовать первый вывод: многообразие решений с открытым исходным кодом не означает, что каждая составляющая продукта, рассматриваемого в примере, автоматизируется независимым технологическим стеком. В «Архитектуре цифрового мира» мы говорили о том, что единственным критерием выбора технологических решений является целесообразность. И когда мы говорим об экосистеме платформенных приложений, о продуктах, предоставляемых указанными приложениями, то крайне неразумно будет рассуждать о том, что каждый продукт, каждая составляющая продукта автоматизируется независимо от других. Да, жизненный цикл продуктов различен, каждый продукт обладает собственным P&L, каждый продукт может получать совершенно разные импульсы к развитию, основанные на множестве факторов. Но платформа помогает им развиваться, она, как мы уже отмечали, является ценностным мультипликатором. И архитектор, занимающийся проектированием платформы, приходит к выводу, что технологический стек, использующийся при проектировании и реализации платформы и платформенных приложений должен быть согласованным. Нет никакого смысла использовать собственные системы управления базами данных для каждого продукта и каждой составляющей такого продукта, если это не диктуется объективными потребностями. Если мы говорим о решениях по обработке данных в оперативной памяти, позволяющих обеспечить требуемые производительность и надежность для процессной и фронтальной составляющих, то имеет смысл рассматривать технологическую унификацию данных решений, а также проектировать и реализовывать унифицированные платформенные сервисы инфраструктурного и инфраструктурно-прикладного характера (подробнее о платформенных сервисах – в соответствующей главе) для обеспечения работы указанных продуктовых составляющих. Разумеется, отсюда вовсе не следует необходимость использования единственно правильной технологии, мы утверждаем необходимость решения схожих технологических задач схожими технологиями. Представим себе, что обработка данных в оперативной памяти производится на уровне процессной составляющей продукта средством решения Infinispan, фронтальной – Apache Ignite, при этом для выделенного подмножества дистанционных каналов – Redis. Поддерживать и развивать подобную конфигурацию будет непомерно затратно. Таким образом, мы приходим к логике технологической унификации платформы и ее сервисов. При этом унификация проводится в логике решений с открытым исходным кодом: выбор используемых в рамках унификации технологий может производиться как выделенно, то есть с точки зрения максимально эффективного технологического решения, так и совместно, когда оценивается эффективность экосистемы технологий (например, с точки зрения возможностей упрощения технологической интеграции).