Датацентричный подход что это

Дата-центрическая архитектура: «волшебная пуля» от интеграционных проблем

Любой корпоративный ИТ-ландшафт состоит из множества приложений, большинство из которых имеет собственные базы данных. В этих базах хранятся информационные объекты, представляющие бизнес-объекты, события и фазы бизнес-процессов. Многие объекты бизнес-процессов имеют «отражения» сразу в нескольких базах данных: например, единица оборудования промышленного предприятия с разных точек зрения описана в системах бухучета, управления ремонтами и обслуживанием, управления производством и др.

Чтобы бизнес-приложения, автоматизирующие разные бизнес-процессы, могли как-то работать вместе, их необходимо интегрировать: внедрять продукты класса MDM (Master Data Management, система управления мастер-данными) и ESB (Enterprise Service Bus, корпоративная сервисная шина), позволяющие хоть как-то управлять обменом информацией между множеством разноплатформенных решений. Тем, кто занимался такой интеграцией, хорошо известно, что это долгий, сложный и неблагодарный труд.

А что, если найдется способ избавиться от всех интеграционных проблем разом? Такая «волшебная пуля» существует, и называется она — дата-центрическая архитектура. Ее основная идея состоит в том, чтобы сделать центральным элементом корпоративной ИТ-архитектуры не бизнес-приложения, а данные. Этот принцип изложен в Манифесте дата-центрической архитектуры и в книге The Data-Centric Revolution: Restoring Sanity to Enterprise Information Systems.

Представьте, что в компании существует единое виртуальное хранилище данных, в котором каждый бизнес-объект или событие существует в единственном экземпляре. Для наглядности можно вообразить, что идея системы MDM доведена до логически полного воплощения, и именно MDM является хранилищем всех корпоративных данных; бизнес-приложения не имеют собственных СУБД и работают только с объектами данных из MDM. Преимущества такой архитектуры очевидны:

Раз и навсегда отменяется необходимость в интеграционных процедурах.

Снижаются затраты на хранение данных за счет избавления от множества копий каждого бизнес-объекта в разных системах.

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

Повышается качество данных за счет избавления от неполных, не актуальных представлений бизнес-объектов.

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

«Это какая-то фантастика», скажут некоторые. Нельзя же выбросить все существующие бизнес-приложения и начать с чистого листа, вывернув наизнанку всю корпоративную ИТ-архитектуру?

Нужен плавный процесс перехода, и его вполне можно обеспечить, если думать о корпоративной платформе управления данными не только как о физическом хранилище, содержащем материализованные представления всех бизнес-объектов, но и как о логической витрине данных, способной извлекать эти объекты из любых хранилищ, в том числе баз данных и сервисов унаследованных бизнес-приложений. Клиенту платформы должно быть безразлично, где находятся нужные ему данные — в одном из множества хранилищ, спрятанных внутри платформы, или в СУБД какого-либо бизнес-приложения. На практике, вероятнее всего, нужный объект данных будет собран платформой в момент выполнения запроса из нескольких источников.

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

Чем такой подход отличается от создания «обычного» корпоративного облака данных (corporate data cloud) или озера данных (data lake)? Прежде всего — методологией использования платформы, особым вниманием к структуре данных и некоторой функциональной спецификой. Если обычный data lake часто представляет собой коллекцию наборов данных, созданных кем-то для решения конкретных задач и заведомо содержащих копию уже существующей где-то информации, то для дата-центрической архитектуры принципиально соблюдение принципа «один объект в реальном мире — один объект данных». И никаких физических срезов, по крайней мере персистентных.

Управление структурой корпоративных данных — отдельный и очень важный вопрос, которому часто уделяется слишком мало внимания. Задача описания структуры всей информации, с которой работает предприятие, может показаться настолько сложной, что никто и не думает ее решать; вместо этого создается множество структур данных под конкретные бизнес-задачи, что влечет очевидные последствия. Мы утверждаем, что эта задача может и должна решаться; она успешно решается на практике в конкретных проектах, нужно лишь использовать подходящие для этого технологии. Одним из возможных вариантов является описание структуры корпоративной информации с помощью онтологий (см. спецификацию OWL консорциума W3C).

Тема онтологического моделирования выходит за рамки этой статьи, отметим лишь, что одной из его ключевых особенностей является технологическая однородность самих данных и описания их структуры. Отсутствие привычного в реляционном мире разрыва между данными и описанием их структуры (которое иногда не совсем точно называют метаданными), возможность управлять данными и их структурой с помощью одних и тех же инструментов обеспечивает уровень гибкости, необходимый для создания и поддержки моделей данных, включающих десятки тысяч типов сущностей и свойств. Нельзя забывать и про множество разработанных методик онтологического моделирования, использование онтологий верхнего уровня, переиспользование и расширение стандартных онтологий.

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

