	Главная \| Случайная страница \| Контакты \| Мы поможем в написании вашей работы!

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

⇐ Предыдущая 12

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

По оценке Gartner, вплоть до конца 2005 года около 70% всех предприятий будут вести определенные проекты, связанные с анализом и совершенствованием бизнес-процессов, несмотря на некоторый негативный осадок, который в корпоративном мире имела практика реинжиниринга бизнес-процессов середины 1990-х годов. "На самом деле, большинство предприятий в действительности не понимают всей глубины и масштабов выполняемых ими бизнес-процессов, если они не занимались бизнес-моделированием в последнее время", – считает Джим Синур (Jim Sinur), аналитик Gartner.

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

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

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

"Если архитектура ИТ предприятия описывает то, как компоненты ИТ объединяются вместе для достижения нужного результата, то точно также бизнес-архитектура описывает, как элементы бизнеса соединены вместе".

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

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

Рис. 5.7. Контекст Бизнес-архитектуры

Усилия по построению бизнес-архитектуры, которая представляется в виде бизнес-моделей, быстро окупают себя и имеют большое количество дополнительных преимуществ [4.11]. Под бизнес-моделями понимается динамический поток событий, связанных с бизнесом, в который вовлечены различные функции бизнеса, организационные единицы и активы предприятия. Возможная отдача от реализации таких моделей достаточно подробно изучалась и описывалась на протяжении последнего столетия. Основная проблема состоит в том, чтобы убедить руководство в этих преимуществах и добиться от него поддержки проведения проекта разработки бизнес-моделей. А преимущества от построения таких моделей лежат в двух плоскостях: дополнительных возможностях для бизнеса и уменьшении затрат. По оценкам, создание бизнес-моделей и связанная с этим оптимизация затрат даже без радикальных изменений бизнеса может дать до 10% экономии. А при моделировании альтернативных вариантов бизнес-процессов организации могут сэкономить до 20% [4.11]. Но не менее важная роль бизнес-моделей состоит в том общем языке, которые они дают представителям бизнеса и ИТ в обсуждении соответствующих возможностей.

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

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

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

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

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

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

Желательно, чтобы рекомендуемое число таких процессов, не превышало "волшебного числа" 8 в соответствии с известным принципом: "семь плюс-минус два" объекта. При необходимости схожие бизнес-процессы могут быть объединены в группы или классы.

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

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

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

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

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

Основные модели и инструменты описания бизнес-архитектуры Как правило, руководители и сотрудники бизнес-подразделений находят задачу понимания архитектуры трудной и требующей слишком больших затрат времени. Действительно, за пределами служб ИТ роль и связующий фактор архитектуры предприятия зачастую не осознается, а взаимосвязи между данными являются непонятными. Поэтому архитекторы нуждаются в простых, высокоуровневых средствах описания активностей и зависимостей в терминах, которые понятны бизнес-руководителям и пользователям и которые показывают соответствия с выполняемыми ими ролями. Графические бизнес-модели являются исключительно полезными в решении этой коммуникационной проблемы. Такие модели являются идеальным способом объяснить на достаточно высоком уровне критические активности и взаимосвязи в терминах бизнеса, и при этом они не требуют знаний в области ИТ. Модели обеспечивают важную связь между бизнес-целями и стратегиями деятельности организации и многими вариантами реализации ИТ (такими как готовые пакеты программ, унаследованные приложения, специально созданные заказные приложения, обслуживание по принципу аутсорсинга и подписки). Модели бывают различных типов: модели процессов/потоков работ, функциональные модели, организационные модели, модели данных/ресурсов, временные модели типа диаграмм Ганта, модели причинно-следственных связей. Факт заключается в том, что нет "одной, самой лучшей" модели для описания бизнес-процессов. Можно провести аналогию с графиками, которые используются для иллюстраций. Круговая диаграмма с сегментами, пропорциональными по размеру проценту чего-либо целого, отлично подходит для определенных задач, но ее нельзя использовать для иллюстрации и анализа всех типов данных (например, изменений каких-то данных во времени). Точно также при анализе бизнес-процессов выбранный метод моделирования должен отражать цели анализа. Оптимизация процесса по времени и четкий анализ взаимодействия между участниками процесса могут потребовать разных моделей. Для автоматизации моделирования процессов сложился специальный класс программных продуктов. Наиболее известными являются такие продукты, как ARIS, Software Architeсt, BPWin (новое название – AllFusion Process Modeler), хотя в большом количестве случаев стандартных графических пакетов типа Microsoft Visio, текстового редактора и электронной таблицы бывает достаточно. В данном курсе мы не будем останавливаться на сравнительном анализе этих и других средств, и отсылаем читателя к специализированным публикациям. Основное внимание при разработке Бизнес-архитектуры должно уделяться "картине в целом". Целью Бизнес-архитектуры не является детальное описание деятельности предприятия. Модели, включенные в Бизнес-архитектуру, должны давать необходимый минимум сведений о ключевых функциях, процессах, бизнес-событиях и потоках информации, достаточный для процесса принятия решений, поиска новых возможностей для инноваций. Дальнейшая детализация выполняется с использованием таких инструментов, как:

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

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

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

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

