Файл: Учебное пособие по дисциплине итинфраструктура предприятия (курс лекций) Направление подготовки 38. 03. 05 Бизнесинформатика.pdf

67

внутренние и внешние технологические факторы;

общее видение архитектуры предприятия;

высокоуровневые принципы построения частных архитектур по бизнес - областям (доменам).
В методологии Gartner архитектурный процесс разбит на четыре основные фазы, в рамках каждой из которых выполняется определенных набор ша- гов (Tasks). Структура архитектурного процесса представлена ниже (Ри- сунок 13).
Рисунок13. Enterprise Architecture Process Model

Фаза 1. Инициализация (Phase I — Initiation).
Шаг 1. Организация архитектурного процесса (Organize Archi-
tecture Effort) является первым шагом по разработке архитектуры пред- приятия и включает в себя организацию необходимой структуры проекта с привлечением необходимых специалистов (включая топ менеджмент компании) и представителей бизнес подразделений, планирование и ини- циацию работ. Архитектура предприятия должна использоваться для при- нятия решений по инвестициям и организационным изменениям. Поэтому важно, чтобы работы по архитектуре были хорошо организованы и обес- печены необходимыми ресурсами, а ее цели и результаты соответствовали требованиям бизнеса.
Шаг 2. Анализ ситуации на предприятии (Analyze Enterprise
Context). При разработке архитектуры предприятия следует знать кон- текст, в котором рассматривается компания. Поэтому важным для всего процесса является мониторинг существующих тенденций, как в отрасли работы компании (Телекоммуникации), так и в области развития инфор- мационных технологий, а также понимание стратегии развития бизнеса компании.
Анализ ситуации на предприятии включает в себя два основных на- правления:

Окружающие тенденции (Environment Trends). Любая операция предприятия зависти от огромного количества постоянно изменяющихся,

68 как внутренних, так и внешних факторов. Соответственно, для эффектив- ной работы предприятия необходимо оценить существующие тенденции.
К таким факторам можно отнести: общую экономическую ситуацию и по- литическую обстановку, состояние отрасли и уровень продаж. Кроме того, в архитектуре предприятия необходимо учитывать современные техноло- гические тенденции, как в производственной сфере, так и в области ин- формационных технологий.

Бизнес - стратегия (Business Strategy) предприятия описывает основные цели и этапы развития предприятия. Архитектуру предприятия можно назвать механизмом, позволяющим сформулировать и показать все изменения, происходящие на предприятии в соответствии с появлением новой бизнес - стратегии.
На основе результатов анализа выявляются основные Business Driv- ers – 10-15 формулировок, описывающих, как компания намерена разви- вать свой бизнес, какие у нее ожидания и какие имеются возможности.

Фаза 2. Определение Целевой архитектуры (Future State
Architecture “Architecting”).
Разработка целевой архитектуры является одним из самых важных элементов архитектурного процесса. Цель данной фазы в том, чтобы представить бизнес - стратегию компании в виде набора руководств и правил, которые можно использовать предприятием в проектах по изме- нению структуры бизнеса.
Шаг 3. Разработка требований (Develop Requirements). На дан- ном этапе разрабатывается документ, описывающий основные требова- ния, предъявляемые к предприятию в соответствии с их стратегическими целями. Документ, разрабатывающийся на данном этапе, может не полно- стью отображать всю бизнес - стратегию компании. Его задача заключает- ся в выработке общего понимания и набора требований, согласованных со стратегическим целями компании.
Шаг 4. Разработка принципов (Develop Principles) – включает в себя выработку набора основных правил, обеспечивающих создание, раз- работку архитектуры предприятия в соответствии с бизнес - стратегией компании. Принципы документируют общие инструкции, правила, кото- рые должны быть использованы предприятием для корректного достиже- ния поставленных перед ним целей и задач. Их можно рассматривать как инструмент управления, упрощающий принятие решений в определенные моменты времени.
Шаг 5. Разработка моделей (Develop Models) включает в себя де- тализированную проработку каждого из архитектурных слоев (EBA, EIA,
ESA, ETA). Естественно, детализированное моделирование всех элемен- тов, обеспечивающих функционирование предприятия, не представляется целесообразным.

69
На данном шаге происходит разработка шаблонов (framework), в хо- де которой выделяются основные, наиболее важные элементы моделиро- вания. Разработка моделей происходит в соответствии с этими шаблонами для раскрытия наиболее актуальных в настоящее время вопросов.
По мнению аналитиков Gartner начинать разработку с создания мо- делей является неправильным. Разработка моделей начинается в соответ- ствии с концептуальными принципами построения архитектуры конкрет- ного предприятия, заложенными на первых шагах. Основу для них со- ставляют простые общие описывающие схемы.
На первых этапах данного шага создаются высокоуровневые модели для каждого архитектурного слоя. Более детализированные модели соз- даются по мере их необходимости.