Какими функциональными свойствами должна обладать платформа, являющаяся ядром дата-центрической архитектуры? Она должна:

Поддерживать хранение состояния каждого объекта данных на любой момент времени. Объекты данных — не просто отражения текущего состояния объектов или событий реального мира, а «четырехмерные» описания всех состояний на протяжении всего времени жизни объекта.

Хранить непрерывную историю модели (структуры) данных. Структура данных столь же изменчива, как и сами данные. Платформа должна иметь возможность представлять объекты данных в соответствии с любой версией структуры. Структура должна формально описывать смысл каждого элемента данных.

Поддерживать множество API для работы с данными, включая REST, GraphQL, SPARQL.

Предоставлять возможности обнаружения и поиска данных.

Иметь развитые инструменты управления доступом к данным и защиты конфиденциальной информации.

Поддерживать инструменты прослеживания происхождения данных (data provenance), контроля их качества (data quality), описания степени доверия к данным.

Построение подобных платформ с использованием онтологических моделей открывает и другие возможности. В онтологической модели можно описать в машинно-читаемой и автоматически исполняемой форме не только структуру данных, но и алгоритмы их обработки — правила контроля целостности, арифметических вычислений, дополнения информации (см. спецификации SHACL и SHACL Advanced Functions). Это позволяет по-новому взглянуть и на принцип low code: если в единой корпоративной платформе управления данными хранятся не только данные и описание их структуры, но и машинно-читаемое описание алгоритмов обработки данных, то новые бизнес-приложения, ориентированные на использование таких описаний, станут еще гибче и смогут изменять свое поведение «на лету» без вмешательства не только в код, но и в настройки приложений.

Платформы, отвечающие таким требованиям, уже существуют и применяются и на российском, и на зарубежном рынке.

Источник

Письмо Банка России от 22 ноября 2021 г. № 46-6-1/1652 “Об оптимизации отчетности и переходе на датацентричный подход”

Департамент управления данными Банка России в соответствии с письмом Ассоциации российских банков от 13.09.2021 № А-02/9-266 о проведении конференции «Регуляторные требования Банка России к кредитным организациям в период ограничительных мер: эффективность смягчения и его перспективы» направляет информацию по вопросам 4 «Оптимизация банковской отчетности» и 6 «Переход ЦБ РФ на датацентричный подход: последствия для банков».

Информация по вопросам 4 «Оптимизация банковской отчетности» и 6 «Переход ЦБ РФ на датацентричный подход: последствия для банков»

1. По вопросу 4 «Оптимизация банковской отчетности».

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

Так, в целях оптимизации действующей отчетности, предусмотренной нормативными актами Банка России, в текущем году совместно с банковским сообществом была проведена работа:

по верификации норм действующего регулирования в части исключения норм, создающих неоправданную нагрузку при составлении отчетности кредитных организаций;

по объединению и консолидации показателей отдельных форм отчетности с целью сокращения количества наборов собираемых данных;

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

по сокращению и упрощению отдельных форм отчетности за счет отмены утративших свою актуальность показателей;

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

В рамках внедрения сбора отчетности на основе модели данных Указанием N 5986-У предусматривается введение 4 новых и значительное изменение 2 действующих форм отчетности, разработанных с учетом интеграции требований к данным, их структурирования и исключения избыточной и повторяющейся информации. Используемый подход к разработке отчетных форм на основе модели данных позволит поднадзорным организациям оптимизировать нагрузку на подготовку и преобразование данных для отчетности, будет способствовать повышению прозрачности их внутренних процессов и качества управленческой и надзорной отчетности.

В рамках проведения работ по оптимизации отчетности кредитных организаций отдельное внимание было уделено ББЛ (как правило это региональные банки). Так, для достижения оптимального соотношения между издержками ББЛ на соответствие установленным регуляторным требованиям и объемом необходимой Банку России информации Указанием N 5986-У предусмотрено:

— изменение периодичности представления 2 форм отчетности: 0409706 «Сведения об объемах внебиржевых сделок» (с месячной на квартальную) и 0409251 «Сведения о счетах клиентов и платежах, проведенных через кредитную организацию (ее филиал)» (с ежеквартальной на полугодовую);

