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

Цифровые платформы и бизнес-процессы

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

Для обеспечения полноты рассмотрения мы возьмем за основу организацию с относительно длительной историей, прошедшую уже не одно поколение автоматизации (применявшую различные архитектурные парадигмы), поскольку вариант рассмотрения стартапа чреват применением к нему фразы Исаака Ньютона: «Если я видел дальше других, то потому, что стоял на плечах гигантов». Случай стартапа может характеризоваться учетом опыта предшественников, при котором удается избежать тех или иных ошибок, кроме того, влияние унаследованного ИТ-ландшафта и устаревшего mindset может оказаться пренебрежимо малым.

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

• Возможно, дело ограничилось просто описанием бизнес-процессов с созданием (и то не всегда) визуализирующих диаграмм в общепринятых форматах – например, BPMN.

• Исполнение бизнес-процессов в автоматизированном режиме может осуществляться в каждой информационной системе отдельно (специфичные процессы выполняются в специфичных информационных системах).

• В организации мог быть внедрен BPM-инструмент для централизованного управления бизнес-процессами (с различным охватом внедрения соответствующего инструментария).

Отметим, что вышеперечисленные пункты не являются фиксированными шагами на пути компании к успеху – возможны самые разные варианты реализации каждого из них, включая различные подводные камни:

• Бизнес-процессы могут быть описаны халатно или в формате «вроде как сейчас так происходит», то есть без необходимой верификации описания.

• Бизнес-процессы, реализованные в информационных системах либо посредством выделенного BPM-инструмента, могут содержать большое количество элементов, автоматизированных с использованием «ручного» программирования, и требовать масштабного привлечения разработчиков при изменениях.

• Элементы бизнес-процессов могут быть реализованы (или управляться) в различных информационных системах, что приводит к избыточным трудозатратам при внесении изменений в автоматизируемые процессы.

• И т. д.

При переходе к современным архитектурным и технологическим принципам необходимо учитывать первичность продуктового подхода, когда деятельность организации определяется тем, какую ценность она приносит клиентам и/или партнерам. При этом ценность в современном мире реализуется автоматизируемыми продуктами – цифровыми продуктами. Бизнес-процессы сегментируются в соответствии с продуктовой логикой. Но далеко не все процессы могут быть ограничены лишь одним продуктом:

• Безусловно, бизнес-процессы, ассоциированные с тем или иным продуктом, автоматизируются в соответствии с ним и размещаются (с точки зрения архитектуры) в соответствующей функциональной области.

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

• Общесистемные сквозные процессы могут выполняться на уровне организации и вовлекать значимое подмножество продуктов, в пределе – все продукты компании. Данный вариант расширяет и усложняет вариант процессов, автоматизирующих работу с кросс-продуктами.

Наглядным представлением такого разграничения процессов является функционально-информационная архитектура, пример которой представлен на Рисунке 6.

Рисунок 6. Пример представления бизнес-процессов

на функционально-информационной архитектуре

Таким образом, переход к современным архитектурным практикам предполагает и наличие важной методологической составляющей: процессы организации должны быть описаны, сегментированы по продуктам (с классификацией в части ограниченности продуктовой областью), а также должны своевременно актуализироваться. Непосредственно при автоматизации необходимо использовать современные средства управления процессами (BPM-движки), которые позволяют наглядным образом создавать шаблоны процессов, моделировать исполнение процессов, собственно осуществлять исполнение, поиск узких мест, мониторинг (системный и прикладной), выставлять и рассчитывать КПЭ процессов и т. д. При этом BPM-движок, используемый при автоматизации, должен отвечать современным тенденциям развития архитектуры – например, поддерживать распределенность. Также отметим, что в предыдущем труде автора («Архитектура цифрового мира») указывались три исключительно важных аспекта автоматизации бизнес-процессов в современном цифровом мире: технический рефакторинг, работа с контекстом, корректное использование шаблонов оркестровки и хореографии. Для полноты восприятия вкратце напомним их читателю.

Технический рефакторинг бизнес-процесса предполагает формирование технической карты бизнес-процесса, в состав которой войдут как пользовательские истории, так и технические задачи, выполнение которых необходимо в рамках реализации автоматизируемой продуктовой логики. При техническом рефакторинге осуществляется выявление повторяющихся компонентов бизнес-процессов, которые выносятся в отдельные единицы исполнения. Одновременно в рамках технического рефакторинга определяются глобальный контекст процесса и его разделение на составляющие локальные контексты.

