Все сказанное касается не только хранения информации и использования распределенных СУБД. Платформа событийного обмена также должна обеспечивать возможность исполнения решений в распределенной конфигурации. Из современных решений первым кандидатом на подобную роль может считаться Apache Kafka, уже использующаяся в таких компаниях, как вышеупомянутый The New York Times, Linkedin, Uber, «Сбербанк России» и многих других. Решение изначально поддерживает распределенную топологию развертывания и предоставляет широкий спектр возможностей для «тонкой» настройки.
Поскольку микросервисы не сохраняют состояние между вызовами, они нуждаются в предварительной выборке данных для отображения пользователю необходимой ему информации, а также реакции на его запросы. Для обеспечения эффективного доступа к часто используемым данным обычно применяются технологии кэширования (IMDG), также поддерживающие распределенные топологии. Примерами могут служить упомянутый выше Apache Ignite или Infinispan.
Пример решения, представленный на Рисунках 13 и 14, не является исчерпывающим с точки зрения распределенного функционирования современных ИТ-решений. Например, для финансовой сферы актуально выполнение групповых операций, предполагающих проведение однотипных действий над огромными объемами данных. Примером такой операции может служить массовое начисление процентов по счетам. Современные технологии позволяют осуществлять выполнение подобных ресурсоемких операций в оперативной памяти на распределенных узлах обработки, при этом мощность каждого отдельного узла соответствует скорее продвинутому персональному компьютеру, а не гигантскому серверу, что представляет собой разительное отличие от традиционных подходов, стяжавших недобрую славу в профессиональном сообществе и по праву получивших наименование жаргонного типа «залить железом». Аналогичным образом данные могут храниться не только в распределенных базах данных, но и в распределенной файловой системе, что принципиально снижает стоимость хранения (крайне актуально при современном росте объемов хранимых данных).
Таким образом, мы видим, что на всех уровнях создания и развития программного обеспечения востребована концепция распределенного исполнения, под нее создается соответствующий технологический базис. Задача архитектора при этом не только распределить границы областей разработки решения по продуктовым областям, но и предложить технологические платформы и их топологии, позволяющие максимально эффективно выполнять задачи ИТ-решения по мере реализации последнего. Одновременно учитывается возможность непредсказуемой нагрузки на решение посредством дистанционных каналов. Например, если финансовая организация предложит исключительно выгодный по меркам рынка продукт, каналом предложения которого и соответствующего приема заявок станет сайт компании (без требования регистрации, что выгодно отличает его перед, например, системами дистанционного банковского обслуживания, ДБО), то нагрузка на ИТ-ландшафт может резко возрасти за краткий промежуток времени. Создаваемая архитектура должна позволить решению сохранить корректность функционирования и качество предоставления услуг и при столь агрессивно возрастающей нагрузке.
Основываясь на вышеизложенном, можем отметить, что роль архитектора в рамках ответа на те вызовы, которые ставит перед архитектурой фактор распределенности, существенно изменилась. На сегодня необходимо обладать знанием широкого спектра программного обеспечения, рассчитанного на функционирование в распределенной гетерогенной среде, знать его основные топологии и сценарии их применения, погружаться в предметную область для качественной грануляции проектируемых информационных систем, позволяющей вести разработку силами распределенных команд. На сегодня архитектор это не выделенный специалист, привлекаемый командами «по случаю», но лидер технологических изменений. Он задает ключевые направляющие создания, развития решений, а также их технологического наполнения.
Архитектура и бизнес-процессы
Важнейшей тенденцией развития архитектуры является ее способность обеспечить качественное и эффективное исполнение бизнес-процессов, актуальных для организации, автоматизация деятельности которой рассматривается.
Любая современная организация обеспечивает структуризацию своей деятельности на основании ее упорядочивания с последующим описанием и формирования бизнес-процессов, которые в удобочитаемом формате (например, в BPMN-нотации) обеспечивают наглядное и доступное описание выполняемых действий. При этом к бизнес-процессам обычно предъявляются требования по обеспечению возможности моделирования, определения этапа исполнения, а также задания количественных метрик (KPI), позволяющих проводить их анализ и оптимизацию.
Архитектура и бизнес-процессы
Важнейшей тенденцией развития архитектуры является ее способность обеспечить качественное и эффективное исполнение бизнес-процессов, актуальных для организации, автоматизация деятельности которой рассматривается.
Любая современная организация обеспечивает структуризацию своей деятельности на основании ее упорядочивания с последующим описанием и формирования бизнес-процессов, которые в удобочитаемом формате (например, в BPMN-нотации) обеспечивают наглядное и доступное описание выполняемых действий. При этом к бизнес-процессам обычно предъявляются требования по обеспечению возможности моделирования, определения этапа исполнения, а также задания количественных метрик (KPI), позволяющих проводить их анализ и оптимизацию.
Для обеспечения автоматизированного исполнения бизнес-процессов используются движки исполнения бизнес-процессов (BPM-движки), обеспечивающие следующие основные возможности:
Моделирование процесса при помощи наглядных визуальных средств (полнота поддержки BPMN-нотации может варьироваться в зависимости от конкретного моделирующего средства).
Задание связей, как выполняемых в рамках процесса действий, так и интеграций с внешними системами, которые ответственны как за непосредственное выполнение операций, так и могут предоставлять интерфейсы автоматизированных рабочих мест для выполнения задач пользователями (внутренними и внешними).
Автоматизированное выполнение шагов процесса в соответствии с заданным алгоритмом.
Назначение ролей, ответственных за этапы выполнения процесса.
Определение метрик и KPI процесса и его составляющих, а также ролей, задействованных в процессе.
При этом в течение долгого времени BPM-движки представляли собой сложные платформы автоматизации монолитного характера, которые осуществляли управление всеми бизнес-процессами организации. Указанный подход содержал серьезные риски, которые затрудняли эффективное внедрение средств автоматизации управления бизнес-процессами:
Невысокая производительность средств автоматизации процессов стала одним из основных препятствий их внедрения. Зачастую многие организации осуществляли автоматизацию бизнес-процессов, жестко программируя их выполнение, при этом основной мотивацией такого выбора была именно забота о производительности.
Монолитный характер BPM-движков приводил к сложной технологической связи бизнес-процессов (зачастую не столь тесно связанных между собой на уровне потребностей бизнеса) и невозможности их независимого масштабирования, что увеличивало затраты на инфраструктурное обеспечение приемлемого качества функционирования.
Поддержание большого количества бизнес-процессов на уровне монолитного BPM-движка явным образом ставило перед организациями проблему создания общей модели данных, применимой для всех бизнес-процессов, либо обеспечения согласования различных используемых моделей данных оба приведенных варианта направления работы влекли серьезные трудозатраты, за которыми логичным образом следовали и финансовые затраты.
Пример монолитного BPM-движка в ИТ-ландшафте схематично показан на Рисунке 15.
Рисунок 15. Пример монолитного BPM-движка в ИТ-ландшафте
На Рисунке 15 представлен BPM-движок, обеспечивающий выполнение бизнес-процессов ИТ-ландшафта, выстроенного в монолитной или SOA архитектуре. Некоторое число информационных систем (N на рисунке) обеспечивают автоматизацию бизнес-действий, организуемых в некоторое число бизнес-процессов (K на рисунке). Соответственно, монолитный движок должен поддерживать значительное число (в современной организации оба параметра могут варьироваться от сотен до тысяч) сочетаний бизнес-действий и систем. При этом независимое масштабирование невозможно.
Подобная топология развертывания решения по автоматизации бизнес-процессов затрудняла разработку ИТ-решений распределенными командами разработки, а распределенное исполнение (в современном понимании, подробно рассмотренном выше) информационных систем и ИТ-ландшафта в целом исключалось. Долгое время лидирующая роль на рынке BPM-движков принадлежала «закрытым» решениям, поставляемым крупными компаниями разработчиками программного обеспечения, таким как IBM и Oracle.
Ранее рассматривались такие архитектурные практики трансформации как переход к микросервисной архитектуре, использование продуктового подхода и EDA. Нетрудно заметить, что при реализации новых технологических решений в парадигме микросервисной архитектуры монолитный BPM-движок становится узким местом в части скорости разработки: каждая информационная система в микросервисной парадигме разрабатывается несколькими продуктовыми командами, что в свою очередь предъявляет серьезные требования к развитию BPM-движка. Нельзя не отметить, что резко возросшие требования к производительности создаваемых решений предъявляют качественно иные требования к масштабированию всех компонентов ИТ-ландшафта, в том числе BPM-движку.