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