Под контекстом бизнес-процесса понимается совокупность информации, характеризующая выполняемые в ходе бизнес-процесса действия, получаемые и обрабатываемые данные, а также служебная информация, необходимая для обработки бизнес-данных. При этом контекст процесса обрабатывается в рамках глобальной транзакции, охватывающей весь бизнес-процесс и представляющей собой последовательность транзакций локальных. Локальная транзакция может быть отменена, в то время как глобальная такой возможностью не обладает, поскольку зафиксированы результаты составляющих ее локальных транзакций. Состояние локальной транзакции определяет ее локальный же контекст. Контекст глобальной транзакции определяется совокупностью контекстов составляющих ее локальных транзакций.

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

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

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

Мы уже неоднократно рассматривали пример продукта, автоматизируемого организацией при помощи платформенного подхода и предоставляемого ее клиентам и/или партнерам. В указанном примере продукт содержит процессную составляющую, в рамках автоматизации которой и осуществляется необходимая автоматизация бизнес-процессов, связанных с продуктом. Рассмотрим данный пример (приведен на Рисунке 7) и уточним его в контексте именно процессной составляющей и применения платформенного подхода.

Рисунок 7. Продукт с процессной составляющей

С учетом изложенного в рамках настоящей книги необходимо определить ключевые вводные для применения платформенного подхода при автоматизации бизнес-процессов:

• В условиях исключительно высокой значимости параметра скорости вывода продукта на рынок (time-to-market) изменения в продукт должны вноситься с максимально возможной быстротой и оперативностью, эффективно тестироваться и немедленно публиковаться доступными для клиентов и/или партнеров организации. Соответствующее требование актуально и для процессной составляющей продукта.

• Автоматизация бизнес-процессов должна соответствовать принципам открытого кода в рамках платформенного развития.

• Автоматизация бизнес-процессов должна соответствовать требованиям распределенности.

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

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

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

Будь вышеприведенный список требований исчерпывающим, читатель справедливо бы задал вопрос: «Да зачем здесь платформы какие-то? Следует взять no-code-инструмент (в крайнем случае low-code), набросать необходимые процессы и запустить». И в этом случае читатель нисколько не опередил бы события. Возможно, вопрос уже витает в воздухе. Попробуем ответить, почему использование такого инструмента не сможет исключить необходимости применения платформенного подхода.

Во-первых, автоматизация каждого бизнес-процесса происходит не в вакууме. Мы уже отмечали, что для обеспечения эффективной цифровой трансформации необходимо максимально гранулировать продукты организации, вести их автоматизацию независимыми командами. Но бизнес организации может быть (и зачастую является) сильно связанным с точки зрения бизнес-процессов (пусть и сегментированных в соответствии с продуктами). В сложной компании (с развитой иерархической структурой) процессы каскадируются «сверху вниз» от совета директоров до конечных подразделений (с соответствующей детализацией и расширением). При наличии холдинговой структуры процессы головной компании каскадируются на подведомственные организации. Наряду с такими «вертикальными» сквозными процессами присутствуют и «горизонтальные», когда разные с точки зрения бизнес-направлений процессы влияют друг на друга. И обеспечение подобного соотношения процессов исключительно средствами BPM-инструмента зачастую либо сопряжено с избыточно (с точки зрения ресурсов) высокими затратами, либо попросту невозможно. Отметим, что процессы не должны перегружаться непосредственно знаниями о деталях исполняемых действий (последние инкапсулируются в микросервисах при применении современных архитектурных и технологических практик). Кроме того, требования к фронтальным интерфейсам, реализуемым на уровне процессной автоматизации, в современном цифровом мире не уступают тем требованиям, что предъявляются к непосредственно фронтальной составляющей продуктовой автоматизации. Используемые в таком случае развитые библиотеки графических инструментов в BPM-движках, как правило, отсутствуют в преднастроенном виде. Здесь необходимо использование общих платформенных сервисов, компонентов и методологий для высокоэффективной автоматизации пользовательских представлений на всех уровнях продуктовой автоматизации (не ограничиваясь только рассматриваемой процессной).