Фаза 3. Разработка текущей архитектуры (Current State
Architecture).
Шаг 6. Документирование (Documenting). Текущая архитектура описывает текущее (исторически сложившееся) состояние предприятия.
Документирование и определение текущего состояние организации явля- ется необходимым процессом, позволяющим подготовить необходимый материал для GAP анализа. При документировании текущей архитектуры необходимо:

Подготовить начальную базу для сравнения с целевой архитек- турой.

Определить дублирующиеся и зависимые друг от друга эле- менты информационных систем.

Обеспечить процесс непрерывного документирования инфор- мации по всем элементам информационных систем.
По мнению аналитиков Gartner нужно избегать без лишней необхо- димости детализированного документирования всех элементов ИС. Мно- гие проекты построения архитектуры предприятия оказались неэффектив- ными именно по этой причине.
Разработка целевой архитектуры должна предшествовать разработке текущей архитектуры. Разработка документации, описывающей текущее состояние, должна быть основана на будущих тенденциях и давать ответ на основные вопросы о приложениях, архитектуре и стандартах.

Фаза 4. Проведение GAP анализа (Closing the Gap).
Шаг 7. GAP анализ (Analyze Gaps) является одним из важнейших шагов архитектурного процесса, который стремится идентифицировать различия между целевой и текущей архитектурой. GAP - анализ является критически важным, с точки зрения определения ключевых шагов и необ- ходимых изменений, в направлении целевой архитектуры. На этом этапе

70 происходит оценка бизнес - требований, технологических потребностей, существующей информации и приложений.
При проведении GAP анализа выполняются следующие шаги:

Проведение классификации всех существующих элементов на категории.

Выделение различий между текущим состоянием и целевой ар- хитектурой.

Создание списка несоответствий между текущей и целевой ар- хитектурой с разделением по категориям.

Группировка идентифицированных несоответствий по уровню их влияния на предприятие.
Шаг 8. План миграции (Plan Migration). В соответствии с резуль- татами GAP анализа разрабатывается документ, определяющий набор проектов, которые необходимо выполнить организации для приведения текущей архитектуры в соответствие целевой. Происходит выделение наиболее приоритетных проектов в соответствии с их уровнем влияния на предприятие.
В ходе разработки плана миграции происходит идентификация уже имеющихся возможностей информационных систем и технологического оборудования, которые могут быть использованы для решения появив- шихся проблем.
Разработка плана миграции включает в себя:

Направление развития бизнес-процессов и информационных технологий в среднесрочный и долгосрочный периоды времени.

Принципы реализации, определяющие «правила» внесения из- менений в структуру предприятия.

Динамичность - планирование изменений с учетом постоянно- го изменения технологий и совершенствованием организационной струк- туры предприятия.
План миграции является результирующим документом архитектурного процесса и описывает набор необходимых изменений (проектов) для при- ведения текущей архитектуры в соответствие целевой.
В заключение, следует отметить, что методика Gartner является в на- стоящий момент одной из наиболее универсальных и может использо- ваться не только для коммерческих предприятий, но и для государствен- ных структур (Рисунок14).

71
Рисунок 14. Gartner Framework для государственных структур
TOGAF
TOGAF (The Open Group Architecture Framework) – архитектурная методика, разработанная некоммерческим объединением the Open Group, позиционируется как «средство для разработки архитектур информацион- ных систем». При разработке архитектуры методология TOGAF отталки- вается от «программной инфраструктуры информационных систем», т.е. идет снизу «от железа», вверх к приложениям и бизнес-процессам.
Первая версия этой методики опубликована в 1995 году. В настоя- щее время на сайте Open Group (
www.opengroup.org
) представлена вось- мая (8) версия данной методики. Сегодня TOGAF является одной из са- мых популярных и рекламируемых на западе методик построения архи- тектуры предприятия. На сайте Open Group можно найти информацию о различных сертификационных программах для специалистов разного уровня, обширный перечень курсов и семинаров по всему миру.
Architecture Development Method (ADM) – методика, описывающая про- цесс разработки архитектуры и включающая в себя следующий набор стандартных шагов:

Подготовка: уточнение модели под особенности организации, определение принципов реализации проекта.

Фаза A: Architecture Vision: определение границ проекта, раз- работка общего представления архитектуры, утверждение плана работ и подхода руководством.

