Архитектура цифрового мира
- -
- 100%
- +
В современных организациях определяются сотни и тысячи бизнес-процессов, эффективное исполнение которых формирует пульс жизни самой организации. Традиционным архитектурным решением для автоматизации выполнения бизнес-процессов было включение в структуру ИТ-ландшафта организации компонента, обычно именуемого Business Process Manager (BPM), который позволяет последовательно выполнять шаги всех бизнес-процессов, требующих автоматизации. Отметим, что современные бизнес-процессы состоят из сотен автоматизируемых действий, при этом в организациях, следующих в своей работе гибким методологиям, в бизнес-процессы постоянно вносятся изменения, применение которых в режиме промышленной эксплуатации востребовано в реальном времени. Традиционное централизованное исполнение бизнес-процессов общим компонентом BPM ограничивает возможности независимой работы команд разработчиков, а также вызывает вопросы к собственной нагрузочной способности. Современная архитектура должна обеспечивать гибкую автоматизацию бизнес-процессов, при которой управление бизнес-процессом децентрализовано, отдельные компоненты бизнес-процесса автоматизируются независимыми командами разработчиков, немедленно внедряющими вносимые ими изменения в промышленную эксплуатацию. Соответственно, определяется третья ключевая тенденция развития архитектуры, связанная с автоматизацией бизнес-процессов.
Одним из краеугольных камней современного цифрового мира являются данные. При этом за последние годы (можно сказать, что даже за последние 10 лет) существенным образом изменился сам подход к данным. Во многом основой изменений стала деятельность технологических гигантов, выросших из вчерашних стартапов. Еще десять лет назад многие компании традиционных секторов экономики в течение длительного периода времени накапливали данные о своих клиентах, продуктах, технологических процессах структурированным образом, предполагавшим сбор информации из анкет, данных органов государственной власти, кредитных бюро, истории взаимодействия с организацией и/или ее несколькими партнерами (с которыми были заключены договоры, предусматривавшие возможность передачи соответствующих данных). Затем на основе собранных данных строились аналитические витрины, позволявшие не только формировать обязательную отчетность, но и определять показатели эффективности и их достижение, планировать разработку новых продуктов организации и т. д. При этом построение аналитических витрин занимало продолжительное время, сами же витрины и выводы на их основе носили статистический характер. В последние 10 лет под влиянием технологических гигантов в части работы с данными произошли существенные изменения. Созданы социальные платформы международного характера, пользователи которых предоставляют сведения о себе, носящие как структурированный, так и неструктурированный (информация о хобби, фотографии, видео и т.д.) характер. В результате автоматизации промышленности собирается колоссальное количество данных о состоянии оборудования, его составных частей, необходимости ремонта, параметрах помещений, где располагается оборудование и т. д. Такое количество данных оказалось фактически невозможно обработать за приемлемый промежуток времени – поломки оборудования происходили за более короткий промежуток времени, нежели требовался для расчета вероятности поломки.
На основании изменившегося характера и количества данных требовались и новые подходы к их обработке. Пионерами здесь также стали технологические гиганты. Новые средства автоматизации работы с данными позволяли обрабатывать качественно новые объемы информации, носящей как структурированный, так и неструктурированный характер, в режиме, приближенном к реальному времени. Более того, результаты обработки зачастую могут носить не статистический, а таргетированный характер. Примерами такой обработки являются лента новостей в социальных сетях и контекстная реклама. Новые возможности, открывавшиеся в результате сбора данных и их обработки современными технологическими средствами, привлекли внимание и представителей традиционных отраслей человеческой деятельности. Сегодня уже не является удивительным, например, формирование комбинированных финансовых продуктов банковскими организациями и их таргетированное предложение клиентам, при этом основанием для формирования и предложения являются предпочтения клиента, представленные им в социальных сетях. Таким образом, данные, их обработка, анализ результатов последней являются исключительно важными аспектами проектирования информационных систем нового поколения во всех областях цифрового мира. Соответственно, следует выделить четвертую ключевую тенденцию развития архитектуры – данные. Отметим также, что большинство современных технологических средств, обеспечивающих качественно новый уровень работы с данными, основаны на принципах открытого кода. Таким образом, можно отметить синергию ключевых тенденций развития архитектуры.
Сбор данных и аналитика, осуществляемая на их основе, дают основание проводить экстраполяцию соответствующей тенденции на принятие решений, выполняемое в автоматическом режиме. Логическим продолжением соответствующих тенденций становится внедрение в различные области человеческой деятельности технологий искусственного интеллекта, позволяющего принимать решения, осуществлять действия, в том числе требующие творческой составляющей и традиционно считающиеся прерогативой человека. Автоматизация соответствующих областей также стала реальностью. Отметим, что на сегодня применение искусственного интеллекта ограничивается решением узкоспециализированных задач: выявление мошенничества, диагностика заболеваний, формирование стратегии интеллектуальных игр (шахматы, го), принятие решений в области рисков, промышленная роботизация. При этом комплексные интеллектуальные технологические решения, объединяющие различные отрасли и сферы деятельности, на сегодня недостаточно развиты, невзирая на имеющийся спрос. Таким образом, следует выделить еще одну (пятую) ключевую тенденцию развития архитектуры, заключающуюся в опоре на искусственный интеллект, позволяющую давать ответ на спрос в части соответствующих решений. Внедрение искусственного интеллекта может кратно (а возможно, и на порядки) повысить эффективность и качество производственных и бизнес-процессов.
Выделенные пять тенденций являются ключевыми современными тенденциями в развитии архитектуры вследствие кратного увеличения качества внедрения ИТ, повышения эффективности соответствующих внедрений и их последующего влияния на сферы, где эти внедрения осуществляются. Отметим также, что данные тенденции не следует рассматривать изолированно друг от друга, по ходу настоящего раздела уже приводились примеры их взаимовлияния. В рамках следующих разделов выявленные тенденции будут рассматриваться более подробно, их синергия также будет подробно рассмотрена.
Необходимо отметить, что многие современные тенденции в архитектуре, считающиеся на сегодняшний день уже стандартом де-факто, такие как микросервисная архитектура, событийно-ориентированная архитектура, потоковая передача данных, машинное обучение, продуктовый подход и ряд других, были сформулированы в качестве ответов на те вызовы, которые предъявляются в рамках отмеченных в настоящем разделе тенденций развития. Данная связь также будет проиллюстрирована по ходу дальнейшего изложения.
Отдельно будут рассмотрены вопросы эволюционного и революционного развития архитектуры. Надо отметить, что вопросы соотношения экстенсивного и интенсивного развития характерны для многих отраслей человеческой деятельности. Не избежали их ИТ и цифровой мир. Рассмотрению вопроса соотношения интенсивного и экстенсивного развития в архитектуре цифрового мира будет посвящен следующий параграф.
Эволюционное и революционное развитие архитектуры
Вопросы развития любого направления всегда затрагивают аспекты интенсивного и экстенсивного развития. Первое обычно сравнивают с революцией, второе с эволюцией. Нельзя избежать рассмотрения соответствующих аспектов и в случае архитектуры.
Следует отметить, что сравнение интенсивного и экстенсивного развития носит качественный и обобщающий характер. Если же говорить о частностях, углубляться в детали, то возможны ошибки. Одна и та же тенденция в развитии, следование ей может на определенном этапе носить интенсивный (революционный) характер, с течением времени же интенсивность снижается, развитие осуществляется строго экстенсивно (эволюционно), в дальнейшем переходя к застою и неся в себе риски деградации. В то же время, строго интенсивное развитие в силу своего революционного характера использует в качестве ресурсного обеспечения мощности своей базовой технологии. Таким образом, может произойти разрушение как конкретной технологии, так и всего сектора экономики, при этом высвобождающиеся мощности становятся ресурсным обеспечением революционного рывка. Например, на базе потери интереса к большим машинам, затраты на содержание которых зачастую превышали прибыли от автоматизации, произошел стремительный рост рынка персональных компьютеров и соответствующего программного обеспечения, что в свою очередь привлекло потребителей и последующие инвестиции в данное направление. Не всякое разрушение в таком случае может создать достаточное ресурсное обеспечение революционного перехода, что чревато разрушением с последующей деградацией всего сектора экономики, технологического направления.
Рассмотрим примеры эволюционного и революционного развития архитектуры и выделим их основные характеристики. В качестве наглядного примера рассмотрения возьмем такую ключевую тенденцию развития архитектуры, как распределенность.
Как уже отмечалось, распределенность характеризуется в двух различных смысловых плоскостях: команды разработчиков, создающие конечную ценность для заказчиков и партнеров, распределены географически и работают автономно друг от друга, сами же создаваемые технологические решения функционируют в распределенной конфигурации, сохраняя высокое качество услуг.
Если взять за отправную точку рассмотрения уже упоминавшийся столь значимый для ИТ 2001-й год, можно отметить, что на тот момент ИТ-решения для большинства направлений человеческой деятельности имели «монолитный» характер, представляли собой целостную единицу развертывания (либо весьма ограниченный набор таких единиц). Создание и развитие таких решений велось обширной командой развития, включавшей представителей разных направлений деятельности.
Возьмем в качестве наглядного примера финансовую сферу. Основой финансовой сферы являлась (и является) учетная платформа (в России традиционное название – автоматизированная банковская система, АБС). Эта система (при исходном проектировании) выполняла следующие функции:
• Учет финансовых/хозяйственных операций;
• Ведение счетов;
• Ведение плана счетов;
• Бухгалтерский документооборот;
• Валютный учет;
• Многофилиальный учет;
• Налоговый учет;
• Формирование учетной документации для проведения проверок;
• Формирование оперативной и аналитической бухгалтерской отчетности (операционный день и т. п.).
По мере автоматизации производственных и бизнес-процессов финансовой организации в состав учетной платформы включались исходно несвойственные ей функции:
• Ведение данных клиентов;
• Управление бизнес-процессами;
• Автоматизированные рабочие места сотрудников, ведущих обслуживание клиентов;
• Продуктовые операции (не только учетного характера, но и, например, продуктовые конвейеры);
• И т. д.
При этом учетная платформа представляла собой «закрытое» (vendor-lock) программное обеспечение, основанное на «закрытом» же технологическом стеке, предоставляемом независимыми поставщиками, требовавшая значительных инфраструктурных мощностей для обеспечения корректного функционирования.
Если подходить к указанному примеру (как частному случаю) с точки зрения эволюционного и революционного развития, то следует отметить, что создание первых учетных платформ было развитием революционным (сам факт создания систем и автоматизации соответствующей области деятельности), сменившимся эволюцией (монотонное наращивание целевого функционала учетной платформы, например, основанное на появлении новых регуляторных требований), также чреватое застоем и деградацией (дополнение системы несвойственным ей с точки зрения потребностей бизнеса функционалом).
Пример указанного функционала монолитной системы в формате учетной платформы приведен на Рисунке 6.
На Рисунке 6 представлено разделение учетной платформы на следующие составные блоки:
• Целевой функционал, который направлен на автоматизацию собственно учетной функции;
• Вмененный функционал, который не связан непосредственно с целями учета;
• Автоматизированные рабочие места, к которым можно отнести целевые (АРМ бухгалтерии) и вмененные (АРМ специалиста по обслуживанию клиентов).
Отметим, что Рисунок 6 не претендует на детальное отображение функционала учетных платформ, внедрявшихся и разрабатывавшихся в финансовых учреждениях. Также следует отметить, что далеко не все финансовые организации современности смогли исключить вмененный функционал из используемых ими учетных платформ, что существенно влияет на возможность применения гибких практик разработки при внедрении ИТ в них (финансовых организациях) в негативном ключе.
Рисунок 6. Пример монолитной системы в формате учетной платформы
Развитие учетных платформ осуществлялось в соответствии с длительными производственными процессами, предполагавшими последовательное прохождение ряда стадий, таких как анализ, проектирование, разработка, тестирование и отладка, при этом релизные циклы решений занимали по нескольку месяцев. Различные компоненты решений оказывали взаимовлияние друг на друга и не могли разрабатываться параллельно, либо же их параллельная разработка была крайне затруднена.
К эволюционному переходу в те годы можно отнести создание новых информационных систем, автоматизировавших часть вмененного функционала учетных платформ, и их точечную интеграцию с последними. Таким образом удавалось несколько упростить функционирование отдельных программных комплексов за счет усложнения интеграционных взаимодействий. Указанные изменения не обеспечивали существенного роста эффективности.
Революционным переходом можно было считать переход финансовых организаций того времени (речь идет о передовых организациях соответствующего сектора) к модели сервис-ориентированной архитектуры (service-oriented architecture, SOA), предполагавшей разнесение различных блоков функционала по отдельным автоматизированным системам, каждая из которых предоставляла доступный контрагентам функциональный набор в формате групп сервисов, при этом интеграционные взаимодействия между системами, как предполагалось, должны были осуществляться унифицированным образом. Пример организации SOA представлен на Рисунке 7.
Рисунок 7. Пример организации SOA
Рассмотрим структуру SOA, пример которой представлен на Рисунке 7, более подробно. При внедрении соответствующих архитектурных практик ИТ-ландшафт организации (в нашем примере финансовой) распределялся по функциональному назначению: выполнение учетных функций (учетная платформа), управление взаимодействием с клиентом (система Customer Relationship Management, CRM), системы дистанционного банковского обслуживания (ДБО), продуктовые конвейеры (на Рисунке 7 в качестве примера приведен кредитный конвейер).
Создатели архитектурных практик SOA стремились выставить акценты при разработке и развитии информационных систем в соответствии с функциональными границами областей, ими автоматизировавшимися. При этом унификация интеграционного взаимодействия осуществлялась посредством реализации шаблона проектирования «Корпоративная сервисная шина» (Enterprise Service Bus, ESB), подробное описание которого приведено в книге Gregor Hohpe, Bobby Woolf «Enterprise Integration Patterns» (2003, ISBN 978—0321200686). Для реализации указанного шаблона применялись, как правило, отдельные информационные системы (было выпущено немало как «закрытых» решений, таких как IBM WebSphere ESB, так и основанных на принципах открытого кода, как Apache ServiceMix). Ключевыми задачами, решавшимися при реализации шаблона ESB, были следующие:
• Обеспечение прозрачной маршрутизации взаимодействий между интегрируемыми информационными системами с избавлением последних от необходимости детального знания о месторасположении контрагентов.
• Преобразование протоколов взаимодействия, что избавляло интегрируемые системы от учета технических особенностей взаимодействия с контрагентами, само же решение ESB, как правило, поддерживало большой набор протоколов, взаимодействуя с системами по базовым протоколам последних.
• Преобразование форматов данных, что обеспечивало возможность каждой интегрируемой системы функционировать в рамках собственной модели данных, при этом список потенциальных контрагентов мог расширяться за счет решения задачи дополнительных преобразований на уровне ESB.
• Мониторинг интеграционных взаимодействий, которые должны были осуществляться строго посредством решения, реализующего шаблон ESB.
Таким образом, решение, реализующее шаблон ESB, оказывалось сквозным в масштабах организации, что привело к дополнению его функционала задачами информационной безопасности, аудита, трассировки и т. д. Кроме того, для реализации непосредственных задач решение реализовывало ряд шаблонов проектирования, представленных как в вышеупомянутом труде («Enterprise Integration Patterns»), так и в одной из основополагающих работ в сфере ИТ: Erich Gamma, Richard Helm, Ralph Johnson, John Vlissides «Design Patterns: Elements of Reusable Object-Oriented Software» (1994, ISBN 0-201-63361-2). К числу подобных шаблонов можно отнести каноническую модель данных, адаптер и т. д.
Как уже отмечалось выше, переход к SOA стал революционным в плане развития архитектуры и внедрения ИТ в организациях. В результате разгрузки учетных платформ от несвойственного им функционала передовые в технологическом плане финансовые организации смогли приступить к активной автоматизации своих производственных и бизнес-процессов. Практики SOA стали основными, при этом к началу 2010-х годов ведущие финансовые организации в целом завершили перевод собственной автоматизации в данном ключе. Сформированный ИТ-ландшафт был, безусловно, намного сложнее, чем представленный на Рисунке 7 пример – в крупных финансовых организациях он включал в свой состав сотни и тысячи информационных систем. Можно отметить, что к этому периоду SOA из революционной практики стала эволюционной с ярко выраженной тенденцией к застою и деградации. В чем же выражалась соответствующая тенденция?
Представим себе ситуацию, что в финансовой организации 200 информационных систем, которые выстроены и взаимодействуют между собой в соответствии с принципами SOA. При этом каждая информационная система предоставляет 10 сервисов, посредством которых ее функционал доступен контрагентам. Как результат, на интеграционной шине представлено 2000 сервисов. Каждая из систем развивается независимо в соответствии с планами владельцев систем (предположим, что владельцами систем в организации являются бизнес-подразделения). Соответственно, команда специалистов, отвечающая за развитие ESB решения, должна поддерживать актуальность всех 2000 сервисов, добавлять новые, обеспечивать корректность функционирования всего комплекса. Не будем забывать, что нередким является случай, при котором потребителями одного сервиса являются несколько информационных систем. В таком случае при развитии соответствующего сервиса необходимо также поддерживать механизмы версионности, а также обеспечивать регрессионное тестирование. Емкость любой команды не является бесконечной величиной. Кроме того, важным является тот факт, что ESB не представляет собой конечной значимой бизнес-функциональности, то есть участие членов команды развития ESB решения в создании бизнес-ценности является опосредованным, что ограничивает возможности масштабирования соответствующей команды. Результатом, как правило, являлось то, что скорость внесения изменений на уровне ESB была существенно ниже, нежели в информационных системах, автоматизирующих прикладной функционал. Особенно заметной разница в скорости внесения изменений была при сравнении ESB с системами дистанционного банковского обслуживания (ДБО), где соответствующая скорость традиционно одна из самых высоких в автоматизации финансового сектора. Автор лично был свидетелем того, как уже выполненные доработки уровня ДБО ожидали необходимых интеграционных доработок год и более.
Шаблон ESB и следование ему было не единственной причиной потенциальной деградации. Заказчики и партнеры любой организации (финансовая не является исключением) заинтересованы в продуктах, которые она предоставляет. В случае финансовой организации это могут быть вклады, счета, кредиты, банковские гарантии и т. д. В случае следования методикам SOA предоставление продукта клиентам и партнерам предполагало реализацию соответствующего функционала в рамках нескольких информационных систем: канального представления, исполнения процессов, связанных с соответствующим продуктом, принятия решений в части исполняющихся процессов, постановки продукта на бухгалтерский учет и т. д. При этом нельзя забывать, что отдельные системы пусть и предоставляли свой функционал в виде набора сервисов, доступность которых контрагентам обеспечивало ESB решение, сами по себе оставались монолитными комплексами с длительными релизными циклами. Многие из этих систем требовали специфических компетенций для развития. При этом компетенции требовались не только технического, но и методологического характера. В результате выпуск продукта зависел от системы с максимально длительным релизным циклом. На фоне успехов стартапов, ряд которых к началу 2010-х годов уже стали технологическими гигантами, сложившаяся ситуация не могла устраивать представителей традиционных секторов экономики (пример, приведенный в настоящей книге для финансовой организации, является характерным для традиционных секторов экономики в целом). Тенденции, сформировавшиеся после экономического кризиса 2008-го года, также требовали повышения эффективности всех отраслей человеческой деятельности. Возникла необходимость в новом революционном переходе.
Первым этапом нового революционного перехода стала концепция микросервисной архитектуры, в соответствии с которой приложения представлялись в виде набора минимально зависимых (в идеальной ситуации независимых) модулей (микросервисов), каждый из которых представлял собой полноценную единицу развертывания с самостоятельным жизненным циклом. При этом взаимодействие микросервисов предполагалось осуществлять исключительно посредством API, что исключало необходимость владения информацией об особенностях исполнения контрагентов. Данная концепция соответствовала практикам гибкой разработки и DevOps. Пример предлагавшейся концепции представлен на Рисунке 8.
Рисунок 8. Пример концепции микросервисной архитектуры
Показанные на Рисунке 8 микросервисы и межсервисные взаимодействия представлены в качестве примера.
При проектировании решений на основе микросервисной архитектуры учитывались следующие характеристики и качества микросервисов:
• Трудоемкость. Разработку микросервиса должна вести одна команда, сформированная в соответствии с гибкими практиками разработки.
• Независимость. Локальные задачи решаются средствами микросервиса. Команда, реализующая микросервис, не должна ожидать исполнения подзадач (в составе данного микросервиса) другой командой. Возникновение ситуаций ожидания являлось признаком ошибок проектирования.
• Бизнес-ориентированность. Микросервисы должны решать конкретные прикладные задачи заказчиков.
• Простота интеграции. Для реализации взаимодействия микросервисов не требуется использования отдельных программных компонентов (по примеру рассмотренного выше ESB решения).
• Учет возможных ошибок. Принимая во внимание возможность возникновения ошибок при выполнении жизненного цикла информационной системы, при проектировании последней в парадигме микросервисной архитектуры следует учитывать потенциальную недоступность каждого микросервиса. При этом система должна реагировать таким образом, чтобы минимизировать вероятность общесистемного сбоя.
• Децентрализация данных. Отдельные микросервисы работают с независимыми источниками данных в рамках собственных моделей данных. Модели данных разных микросервисов развиваются независимо друг от друга.