Архитектура цифровых платформ. От настоящего к будущему - страница 10

Архитектура распределенных программных комплексов, к которым относятся и сами платформы, и платформенные приложения, является достаточно сложной по сравнению с архитектурными решениями предыдущих поколений. И создавать ее ограниченной командой крайне затруднительно (конечно, такой вариант также возможен, но он приводит к неприемлемым в современном цифровом мире временным затратам). Практика (которая, как известно, является критерием истины) показывает, что современные команды создания и развития платформ и платформенных приложений являются распределенными: как члены одной команды могут находиться в самых разных точках земного шара, так и работа нескольких команд над современными технологическими решениями не только допускает, но и настаивает на их распределенной работе. Здесь есть прямое пересечение с вопросами использования решений с открытым исходным кодом: если успешные решения развиваются десятками (а иногда и сотнями) организаций, то отдельные специалисты и команды развития априори не могут не быть распределенными. Соответственно, и платформы, составляющие вместе с платформенными приложениями полноценные экосистемы, использующие развитые решения с открытым кодом, также развиваются распределенными командами.

Мы уже отмечали ранее, что современные компании, ставящие целью сохранение конкурентоспособности в цифровом мире, стараются уйти от процессной организации деятельности, отказываются от нее в пользу продуктовой. Подобный переход достаточно легко объясним: лишь эффективное взаимодействие с клиентами и партнерами, позволяющее решать их задачи, обеспечивает конкурентоспособность, а решение клиентских и/или партнерских задач осуществляется за счет предоставления им ценности. Ценность же выражается в продукте. В задачи настоящей книги не входит описание всей продуктовой и ценностной концепции, желающие могут изучить разнообразную литературу, посвященную гибким практикам, разработкам клиентского пути и т. д. Мы лишь констатируем, что продукт в организации первичен. Но первичность продукта не означает отсутствия иных сущностей. Продуктовый подход декларирует первичность продукта, но не отрицает бизнес-процессы. Последние в обязательном порядке присутствуют в современной организации, но их задача в реалиях интенсивного развития – описывать жизненный цикл продукта, таким образом, мы приходим к сегментации бизнес-процессов. Вслед за продуктами, группами продуктов или продуктовыми доменами мы имеем все основания определить группы бизнес-процессов, характеризующих конкретные продукты.

Так как платформа поддерживает (и даже продвигает) продуктовый подход, то она обязана поддерживать и бизнес-процессы, связанные с продуктами. Под поддержкой в данном случае понимается широкий спектр активностей: здесь и проектирование бизнес-процессов, и исполнение их экземпляров, и поддержка версионности, и мониторинг (технический и прикладной), и выставление КПЭ процессов, поиск узких мест. Разумеется, непосредственное исполнение экземпляров процессов ассоциируется с конкретными платформенными приложениями, но в задачи платформы входит предоставление инструментальных средств поддержки столь важного функционала, что снимает повышенную нагрузку с каждого выделенного приложения, позволяя не изобретать велосипед, а решать конкретные задачи, связанные с потребностями клиентов и/или партнеров организации. Распределенность же платформ и платформенных приложений диктует необходимость обеспечения распределенности исполнения бизнес-процессов, что также является одним из важнейших аспектов поддержки платформами тренда развития архитектуры, связанного с автоматизацией процессной деятельности (в рамках привязки ее к продуктовому подходу, учитывая указанное выше первостепенное, но не единственное значение продуктов).