Фундамент для цифровых сервисов

slide1_1Хочу чуть подробней рассказать о том, почему я на днях поместил ссылку на короткий ролик Case Lifecycle Management от PEGA Systems. (Кстати, вот ссылка на тот же ролик на YouTube.) Необходимость некоторого промежуточного слоя между так называемыми Systems of Engagement и Systems of Record более-менее очевидна. (Не стану сейчас глубоко погружаться в разговор о том, что этот такое, а тем более затрагивать тему System of Systems. Systems of Engagement нужны для налаживания романтических отношений с клиентом, Systems of Record для осуществления и учета операций. Думаю, что картинки от Forrester будет вполне достаточно.) Такой промежуточный слой нужен даже не столько для того, чтоб улучшить опыт клиентского взаимодействия, а в первую очередь для защиты унаследованных приложений. Разработчики корпоративных систем вряд ли предполагали, что их решения кто-то «обвяжет» программными интерфейсами и вытащит эти интерфейсы в открытый Интернет, на растерзание веб-сайтам, мобильным приложениями, чат-ботам и инфороботам.

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

gartnerpl

В общем, промежуточный слой делать надо, вопрос из чего и как. Достаточно долго эта задача закрывалась сервисной шиной предприятия ESB. Для обработки клиентских команд это как-то еще работало, а вот для предоставления данных на чтение – не очень. Во времена создания ESB слова CQRS и Event sourcing не обрели еще современной популярности, потому и специализированных средств для предоставления данных на чтение в ESB никогда не было.

cqrs

Следующая проблема уже в большей степени связана с customer experience. Данные учетных систем нуждаются в консолидации и существенном упрощении. В принципе эту задачу можно было порешать во времена создания корпоративных хранилищ данных. Но разработчики хранилищ думали совсем о другом – они готовили данные для отчетных и аналитических приложений. Потому основная идея этого класса систем состояла в том, чтоб собрать побольше данных и построить для них правильные индексы. Конечно же процесс загрузки и последующей обработки всего что есть занимает значительное время. Но ответом на этот вызов стали сначала инженерные решения, а затем и Big Data очень своевременно подоспела. В общем, корпоративные хранилища данных это не фундамент для цифровых сервисов, а скорее котлован – чем больше копаешь, тем глубже он становиться.

Совсем не удивительно, что PEGA стремиться позиционироваться, как решение для промежуточного слоя. Но не надо спешить. Дело в том, что все наши богатые и знаменитые BPM и ACM решения ни разу ни cloud-native. Они сделаны в стандартной n-уровневой архитектуре и потому обладают всеми присущими ей недостатками. Я бы смотрел в сторону легковесных open source решений, таких как Nuxeo, построенная поверх MongoDB (см. https://www.nuxeo.com/mongodb/) или Camunda BPM. Об этом я и постарался рассказать на вчерашнем вебинаре Docflow.

Похожие материалы:

Реклама

One Comment

  1. As a “Фундамент для цифровых сервисов” I would recommend a Corporate Unified Business Execution (CUBE) platform approach – see http://improving-bpm-systems.blogspot.ch/2015/12/typology-of-platforms.html

    RE “native-cloud and n-tier” the problem is not cloud vs on-prem (for example, Pega is a very good APaaS) but the whole enterprise application architecture — see “Better application architecture (#apparch) with #microservices and #BPM (as APaaS)” http://improving-bpm-systems.blogspot.ch/2016/08/better-application-architecture-apparch.html

    Agree about DWH.

    Thanks,
    AS

    Ответить

Добавить комментарий

Заполните поля или щелкните по значку, чтобы оставить свой комментарий:

Логотип WordPress.com

Для комментария используется ваша учётная запись WordPress.com. Выход / Изменить )

Фотография Twitter

Для комментария используется ваша учётная запись Twitter. Выход / Изменить )

Фотография Facebook

Для комментария используется ваша учётная запись Facebook. Выход / Изменить )

Google+ photo

Для комментария используется ваша учётная запись Google+. Выход / Изменить )

Connecting to %s