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

• Быть открытыми, чтобы иметь возможность развиваться при расширении набора продуктов и появлении новых/дополнительных требований.

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

• Для обеспечения высокой производительности фронтальной составляющей может использоваться решение по обработке и хранению данных в оперативной памяти (IMDG/IMDB). При этом данное решение должно быть технологически общим, дабы при поддержке и развитии продуктов не приходилось учитывать «зоопарк технологий». Примером неудачного проектирования может служить вариант, при котором в роли IMDG/IMDB-решения для высокопроизводительного продукта выступает Apache Ignite, а для продукта, требования к производительности которого ниже, Redis. В дальнейшем при появлении еще одного продукта с высокими требованиями по производительности команда развития внедрит Hazelcast, после чего драматически возрастет стоимость обеспечения непрерывности, поддержки и развития подобного «унифицированного» решения. Но выбором общей технологии работы (например, Apache Ignite ввиду наличия требований по высокой нагрузочной способности) дело не ограничивается. На первый план выступает вопрос использования топологий. И платформа должна предоставлять возможность развернуть топологию, поддерживающую исполнение продукта в соответствии с требованиями. Например, соответствующее число узлов, правила репликации, даже сложность и развитость встраиваемого платформенного API могут различаться в зависимости от требований, предъявляемых к продукту. Таким образом, и варианты использования платформенного сервиса также могут различаться. В конце концов, и обеспечение групп продуктов может осуществляться множеством платформенных сервисов, каждый из которых отвечает своему подмножеству требований.

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