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

Письмо Банка России от 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 (за исключением отдельных положений) вступят в силу изменения в перечень, формы и порядок составления и представления отчетности кредитных организаций.

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

Источник

Дата-центричное и интегрированное решение EPLAN для полного жизненного цикла Автоматизированных систем управления технологическим процессом

Дата-центричное и интегрированное решение EPLAN для полного жизненного цикла Автоматизированных систем управления технологическим процессом

Дата-центричное и интегрированное решение EPLAN для полного жизненного цикла Автоматизированных систем управления технологическим процессом (АСУ ТП).

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

Его сканирование и сохранение в электронном архиве не меняет сути подхода.

Для получения данных необходимо открыть документ и прочитать его.

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

Документ в этом подходе первичен, а данные, содержащиеся в нем, вторичны.

Поэтому и бизнес-процессы сконцентрированы вокруг документов.

Исполнители несут ответственность за выпуск документов (томов, комплектов) и по документам распределяют свои зоны ответственности.

В рамках такого подхода информатизация сводится к созданию электронного архива и автоматизации движения документов.

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

Дата-центричный подход подразумевает, что данные первичны.

Пользователи отвечают за внесение и редактирование тех или иных данных.

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

Качество данных в рамках дата-центричного подхода может непрерывно контролироваться.

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

Дата-центричность всех задействованных систем – необходимое условие их полноценной интеграции.

В частности, только в рамках такого подхода возможна интероперабельность в том виде, в котором она описана в ISO 15296.

Говоря о жизненном цикле АСУ ТП стоит отметить, что в связи с бурным развитием технологий эта сфера постоянно совершенствуется и обновляется.

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

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

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

Основной ресурс повышения эффективности – системы управления, построенные на новых принципах.

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

В этой ситуации наличие дата-центричной модели значительно ускоряет модернизацию и снижает связанные с ней риски.

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

В самом деле, большая часть оборудования АСУ ТП устанавливается в шкафах.

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

Создание центральной базы данных проекта – оптимальный шаг на пути создания единой цифровой модели производства.

У компании Intergraph есть такое решение – это SmartPlant Foundation.

Благодаря своей дата-центричности среда EPLAN может быть без проблем интегрирована SPF.

Для быстрой и беспроблемной интеграции необходим партнер, обладающий компетенциями как в EPLAN, так и в Intergraph.

Такой партнер есть – это компания Ulysta.

Решение uConnect этой компании готово к интеграции с EPLAN.

Сроки и стоимость такой интеграции определяются в зависимости от объема данных, которые необходимо публиковать в SPF.

Если центральной базы данных нет, это не проблема.

Среда EPLAN обладает мощными инструментами интеграции, начиная от стандартных инструментов импорта-экспорта данных в форматах TXT, CSV, XML, XLS и интеграции с базами данных (Access, SQL) и заканчивая мощным API, дающим внешним приложениям доступ к любым инженерным данным, содержащимся в проекте EPLAN.

Среда EPLAN «умеет» автоматически создавать ссылки на свои объекты для быстрого открытия этих объектов из внешних приложений, а так же может хранить ссылки на внешние объекты для их быстрого открытия в сторонних приложениях.

EPLAN – глобальная компания с собственными офисами в 51 й стране мира.

Еще более чем в 20 странах мы представлены нашими партнерами.

EPLAN работает в объектно-ориентированной парадигме с момента своего основания – уже более 32 лет, и за эти годы превратился в лучшее в своем классе решение, доминирующее в целом ряде отраслей.

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

В среде EPLAN проект представляет из себя базу данных в особом проприетарном формате.

Любые данные, вносимые в систему, индексируются в базе данных проекта и увязываются между собой в контексте этого проекта.

Данные могут вноситься как из отдельных файлов (таблиц excel, csv, xml, txt), так и баз данных (Access, SQL, Oracle).

Как только необходимый объем данных внесен в базу данных проекта, среда EPLAN автоматически сгенерирует требуемую документацию.

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

Внешние документы (руководства по эксплуатации, паспорта приборов) индексируются в системе и становятся доступны пользователю.

Пара кликов позволяет перейти с генплана на монтажную документацию по конкретному датчику, посмотреть его manual, перейти на P&ID, затем на схему внешних проводок (чтобы увидеть, как подключен датчик), затем, например, на кабельный журнал (непосредственно на кабель, которым подключен этот датчик).

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

Наиболее эффективным инструментом построения единой информационной модели АСУ ТП является работа в едином формате EPLAN.

При работе с подрядчиками\субподрядчиками в формате EPLAN им направляется техническое задание и шаблон проекта (либо частичный проект EPLAN).

ZW1 – это резервная копия проекта, единый файл архива, содержащий все необходимые настройки (например, кодирования оборудования, нумерации проводов, кабелей и устройств), рамки, структуру и формы отчетов.

Как правило, проверка входящих проектов может быть автоматизирована, а детальный отчет по требуемым доработкам создан автоматически.

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

Тематика АСУ ТП кардинально отличается от, например, строительства тем, что решения на 100% составляются из покупных изделий. Их не надо конструировать, надо просто взять и соединить между собой.

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

В EPLAN Data Portal пользователи могут скачать или сконфигурировать свое изделие, получая как его схему подключения, техническую информацию (руководства по эксплуатации, паспорта приборов).

