Резюмируя вышеизложенное, мы можем отметить, что при использовании современного платформенного подхода обеспечиваются:

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

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

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

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

Резонным будет рассмотреть вопрос возможности применения аналогичных принципов к рассмотренному ранее примеру множества «платформ». На самом деле, активным образом применяя указанные принципы, мы приходим к тому, что подобные «платформы» сливаются в единую, при этом остается организационное разграничение команд развития соответствующих «платформ». Ставя целью обеспечение интенсивного развития, современная организация логически приходит к необходимости устранения подобного разграничения, в результате чего мы сталкиваемся уже с примером, рассмотренным в настоящем разделе. То есть интенсивное развитие требует ухода от множества «платформ», и исключительно важную роль в этом уходе играет философия открытого кода.

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

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