Ведение синтетического учета предполагает выполнение большого количества транзакционных операций, характеризующихся высокой степенью унификации, минимальными (а зачастую отсутствующими в принципе) требованиями по гибкости настройки (ввиду указанной унификации), серьезными вызовами в части производительности, необходимостью проведения высокоэффективных групповых операций (в случае финансовой организации в качестве примера можно привести необходимость формирования регуляторной отчетности), скромными требованиями к удобству пользовательского интерфейса (в данном случае говорить о вроде бы ставших общепринятыми терминах «клиентский путь», «дизайн-мышление» и им подобных не приходится).
При ведении аналитического учета предъявляются требования гибкой настройки параметров продукта и их связи с показателями синтетического учета. В данном случае имеет смысл говорить об адресности проводимых операций (уже их результаты преобразуются в синтетические проводки, требования к которым становятся базовыми для платформы синтетического учета). То есть производительность в случае аналитического учета рассматривается не с точки зрения эффективности выполнения групповых или пакетных операций, а с точки зрения возможности сегментации работы с продуктами различных типов (например, депозитными и кредитными продуктами в случае финансовой организации) и снижения нагрузки на каждый продукт в отдельности, а также исключения их взаимовлияния. Требования к пользовательскому интерфейсу формируются в соответствии с параметрами аналитического учета, а также ширины спектра продуктов организации: необходимо предоставить развитые пользовательские настройки для формирования параметров продуктов, организации связи кросс-продуктов, адаптации интерфейсов к развитию продуктового ряда, характерному для современного цифрового мира. Поскольку соответствующие настройки проводят сотрудники организации (в более редких случаях – сотрудники компаний-партнеров), то мы говорим скорее об удобстве интерфейсов, нежели о производительности последних.
Автоматизация бизнес-процессов предполагает возможность быстрого создания и изменения последних, а также обеспечение их мониторинга, расчета КПЭ и т. д. Продуктовые бизнес-процессы предполагают исключительно широкие возможности настройки, необходимость создания и исполнения кросс-продуктовых процессов (задействующих различные типы продуктов с генерацией совместной аналитической и синтетической учетной логики), потенциал создания большого количества точек интеграции, использование современных практик low-code и no-code для проектирования и исполнения процессов. Можно констатировать, что требования к удобству и гибкости настроек для данного слоя исключительно актуальны. Долгое время считалось, что вопросы производительности на уровне настройки и исполнения бизнес-процессов уходят на второй план по сравнению с гибкостью, но современный мир диктует необходимость изменения подобного подхода. В условиях повсеместного развития дистанционных каналов обслуживания невысокая производительность автоматизированных бизнес-процессов приведет к утрате конкурентоспособности организации, допустившей указанный недостаток. Например, низкая скорость обработки поступающих заявок на кредит исключает привлекательность для клиентов каналов, не требующих аутентификации (например, сайты компании или ее партнеров), обнуляя возможность лидогенерации, что недопустимо для организации, ставящей во главу угла интенсивное развитие. При этом вопросы выполнения групповых и пакетных операций (по аналогии с автоматизацией аналитического учета) практически неактуальны. Вопросы мониторинга исполняющихся процессов, напротив, крайне важны: специалисты, ответственные за развитие бизнес-процессов организации, должны иметь возможность моделирования и установки КПЭ процессов, клиенты и партнеры нуждаются в развитой статусной модели процессов, позволяющей получать информацию о состоянии интересующих их процессов и обрабатываемых в ходе их исполнения данных. При этом традиционной характеристикой автоматизации бизнес-процессов является высокое потребление вычислительных ресурсов при выполнении данной задачи. Соответственно, необходим мониторинг ресурсов, потребляемых теми или иными бизнес-процессами и их экземплярами, на основании данных которого оказывается возможным обеспечивать «здоровье» ИТ-ландшафта организации. В рассматриваемом случае речь идет о командах DevOps и/или сопровождения, являющихся пользователями мониторинга бизнес-процессов. То есть речь идет как о системном, так и о прикладном характере мониторинга. Пользователи же мониторинга являются как внутренними с точки зрения организации, так и внешними. Проанализировав все указанные аспекты, мы приходим к необходимости высоких требований к возможностям пользовательского интерфейса «платформы» автоматизации бизнес-процессов. При этом автоматизация бизнес-процессов в большинстве случаев не предполагает транзакционного характера исполняемых операций (в части того, что операции на уровне данной составляющей не являются типовыми и/или короткоживущими).
При автоматизации фронтальной составляющей продукта особое внимание уделяется упомянутым выше «клиентскому пути» и «дизайн-мышлению», а также аналогичным им аспектам. В противном случае конкурентоспособность продукта оказывается чрезвычайно низкой в современном цифровом мире, инвестирование средств в создание, развитие и продвижение такого продукта теряет всяческий смысл. При несомненной важности рассмотренных выше аспектов продуктовой автоматизации фронтальное представление является базовой составляющей формирования эффективного P&L (profit and loss analysis) продукта. Составляющей исключительной важности в случае фронтального представления является производительность этого самого автоматизируемого фронтального представления: в случае медленной отрисовки графики по продукту, длительного переключения экранов представления потенциальный (да и действующий) клиент потеряет интерес к продукту, обратит внимание на предложения конкурентов, и организация понесет убытки. Особенно актуален вопрос производительности в условиях дистанционных каналов, далеко не все из которых в процессе лидогенерации предъявляют требования к обязательности аутентификации или заполнению пространных анкет. В условиях резкого роста числа каналов продукты должны быть представлены если не в каждом из них, то в некоем значимом множестве. В противном случае можно неоправданно сократить воронку продаж. И организация приходит к необходимости поддержки концепции омниканальности, при которой все каналы коммуникации с пользователями (в их число могут входить не только клиенты организации, но и ее сотрудники и партнеры) объединяются в единую связанную экосистему, при этом коммуникация в рамках продуктового взаимодействия носит сквозной характер. Таким образом достигается целостное взаимодействие пользователей с автоматизируемым продуктом. Но как обеспечить рассматриваемую омниканальность? Зачастую организации добавляют в свой ландшафт очередную «платформу» – омниканальную, в задачи которой входит:
• Отделение логики представления от процессной.
• Предоставление развитых инструментов создания интерфейсов.
• Поддержка различных каналов взаимодействия с пользователем как на уровне восприятия, так и на уровне фронтальных процессов (дополнительной сущности, отделяемой от продуктовых процессов прикладного характера, рассмотренных выше).
• Обеспечение непрерывности коммуникации с пользователями.
• И многие другие…
Также отметим уже ставшее фактически стандартом де-факто требование, предъявляемое к технологиям создания фронтальных интерфейсов, заключающееся в легковесности последних. Фронтальные приложения и их компоненты выполняются на самых разных устройствах, обеспечивают различные каналы коммуникации, вынуждены учитывать проблемы сетевого взаимодействия и т. д. Создание тяжеловесных фронтальных компонентов пользовательского приложения фактически обнуляет конкурентоспособность продукта, а вместе с ним и организации, его предоставляющей. Соответствующее требование легковесности транслируется и в отношении омниканальной «платформы», отличая ее от предшествующих.
Изучив приведенное выше описание, читатель непременно задаст вопрос: «Так в чем же отличие этого платформенного подхода от классической SOA-архитектуры? В такой ситуации надо создавать микросервисы, которые обеспечат распределенность, а то по факту просто системы заменили платформами!» И принципиально внимательный читатель будет прав: фактически значимая доработка продукта, созданного в подобной архитектуре, будет весьма схожа с его доработкой при реализации принципов SOA. Действительно, столь разная организация автоматизации каждого уровня продукта, предоставляемого организацией клиентам и/или партнерам, потребует фактически выделенной продуктовой команды на каждом уровне. Да, в случае простого продукта можно составить продуктовую команду, отвечающую принципам гибких практик, но современные продукты (а особенно если речь идет о кросс-продуктах) крайне сложны, требуют привлечения специалистов разных компетенций. А потому даже на одном уровне автоматизации (при приведенном выше примере принципиально различных технологических и организационных требованиях к базису каждого) может оказаться весьма затруднительным собрать единую команду гибких практик, развивающую соответствующий продукт. После чего возникнет необходимость синхронизации работы команд для обеспечения качества создаваемого продукта, дабы последний не стал подобен лоскутному одеялу из слабо связанных между собой доработок, что в свою очередь может повлечь как рыночную слабость продукта, так и нарушение непрерывности его предоставления. При этом команда развития каждого уровня автоматизации продукта реализует требуемые доработки с разной скоростью, зависящей от функциональной и нефункциональной составляющей, например:
• Доработки могут проводиться на некотором подмножестве уровней автоматизации продукта: доработки фронтального представления, например, не затрагивать учетные составляющие.
• Различный технологический базис уровней автоматизации приводит к разной скорости их развития в соответствии с нефункциональными требованиями.
Добавим сюда еще и возможное попадание в ментальную ловушку, рассмотренную в главе «Архитектуры цифрового мира», посвященной цифровым платформам, а именно создание выделенных команд разработки и развития платформ. В случае масштабирования указанной ошибки на рассматриваемую в примере организацию может оказаться вероятным, что продукт разрабатывается набором команд гибких практик разработки, при этом для каждой платформы в организации существует отдельная команда развития. Получается, что в общем случае (при условии высокой сложности автоматизируемого продукта) мы можем столкнуться с ситуацией, при которой в реализации значимой продуктовой доработки могут быть задействованы до восьми (!) команд разработки. Синхронизация их деятельности становится весьма нетривиальной задачей. И даже совмещение платформенных и продуктовых команд в отдельных случаях (например, это вполне возможно для случая автоматизации функций синтетического учета) не привносит принципиального упрощения ситуации. И стоит учесть, что в рассматриваемом примере мы сознательно учитывали относительно простую структуру как продукта, так и организации. Последняя может внедрять еще и «платформу CRM», и расширяющую «омниканальную платформу» «платформу» ДБО, к примеру, и «платформу MDM», и многие другие аналогичные «платформы».
Мы видим, что подобное следование платформенному подходу, заключающееся фактически в бездумном производстве все новых и новых «платформ», нисколько не упрощает автоматизацию деятельности организации, не приближает ее к перманентному интенсивному развитию. Более того, создание платформ само по себе является трудоемким и финансово недешевым процессом. Результат же, который нами был продемонстрирован на достаточно простом примере, вовсе не приводит к экономии каких-либо ресурсов, доступных организации. В то же время мы регулярно говорим о необходимости перехода к платформенному подходу. В чем же дело? Мы просто следуем моде либо обосновываем бесконечный рост затрат на автоматизацию и цифровизацию? Поставим вопрос по-другому: какой должна быть платформа для достижения результатов автоматизации/цифровизации, заключающихся в переводе организационных процессов и продуктов на новый качественный уровень, какая платформа становится инструментом, обеспечивающим перманентное интенсивное развитие, какая платформа соответствует mindset современности, то есть какой должна быть современная платформа? Также впору задать вопрос: что можно, а что нельзя считать современной цифровой платформой?
Ответ на вопрос о платформе и ее видении необходимо начать с краткого обзора современного mindset. Мы не будем подробно рассматривать все его аспекты, желающие могут ознакомиться с ними в «Архитектуре цифрового мира». В отношении особенностей современного архитектурного mindset, обеспечивающего перманентное интенсивное развитие, можно выделить следующие:
– Ключевым элементом mindset является фокус на продукте, представляющем ценность для партнеров и клиентов организации, его создающей. Далеко не всегда определить продукт оказывается простой задачей, во многом корректное формирование продуктового видения конкретной организации требует серьезного изменения мышления и позиционирования себя на рынке, частным случаем которого является уход от продуктологов к владельцам продуктов.
• Как уже отмечено, современный архитектурный mindset должен обеспечивать перманентное интенсивное развитие. Соответственно, его инструментальное обеспечение (куда можно отнести и платформы) должно отвечать указанному требованию.
• Современный архитектурный mindset должен успешно обходить ментальные ловушки, связанные с гибкими практиками, информационной безопасностью, шаблонами проектирования, эффектом Даннинга – Крюгера (подробно рассмотрены в «Архитектуре цифрового мира»). И платформы также должны успешно противостоять той ментальной лености, которая тянет нас в указанные ловушки.
Возвращаясь к представленному выше примеру платформенного подхода, основанного на множестве «платформ», можно отметить, что он полностью игнорирует современный mindset. Фактически в нем отсутствует видение продукта – нет общей продуктовой концепции (а во многих случаях она окончательно «добита» наличием платформенных команд). Создание и развитие продукта, отвечающие требованиям современного цифрового мира, при таком подходе невозможны ввиду необходимости синхронизации рабочего процесса огромного количества специалистов разных направлений деятельности. В особо запущенных случаях деградации организации понятие продукта сводится к его визуальному или процессному представлению. В таком ракурсе невозможно обеспечить перманентное интенсивное развитие, так как векторы «развития» каждой применяемой «платформы» оказываются строго разнонаправленными, результат же получается аналогичным басне И. А. Крылова «Лебедь, щука и рак». Ведь самостоятельное развитие каждой «платформы» может затормозить общее продуктовое развитие, останов же платформенного развития приведет к бесконечному наращиванию продуктового функционала на стремительно устаревающей технологической базе.
При подобном развитии событий крайне сложно избежать и ментальных ловушек, перечисленных выше. При отсутствии общего продуктового видения корректные адаптация и применение гибких практик становятся невозможными, так как отсутствует продукт, на реализацию которого и направлены сами гибкие практики. Наиболее частым случаем, встречающимся на практике при применении такого подхода, является бесконечный «Waterfall со стендапами», в который погружаются разрозненные команды, отвечающие за автоматизацию конкретных уровней рассмотрения продукта (в нашем примере их представлено четыре, но может быть и существенно больше при мелкой грануляции технологий автоматизации, применяемых в организации). При этом можно клеить на доску сколько угодно стикеров с описанием решаемых задач, синхронизировать бэклоги команд на соответствующих статусах, использовать современные инструментальные средства поддержки гибких практик, но не будет главного – согласованной работы над продуктом. Для упрощения производственной деятельности, пытаясь ускорить разработку тяжеловесных платформ, будут применяться новые и новые шаблоны проектирования, не ведущие к созданию ценности, но с какого-то момента существующие сами по себе. Ну и выход на «плато стабильности» эффекта Даннинга – Крюгера для подобным образом собранного сообщества также будет затруднен. Некая команда (например, реализующая фронтальное представление продукта при помощи «омниканальной платформы») будет продолжать находиться на «пике тупости», основываясь на относительно невысокой скорости реализации требуемого продуктового функционала другой командой, обладающей априори меньшей емкостью в терминах гибких практик (в качестве примера можно привести команду, отвечающую за ведение частного аналитического продуктового учета), которая, погрязнув в задачах и техническом долге, окажется зажатой в «обрыве сознания».
Разумеется, говорить об интенсивном развитии в данном случае не приходится, а потому и считать приведенный выше пример реальным следованием платформенному подходу также нельзя. Более того, невозможно именовать приведенные в примере «платформы» таковыми, поскольку они затрудняют развитие, обеспечивают попадание в ментальные ловушки, исключают формирование комплексного архитектурного mindset. И здесь содержится важная часть ответа на вопрос, что можно считать цифровой платформой будущего.
Мы сразу оговоримся, что платформа не предоставляет продукты сама по себе. Автоматизация продуктов, предоставляемых организацией клиентам и партнерам, осуществляется посредством платформенных приложений, которые мы рассмотрим в соответствующей главе. Но платформа должна предоставлять полноценный спектр инструментального обеспечения для автоматизации всех аспектов продуктов организации. То есть концепция продукта организации должна иметь инструментальную платформенную поддержку. Важное свойство отсутствия замкнутости платформы позволяет ей поддерживать развитие продуктов и их представлений, требующих новых технологических решений. При этом свойство открытости позволяет продуктовым командам вносить изменения в платформу, публиковать их на уровне платформы, делая их доступными для смежных команд, повышать тем самым общую производительность труда. Таким образом резко снижается потребность в синхронизации команд, столь критичная в приведенном выше примере.
Синхронизация технологического развития платформы (отсутствие замкнутости) и продуктового развития организации позволяет обеспечить ту самую интенсивность, которая является ключом к конкурентоспособности в современном цифровом мире. Технологии, обеспечивая эффективную сквозную автоматизацию, создают простор для продуктового развития, ускоряя и стимулируя его, а развитие в свою очередь требует новых технологий для автоматизации, которые (опять же вследствие отсутствия замкнутости) добавляются в платформу и платформенные приложения.
Читатель вновь может задать вопрос: «Но разные уровни продуктовой автоматизации требуют различных технологий и подходов, как все это обеспечится платформой?» И ответ даст архитектура платформы: последняя должна обладать составной многомодульной структурой, которая обеспечивает создателей приложений сервисами для решения различных задач продуктовой автоматизации в универсальном формате. Взаимосвязь платформ и платформенных сервисов мы рассмотрим в соответствующей главе. Открытость платформы же позволяет создавать расширения модулей, сервисов и самой платформы командам развития продуктов, расширяя возможности инструментального обеспечения.
Указанное согласованное развитие продуктовых команд, эффективно адаптирующих и применяющих гибкие практики разработки, их совместная работа с использованием платформенных технологий и сервисов позволяют обеспечить и совместное развитие mindset на пути достижения уровня, адекватного современному цифровому миру. И пройти этапы эффекта Даннинга – Крюгера до уровня «плато стабильности» становится не в пример легче, главное же – достичь его оказываются в состоянии все команды, задействованные в развитии организации.
Фактически, если применять закон S-кривой и взять за старт последней классическую SOA-архитектуру, то можно констатировать, что рассмотренный выше пример платформенного подхода, заключающийся в использовании множества «платформ», находится на рабочем подготовительном этапе (значительные инвестиции с невысоким результатом), при этом использование современной платформы относится к этапу интенсивного внедрения технологий. Говорить об этапе стагнации платформенного подхода пока рано, поскольку рынок автоматизации нельзя считать насыщенным современными платформенными технологиями (речь идет именно о полноценных цифровых платформах, а не о частных «платформах», которые скорее осложняют автоматизацию). Схематично развитие платформенного подхода представлено на Рисунке 3.
Рисунок 3. S-кривая платформенного подхода
Получается, что создание цифровой платформы, позволяющей обеспечивать достижение современного архитектурного mindset, является ключевым элементом перехода организации к интенсивному развитию в цифровую эпоху. Отметим, что технологические гиганты, создающие и развивающие собственные платформы, идут именно этим путем. Развитая архитектура платформы, тезисно представленная выше, позволит создавать продукты, несущие ценность клиентам и партнерам организации. При этом архитектура платформы должна следовать ключевым тенденциям развития архитектуры в целом, рассмотрению чего будет посвящена следующая глава.
Цифровые платформы и ключевые тренды развития архитектуры
Еще раз о ключевых трендах развития архитектуры
В предыдущей книге «Архитектура цифрового мира» ключевым трендам развития архитектуры был посвящен специальный раздел ввиду исключительной важности данной темы. При этом мы говорили о тех трендах, которые актуальны для современной архитектуры (а также актуальны для цифрового мира) в целом. С учетом той важности платформ, которая заставила нас вновь «взяться за перо», данные тренды актуальны и для платформенного подхода. Напомним их читателю:
• Открытый код.
• Распределенность.
• Бизнес-процессы.
• Данные.
• Искусственный интеллект.
Применение решений с открытым исходным кодом позволило резко повысить производительность труда при создании ИТ-решений. Основой повышения стало значительное увеличение цепочки разделения труда по сравнению с созданием «закрытых» (vendor-lock) решений. Если последние были ограничены масштабами конкретной организации, выступавшей поставщиком (вендором) ИТ-решения, то в случае успешного свободно распространяемого решения, основанного на открытом исходном коде, становится возможным вовлекать принципиально большее сообщество разработчиков в развитие такого решения. Например, являющуюся одной из самых популярных нереляционных СУБД Apache Cassandra развивают десятки крупнейших технологических компаний по всему миру, используют же и вносят точечные исправления сотни. Подобный масштаб недостижим для любой корпорации, развивающей собственные закрытые решения, пусть даже и исключительно масштабной. Указанный подход позволяет резко наращивать производительность труда вследствие включения в цепочку развития все новых и новых специалистов.
Платформы также являются средством повышения эффективности деятельности организации и роста производительности труда (разумеется, мы говорим именно о тех платформах, к архитектуре которых надо стремиться, что было отмечено в предыдущей главе). Было бы странно предположить, что два фактора, обеспечивающих рост производительности труда в современном цифровом мире, не должны присутствовать и взаимодействовать в современной организации, более того, не учитывать друг друга. К сожалению, именно такой деструктивный подход регулярно встречается и на сегодняшний день в ряде организаций. Тем не менее лучшие практики говорят о том, что решения с открытым исходным кодом стремятся к платформенному подходу, лучшие же платформы активно используют решения с открытым исходным кодом. Поэтому первая ключевая тенденция развития платформ – синергия платформ и решений с открытым исходным кодом.
Распределенность рассматривалась нами в «Архитектуре цифрового мира» в двух смысловых плоскостях: распределенное исполнение современных технологических решений и организационная распределенность команд, создающих и развивающих эти решения. Обе смысловые составляющие более чем применимы к платформам. Платформы должны обеспечивать эффективное создание и исполнение приложений (платформенных приложений), несущих ценность клиентам и партнерам организации. Ценность несут продукты организации, автоматизация (и цифровизация) которых осуществляется с помощью платформенных приложений. Современные продукты доступны клиентам во всех часовых поясах и климатических зонах в режиме 24?7. Подобная доступность предполагает непрерывность бизнеса, которая диктует требования к используемой платформе. Платформа должна поддерживать указанный режим функционирования и предоставления продуктов, то есть сама стать распределенной. Длительные периоды недоступности, сервисный останов, ожидание времени отклика – все это признаки технологического застоя и деградации, ведущих к утрате организацией конкурентоспособности на рынке. Поэтому современная платформа (как и платформа будущего) – это распределенная платформа, обеспечивающая эффективное исполнение распределенных же платформенных приложений.
Архитектура распределенных программных комплексов, к которым относятся и сами платформы, и платформенные приложения, является достаточно сложной по сравнению с архитектурными решениями предыдущих поколений. И создавать ее ограниченной командой крайне затруднительно (конечно, такой вариант также возможен, но он приводит к неприемлемым в современном цифровом мире временным затратам). Практика (которая, как известно, является критерием истины) показывает, что современные команды создания и развития платформ и платформенных приложений являются распределенными: как члены одной команды могут находиться в самых разных точках земного шара, так и работа нескольких команд над современными технологическими решениями не только допускает, но и настаивает на их распределенной работе. Здесь есть прямое пересечение с вопросами использования решений с открытым исходным кодом: если успешные решения развиваются десятками (а иногда и сотнями) организаций, то отдельные специалисты и команды развития априори не могут не быть распределенными. Соответственно, и платформы, составляющие вместе с платформенными приложениями полноценные экосистемы, использующие развитые решения с открытым кодом, также развиваются распределенными командами.
Мы уже отмечали ранее, что современные компании, ставящие целью сохранение конкурентоспособности в цифровом мире, стараются уйти от процессной организации деятельности, отказываются от нее в пользу продуктовой. Подобный переход достаточно легко объясним: лишь эффективное взаимодействие с клиентами и партнерами, позволяющее решать их задачи, обеспечивает конкурентоспособность, а решение клиентских и/или партнерских задач осуществляется за счет предоставления им ценности. Ценность же выражается в продукте. В задачи настоящей книги не входит описание всей продуктовой и ценностной концепции, желающие могут изучить разнообразную литературу, посвященную гибким практикам, разработкам клиентского пути и т. д. Мы лишь констатируем, что продукт в организации первичен. Но первичность продукта не означает отсутствия иных сущностей. Продуктовый подход декларирует первичность продукта, но не отрицает бизнес-процессы. Последние в обязательном порядке присутствуют в современной организации, но их задача в реалиях интенсивного развития – описывать жизненный цикл продукта, таким образом, мы приходим к сегментации бизнес-процессов. Вслед за продуктами, группами продуктов или продуктовыми доменами мы имеем все основания определить группы бизнес-процессов, характеризующих конкретные продукты.
Так как платформа поддерживает (и даже продвигает) продуктовый подход, то она обязана поддерживать и бизнес-процессы, связанные с продуктами. Под поддержкой в данном случае понимается широкий спектр активностей: здесь и проектирование бизнес-процессов, и исполнение их экземпляров, и поддержка версионности, и мониторинг (технический и прикладной), и выставление КПЭ процессов, поиск узких мест. Разумеется, непосредственное исполнение экземпляров процессов ассоциируется с конкретными платформенными приложениями, но в задачи платформы входит предоставление инструментальных средств поддержки столь важного функционала, что снимает повышенную нагрузку с каждого выделенного приложения, позволяя не изобретать велосипед, а решать конкретные задачи, связанные с потребностями клиентов и/или партнеров организации. Распределенность же платформ и платформенных приложений диктует необходимость обеспечения распределенности исполнения бизнес-процессов, что также является одним из важнейших аспектов поддержки платформами тренда развития архитектуры, связанного с автоматизацией процессной деятельности (в рамках привязки ее к продуктовому подходу, учитывая указанное выше первостепенное, но не единственное значение продуктов).
Значимость данных и их использования растет с каждым годом. Необходимость следования соответствующему тренду развития архитектуры стала еще более очевидной с момента публикации предыдущей книги автора, где данный тренд также специально подчеркивался. Данных, необходимых организациям, становится все больше, потребности в их эффективных хранении и обработке все выше. Использование для решения подобных задач архитектурных подходов предыдущих поколений попросту недопустимо: представим себе очередную (уже которую по счету) BI-систему, продаваемую лицам, принимающим решения в организации, в качестве «серебряной пули», обеспечивающей качественную аналитику и принятие решений. И раз за разом подобные «спасительные» инструменты терпят крах вследствие низкого качества данных организации, необходимости взаимодействия с несвязанными источниками данных, сложнейшими алгоритмами обработки последних и т. д. Подобный пример приведен с целью подчеркнуть актуальность проблемы с данными, которая не исчезла, а скорее усугубилась за последние годы. И цифровая платформа, предоставляющая средство обеспечения перманентного интенсивного развития, должна помогать в решении проблем с данными, обеспечивать следование указанной тенденции развития архитектуры.
В рамках поддержки управления данными в современной архитектуре платформа должна обеспечивать:
• Возможность следования самым разным концепциям управления данными (за разработку подобных концепций отвечают, как правило, выделенные специалисты), используемым в организации.
• Осуществлять поддержку сбора данных из источников (распределенных, что показывает связь с обозначенной выше распределенностью как тенденцией развития архитектуры), их обработку, подготовку витрин (как аналитических, создающихся за продолжительные промежутки времени, так и создаваемых в режиме реального времени).
• Создание универсальных форматов отображения (в этом случае BI-инструменты могут и не входить в состав платформы, но, работая с предоставляемыми выгрузками, выполнять заявленные функции вполне качественно).
Еще раз необходимо уточнить, что непосредственную работу с данными осуществляет не сама платформа, а платформенное приложение (в некоторых случаях платформенный сервис; разграничение между платформенным сервисом и платформенным приложением будет рассмотрено в соответствующей главе). Но платформа предоставляет все необходимые инструменты для создания и работы приложений.
Искусственный интеллект как тенденция развития архитектуры (а скорее как тенденция развития мира) пережил с момента публикации «Архитектуры цифрового мира» целый взрыв интереса к технологии, при этом спектр эмоций менялся от страха и недоверия до обожания, граничащего с почитанием. Неудивительно, что существенная часть мнений в отношении технологий искусственного интеллекта относится к тому, что принято именовать «хайпом». Как правило, хайп имеет вполне конкретное приложение усилий, в последние годы этим приложением является ChatGPT. Но наличие хайпа не может и не должно заслонять главного: в мире существует огромный и объективный запрос на массовое применение технологий искусственного интеллекта. Этот запрос обусловлен ограниченностью определенных возможностей человеческого интеллекта (быстродействие, скорость принятия решений, объем и долговременность памяти и т. д.). Следовательно, современная платформа должна поддерживать соответствующее технологическое направление (искусственный интеллект), его развитие и применение в приложениях. Если в предыдущей книге автор писал, что «на сегодня применение искусственного интеллекта ограничивается решением узкоспециализированных задач: выявление мошенничества, диагностика заболеваний, формирование стратегии интеллектуальных игр (шахматы, го), принятие решений в области рисков, промышленная роботизация», то по прошествии времени можно уверенно сказать, что соответствующий рубеж пройден. Пусть пока и на относительно примитивном уровне, но решаются задачи комплексного характера, связанные с систематизацией научных исследований, разработкой программного кода, подготовкой судебных решений, развитой роботизацией и т. д. Нельзя не отметить, что современные решения искусственного интеллекта весьма ресурсоемки, требуют значительных вычислительных мощностей (что приводит даже к перекосам на фондовом рынке). Поэтому к задачам поддержки соответствующей тенденции развития архитектуры можно отнести в том числе и оптимизацию потребления ресурсов при решении актуальных задач, которые ставятся перед технологиями искусственного интеллекта.