Фаза B: Business Architecture: разработка бизнес - архитектуры предприятия.

Фаза C: Information System Architectures: разработка архитекту- ры данных и архитектуры приложений.

Фаза D: Technology Architecture: разработка технологической архитектуры.

Фаза E: Opportunities and Solutions: проверка возможности реа- лизации предложенных решений.

72

Фаза F: Migration Planning: планирование и переход к новой системе.

Фаза G: Implementation Governance: формирование системы управление преобразованиями.

Фаза H: Architecture Change Management: управление измене- нием архитектуры.
Foundation Architecture (базовая архитектура) – с точки зрения методологии TOGAF является некоторой моделью, описывающей состоя- ние информационных технологий на предприятии, и включает в себя не- сколько типов детализации (рисунок 15)
Базовая архитектура
Архитектура общих систем
Отраслевая архитектура
Архитектура организации
Рисунок 15. Иерархия описаний архитектур TOGAF
Базовая архитектура (Foundation Architectures) – содержит набор служб и стандартов, является некоторой абстрактной реализацией ИТ сис- темы, в целом.
Архитектура общих систем (Common Systems Architectures) реа- лизуется путем выбора и интеграции определенных служб для формиро- вания выделенных блоков, которые могут (возможно, повторно или в раз- личных комбинациях) использоваться в различных функциональных об- ластях, таких, как архитектура безопасности, сетевая архитектура и т.п.
Отраслевая архитектура (Industry Architectures) – включает в се- бя специфичные для каждой индустрии модели данных, приложения, стандарты, бизнес-правила, а также, при необходимости, процедуры взаи- модействия различных отраслевых систем между собой.
Архитектура организации (Organization Architectures) – описыва- ет архитектуру ИТ систем конкретного предприятия, учитывающая все его особенности, в том числе наличие унаследованных систем, планы и возможности реализации, организацию данных на физическом уровне.
Основу TOGAF составляют принципы, которые являются фундамен- том для построения всей архитектуры предприятия. Принципы, как пра- вило, включают в себя основные системные требования и критерии оцен- ки различных решений. Примерный набор принципов, удовлетворяющий методологии TOGAF описан в книге «архитектура и стратегия » Данилина
А. и Слюсаренко А. и представлен в таблице 3.

73
Таблица 3.
Архитектурные принципы (TOGAF)
Название
Содержание
Простота ис- пользования
Сформулированные принципы управления ИТ применимы для всех случаев и подразделений организации.
Максимальная польза
Решения в области ИТ принимаются исходя из максимума пользы для организации в целом.
Привлечение всех
Управление информацией есть дело каждого
Непрерывность бизнеса
Деятельность предприятия должна обеспечиваться, несмотря на возможные помехи в работе ИТ
Общее исполь- зование
Предпочтение должно отдаваться разработке или внедрению приложений, применимых в масштабах всего предприятия, а не отдельных его подразделений.
Соответствие закону
Управление ИТ не должно противоречить применяемому за- конодательству и принятым регламентам, однако это не есть препятствие к оптимизации бизнес процессов компании.
Ответственность
ИТ – службы
ИТ служба является ответственным владельцем ИТ ресур- сов.
Данные являют- ся активом
Данные в ИС предприятия имеют определенную ценность и должны соответствующим образом управляться, быть об- щими и доступными для пользователей с учетом их прав доступа.
Обеспечение ка- чества.
Каждый элемент данных должен иметь ответственного за их качество и корректность.
Общие метадан- ные
Метаданные должны быть едиными в рамках предприятия и доступными для всех пользователей.
Безопасность данных
Данные должны быть защищены от неавторизованного ис- пользования и распространения.
Технологическая независимость
Прикладное ПО не должно зависеть от специфичных моде- лей оборудования и системного ПО.
Простота ис- пользования
Приложения позволяют сконцентрироваться на выполнении бизнес - задач за счет единого интерфейса, минимизации специфики работы, интеграции систем, снижения вероятно- сти неправильного использования.
Взаимодействие Компоненты программного и аппаратного обеспечения должны обеспечивать интеграцию между собой в соответст- вии с общими стандартами.
Минимизация разнообразия
Уменьшение числа различных вариантов применяемых платформ, продуктов и версий.
Модель «4+1» представления архитектуры
Модель «4+1» была предложена Филиппом Кручтеном (Philippe
Kruchten) в 1995 году и была ориентированна на построение информаци- онных систем различного уровня сложности. Считается, что данная мето-

74 дика позволяет внедрять не только информационные системы, но разраба- тывать архитектуру предприятия.
В основе методики заложено разделение процесса проектирования системы на пять логических уровней соответствующих уровням абстрак- ции при проектировании систем (рисунок 16).
Представление уровня разработки
Физическое представление
Логическое представление
Процессное представление
Сценарии
Системные интеграторы
Производительность
Масштабируемость
Системные инженеры
Топология
Коммуникация
Разработчики
Управление разработкой ПО
Функциональность с точки зрения конечного пользователя
Рисунок 16. Модель 4+1
Логическое представление – описывает архитектуру и функцио- нальность с точки зрения конечного пользователя. Является объектной моделью проектирования. Основу этого уровня составляет описание функциональных требований.
Процессное представление – описывает модель с точки зрения сис- темных интеграторов и оперирует такими понятиями, как производитель- ность и «масштабируемость». Включает вопросы параллельного исполне- ния и синхронизации процессов. Учитывает некоторые нефункциональ- ные требования к системе, включая производительность и доступность.
Физическое представление – это взгляд системного инженера на архитектуру, включающий, в первую очередь информацию о топологии и коммуникациях. Описывает размещение программно-аппаратных средств и физическое расположение приложений.
Представление уровня разработки - это уровень разработчиков программного обеспечения, включающий информацию об управлении разработкой программного обеспечения (ПО). Описывает статическую ор- ганизацию ПО в среде разработки.
Сценарии – уровень, объединяющий все элементы в единое целое.
На этом уровне описывается последовательность взаимодействия объек- тов и процессов, отражающих наиболее важные требования.

75
Стратегическая модель архитектуры SAM
Стратегическая модель архитектуры SAM (Strategic Architecture
Model) является инструментом, обеспечивающим анализ и документиро- вание архитектуры предприятия.
В основе методики заложена нотация «сфер интересов». Нотация описывает набор основных объектов, обеспечивающих функционирование предприятия, связанных между собой (рисунок 17).
Цели и задачи
Организация
Бизнес процессы
Прикладные системы
Бизнес функции
Инфра- структура
Данные
Проекты
Технологии
Бизнес компоненты
Стабильные сферы
Динамичные
сферы
Подвижные сферы
Рисунок 17. Стратегическая модель архитектуры SAM
SAM является надстройкой модели Захмана, обеспечивающей об- щий анализ и документирование всей информации по архитектуре пред- приятия. Методика позволяет легко систематизировать информацию, имеющую отношение к основным объектам архитектуры.
В методике SAM выделяется три категории сфер:

Стабильные. Эти сферы включают в себя набор объектов, из- менения в которых растягиваются на длительные промежутки времени и, как правило, являются дорогостоящими.

Подвижные. Эта область описывает, легко изменяемые объек- ты. При этом, их модернизация может привести к существенным эффек- там для бизнеса компании. Эти сферы могут находиться в процессе посто- янных изменений (например, новые релизы ИС).

Динамичные. Сферы, которые задают направление бизнеса и претерпевают постоянные изменения. Они описывают основные области, в которых работает предприятие и усилия, требующиеся для достижения целей и задач.
Методики Microsoft
При рассмотрении архитектурных методик построения архитектуры предприятия нельзя не затронуть методики крупных поставщиков про- граммно - аппаратного обеспечения. Следует отметить, что набор методик

76
Microsoft в настоящий момент ориентирован на разработку конкретных программных прикладных систем и создание технологической инфра- структуры (рисунок 18).
В настоящий момент выделяют следующий набор методик:

Microsoft Solution Framework (MSF) – Как правильно создавать системы?

Microsoft Operational Framework (MOF) – Как правильно экс- плуатировать технологическую инфраструктуру?

Microsoft System Architecture (MSA) – Как правильно создавать технологическую инфраструктуру?

Microsoft Solution for Management (MSM) - Как правильно строить процессы управления технологической инфраструктурой?
Microsoft Operational
Framework
Как правильно эксплуатировать технологическую инфраструктуру?
Microsoft Solution Framework
Как правильно создать ИТ системы?
Microsoft System Architecture
Как правильно создавать технологическую архитектуру?
Microsoft Solution for
Management
Как правильно строить процессы управления технологической инфраструктурой?
Эксплуатация
Внедрение
Планирование
Подготовка
Рисунок 18. Методики Microsoft
Методики Microsoft можно рассматривать, как детализированный набор технических методик, обеспечивающих оптимальную архитектуру
информационных систем, соответствующую требованиям бизнеса. Та- ким образом, их можно использовать, как эффективный инструмент, до- полняющий другие методологии, такие как модель Захмана или GEAF.