Во-вторых, инструменты, обеспечивающие гибкую настройку бизнес-процессов, сами по себе, как отмечалось ранее (и в предыдущем труде автора – «Архитектуре цифрового мира», и в настоящей книге), обладают не самой высокой производительностью, что неприемлемо в современном цифровом мире, характеризующемся использованием в первую очередь дистанционных каналов коммуникации. В связи с этим на уровне процессной составляющей продуктовой автоматизации требуется совместно с BPM-движком использовать инструментарий поддержки высокой производительности – например, решения класса IMDG/IMDB. Решения указанного класса также являются сквозными и могут использоваться на каждом уровне продуктовой автоматизации, но в нашем примере (Рисунок 7) наиболее применимы к фронтальной и процессной составляющим. Хранение данных в оперативной памяти, их высокоэффективная обработка соответствующими средствами позволяют повысить производительность бизнес-процессов на порядки, выводя зрелость автоматизации на новый качественный уровень. Соответственно, для корректного и значимого применения указанного класса инструментов необходимы общие платформенные сервисы и компоненты, а также унифицированная методология их использования.

В-третьих, уровень процессной автоматизации может нуждаться в выполнении пакетных и/или групповых операций. Безусловно, здесь мы согласимся с внимательным читателем, который отметит, что указанные классы операций скорее характерны для учетной и частной учетной составляющих. Но и на уровне процессной автоматизации могут быть выявлены потребности в соответствующих типах операций, на чем основывается также и коммерческая политика ряда производителей программного обеспечения. Многие поставщики включают поддержку групповых и пакетных операций в состав распространяемых на коммерческой основе BPM-движков, сохраняя при этом и свободно распространяемые версии последних. Собственно, такой подход поставщиков демонстрирует реальность сегодняшнего дня: большая часть автоматизации бизнес-процессов успешно выполняется при помощи свободно распространяемых средств (без поддержки групповых или пакетных операций), при этом указанные средства активно развиваются в соответствии с практиками открытого кода, в то время как поддержка групповых или пакетных операций становится коммерческой функцией, выполняя роль полезного, но не обязательного для потребителей дополнения. Аналогично пунктам про фронтальную автоматизацию или поддержку IMDG/IMDB-технологий реализация групповых и пакетных операций на уровне платформы может (и должна) осуществляться общими технологическими сервисами и методологией. При этом применение сервисов на разных уровнях продуктовой автоматизации может различаться. Одновременно с этим (в соответствии с тенденцией использования решений с открытым исходным кодом) поддержка групповых и пакетных операций осуществляется не средствами самого BPM-движка (в таком случае она не будет доступна смежным составляющим продуктовой автоматизации), а специально спроектированными и реализованными платформенными инструментами.

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

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

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

• Индексация BPM-инструкций (весьма ресурсоемкая задача).

• Реализация фронтального представления работы с бизнес-процессами и неавтоматизируемых задач в их составе (так называемые human tasks).

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

• Хранение схем процессов в отделенном от непосредственного исполнения формате.

• Предоставление встраиваемых API для платформенных сервисов и приложений.

Указанные задачи не являются (как правило) свойствами самого BPM-движка, но являются свойствами платформы, позволяющими повышать производительность труда команд развития.

Для индексации BPM-инструкций могут использоваться как легковесные средства поддержки (таковых немало в современном мире открытого кода), так и более сложные инструменты, как, например, упомянутые выше IMDG/IMDB-решения по хранению данных и выполнению операций над ними в оперативной памяти. Выбор наиболее подходящего решения указанной задачи осуществляется архитектором, являющимся лидером технологических изменений, в рамках тесной кооперации с командой разработки. В качестве факторов выбора той или иной технологии поддержки, топологий ее развертывания, реализации платформенных сервисов, предлагающих решение задач индексации платформенным приложениям, могут выступать потенциальная скорость внесения изменений, унификация с другими используемыми в платформе технологиями, имеющиеся командные наработки, массовость применения в смежных продуктовых решениях (и их процессных составляющих), качество поддержки на уровне сообщества в соответствии с практиками открытого кода и т. д. Мы специально совместно перечислили в приведенных примерах факторов выбора как прикладные, так и платформенные факторы, чтобы показать их тесное переплетение и взаимовлияние. Отметим, что для осуществления корректного выбора архитектор не должен быть «специалистом по квадратикам» (или иным геометрическим фигурам), к чему, к сожалению, есть склонность у специалистов, обладающих mindset предыдущего поколения, а современным специалистом, стремящимся к обеспечению перманентного интенсивного развития организации, продукты которой автоматизируются с применением платформенного подхода.