В будущем все важнее будет становиться наличие в цифровой форме информации по надежности (MTBU) и эксплуатации (сроки поверок\замен) изделий.

EPLAN Data Portalготов к предоставлению такой информации.

EPLAN – важная часть Индустрии 4.0.Формат проектов EPLAN используется в лидирующих проектах по созданию производства будущего, таких как SmartFactory KL.

Источник

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

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

Чтобы бизнес-приложения, автоматизирующие разные бизнес-процессы, могли как-то работать вместе, их необходимо интегрировать: внедрять продукты класса 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: если в единой корпоративной платформе управления данными хранятся не только данные и описание их структуры, но и машинно-читаемое описание алгоритмов обработки данных, то новые бизнес-приложения, ориентированные на использование таких описаний, станут еще гибче и смогут изменять свое поведение «на лету» без вмешательства не только в код, но и в настройки приложений.

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

Источник

Дата-центричная архитектура

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

датацентричный подход что это. Смотреть фото датацентричный подход что это. Смотреть картинку датацентричный подход что это. Картинка про датацентричный подход что это. Фото датацентричный подход что это

Пожалуй, главным популяризатором этой концепции можно назвать Дэйва Маккомба. Маккомб возглавляет агентство Semantic Arts, более 20 лет курирующее построение IT-архитектур для крупных организаций. Также Маккомб известен своими научными и публицистическими трудами. Каждый, кто задействован в работе с бизнес-данными, должен быть знаком с его Манифестом дата-центричности (The Data-Centric Manifesto).

Проблематика Манифеста

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

Поставив в центр системы корпоративные данные, компании перестанут быть зависимыми от прикладного ПО и его разработчиков. Появится возможность включать в систему предприятия любые новые приложения и исключать старые.

Мы раскрыли основную причину беспорядка в информационных системах крупных учреждений. Это ориентация на приложения, которая придает ПО приоритет над данными. Выход состоит в том, чтобы перевернуть ситуацию с ног на голову. Данные – это центр вселенной, приложения эфемерны.

Ведь все и так работает… (Почему зависимость от приложений существует?)

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

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

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

Отметим, что переход к дата-центричной архитектуре можно провести практически незаметно, и бояться изменений не стоит. Ряд IT-компаний предлагают такие решения для перехода, которые не тормозят деятельность заказчика. Более того, обновление быстро окупается (экономия на интеграции; хранении данных; сотрудниках, обслуживающих прежнюю систему и пр.). И зависимости от тех, кто помог провести изменения, не возникает. Само ПО для виртуализации корпоративных данных, наравне с любым другим, может быть при необходимости заменено, и это не повлияет на сами данные.

Вторая причина, по которой ориентация на данные пока не имеет широкого распространения – незнание. Не всем известно, что такой путь существует. Манифест призван побороть это незнание. Он помогает популяризировать дата-центричность за счет того, что в нем сжато и ясно изложена суть концепции. Более того, на сайте The Data-Centric Manifesto формируется комьюнити, к которому присоединяются люди со всего мира. Среди участников сообщества множество представителей крупнейших компаний, таких как Johnson&Johnson и IBM. Комментарии специалистов, убедившихся в потенциале дата-центричности, привлекают новых сторонников.

Из раздела «Подписавшиеся» сайта The Data-Centric Manifesto

«Я лично испытал на предыдущем месте работы разрушительные последствия архитектуры, ориентированной на приложения. Команды разработчиков отвергли решения на основе SQL, которые работали в от 10 до 100 раз лучше с меньшим количеством кода и меньшими ресурсами, и все это из-за догмы ориентации на приложения», – Стив Эштон, IT-архитектор.

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

Звучит достаточно конспирологически, но Маккомб подкрепляет свои заявления фактами.

«Существует огромное количество случаев, когда системы стоят более чем в 1000 раз дороже, чем должны. Большинство людей слышали о Healthcare.gov (Healthcare.gov – масштабный проект правительства США, направленный на оптимизацию оформления медстраховки. Траты на разработку системы проекта стали причиной скандала. – прим. авт.). Некоторые знают, что на сегодняшний день это обошлось в 2,1 миллиарда долларов (против первоначального бюджета в 93,7 миллиона долларов). Еще меньше людей понимают, что его можно было бы построить (гораздо лучше) менее чем за 1 миллион долларов, что именно и сделала HealthSherpa (HealthSherpa – стартап независимых разработчиков, запущенный как ответ Healthcare.gov – прим. авт.). Healthcare.gov в итоге были приняты многие элементы дизайна, разработанные в HealthSherpa», – Дэйв Маккомб в интервью для InfoQ.

Мы понимаем, что на создании, внедрении и интеграции приложений зарабатываются огромные деньги, и именно это поддерживает ориентацию на приложения.

Ключевые принципы Манифеста

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

Если вы хотите узнать больше о дата-центричном подходе в управлении данными, начните изучение с трудов Дэйва Маккомба The Data-Centric Revolution: Restoring Sanity to Enterprise Information Systems и Software Wasteland: How the Application-Centric Mindset is Hobbling our Enterprises.

Подробнее о требованиях к платформе для реализации дата-центричной архитектуры, ее преимуществах, отличиях от концепций Data Lake и Corporate Data Cloud можно прочитать в нашей статье.

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

Источник

Добавить комментарий

Ваш адрес email не будет опубликован. Обязательные поля помечены *