Данные не являются информацией, а Архитектура Данных не тоже самое что и Информационная Архитектура, несмотря на то, что два термина часто ошибочно взаимозаменяемо используются.
Эта путаница возникает еще и из-за того, что определению понятия Информационной Архитектуры уделено недостаточное внимание в материалах TOGAF 9.1 (скорее более подробно рассматриваются вложенные фазы Data Architecture и Application Architecture, составляющие фазу C).
Неверное трактование усугубляется еще и термином “информационная архитектура”, используемым в отрасли веб-разработки, где он исключительно связан со способом структурирования веб-контента.
В этой статье хотелось бы немного разобраться с тем, что такое Информационная Архитектура, в чем ее ценность и как мы можем описать такую архитектуру.
Начнем с определения информации как: данных дополненных контекстом (data + context). Данные без контекста бессмысленны. К примеру, возьмите столбец значений с плавающей запятой в таблице базы данных - в то время как разработчик может распознать некоторый смысл значений, проверяя физические имена таблиц и столбцов базы данных - значения не имеют смысла для обычного пользователя до тех пор, пока они не представлены на экране компьютера в поле с надписью, например, “Уровень холестерина (ммоль/л)”
Это различие между данными и информацией фиксируется концепцией Информационного Актива.
Информационные Активы (а не активы данных или объекты данных) являются предметом Информационной Архитектуры.
Информационный Актив определяется как комбинация одного или нескольких источников данных, управляемых и передаваемых системой. Система посредством собственного уровня представления отвечает за управление контекстом, в котором представлены данные, для передачи правильного заложенного смысла. “Система” может быть реализована с использованием бумажных, ручных или компьютерных технологий.
Информационный Актив, как и другие активы, имеет ценность и жизненный цикл. Ценность Информационного Актива варьируется в зависимости от его жизненного цикла и зависит от качества нижележащих данных, а также от характеристик системы, которая управляет ими (например, времени отклика системы, доступности).
Дисциплина Управления Информацией (Information Management), как правило, описывает управление Жизненным Циклом Информационных Активов.
Информационные Активы на концептуальном уровне категоризируются как (это не исчерпывающий список):
- Онтологии
- Термины / Терминологии
- Таксономии
- Каталоги / Реестры
- Расписания
- Документы
- Шаблоны
- Информационные Панели
Эти высокоуровневые категории используются для дальнейшей группировки логических типов Информационных Активов, необходимых внутри предприятия для успешного ведения бизнеса (например, отчеты о бюджете, стратегические планы, информационные панели показателей эффективности, финансовая отчетность, проектная отчетность, медицинские записи, торговые и бухгалтерские книги, организационные диаграммы, графики работы, календари и т. д.).
Каждый логический тип имеет жизненный цикл и может быть физически представлен используемыми источниками данных и системами в текущем и целевом состоянии. Кроме того, различные нижележащие технологии более подходят для разных категорий информационных активов (например, многомерные базы данных по сравнению с реляционными базами данных, OWL по сравнению с XML или электронная таблица по сравнению со средством визуализации данных), и поэтому Информационная Архитектура начинает охватывать типы требуемых технологий и систем.
Реализации в целевом состоянии предназначены для улучшения ценности Информационных Активов путем снижения затрат или улучшения точности, безопасности, качества и своевременности предоставления информации. Например, целевое состояние Информационной Архитектуры может идентифицировать Информационный Актив (например, информационная панель контроля показателей эффективности), который на сегодняшний день реализован с использованием вручную ведущихся электронных таблиц. В целевом состоянии он будет реализован как информационная панель, например, на базе Cognos BI или SharePoint, которая будет автоматически наполняться данными из хранилища данных или нескольких внешних источников данных в режиме близком к реальному.
Информационная Архитектура предоставляет средства для просмотра и категоризации информации, необходимой для поддержки и использования в бизнес-процессах. Понимая ее согласованное использование в процессах, мы можем начать идентификацию ценности информации и определить насколько она важна для бизнеса. Таким образом, Информационная Архитектура предоставляет средства для охвата и приоритезации такой деятельности, как Управление Основными Данными (Master Data Management), Управление Портфелем Приложений (Application Portfolio Management), разработка и поддержка хранилища данных.
Как данные физически структурированы и управляются, это дело Архитектуры Данных (Data Architecture) и дисциплины Управления Данными (Data Governance).
Физическое структурирование данных должно быть прозрачным для Информационной Архитектуры, поскольку обычно уровень приложений выступает посредником в представлении данных и их обработке. Например, единое хранилище данных скорее предназначено для хранения и управления данными, которые проявляются в нескольких Информационных Активах.
Общая польза от разработки Информационной Архитектуры включает консолидацию отчетов и улучшенную согласованность отчетности. Нередко бывает так, что один и тот же логический тип Информационного Актива (например, ежемесячный отчет о статусе проекта) реализуется в организации с использованием различных конфигураций систем и данных. Информационная Архитектура подчеркивает эти возможности для улучшения бизнеса.
Информационная Архитектура часто неправильно понимается, в результате чего игнорируется архитектурный домен, который логически связывает домены бизнес, приложений и данных и обеспечивает ключевую связь между бизнес-процессами, приложениями и данными, используемыми организацией.
Возвращаясь к TOGAF, целью фазы C является разработка целевой Информационной Архитектуры (Данных и Приложений), описывающей, как Информационная Архитектура предприятия позволит поддержать Бизнес-Архитектуру и Архитектурное Видение (Architecture Vision) способом, который соответствует Запросу на Архитектурную Работу и интересам заинтересованных сторон, а также идентифицировать потенциальные компоненты для Архитектурного Плана Действий (Architecture Roadmap) на основе анализа расхождений между текущим и целевым состоянием Информационной Архитектуры (Данных и Приложений).
Подход, используемый в Фазе C включает в себя некоторую комбинацию описания Архитектуры Данных и Архитектуры Приложений в любой удобной последовательности. Существуют приверженцы обеих последовательностей при описании. Например, Enterprise Architecture Planning (EAP) от Стивена Спьюака рекомендует подход “от данных” (data-driven).
С другой стороны, основные прикладные системы, такие как ERP-системы, системы управление взаимоотношениями с клиентами (CRM) и т.д., часто являются сочетанием технологической инфраструктуры и логики бизнес-приложений, и некоторые организации используют подход “от приложений” (application-driven), в соответствии с которым, они выделяют определенные ключевые приложения как формирующие ядро для критически важных бизнес-процессов и берут на себя внедрение и интеграцию этих ключевых приложений в качестве основного направления усилий в области архитектуры (задачи интеграции часто представляют собой серьезную проблему).
Чтобы показать суть онтологии, создаваемой в результате фазы С и подтвердить применимость обоих подходов в любой их комбинации, полезно рассмотреть артефакты создаваемые в результате вложенных фаз.
Одним из примеров такого артефакта является Диаграмма Распространения Данных (Data Dissemination Diagram).
Цель Диаграммы Распространения Данных - показать взаимосвязь между сущностями данных, бизнес-сервисами / бизнес-процессами и компонентами приложения. Это позволяет на последующих фазах провести эффективный сайзинг и уточнить и запланировать инфраструктурные ресурсы / расширение / преобразования. Присваивая бизнес-ценность данным, можно получить информацию о критичности компонентов приложения для бизнеса. Кроме того, диаграмма может отображать потоки репликации данных и информацию о том, что система является владельцем и поставщиком основных данных (master data). В этом случае на диаграмме отражается две копии данных и связь типа мастер-копия между ними. Эта диаграмма может включать в себя сервисы. Сервисы могут инкапсулировать данные, и находиться внутри приложения или сервисы, могут находиться в приложении и получать доступ к данным, инкапсулированным внутри другого приложения.
Идентифицируя Информационные Активы, необходимые для ведения бизнеса и то, как они структурированы, Информационная Архитектура охватывает требования к текущим и целевым технологиям поддержки данных, а также устраняет сложности проектирования приложений и управления данными.
При нынешней популярности направления Больших Данных (Big Data) и увеличении размеров хранилищ данных и затрат на них, необходимо, как никогда, понимать важность информации, получаемой из этих данных.
Простое приобретение большего количества данных, подобно приобретению большего количества технологий, больше не представляет собой конкурентное преимущество само по себе. Целью скорее является осмысленное, интеллектуальное и целенаправленное использование данных и технологий, которые могут привести к прорывным возможностям на рынке, основанным на использовании информации.
Информационная Архитектура обеспечивает представление для идентификации бизнес-ценности информации и предназначена для достижения более целенаправленного подхода к использованию и управлению как данными, так и технологиями на предприятии.