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

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

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

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

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

–      получение информации из внутренних и внешних источников;

–      классификация информации;

–      хранение и извлечение данных;

–      редактирование и обновление данных;

–      исправление или удаление некорректных данных;

–      презентация или трансформирование информации под потребности определенной категории потребителей;

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

–      оценка полезности информации;

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

На рисунке 1 приведена общая схема архитектуры информации [1]. Безусловно, она далеко не полная: в частности, не отражает наличие неструктурированной и полуструктурированной информации, которая хранится в форме текстов, образов документов, электронных сообщений и т.п. Тем не менее схема дает некоторое представление об архитектуре информации экономической системы и позволяет уяснить довольно тонкие отношения между понятиями «информация» и «данные».

Для понимания архитектуры информации и того, как хранятся и обновляются данные, важно отличать типы прикладных систем, обеспечивающих доступ к данным. Существуют два класса прикладных систем: системы онлайновой обработки транзакций (On-line Transaction Processing – OLTP) и системы онлайновой аналитической обработки (On-line Analytical Processing – OLAP).

OLTP-системы применяются для выполнения критически важных, повседневных операций [2]. Чаще всего они используются многими пользователями одновременно для ввода, обновления и извлечения данных. OLTP-системы способны реализовать атомарные бизнес-функции и четко обозначенные работы, как правило, в форме одной или нескольких транзакций, выполняемых как одно целое (например, транзакция «изменение адреса клиента»).

OLAP-системы используются для анализа, планирования и формирования отчетов путем обеспечения интерактивного доступа к широкому спектру архитектурной информации [3]. В OLAP-системах обычно обрабатываются агрегированные данные для получения ответа на вопросы, например, о том, сколько средств было потрачено на покупку офисной техники в прошлом году, каков был объем продаж изделия х в городе N в первом квартале текущего года и т.п. Данные для OLAP-систем, как правило, извлекаются из транзакционных OLTP-систем и помещаются в специальные БД – хранилища или витрины данных. Витрины данных – это специализированные хранилища, ориентированные на предоставление информации аналитического характера.

Таким образом, для создания архитектуры информации необходимы глубокие знания в следующих областях (дисциплинах):

–      метаданные (описание данных, формирование словарей и репозиториев);

–      информационное моделирование;

–      моделирование данных;

–      БД;

–      СУБД;

–      ПО доступа к данным (так называемые программы промежуточного слоя – middleware);

–      безопасность данных.

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

В результате разработки архитектуры информации на выходе должны появиться следующие артефакты:

–      документированное описание источников данных;

–      модели информации и модели данных;

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

–      соглашения по уровню сервиса, связанного с передачей данных;

–      описание решений по организации хранения данных (от общих каталогов до витрин и хранилищ данных);

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

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

Цель разработки моделей информации и моделей данных – создание графических представлений потребностей организации и отдельных бизнес-процессов в информации. Эти представления являются основой для реорганизации бизнес-про­цессов и конструирования новых прикладных систем, спецификации взаимодействий и информационного обмена между экономической системой и ее контрагентами, но самое главное – оказывают основное влияние на логическую и физическую структуру БД корпоративной информационной системы. В общем случае информационную модель образуют определенным образом упорядоченные информационные сообщения, отражающие процессы преобразования ресурсов (трудовых, материальных, энергетических, интеллектуальных) в потребительские стоимости. Таким образом, основная задача начального этапа архитектурного процесса заключается во взаимосвязанном описании ресурсов и процессов в терминах исследуемой предметной области. В результате должна получиться некая информационная проекция исследуемой экономической системы относительно обеспечения ее функциональности в текущий момент и в обозримой перспективе.

Информационная модель должна адекватно отражать предметную область исследования, быть непротиворечивой, конечной и легко расширяемой, допускать композицию и декомпозицию, без труда восприниматься разными категориями пользователей [5].

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

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

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

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

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

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

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

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

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

На физическом уровне осуществляется жесткая привязка данных к прикладным системам, с одной стороны, и физическим носителям – с другой. По сути физическая модель дает представление о том, как данные, приведенные в логической модели, будут храниться в БД.

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