— увеличение срока представления для 4 форм отчетности: 0409115 «Информация о качестве активов кредитной организации (банковской группы)», 0409118 «Данные о концентрации кредитного риска», 0409125 «Сведения об активах и пассивах по срокам востребования и погашения» и 0409157 «Сведения о крупных кредиторах (вкладчиках) кредитной организации»;

— исключение требования о представлении декадной отчетности по форме 0409664 «Отчет о валютных операциях, осуществляемых по счетам клиентов в уполномоченных банках».

2. По вопросу 6 «Переход ЦБ РФ на датацентричный подход: последствия для банков».

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

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

Указанием N 5986-У предусмотрено введение новых форм отчетности, разработанных в датацентричном формате:

— формы 0409071 «Сведения об оценке выполнения кредитными организациями требований к обеспечению защиты информации» для целей эффективного осуществления надзора за соблюдением требований к обеспечению защиты информации и получения актуальных сведений об уровне информационной безопасности кредитных организаций, в том числе о событиях, связанных с нарушением защиты информации при осуществлении переводов денежных средств;

— формы 0409106 «Отчет по управлению операционным риском в кредитной организации» для целей осуществления контроля уровня операционного риска в кредитных организациях и корректности расчета его размера;

Кроме того, проводятся работы по актуализации Методических рекомендаций по унификации подходов к формированию в кредитных организациях исходных данных для представления в Банк России отчетных данных по отдельным предметным областям (от 28.11.2017 N 31- МР).

Также на площадке рабочей группы по рассмотрению вопросов перехода на датацентричный сбор информации от кредитных организаций и созданию единой модели данных будет продолжена работа по выработке решений организации сбора реестровой информации в составе отчетности по ценным бумагам, проектированию отчетности об аффилированных лицах, а также оптимизации нагрузки на кредитные организации при сборе сведений о ссудах физических лиц на основе шаблонов типовых запросов.

1 В настоящее время находится на государственной регистрации в Министерстве юстиции Российской Федерации

2 Инструкция Банка России от 02.04.2010 N 135-И «О порядке принятия Банком России решения о государственной регистрации кредитных организаций и выдаче лицензий на осуществление банковских операций».

Банк России подвел итоги работы за 2021 г. по оптимизации действующей отчетности.

В частности, 31.03.2022 (за исключением отдельных положений) вступят в силу изменения в перечень, формы и порядок составления и представления отчетности кредитных организаций.

В рамках оптимизации отчетности отдельное внимание было уделено ББЛ (как правило это региональные банки).

Источник

Три шага к дата-центричной архитектуре

Данные — основа цифровой экономики, однако большинство автоматизированных систем ориентированы на приложения. Дата-центричная архитектура позволяет избавиться от проблем с интеграцией и получить аналитические инструменты качественно нового уровня.

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

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

Каждый раз, когда предприятие сталкивается с необходимостью поддержки бизнес-процессов, разные этапы которых автоматизируются различными приложениями, или намеревается построить сквозную аналитику, возникают сложные интеграционные решения. Бизнес-объекты, участвующие в таких процессах, имеют несколько представлений в разных автоматизированных системах. Например, конкретная единица оборудования в одной системе рассматривается как объект эксплуатации со своей историей ремонтов и обслуживания, в другой — как единица учета основных средств, в третьей — как потребитель энергии и т. п. При интеграции приходится неявно связывать эти различные точки зрения на один объект.

Принципиально новая архитектура, свободная от данных проблем, должна быть построена на следующих принципах [1]:

При такой архитектуре не нужны копии одних и тех же информационных объектов, а значит — не требуются сложные интеграционные механизмы; не нужны дополнительные усилия для формирования аналитических представлений; исчезает зависимость от производителей ПО, поскольку одни и те же данные смогут обрабатывать разные приложения; компании смогут не только экономить на поддержке ИТ-инфраструктуры, но и получить преимущества за счет быстрой адаптации своих инструментов к новым функциональным требованиям и более совершенной аналитике.

Путь к дата-центричной архитектуре

На практике переход к архитектуре, ориентированной на данные, предполагает выполнение ряда шагов.

Второй шаг. Создание хранилища, управляемого витриной. Часть данных хранится теперь только в витрине, а работающие с ними приложения не реплицируют эту информацию в собственные хранилища. Очень важно, чтобы приложения были готовы к изменению структуры данных. Благодаря тому, что они могут считывать из хранилища и сами данные, и их структуру, они получают возможность изменять алгоритмы своей работы по мере изменения структуры данных. Таким образом начинает реализовываться управляемость приложений со стороны модели.

