Архитектурная проработка

Архитектурная проработка – это информационно-технологическая основа всего проекта IT-системы. В ходе процесса проработки команда BI.Qube создает концептуальную модель, которая детально описывает структуру, выполняемые функции и взаимосвязи компонентов, учитывает риски, требования и ограничения.

В практике нашей компании – сразу выполнить проверку предложенной концепции (PoC, proof of concept). Непрерывные прототипы и бенчмарки на реальных функциональных задачах позволяют получить работающую и масштабируемую архитектуру.

За счет подбора оптимального стека технологий, инструментов и методов, архитектурная проработка позволяет снизить затраты на реализацию и последующую эксплуатацию системы.

В какой ситуации важно

Когда и зачем нужна архитектурная проработка IT-проекта

Если архитектура аналитического хранилища данных не сбалансирована физически и логически, имеет проблемы с иерархией данных, методикой построения ХД, актуализацией, полнотой и скоростью обработки поступающей информации, не обладает удобным пользовательским интерфейсом для анализа данных, то этот мощный инструмент становится бесполезен.

С точки зрения пользователя это проявляется как утрата доверия к аналитике, когда «озеро данных» стало превращаться в «болото данных», а значения одного и того же показателя не сходятся в отчётах разных подразделений. Когда для повторяющихся задач каждый раз формируется новая копия сырых данных, когда происходят долгие пересчёты, под каждый отчёт формируется своя визуализация (нет единого центра правды), и т.д.

Подходы для оптимального результата

В чём сложность и почему мы

Наилучший результат приносит практика работы с IT-ландшафтом компании заказчика системно, как на высоком уровне абстракции, так и досконально изучая все аспекты деятельности организации, касающиеся работы с данными.

Для выявления плюсов и минусов каждого варианта при выдвижении концепций и гипотез проводится серия тестов и бенчмарков, в ходе которых учитывается широкий спектр влияющих факторов. В их числе: производительность и оперативность получения результатов в условиях роста объемов данных, разнообразие и сложность алгоритмов обработки данных, масштабирование, долгосрочные перспективы развития, стоимость владения и экономическая целесообразность, vendor lock и иные запросы заказчика.

Типовая последовательность этапов архитектурного проекта:

• Системный анализ бизнес-задач заказчика
• Изучение нормативной и технической документации, интервьюирование специалистов заказчика
• Обследование организационно-методического облика IT-инфраструктуры организации
• Выявление, сбор, анализ и описание требований к информационно-аналитической системе
• Подбор технологического стека и платформы для реализации поставленных задач, разработка концепций интеграции данных и взаимодействия компонентов программно-аппаратного комплекса
• Определение концептуальной схемы и проектирование IT-архитектуры системы на основе требований и проведенного исследования
• Создание прототипа системы
• Проверка гипотез, обзор и анализ кода, оценка работоспособности и взаимодействия компонентов
• Разработка документации в виде набора ключевых архитектурных артефактов, состава необходимых работ и оценки их трудоемкости

Системный подход в архитектурной проработке – важное условие для получения максимального результата в кратчайшие сроки и минимизации затрат. Существует множество методик, помогающих упорядочить и упростить процесс построения архитектуры решения. В числе применяемых нами методов и структур: Attribute-Driven Design (ADD), Architecture Development Method (ADM), The Open Group Architecture Framework (TOGAF) и др. Как правило, одна методика не охватывает в полной мере все нюансы разработки. Поэтому архитекторы и бизнес-аналитики команды BI.Qube не зацикливаются на чем-то одном, а оперируют большим количеством методик и фреймворков, также создают свои собственные методические наработки на основании накопленного опыта.

Типовые решения

Вариативность и гибкость – основа эффективной архитектуры

Задачами любой информационно-аналитической системы являются сбор, хранение, обработка и анализ данных. Несмотря на это, каждый реализуемый проект уникален. Разнообразие бизнес-задач требует поиска своих наиболее эффективных путей решения. Так, например, на основании проведенных исследований мы можем прийти к мотивированному выводу, что для удовлетворения запросов заказчика в проекте с традиционной системой КХД достаточно использовать реляционную СУБД (MS SQL Server, PostgreSQL) вместе с витриной данных на базе СУБД поколоночного хранения (MS Analysis Server Tabular, Yandex Clickhouse). При этом пользовательская отчетность может быть реализована на системах визуализации: Power BI, SQL Server Reporting Services, Yandex DataLens. Организация внесистемного учета и обогащение данных КХД – с применением системы MDM (Master Data Services, BI.Qube MetaMasterData).

В других более сложных проектах, где требуется создать Operational Data Store (ODS), а запросы на скорость обработки данных близки к реальному времени, для оптимального решения задач мы организуем доставку журналов транзакций (Change Data Capture). Если объем данных велик или их обработка настолько сложна, что её нельзя выполнить на одном узле, на основании сравнительных расчётов применяем СУБД массовой параллельной обработки (Azure Synapse, Arenadata DB, Yandex Greenplum). При этом, для распределенной обработки может потребоваться кластер Apache Spark, а для холодного хранения больших объёмов данных – организация Data Lake («озера данных») поверх файловой системы HDFS в форматах Parquet, Avro, ORC, с интеграцией в DWH через механизм PXF. Также, чтобы обеспечить масштабируемость и историчность КХД можем применить подходы Data Vault 2.0.

Дело не ограничивается реляционными источниками данных. При наличии разных неструктурированных источников возможна организация Data Lake (озеро данных) на платформе Hadoop.

В иных случаях результаты проверок могут показать, что разрабатывать решение рациональнее с использованием разных подходов. Например, там, где часть данных требуется получать максимально оперативно – задействовать технологии In-Memory хранения. Другую часть разместить в обычных реляционных таблицах, а «холодные» данные расположить в Data Lake в соответствующей файловой системе. При этом все три типа данных могут быть представлены одной таблицей!

Архитекторы BI.Qube комплексно прорабатывают каждый элемент проекта, уделяя внимание не только концептуальной архитектуре решения, но и его сервис-дизайну. Так, в рамках проекта, исходя из поставленных задач, может потребоваться описать бизнес-процессы, бизнес-компоненты и сценарии их взаимодействия, составить интеграционную и компонентную схемы решения, создать карту развертывания, карту клиентского пути (CJM), Use-cases, Service BluePrint, Sequence-диаграммы бизнес-процессов и сделать многое другое для достижения запланированного результата.

Наши методики проектирования и подход с применением Data Governance и Agile, позволяют создавать архитектуру, которая обеспечивает возможность построения в сравнительно короткие сроки сложной информационно-аналитической системы, адаптируемой к быстро изменяющимся требованиям и пригодной для деятельности большой группы предприятий в условиях постоянного роста объема данных.