При разработке домена «Архитектура информации» необходимо помнить об использовании в процессах функционирования и развития экономической системы как структурированной, так и неструктурированной информации. Многие исследования показывают, что люди, принимающие решения, только на одну треть полагаются на информацию из структурированных источников (содержимого БД). Две трети необходимой информации они получают в результате встреч, телефонных разговоров, участия в дискуссиях или по «сарафанному радио» [6]. Этот факт обязательно надо учитывать при построении архитектурных информационных моделей.

Стратификация процесса построения архитектуры информации

Акцент	Уровень
	Концептуальный (модель информации)	Логический (модель данных)	Физический (реализация данных)
Точка зрения	Бизнес-взгляд на ИТ	ИТ-взгляд на бизнес	ИТ-взгляд на ИТ
Предмет анализа	Связи информации с бизнес-функциями, интерфейсами, технологиями	Связи данных с другими данными	Связи данных с системами хранения
Фокус	Описание информации	Описание структур данных	Объемы и частота использования данных
Фаза разработки	Анализ	Проектирование	Реализация
Характер работ	Искусство	Наука	Ремесло

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

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

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

Рисунок 2 иллюстрирует принципы интеграции информации на основе управления метаданными [1]. В его нижней части имеется набор различных физических систем управления данными. Уровень выше представляет набор моделей этих систем, не зависящих от платформы реализации. Уровень запросов устанавливает соответствие для создания виртуальных моделей объектов, чьи аналоги могут и не существовать в физических системах. Эти виртуальные модели для различных пользователей могут представляться по-разному: БД, бизнес-объектами, выборками из БД, моделями данных, документами, сервисами – в зависимости от потребностей. Важно то, что определение этих объектов осуществляется с помощью моделей.

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

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

Литература

1.     Данилин А., Слюсаренко А. Архитектура и стратегия: «инь» и «янь» информационных технологий предприятия. М.: Изд-во ИНТУИТ, 2009. 504 с.

2.     Vieira M. Depenbility Benchmarking to OLTP Systems. Saarbriicen: LAP Lambert, 2010, 273 p.

3.     Барсегян А.А., Куприянов М.С., Степаненко В.В., Холод И.И. Технологии анализа данных: учеб. пособие. СПб: БХВ–Петербург, 2004. 538 с.

4.     Спирли Э. Корпоративные хранилища данных: планирование, разработка, реализация. М.: Вильямс, 2001. 522 с.

5.     Адизес И. Управляя изменениями: как эффективно управлять изменениями в обществе, бизнесе и личной жизни. СПб: Питер, 2008. 224 с.

6.     Хорошилов А.В., Селетков С.Н., Днепровская Н.В. Управление информационными ресурсами. М.: Финансы и статистика, 2006. 272 с.

References

1.     Danilin A., Slyusarenko A. Arkhitektura i strategiya: «in» i «yan» informatsionnykh tekhnologiy predpriyatiya [An architecture and strategy, "yin" and "yang" for information technology enterprise]. Moscow, Internet Univ. of IT Publ., 2009, 504 pp.

2.     Vieira M. Depenbility Benchmarking to OLTP Systems. Saarbriicen, LAP LAMBERT Publ., 2010, 273 p.

3.     Barsegyan A.A., Kupriyanov M.S., Stepanenko V.V., Kholod I.I. Tekhnologii analiza dannykh [Data mining technologies], manual, St. Petersburg, BHV-Peterburg Publ., 2004, 538 p.

4.     Sperley E. Enterprise data warehouse. Planning, building, and implementation. Prentice Hall Publ., 1st ed., 2001, 333 p.

5.     Adizes I. Mastering Change: The Power of Mutual Trust and Respect in Personal Life, Family Life, Business & Society. Santa Monica, CA, Adizes Institute Publ., 1991, 240 p.

6.     Khoroshilov A.V., Seletkov S.N., Dnipro N.V. Upravlenie informatsionnymi resursami [Information resources management]. Moscow, Finance and Statistics Publ., 2006, 272 p.