Андрей Трушкин – Архитектура цифровых платформ. От настоящего к будущему (страница 12)
• Подобное технологическое решение по обеспечению высокой производительности может (и должно) применяться при автоматизации процессной составляющей рассматриваемых продуктов. Как мы уже отмечали ранее, стандартные средства автоматизации бизнес-процессов, как правило, не отличаются высокой производительностью. В них закладываются возможности гибкого моделирования процессов, их быстрой сборки и развертывания, возможности мониторинга, но производительность отказывается не самым передовым показателем данного класса инструментов. Одновременно (и мы также обращали внимание читателя на данный факт) в современной архитектуре бизнес-процессы не могут характеризоваться низкой производительностью, в противном случае организация потеряет конкурентоспособность на рынке. Поэтому (так как базовый инструмент управления процессами не может сам по себе обеспечить адекватную требованиям дистанционного обслуживания производительность) на уровне реализации процессной составляющей продуктовой автоматизации могут применяться упомянутые выше IMDG/IMDB-инструменты. С их помощью, например, может осуществляться высокоэффективная работа с контекстом экземпляра процесса, его бизнес-данными, обеспечиваться надежность и т. д. Конкретные топологии (и сущности) развертывания могут различаться как от продукта к продукту, так и в зависимости от той продуктовой составляющей, к которой они относятся. Но технологическая унификация, а также специфика платформенных сервисов должны быть общими на уровне платформенных приложений и предоставляемых ими продуктов организации клиентам и партнерам последней. Фактически множество платформенных сервисов, обеспечивающее исполнение фронтальной составляющей продукта, пересекается с множеством платформенных сервисов, обеспечивающих исполнение процессной составляющей продукта, по принципу кругов Эйлера. Аналогичным образом пересекаются множества платформенных сервисов, обеспечивающих исполнение различных продуктов (даже при аналогичной структуре последних). А требования к платформенным сервисам, режимам их функционирования, топологиям развертывания технологической составляющей предъявляют продукты. Отметим, что указанные требования не являются статическими. Например, при добавлении новых продуктовых бизнес-процессов или расширении использования существующих требования к инструментальной поддержке высокой производительности процессов могут кардинально измениться – как вариант, возрасти. Подобное происходит при добавлении новых каналов лидогенерации, привлекающих большие объемы клиентов. Соответственно, используемые в платформах технологии, а также предоставляемые платформами сервисы должны быть адаптируемыми к подобным изменениям требований, что, в свою очередь, напрямую следует из свойства отсутствия замкнутости платформ.
• Каждый продукт, реализуемый платформенными приложениями, может функционировать в собственном режиме, а требования к нему могут изменяться независимо от остальных продуктов, предоставляемых организацией клиентам и партнерам. А потому платформа должна обеспечивать достаточную гибкость для независимой поддержки развития каждого продукта. То есть платформа должна быть распределенной, каждый ее модуль, каждый платформенный сервис должен быть распределенным, в противном случае он окажется узким местом развития независимых продуктов.
Мы не будем подробно рассматривать варианты распределенного исполнения остальных составляющих продуктовой автоматизации, представленных на Рисунке 5. Их сопоставление (как между собой, так и в контексте нескольких автоматизируемых продуктов) будет аналогично приведенному выше для фронтальной и процессной составляющих. Здесь важно отметить другое. При технологической унификации решений, предлагаемых платформами для продуктовой автоматизации, необходимо учитывать раздельное и распределенное исполнение как продуктов, так и отдельных уровней автоматизации, то есть платформы должны предлагать (с точки зрения визуализации Рисунка 5) как горизонтальную, так и вертикальную распределенность. И добиться такого результата позволит эластичное масштабирование.
Поддержка той или иной технологией эластичного масштабирования подразумевает, что соответствующая технология обеспечивает:
• Сегментацию собственных сущностей. В приведенном выше примере мы можем, в частности, сформировать отдельные сегменты IMDG/IMDB-решения для поддержки различных составляющих автоматизации продуктов, разделить по сегментам те или иные продуктовые процессы в зависимости от требований.
• Каждый сегмент может масштабироваться независимо. Например, может быть выделен сегмент IMDG/IMDB под каждый тип продуктового процесса, при этом сегменты, обеспечивающие производительность высоконагруженных процессов, масштабируются независимо от других. Таким образом обеспечивается использование ресурсов в соответствии с реальными потребностями приложений, причем гранулированное, исключающее избыточные затраты.
• Технологическое решение, применяемое для автоматизации соответствующего сегмента, может использовать динамически расширяемое или сокращаемое количество вычислительных узлов для своего функционирования.
• Технологические решения сохраняют корректность функционирования при увеличении или уменьшении количества используемых ими вычислительных узлов (разумеется, уменьшение в данном случае не подразумевает сокращения количества узлов ниже требуемого для обеспечения минимальной нагрузочной способности).
Отметим, что приводимые нами в качестве примеров в течение настоящей книги технологии Apache Ignite, Apache Cassandra, Apache Kafka и многие другие ведущие решения с открытым исходным кодом обеспечивают вышеприведенные характеристики.
Но мало применять технологии, поддерживающие эластичное масштабирование. Платформенные сервисы и платформенные приложения, использующие подобные технологии, также должны поддерживать эластичное масштабирование. И здесь задача архитектора совместно с командами развития – спроектировать и реализовать сервисы и приложения таким образом, чтобы они не стали узким местом платформы, чтобы сама платформа не стала барьером между развитыми технологиями с открытым исходным кодом и командами развития, которые в таком случае окажутся вынуждены «бороться» с предоставляемыми им сервисами, чтобы обеспечить распределенность.
Считаем нелишним еще раз подчеркнуть, что мы не рассматриваем конкретные платформенные решения. Реализации конкретных платформ как требуют детальной проработки технологий и их топологий, так и содержат гораздо большее количество поддерживаемых составляющих автоматизации продуктов организации, наполняя их существенно более богатым набором технологических решений. Наша же задача в рамках данного изложения заключается в том, чтобы показать читателю связь цифровых платформ и такой ключевой тенденции развития архитектуры, как распределенность, проиллюстрировать способы поддержки соответствующей тенденции путем платформенного подхода.
Цифровые платформы и бизнес-процессы
Перечисляя ключевые тенденции развития архитектуры, мы говорили о том, что современные организации, ставящие себе целью перманентное интенсивное развитие, стараются уйти от процессной методологии работы к продуктовой. При этом смещение фокуса внимания на продукты не отменяет важности бизнес-процессов, более того, мы относим последние к трендам, определяющим развитие архитектуры. Внимательный читатель и тут не оставит нас без каверзного вопроса: «Нет ли противоречия в указанной логике?» Мы отвечаем, что противоречие отсутствует, а ниже объясним, почему так происходит.
Для обеспечения полноты рассмотрения мы возьмем за основу организацию с относительно длительной историей, прошедшую уже не одно поколение автоматизации (применявшую различные архитектурные парадигмы), поскольку вариант рассмотрения стартапа чреват применением к нему фразы Исаака Ньютона: «Если я видел дальше других, то потому, что стоял на плечах гигантов». Случай стартапа может характеризоваться учетом опыта предшественников, при котором удается избежать тех или иных ошибок, кроме того, влияние унаследованного ИТ-ландшафта и устаревшего mindset может оказаться пренебрежимо малым.
Как правило, такая организация уже проводила описание выполняемых бизнес-процессов (в ряде случае они могут именоваться производственными ввиду специфики деятельности), зачастую с приглашением внешних консультантов проводились попытки провести и некую оптимизацию последних. Результаты подобных действий могут различаться:
• Возможно, дело ограничилось просто описанием бизнес-процессов с созданием (и то не всегда) визуализирующих диаграмм в общепринятых форматах – например, BPMN.
• Исполнение бизнес-процессов в автоматизированном режиме может осуществляться в каждой информационной системе отдельно (специфичные процессы выполняются в специфичных информационных системах).
• В организации мог быть внедрен BPM-инструмент для централизованного управления бизнес-процессами (с различным охватом внедрения соответствующего инструментария).
Отметим, что вышеперечисленные пункты не являются фиксированными шагами на пути компании к успеху – возможны самые разные варианты реализации каждого из них, включая различные подводные камни: