пособие по архитектуре предприятия. пособие по архитектуре предприятия2. Пособие по дисциплине Архитектура предприятия Д. Р. Богданова, В. А. Котельников, Л. У. Минибаева Уфа 2015. 89с

• Название: Пособие по дисциплине Архитектура предприятия Д. Р. Богданова, В. А. Котельников, Л. У. Минибаева Уфа 2015. 89с
• Анкор: пособие по архитектуре предприятия
• Дата: 12.01.2021
• Размер: 1.76 Mb.
• Имя файла: пособие по архитектуре предприятия2.doc
• Тип: Пособие; #167343
• страница: 6 из 8

Вопросы

1. 
   Из чего состоит контекст архитектуры?
   
2. 
   Каковы уровни абстракции архитектуры?
   
3. 
   Какие концепции соответствуют различным элементам и уровням абстракции архитектуры?
   
4. 
   Перечислите домены описания архитектуры?
   
5. 
   В чем заключаются перспективы описания архитектуры?
   
6. 
   Чем определена концепция архитектуры предприятия?
   
7. 
   На какие вопросы должен давать ответы уровень контекста предприятия?
   
8. 
   Перечислите ключевые вопросы, которые рассматриваются на концептуальном уровне архитектуры?
   
9. 
   Перечислите ключевые вопросы, которые рассматриваются на логическом уровне архитектуры?
   
10. 
    Какие принципы описывает физический уровень архитектуры?
    

5. Лекция: Элементы Архитектуры предприятия. Бизнес-архитектура и архитектура информации

Содержание

• 
  Домены (предметные области) архитектуры
  
• 
  Бизнес-архитектура
  
• 
  Архитектура информации
  

5.1 Домены (предметные области) архитектуры

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

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

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

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

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



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

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

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




Рис. 5.2.  Модель, используемая для описания стратегии и архитектуры информационных технологий

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

• 
  Миссия и видение.
  
• 
  Руководящие принципы. Утверждения, описывающие принципы и ключевые элементы философии использования информационных технологий.
  
• 
  Цели, задачи и стратегии.
  
• 
  Архитектура информационных технологий.
  
• 
  Политики (правила). Политики являются общими утверждениями, которые задают направления и цели, связанные с инициативами в области ИТ. Они носят, как правило, достаточно высокоуровневый и общий характер и обеспечивают скоординированный процесс планирования, закупку критически важных технологий, эффективную разработку систем и эффективное использование информационных технологий и ресурсов.
  
• 
  ИТ-стандарты. Стандарты – это обязательные к использованию утверждения, касающиеся используемых технологий, продуктов и/или услуг. Они должны быть достаточно полными и в то же время определять разумный минимум требований, обязательных для использования. В случае, когда речь идет о стандартах, выбираемых государством, особенно важным является подход, когда стандарты описывают только наиболее общие и важные элементы технологий в соответствии с принципами честной конкуренции.
  
• 
  Процедуры. Процедуры – это инструкции, описывающие, как выполняются политики и стандарты. Процедуры устанавливают и описывают процессы, которые выполняются на регулярной основе.
  
• 
  Руководства или рекомендации (guidelines). Руководства и рекомендации – это описания лучших практик или приемлемых подходов к практической реализации политик и процедур. Руководства могут стать стандартами.
  

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

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

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

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

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

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

Примеры декларируемых принципов в области ИТ-инфраструктуры:

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

Примеры принципов в области управления данными:

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

Примеры принципов, связанных с прикладными системами:

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

Примеры принципов, связанных с управлением и контролем:

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

Вот еще некоторые варианты формулировок принципов:

• 
  организация должна иметь интегрированный процесс управления архитектурой.
  
• 
  должны существовать механизмы управляемого развития архитектуры.
  
• 
  целью архитектуры должно быть уменьшение сложности интеграции систем.
  
• 
  организация будет "разрабатывать" те прикладные системы, которые связаны с получением конкурентных преимуществ, и "покупать" стандартные прикладные системы в тех областях, где достаточно иметь паритет по отношению к другим участникам рынка.
  
• 
  Информация является общекорпоративным активом.
  
• 
  Прикладные системы будут строиться с использованием n-уровневой архитектуры (презентационная логика, бизнес-логика, уровень доступа к данным, уровень данных).
  
• 
  Для интерфейсов между системами будет использоваться технология пересылки сообщений.
  
• 
  Применение компонентной разработки информационных систем.
  
• 
  Использование технологий анализа данных (Business Intelligence) для ускорения принятия решений и упрощения разработки.
  
• 
  ИТ-служба будет использовать стандарты и методику управления качеством "Шесть Сигма" в процессе обеспечения качества прикладных систем и ИТ-услуг (принцип, который может быть принят в результате анализа сильных и слабых сторон ИТ-службы).
  

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

При разработке и использовании стандартов следует учитывать нижеперечисленные аспекты:

• 
  Уделяйте большее внимание тем стандартам, которые обеспечивают эффективное использование базовых технологий. Прежде всего, это технологии, на которых построены многие системы и которые стали индустриальными стандартами. Примерами таких технологий для организаций являются XML, .NET, Java (рассматриваемая не как язык, а как среда разработки).
  
• 
  Определяйте стандарты процессов. Примерами являются процессы бизнес-моделирования, методы разработки систем, тестирования, интеграции.
  
• 
  Уделяйте внимание интерфейсам. Понимание интерфейсов является основой для интеграции систем.
  
• 
  Теснее взаимодействуйте с бизнес-подразделениями. Например, разработка основанных на XML стандартов на электронные сообщения невозможна без участия специалистов в конкретных предметных областях.
  
• 
  Для того чтобы быть эффективным инструментом, стандарты должны включать списки конкретных версий технологий, интерфейсов программирования (API), утилит и т.д. Примерами могут быть версии систем управления базами данных, версии XML и т.п.
  
• 
  Стандарты должны включать способы проверки на соответствие.
  
• 
  Стандарты должны содержать описание того, как организован процесс их поддержки. Стандарты должны периодически пересматриваться и обновляться.
  

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

• 
  Руководства не заменяют техническую документацию, но рассматривают некоторые проблемы в контексте конкретной организации.
  
• 
  Хорошие руководства сфокусированы на конкретных проблемах, общих для большинства разработчиков систем. Это включает, например, интеграцию приложений с использованием соответствующих систем интеграции корпоративных приложений, создание "горизонтальных" порталов, контроль версий.
  
• 
  Тематика руководств может быть связана как с технологиями и их использованием, так и с процессами. Например, весьма полезными могут стать руководства, описывающие процессы создания конфигурации систем, построения версии системы или процесс контроля качества.
  
• 
  Наиболее эффективные руководства, как правило, короткие и специфичные. Желательно ограничивать их четырьмя страницами.
  

5.2. Бизнес-архитектура

Контекст и основные элементы бизнес-архитектуры

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

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

Таким образом, можно сказать, что Бизнес-архитектура включает в себя, как правило, следующие аспекты:

• 
  Бизнес-стратегия, функции и организационные структуры – собрание целевых установок, планов и структур организации. Данная информация может быть представлена в самых разных форматах, но наиболее важный аспект состоит в создании контекста для описания бизнес-процессов. Эта часть архитектуры не является технической, но она критически важна с той точки зрения, что архитектура информационных технологий (информации, прикладных систем, технологическая архитектура) строится на ее основе и обеспечивает реализацию ключевых функций организации.
  
• 
  Архитектура бизнес-процессов, которая определяет основные функциональные области организации. Для министерства – это могут быть функции, перечисленные в Положении о министерстве, для коммерческой организации – процессы разработки новых продуктов, услуг и сбыта товаров и т.п. Она также описывает специфические процессы внутри каждой функциональной области и их операционные параметры – например, объемы операций, роли, реализацию централизованной или децентрализованной модели операций и т.д. Эта часть является как бы "точкой соприкосновения" между бизнес-архитектурой и архитектурой приложений и обеспечивает взгляд на бизнес и функции организации, достаточно детализированный для того, чтобы использовать его при выработке стратегии и планов создания приложений.
  
• 
  Показатели эффективности. Этот аспект состоит в определении ключевых показателей эффективности (КПЭ) работы организации, их текущих уровней и желаемых, будущих уровней и включает в себя также разработку на верхнем уровне модели КПЭ для мониторинга.
  

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

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

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

Далее рекомендуется выполнить следующие шаги.

