Основные модели и инструменты описания архитектуры информации

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

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

· модели данных. Специалисты Gartner не рекомендуют, однако, тратить избыточные усилия на создание единой, полной и детальной модели в рамках всего предприятия, так как затраты на ее разработку и последующее поддержание могут быть неадекватны получаемым выгодам. Основное внимание стоит уделять выявлению семантической разницы в описаниях данных, поступающих из различных источников, и созданию относительно стабильных так называемых "канонических" представлений данных, описывающих их использование бизнес-пользователями;

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

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

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

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

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

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

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

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

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

· Атрибут является характеристикой, которая обеспечивает более детальную информацию о сущности (объекте), например, "фамилия", "имя", "пол" и т.д. Атрибут становится колонкой в таблице базы данных. Ключевой атрибут, или первичный ключ, является уникальным идентификатором сущности. Примером является серийный номер.

· Отношения показывают, как одна сущность соотносится с другой. При описании связи представлены глаголами, поскольку означают действие. Примером может быть высказывание "гражданин владеет недвижимостью": сущность "гражданин" "владеет" некоторой другой сущностью "недвижимость". Когда между сущностями установлены связи, то одна сущность является "родителем", а другая "потомком".

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

Одним из способов моделирования данных на логическом уровне является построение моделей "Сущности-Отношения" (ERM – Entity-Relationship Model).

На физическом уровне даются точные ответы на вопросы типа: "Какие данные требуются для того, чтобы реализовать логику бизнес-процесса соответствующей прикладной системой?", "Сколько требуется различных информационных объектов (сущностей)?", "Каков набор элементов данных каждой сущности?". Физическая модель данных служит, по сути, представлением того, как данные, приведенные в логической модели, будут храниться в системе управления базами данных.

Сравнительные характеристики этих уровней (с использованием идеи систематизации из [4.19] приведены в таблице 5.6.

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