На этой стадии в ИТ-экосистеме предприятия еще сосуществуют унаследованные приложения, с данными которых можно работать через логическую витрину, и новые приложения, ориентированные на использование единого хранилища с изменяемой структурой данных. Со временем унаследованные системы заменяются на приложения, управляемые моделью, и завершается эволюционный переход к дата-центричной архитектуре.

Третий шаг. Развитие возможностей управления поведением приложений нового типа со стороны модели. Такие приложения не просто ориентированы на работу с гибкой моделью данных, но и часть описания алгоритмов их работы также находится в онтологии. Допустим, в результате изменения бизнес-требований необходимо создать новый вид бизнес-объектов и описать процедуры работы с ним. Аналитик создает в онтологической модели класс, объектами которого станут информационные объекты, представляющие бизнес-объекты нового вида. Этот класс помещается в определенное место в иерархии классов — к его объектам будут применимы все атрибуты, применимые к вышестоящим классам. Например, если новый класс «Трансформатор» станет подклассом класса «Устройства преобразования напряжения», его объекты будут обладать атрибутами «Верхнее напряжение» и «Нижнее напряжение». Новый класс «Снятие показаний приборов учета» станет подклассом «Событие» и приобретет атрибут «Дата и время». Кроме того, к новому классу будут применимы все алгоритмы и настройки, уже существующие в модели для вышестоящих классов. Во многих случаях этого вполне достаточно, чтобы система начала работать с новым типом бизнес-объектов без дополнительных настроек. Если для новых бизнес-объектов требуются особые правила обработки, аналитик может определить их в модели. Правила могут описываться разными способами: с помощью специальных метамоделей, таких как модели правил отображения данных или построения отчетности; с помощью правил логического вывода, которые лучше подходят для формализации алгоритмов с ветвлением и выполнением форматно-логических проверок.

Таким образом, управление разными видами правил обработки информации, тесно связанными со структурой данных, через редактор онтологической модели позволяет адаптировать приложения к новым функциональным требованиям. Важно, что одни и те же правила могут использоваться разными приложениями, позволяя аналитику синхронно менять логику работы сразу нескольких бизнес-приложений.

Платформа «АрхиГраф»

Платформа «АрхиГраф» предназначена для создания логической витрины данных и построения кластера физического хранения информации под управлением онтологической модели. Главная идея платформы состоит в объединении всей корпоративной информации в рамках одной или нескольких онтологических моделей. Основным хранилищем подобных моделей являются графовые базы данных класса RDF triple store, обеспечивающие богатые возможности поиска по графам и управления ими при помощи языка SPARQL. Однако такие СУБД довольно медленны и не предназначены для хранения больших объемов данных. С другой стороны, традиционные средства, такие как реляционные и документоориентированные СУБД, обеспечивают быструю обработку больших объемов информации за счет развитых инструментов оптимизации, включая индексацию и сегментацию таблиц и коллекций объектов. Требуется промежуточный слой физического хранения данных в реляционных базах данных и NoSQL-базах, которые с точки зрения приложений выглядели бы как графовые СУБД. Это позволит совместно использовать преимущества способов управления данными, целостности структуры и состава данных, характерные для онтологий и графовых СУБД, с совершенными механизмами оптимизации производительности традиционных хранилищ.

Рис. 1. Структура платформы «АрхиГраф»

В платформе «АрхиГраф» имеется промежуточный слой (рис. 1), позволяющий распределить данные между множеством кластеров реляционных и NoSQL СУБД, а также хранилищ Hadoop, управлять их распределением и применять различные способы оптимизации скорости доступа к данным. Доступ к данным со стороны приложений осуществляется через программные интерфейсы REST, SPARQL, GraphQL, очереди обмена сообщениями RabbitMQ, Kafka, с помощью протокола Websocket.

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

«АрхиГраф» допускает хранение информационных объектов в различных физических хранилищах. Приложения-клиенты платформы абстрагированы от деталей хранения данных, в то же время для ускорения доступа к данным можно использовать специализированные средства на уровне каждого хранилища: индексацию, сегментацию, кластеризацию и др. Платформа обеспечивает также прозрачное для пользователя перемещение данных между хранилищами.

Кроме того, в платформе обеспечивается работа с пространственными данными — точками, линиями, многоугольниками и их наборами, пригодными для отображения в составе геоинформационных систем; реализованы разграничение прав доступа к модели и информационным объектам на основе настраиваемых правил, а также вычисление эффективного уровня доступа с учетом наследования и множественной классификации.

Как и в любой развитой системе работы с данными, в платформе имеются средства ведения журналов запросов для просмотра администратором; фиксируется история модели и хранения данных, что позволяет отследить состояние модели и информационных объектов в любой момент времени; предусмотрена подача заявок на внесение изменений в информационные объекты; возможна подписка на уведомления о создании или изменении информационных объектов через очереди MQ или Kafka.