Таблица 5.2. Компоненты декомпозиции функций/процессов
Основная область анализа	Результаты (артефакты) анализа	Основные вопросы
Определить границы каждой бизнес-функции Понять состав подпроцессов каждой бизнес-функции Дать основу для увязывания архитектуры информации, приложений и технологической архитектуры с бизнес-функциями	Подпроцессы основных бизнес-функций Идентификация излишних и малополезных, неэффективных активностей Требования к прикладным системам и информации	Каковы основные функции организации? Какие функции не несут в себе ценности? Какие функции пересекаются с другими бизнес-функциями?

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

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

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

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

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

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

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

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

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

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

Мы уже отмечали, что показатели эффективности являются важной составляющей бизнес-архитектуры. Например, в методике FEAF Федеральной Архитектуры США имеется отдельная, явно выделенная модель показателей эффективности.

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

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

В связи с развитием принципов сервис-ориентированной архитектуры и появлением технологически нейтрального, платформенно-независимого языка описания и выполнения бизнес-процессов BPEL (Business Process Execution Language) появилась возможность не только моделировать бизнес-процессы, но и делать их целиком или частично доступными другим системам и организациям в виде сервисов. К этому можно добавить также возможности еще одного стандарта XML Metadata Interchange (XMI) для обмена (экспорта/импорта) данных практически в любые интеграционные продукты. В совокупности это дает возможность создавать модели и репозитории бизнес-процессов для их эффективной интеграции. Более подробную информацию о новых стандартах для моделирования процессов можно найти на сайте www.bpmi.org.

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

