Во-вторых, структура платформы определяется теми прикладными вариантами использования, исполнение которых планируется для продуктов, создаваемых с применением платформы. А варианты использования диктуют те характеристики платформы, которые обеспечат требуемый P&L продуктов. То есть в рамках технологической унификации, представленной выше, топологии развертывания технологических решений, применяемых в платформе, могут существенно различаться. Например, упомянутый выше Apache Ignite может иметь различные топологии развертывания и сервисное окружение для вариантов автоматизации процессной и фронтальной составляющих. И указанные топологии диктуются вариантами использования. Здесь мы видим очередную синергию платформенного подхода и философии открытого кода: успешные решения с открытым исходным кодом используются огромным числом организаций по всему миру, изменения в данные решения вносятся аналогично огромным числом пользователей, поэтому количество доступных вариантов топологий оказывается априори большим, нежели у закрытых (vendor-lock) решений, даже если последние являются собственностью крупнейших корпораций. И для каждого частного платформенного решения может выбираться (а в случае необходимости и создаваться) собственная топология развертывания технологического продукта. То есть мультипликативный ценностный эффект платформы накладывается на мультипликатор эффективности открытого кода. Мы можем создавать множество топологий в рамках технологической унификации применяемых решений в зависимости от требований к той или иной составляющей продуктовой автоматизации.
Резюмируя вышеизложенное, мы можем отметить, что при использовании современного платформенного подхода обеспечиваются:
• Технологическая унификация, в рамках которой могут оформляться те или иные подсистемы платформы – например, отвечающие за обработку данных в оперативной памяти и соответствующее повышение производительности и надежности платформенных приложений.
• Подсистемы платформы предоставляют сервисы (и сами могут предоставляться в виде