Начнем с организационной распределенности. В современном цифровом мире использование гибких практик стало стандартом де-факто (напомним, что подобное использование может привести к попаданию в ментальные ловушки, разобранные в соответствующей главе «Архитектуры цифрового мира»). Гибкие практики (и их адаптации для применения в крупных компаниях) предполагают, что в организации определяются продукты, при этом продукты создаются и развиваются выделенными командами специалистов, минимальным образом зависящими друг от друга. Подобные команды могут находиться в самых разных точках земного шара, при этом все они должны работать согласованно (в архитектурном, а не управленческом смысле, поскольку последнее граничит с «микроменеджментом») для обеспечения создания ценности и сохранения конкурентоспособности организации.

Мы уже неоднократно отмечали (как в текущем изложении, так и в предыдущем труде автора), что открытый код и гибкие практики позволяют увеличивать разделение труда и тем самым кардинально повышать его производительность по сравнению с использованием «закрытых» решений (как технологически, так и при «закрытой» философии). В цепочку создания ценности вовлекаются все новые участники (как отдельные специалисты, так и команды), которые отвечают за свои участки деятельности, обеспечивая максимальную эффективность. При этом возрастает общая производительность труда в цепочке разделения, но обратной стороной медали являются резко возрастающие риски отдельных участников технологической цепочки. Ведь чем больше участников цепочки разделения труда (при создании общей ценности), тем больше они зависят от результатов работы друг друга (увеличивается число как поставщиков составляющих, используемых командами в своей работе, так и потребителей результатов этих работ). И в данном случае платформа, выступающая, как говорилось ранее, ценностным мультипликатором, позволяет обеспечить управление соответствующими рисками в цепочке разделения труда. Рассмотрим это на примере, который визуально представлен на Рисунке 5.

Рисунок 5. Продукты, автоматизируемые с помощью платформы

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

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