Рис. 2. Кластеризация платформы «АрхиГраф» и хранилищ данных

Сервисы «АрхиГраф» выполняются в контейнерах под управлением Kubernetes, что обеспечивает практически неограниченное масштабирование при росте нагрузки (рис. 2). Хранилища данных могут также кластеризоваться с помощью своих собственных средств, таких как pgpool или Stolon для СУБД Postgres, причем к платформе «АрхиГраф» можно подключить любое количество подобных кластеров.

Несколько кластеров могут размещаться в различных территориально распределенных ЦОД, а для управляемой синхронизации данных используются специальные механизмы синхронизации через подписки: можно указать, какие данные должны синхронизироваться, а какие — оставаться оригинальными в пределах каждого кластера.

Сценарии использования

Платформа «АрхиГраф» используется сегодня в ряде проектов: в системе построения корпоративной отчетности, системе информационного обмена между несколькими субъектами энергетического рынка, системе консолидации корпоративных знаний. Опишем один из сценариев использования платформы для построения логической витрины данных как первого шага на пути к дата-центричной архитектуре.

Рис. 3. Процесс сбора и анализа информации в логической витрине данных

При настройке витрины (рис. 3) указываются реквизиты источников структурированных и неструктурированных данных, по которым будет осуществляться поиск с ее помощью. Задача процессов индексации данных состоит в идентификации информационных объектов из этих источников и построении «семантического портрета» каждого из них, включающего наборы формальных признаков и связей с другими объектами. Выполнение такого распознавания производят алгоритмы, настраиваемые со стороны информационной модели, — от шаблонов разбора текстовых данных до сервисов машинного обучения и нейросетей, применяемых для выявления именованных сущностей в текстах и извлечения из них фактов. Результат работы процессов — семантическая аннотация источников данных и содержащихся в них конкретных элементов. Из таких аннотаций информационных объектов формируется корпоративный граф знаний, к которому пользователи строят поисковые запросы через визуальный интерфейс. Программные компоненты также могут выполнять запросы к графу при помощи API — например, загружать данные в аналитические приложения. Важно, что сами объекты данных остаются в исходных хранилищах, при этом происходит смысловое связывание копий одного и того же бизнес-объекта, по-разному представленного в различных хранилищах.

Рис. 4. Конвейер обработки событийных данных, поступающих в систему

В качестве примера другого сценария можно привести конвейер по связыванию разнородной событийной информации, поступающей из разных источников (рис. 4), — такие задачи возникают в системах информационного обмена или сбора отчетности, а также в ситуационных центрах. Для обработки разнообразных потоков данных создаются компоненты, в реальном времени собирающие данные от источников и преобразующие их в соответствии с информационной моделью при помощи специальной метамодели, которая описывает соответствие элементов разных информационных структур. Такая метамодель позволяет определить широкий спектр преобразований — от разбора JSON-коллекций и XML-файлов до импорта таблицы Excel. После получения графа с набором информационных объектов и их свойств, поступивших в составе обрабатываемого сообщения, к нему применяются правила валидации, записываемые в синтаксисе SHACL (Shapes Constraint Language). После этого нужно применить следующий набор правил, которые обновят общесистемное хранилище данных в соответствии с поступившей информацией, — здесь также используется SHACL. Использование логически корректных правил позволяет гарантировать логическую целостность и корректность информации в общесистемном графе.

Архитектура, ориентированная на данные, предоставляет возможность редактировать бизнес-правила в ходе эксплуатации информационной системы, позволяя гибко изменять как структуру данных, с которыми работает приложение, так и логику их обработки. Внедрение подобных элементов дата-центричной структуры, управляемой с помощью модели, дает возможность предприятию быстро получить выгоду от новых решений и обосновать необходимость дальнейшего преобразования корпоративной ИТ-архитектуры путем переноса автоматизируемых процессов из унаследованных систем. По мере развития бизнеса могут меняться физические хранилища данных и кластерная группировка и даже может быть заменена сама платформа «АрхиГраф», но приложения продолжат работать с информацией через неизменные, стандартные программные интерфейсы.

2. Dave McComb. The Data-Centric Revolution: Restoring Sanity to Enterprise Information Systems. O’Reilly, 2019.

Источник

• Популярная книга Круть доступна для чтения прямо сейчас на нашем сайте boochi.ru. Скачать книгу в формате FB2, TXT, PDF, EPUB бесплатно без регистрации. →