Архитектура информации Контекст и основные элементы архитектуры информации Сегодня организации должны искать эффективные способы работы с информацией, которая поступает из самых разнообразных источников и должна быть доступна там, где это нужно, и тогда, когда это необходимо. Ситуация осложняется тем, что различные формы информации зачастую требуют специфических технологий и методов работы с ней: 1) структурированная информация (реляционные и объектные модели); 2) развивающиеся, основанные на XML стандарты для полуструктурированной информации; 3) неструктурированная информация в форме текстов, графиков, образов, сопровождаемая определенными описательными данными (метаданными и каталогами). Архитектура информации включает в себя видение, принципы, модели и стандарты, которые обеспечивают процессы создания, использования и поддержания информации, относящиеся к деятельности предприятия. Архитектура информации описывает, как информационные технологии обеспечивают в организации возможности для быстрого принятия решений, распространения информации внутри организации, а также за ее пределы, например, партнерам по бизнесу. Архитектура информации является как бы "зеркальным отражением" бизнес-архитектуры. Бизнес-архитектура отвечает на вопрос: "С учетом нашего общего видения, целей и стратегий, кто и что будет делать?" Архитектура информации отвечает на вопрос: "Какая информация должна быть предоставлена для того, чтобы эти процессы могли выполняться теми, кто их должен выполнять?" Архитектура информации включает в себя модели, которые описывают процессы обработки информации (information value chain), основные информационные объекты, связанные с бизнес-событиями, информационные потоки, принципы управления информацией. Архитектура должна описывать как те данные, которые требуются для выполнения процессов (операционные), так и аналитические данные и "контент", публикуемый на Web. Это действительно обширная задача. Приведем следующую цитату, касающуюся создания архитектуры информации в Citibank [4.14]: "В силу сложности банковских продуктов, услуг и разнообразия условий ведения бизнеса, задача разработки корпоративной модели данных заняла несколько лет. Отсутствие общекорпоративного подхода к управлению данными было слабостью банка в прошлом, но теперь у банка имеется возможность обеспечить единые стандарты обслуживания клиентов". Речь идет, конечно, об одном из крупнейших финансовых институтов мира, и большинство компаний столкнется с гораздо меньшими проблемами, но в любом случае, разработка и реализации архитектуры информации – это длительный итеративный процесс. Разработка архитектуры информации как части дисциплины архитектуры предприятия не состоит в создании структур баз данных или моделей всех данных, использующихся предприятием. Суть заключается в организации более общего описания информации, требующейся для бизнеса, а также политик и правил работы с информацией. В связи с этим следует отметить, что в контексте архитектуры предприятия более правильно говорить об архитектуре и моделях информации, а не данных, хотя эти понятия и пересекаются. Модели архитектуры информации являются более абстрактными, они используют язык бизнеса и обеспечивают контекст, который требуется для моделирования данных. Модели данных уже предполагают четкие описания структуры объектов, атрибутов, отношений между сущностями. Поэтому понятие "архитектура информации" является расширением понятия "архитектура данных". В общем, под архитектурой информации понимается процесс организации и представления значимой информации для пользователей в интуитивно-понятной форме, с использованием соответствующих средств каталогизации, навигации, пользовательского интерфейса. Этот аспект архитектуры предприятия также призван подчеркнуть позиционирование хранимой и обрабатываемой информации как стратегического корпоративного ресурса и неотъемлемой части "интеллектуального капитала" организации. Поэтому описание этой области будет дополнительно включать средства для оценки качества данных, их востребованности, учета стоимости как нематериального актива и т.п. Потребность в архитектуре информации сейчас велика как никогда. Аналитические компании, такие как META Group и Aberden, считают, что при разработке новых систем до 70% времени тратится на решение задач, связанных с идентификацией источников данных, которые должны использоваться прикладной системой, и на написание программного кода для доступа и трансформации данных [4.15]. Для большинства средних и практически всех крупных предприятий использование нескольких различных СУБД, средств управления и преобразования данных является скорее правилом, чем исключением. Кроме того, в течение последнего десятилетия мы являлись и являемся свидетелями тенденции все более широкого использования готовых прикладных систем (финансового учета, управления кадрами, управления закупками, управления продажами и т.д.), каждая из которых имеет свои модели данных. С учетом наличия и других унаследованных систем тенденция к росту количества источников данных только увеличивается. Объективными факторами, приводящими к дальнейшему усложнению проблемы, является объединение информационных систем разных предприятий как следствие слияний и поглощений, а также углубление специализации обслуживающего персонала. На рисунке 5.8 приводится пример упрощенной схемы перемещения данных в процессе работы над ними на некотором гипотетическом предприятии.

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

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

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

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

Рисунок 5.9 показывает общую картину архитектуры информации, взятую из документов описания архитектуры правительства штата Северная Каролина, США [4.17].

Рис. 5.9. Общая архитектура информации (данных) Безусловно, эта картина является далеко не полной. Она, например, не отражает наличие в организации огромного пула неструктурированной и полуструктурированной информации, которая хранится в форме текстов и образов документов, сообщений электронной почты, неявных знаний и т.д. Реализация архитектуры информации обеспечивает единый в масштабах всего предприятия доступ к определениям элементов данных, своевременный доступ к корректным данным и соответствующий уровень безопасности и защиты для всех данных. Это является основой для реализации систем поддержки принятия решений, систем обработки транзакций и аналитических систем. Для понимания архитектуры информации и того, как данные хранятся и обновляются, важно отличать типы прикладных систем, которые обеспечивают доступ к данным. Два наиболее важных типа таких систем – это системы онлайновой обработки транзакций (OLTP – Online Transaction Processing) и системы он-лайновой аналитической обработки (OLAP – Online Analitical Processing). Третий тип – системы управления неструктурированными данными (контентом). OLTP-системы применяются для выполнения критически важных, повседневных операций. Чаще всего они используются многими пользователями одновременно для ввода, обновления и извлечения данных. OLTP-системы способны выполнять атомарные бизнес-функции и четко обозначенные единицы работ – как правило, в форме одной или нескольких транзакций, выполняемых как одно целое (например, транзакция "изменение адреса клиента"). OLAP-системы используются для анализа, планирования и управления получением отчетов путем обеспечения интерактивного доступа к широкому спектру информации. В OLAP-системах обычно обрабатываются агрегированные данные для получения ответа на такие вопросы: "Сколько было потрачено на покупку офисной техники в прошлом году?", "Каков был объем продаж изделия X в городе N в первом квартале?" Данные для OLAP-систем, как правило, извлекаются из транзакционных OLTP-систем и помещаются или реплицируются в специальные базы данных – хранилища или витрины данных. Витрины данных являются специализированными хранилищами, которые ориентированы на предоставление информации, требующейся для бизнес-анализа на предприятии. Таким образом, мы можем сказать, что архитектура информации включает в себя, в частности, такие области (а также связанные с ними стандарты, руководства и пр.), как:

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