Шаг 1. Идентификация критически важных для предприятия процессов (обычно не более восьми).

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

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

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

Шаг 3. Построить модели высокого уровня для ключевых бизнес-процессов. Это включает последовательность основных шагов (желательно, не более восьми на процесс).

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

Шаг 5. Идентифицировать и документировать основные категории информационных объектов (опять же рекомендуется не более восьми).

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

Для автоматизации моделирования процессов сложился специальный класс программных продуктов. Наиболее известными являются такие продукты, как ARIS, Software Architeсt, BPWin (новое название – AllFusion Process Modeler).

Основное внимание при разработке Бизнес-архитектуры должно уделяться "картине в целом". Целью Бизнес-архитектуры не является детальное описание деятельности предприятия. Модели, включенные в Бизнес-архитектуру, должны давать необходимый минимум сведений о ключевых функциях, процессах, бизнес-событиях и потоках информации, достаточный для процесса принятия решений, поиска новых возможностей для инноваций. Дальнейшая детализация выполняется с использованием таких инструментов, как:

• 
  декомпозиция функций/процессов;
  
• 
  анализ бизнес-событий;
  
• 
  моделирование местоположений выполнения функций/процессов;
  
• 
  модель интеграции функций/процессов.
  

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

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

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

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

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

После того как модели созданы, на их основе можно выполнять различные методы анализа:

• 
  Анализ цепочек создания добавочной стоимости (А нужно ли вообще выполнять этот шаг?)
  
• 
  Динамическое моделирование (Как эта модель выполнения бизнес-функций будет себя вести при различных значениях на входе и доступных ресурсах, и как со временем будет меняться поведение процесса?)
  
• 
  Анализ пересечений и непокрытых областей (Gap-overlap analysis) (Будет ли наша бизнес-архитектура иметь избыточные элементы, и есть ли в ней "пробелы"?)
  
• 
  Соотнесение затрат с активностями (Activity-based costing) (На каких процессах, каналах продаж и заказчиках мы реально зарабатываем или теряем деньги?)
  
• 
  Обучение (Как эти бизнес-процессы соотносятся с другими?)
  
• 
  Общая стоимость владения (Сколько стоит этот процесс?)
  
• 
  Возврат инвестиций (ROI) (Будет ли достигнут возврат инвестиций в данный бизнес-процесс и когда?)
  

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

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

5.3. Архитектура информации

Контекст и основные элементы архитектуры информации

Сегодня организации должны искать эффективные способы работы с информацией, которая поступает из самых разнообразных источников и должна быть доступна там, где это нужно, и тогда, когда это необходимо. Ситуация осложняется тем, что различные формы информации зачастую требуют специфических технологий и методов работы с ней: 1) структурированная информация (реляционные и объектные модели); 2) развивающиеся, основанные на XML стандарты для полуструктурированной информации; 3) неструктурированная информация в форме текстов, графиков, образов, сопровождаемая определенными описательными данными (метаданными и каталогами).

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

Архитектура информации включает в себя модели, которые описывают процессы обработки информации (information value chain), основные информационные объекты, связанные с бизнес-событиями, информационные потоки, принципы управления информацией. Архитектура должна описывать как те данные, которые требуются для выполнения процессов (операционные), так и аналитические данные и "контент", публикуемый на Web.

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

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

На рисунке 5.4 приводится пример упрощенной схемы перемещения данных в процессе работы над ними на некотором гипотетическом предприятии.



Рис. 5.4.  Пример потоков данных на предприятии

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

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

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

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

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

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

Рисунок 5.5 показывает общую картину архитектуры информации.

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

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

• 
  федеративные данные (метаданные);
  
• 
  моделирование данных;
  
• 
  системы управления базами данных;
  
• 
  программное обеспечение промежуточного слоя (middleware) для доступа к данным;
  
• 
  механизмы доступа к данным;
  
• 
  безопасность данных.
  

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

Рекомендуемыми первыми шагами на пути создания архитектуры информации являются следующие шаги:

• 
  создание словаря данных и репозитория метаданных;
  
• 
  выбор системы записи информации о каждом элементе данных.
  

Рис. 5.5.  Общая архитектура информации (данных)
Основные модели и инструменты описания архитектуры информации

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

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

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

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

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

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

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

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

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

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