Фронтальное представление при автоматизации процессной составляющей продукта должно осуществляться способом, аналогичным реализации фронтального представления любой другой составляющей продукта, предоставляемого организацией. Упомянутые ранее неавтоматизируемые задачи (human tasks) должны соответствовать лучшим практикам современной фронтальной автоматизации, а не довольствоваться положением «бедного родственника», в то время как автоматизация непосредственного предоставления продукта клиентам и/или партнерам организации занимает первостепенные позиции и находится в фокусе внимания лиц, принимающих решения в компании. Безусловно, непосредственно автоматизация фронтальной составляющей крайне важна, но исполнение бизнес-процессов является неотъемлемым компонентом формирования ценности для клиентов и/или партнеров, а потому и фронтальные интерфейсы указанной составляющей также задействованы в создании итоговой ценности. При недостаточной производительности фронтальных интерфейсов процессной составляющей или их затрудненном восприятии сотрудниками, выполняющими работу над неавтоматизируемыми задачами, общая производительность и качество исполнения бизнес-процессов могут существенно снижаться, что негативно повлияет на общее качество продукта и его P&L. Поддержку эффективной и унифицированной автоматизации фронтальных представлений также выполняют в современном цифровом мире платформенные сервисы и компоненты, обеспечивающие омниканальность выполнения операций, их высокую производительность (и опять вспоминаем про IMDG/IMDB-инструменты), общие библиотеки графических элементов и т. д. То есть платформенные сервисы играют важнейшую роль в поддержке создания фронтальных элементов автоматизации процессной составляющей продуктов. И, как правило, указанные сервисы являются внешними по отношению к BPM-движку.

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

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

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

Практики распределенности и эластичного масштабирования позволяют устранить указанное выше противоречие. Уже сам факт распределенного исполнения различных компонентов, задействованных в автоматизации бизнес-процессов, позволяет предложить варианты обеспечения масштабирования только тех узлов, которые являются узкими местами в текущем исполнении процессной составляющей. Безусловно, при устранении текущих узких мест могут появляться новые, но в условиях распределенного исполнения мы можем обеспечивать уже их точечное масштабирование (в случае недостаточной производительности элементов процессов, в противном случае масштабирование может не осуществляться). Результатом подобного применения практик распределенности становится требование к используемым технологиям обеспечить возможность распределенного исполнения. Фактически распределенное исполнение бизнес-процессов каскадируется на обеспечивающие их автоматизацию технологии. Но не только технологии – платформенные сервисы и компоненты также должны обеспечивать соответствующее распределенное исполнение. Мы вновь возвращаемся к требованию к платформам соответствовать распределенности (как ключевой тенденции развития архитектуры).

Эластичное масштабирование фактически обеспечивает «масштабирование по требованию» для компонентов бизнес-процессов. При росте нагрузки число узлов в кластере увеличивается, нагрузка распределяется, состояние, сохраняемое программными компонентами, при необходимости реплицируется (техники репликации могут быть различными и выбираться архитектором адресно в отношении каждой технологии, элемента платформенного сервиса или приложения и вариантов использования). При снижении нагрузки число узлов уменьшается до некоего определенного минимума, позволяющего корректно функционировать автоматизируемому решению. Отметим, что техника и технология эластичного масштабирования могут выбираться независимо для каждого распределенного элемента прикладной топологии. Таким образом обеспечивается снижение избыточно потребляемых вычислительных ресурсов и, соответственно, затрат организации. И здесь возникают аналогичные случаю распределенности требования к поддержке платформой эластичного масштабирования: применяемые при создании и развитии платформы технологии должны максимальным образом поддерживать эластичное масштабирование, указанное масштабирование должны поддерживать предоставляемые платформой для реализации приложений сервисы и компоненты. Отметим, что и ведущие BPM-движки развиваются в сторону поддержки эластичного масштабирования (примером может служить переход начиная с 8-й версии решения BPM Camunda на движок Zeebe), равно как и их окружение, формируемое в лучших практиках открытого кода, также стремится обеспечивать эластичное масштабирование. Такие технологии поддержки потоковой передачи информации, как Apache Kafka и Apache Pulsar, изначально обеспечивали эластичное масштабирование уже на архитектурном уровне, равно как и ведущие решения IMDG/IMDB (Apache Ignite, Infinispan и т. д.). Решения же по технологиям, их выбору, конкретным реализуемым сервисам, топологиям развертывания, применяемым при создании и развитии ИТ-решений, принадлежат (разумеется, с учетом принципов меритократии) архитектору, являющемуся лидером технологических изменений.

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

• BPM-движок должен поддерживать распределенное исполнение, эластичное масштабирование и отделяемость реестра схем бизнес-процессов.

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

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