Однако окончательный набор дисциплин, связанных с архитектурой информации, определяется, в конечном итоге, потребностями предприятия. Безусловно, область архитектуры информации имеет пересечения с остальными доменами архитектуры предприятия. Типичным примером такого пересечения является стандарт XML, который имеет отношение одновременно как к архитектуре информации, так и к архитектуре приложений. Другим примером являются системы управления базами данных, которые относятся и к архитектуре информации, и к технологической архитектуре (инфраструктуре). Реализация сложных систем, таких, например, как хранилища и витрины данных, требует участия специалистов по архитектуре информации, прикладным системам и инфраструктуре. Рекомендуемыми первыми шагами на пути создания архитектуры информации являются следующие шаги [4.18]:

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

Эти шаги впоследствии будут способствовать созданию оперативного хранилища данных (ODS – Operational Data Store), которое обеспечивает стандартные процессы извлечения, трансформации и загрузки данных (ETL – Extract, Transform, Load), а также очистки данных и создания метаданных. Оперативное хранилище является краеугольным камнем для повторного, многократного использования данных, а в последующем – для создания хранилищ и витрин данных. После того как решены эти первые задачи, необходимо обеспечить такие условия, чтобы все процессы создания и доступа к информации на предприятии соответствовали разработанной архитектуре.

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

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

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

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

Одним из способов моделирования данных на логическом уровне является построение моделей "Сущности-Отношения" (ERM – Entity-Relationship Model). На физическом уровне даются точные ответы на вопросы типа: "Какие данные требуются для того, чтобы реализовать логику бизнес-процесса соответствующей прикладной системой?", "Сколько требуется различных информационных объектов (сущностей)?", "Каков набор элементов данных каждой сущности?". Физическая модель данных служит, по сути, представлением того, как данные, приведенные в логической модели, будут храниться в системе управления базами данных. Сравнительные характеристики этих уровней (с использованием идеи систематизации из [4.19] приведены в таблице 5.6.

Таблица 5.6.
Модель/уровень	Концептуальная	Модель данных	Реализация данных
Точка зрения	Бизнес-взгляд на ИТ	ИТ-взгляд на бизнес	ИТ-взгляд на ИТ
Фаза	Планирование	Анализ	Реализация
Рассматриваемые связи	Связи данных с бизнес-функциями, интерфейсами, технологиями	Связи данных с другими данными	Связи данных с системами хранения
Фокус	Сбор, обработка и использование данных	Структура данных	Объемы и степень использования данных
Это, скорее…	Искусство?	Наука?	Религия? (cледование рекомендациям вендоров)

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

Еще одним важным понятием, относящимся к архитектуре информации, которое является особенно серьезным для крупных организаций или органов государственной власти с их большим количеством достаточно независимых систем и организационных структур (на национальном, региональном или муниципальном уровнях), является управление федеративными данными и метаданными (federated data management) [4.17]. Под управлением федеративными данными понимается архитектура, которая обеспечивает управление и доступ к данным и метаданным независимо от их внутренней логической структуры и физических границ их расположения, в целях организации взаимодействия систем и различных подразделений внутри организации и с внешними организациями.

Рисунок 5.10 показывает общее видение принципов управления федеративными данными, который, в частности, положен в основу справочной модели архитектуры данных методики Федеральной архитектуры США FEAF [4.15].

Рис. 5.10. Видение принципов управления федеративными данными

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

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

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

Рисунок 5.11 иллюстрирует принципы интеграции информации на основе управления федеративными данными.

Рис. 5.11. Принципы интеграции через управление федеративными данными

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

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

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

⇐ Предыдущая 12

Дата публикования: 2014-11-29; Прочитано: 1760 | Нарушение авторского права страницы | Мы поможем в написании вашей работы!

studopedia.org - Студопедия.Орг - 2014-2025 год. Студопедия не является автором материалов, которые размещены. Но предоставляет возможность бесплатного использования (0.008 с)...