Добавил:

ivanov666 Опубликованный материал нарушает ваши авторские права? Сообщите нам.

Вуз:

Башкирский Государственный Аграрный Университет

Предмет:

[НЕСОРТИРОВАННОЕ]

Файл:

Проектирование сложных бизнес-объектов на основе системного анализа. Монография

.pdf

Скачиваний:

Добавлен:

08.09.2026

Размер:

2 Мб

Скачать

☆

<<< < Предыдущая 1 2 3 4 5 6 78 / 158 9 10 11 12 13 14 15 > Следующая >>>

Разработка моделей для различных доменов архитектуры является итерационным процессом, который связан с рассмотрением различных уровней абстракции, а также связей между отдельными моделями доменов архитектуры. Эти модели описывают архитектуру предприятия на различных уровнях абстракции, которые соответствуют «взглядам» на предприятие различных категорий людей. По мере того, как создаются более детальные описания доменов архитектуры, будут разрабатываться более детальные модели бизнес-процессов, вместо списка бизнес-сущностей будут создаваться семантические, логические и физические модели данных (рисунок 4.1, [6]).

4.3 Методологии построения архитектуры предприятия

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

− непосредственно архитекторам предприятия, занимающихся форми-

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

− системным архитекторам, ответственным за формирование архитек-

туры отдельных информационных систем;

− бизнес-аналитикам, отвечающим за процесс проектирования органи-

зационных структур и бизнес-процессов;

− проектировщикам информационных систем, вовлеченным в проекты

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

− и другим.

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

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

− модель Захмана;

− метод формирования архитектуры организации EAP (Enterprise

Architecture Planning) Стивена Спивака;

− TOGAF (The Open Group Architectural Framework);

− методика META Group;

− методология Gartner;

− для государственных организаций существуют специальные методи-

ки, такие как разрабатываемая при поддержке правительства США Федеральная Архитектура Госорганизаций (FEAF – Federal Enterprise Architecture Framework) или используемая в Министерстве Обороны США DoDAF (Department of Defence Architecture Framework).

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

Модель Захмана (John A. Zachman)

В 1987 году в журнале IBM Systems Journal была опубликована статья Дж.А.Захмана «Структура архитектуры информационных систем», в которой был изложен вариант обобщенной схемы для описания и анализа архитектуры предприятия. В 1992 году предложенная модель была расширена и уточнена. Де-факто модель Захмана стала стандартом и применяется на большинстве предприятий.

В основе схемы Захмана лежит следующая идея: деятельность даже очень большой организации можно описать, используя ответы на простые вопросы – зачем, кто, что, как, где и когда – и разные уровни рассмотрения. Модель представляет собой матрицу 6х6, в которой в каждой ячейке указывается собственный тип описания свойств предприятия (рисунок 4.2).

Еще философ Древнего Рима Квиантилиан утверждал, что любую сколь угодно сложную ситуацию можно полностью структурировать и описать, руководствуясь следующими семью вопросами: что? где? когда? кто? почему? с какой целью? при каких условиях?

Таким образом, можно простить Захману нескромность, когда он в интервью он-лайновому журналу «Enterprise Architect Online» сравнил свою модель с периодической таблицей элементов Менделеева и назвал ее «периодической таблицей описательных представлений предприятия или двумерной системой, схемой классификации».

Столбцы описывают аспекты деятельности предприятия и имеют сле-

дующее значение:

− «ЧТО делается» – объекты/данные;

− «КАК делается» – функции/процессы;

− «ГДЕ делается» – размещение или инфраструктура;

− «КТО делает» – люди, организационные единицы;

− «КОГДА делается» – графики событий и работ;

− «ЗАЧЕМ делается» – стимулы, мотивы и стратегии деятельности.

Контекст

Модель бизнеса

Системная модель

Технологическая модель

Детальное представление

Работающая организация

ЧТО

Данные

Вещи,

значимые

для бизнеса

Бизнес-

сущности и

их связи

Концепту-

альная модель данных

Физическая

модель данных

Специфика-

ции

форматов

данных

Данные

КАК

Функции

Основные

бизнес-

процессы

Модели

бизнес-

процессов

Архитектура

приложений

Архитектура программно-

аппаратной

системы

Код

программных

компонентов

Выполняе-

мые

функции

ГДЕ

Расположение

География

бизнеса

Система

логистики

Архитектура

распредели-

тельной

системы

Технологическая

архитектура

Спецификации

архитектуры

сети

Географическое расположение и

сети

Рисунок 4.2. Модель Захмана

КТО

Люди

Важные для

бизнеса

организации

Модели потоков

работ

Архитектура

пользовательского

интерфейса

Архитектура

представ-

ления

Специфи-

кация ролей

и прав

доступа

Структура

организации

КОГДА

Время

События и

периоды,

важные для

бизнеса

Базовый

график

работ

Структура обработки

событий

Структура

циклов

управления

Спецификаци

и обработки

событий и

прерываний

Планы

ПОЧЕМУ

Мотивация

Цели и

стратегия

бизнеса

Бизнес-план,

частные цели

и стратегии

Модель

бизнес-правил

Модель

правил

обработки

событий

Спецификаци

и правил

работы

системы

Стратегия и

тактика

Строки имеют следующее значение:

− Строка 1 «Контекст» (Моделирование бизнес-функций) – представ-

ление организации в окружении внешних факторов;

− Строка 2 «Модель бизнеса» (Модели бизнес-процессов) – представ-

ление бизнес-процессов внутри организации;

− Строка 3 «Системная модель» (Логические модели) – бизнес-

процессы описываются в терминах информационных систем, включая различные типы данных, правила их преобразования и обработки;

− Строка 4 «Технологическая модель» (Физические модели, определе-

ние и разработка решения) – инженерное представление, осуществля-

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

− Строка 5 «Детальное представление» – рабочие конфигурации;

− Строка 6 «Работающая организация» (Функционирование организа-

ции и оценка).

Для строк Захман применил аналогии с классическим архитектурным делом и строительством [51]. Верхняя строка матрицы фиксировала представление «планировщика застройки», который рассматривает не одно здание, а все его окружение и то, как в это окружение вписывается здание. Вторая строчка фиксировала представление «владельца дома», третья – представление дизайнера, четвертая – того, кто будет руководить собственно строительными работами, пятая – взгляд тех, кто будет выполнять отдельные работы, а шестая относилась к эксплуатации дома. Посредством этой аналогии для архитектуры предприятия задавались представления предприятия с позиций бизнеса, аналитиков-проектировщиков ИС, а также их разработчиков.

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

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

Модель Захмана также послужила основой для создания целого ряда других методик и моделей описания архитектуры предприятия, таких как Федеральная Архитектура США (FEAF – Federal Enterprise Architecture

Framework), Методика описания архитектуры Open Group (TOGAF – The Open Group Architecture Framework), Методика описания архитектуры министерства обороны США (DoDAF – Department of Defence Architecture Framework) [6].

Enterprise Architecture Planning

В основе метода EAP (Enterprise Architecture Planning), разработанного Стивеном Спиваком, лежит процесс планирования архитектуры организации, ориентированный на создание архитектуры для поддержки бизнеса организации (на основе того, какие конкретно данные, приложения и технологии наиболее полно отвечают ее потребностям). ЕАР декларирует 10 этапов, определяющих состав и структуру слоев и элементов архитектуры, а также план ее проектирования, обеспечивающий реализацию как традиционных требований к архи-

тектуре, так и специфических требований конкретной организации (Таблица

4.1).

Таблица 4.1. Этапы планирования архитектуры

Номер уровня Название этапа Результаты

Уровень 1 Инициация планирова-

ния

Уровень 2 Предварительное бизнес-

моделирование

Формирование снимка организации

Описание текущих систем и технологий

Уровень 3 Формирование архитек-

туры данных

Формирование архитектуры приложений

Формирование технической архитек-

Уровень 4 Разработка плана реали-

зации

Цели, видение, методологии, инструментарий, команда, презентации, рабочий план

Организационно-штатная структура, предварительная функциональная бизнесмодель

Полная функциональная бизнес-модель

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

Определение сущностей, ER-модель, матрица сущности-функции, отчет по архитектуре данных

Определение приложений, матрицы приложений, анализ покрытия, отчет по архитектуре приложений

Распределение данных/приложений, отчет по технологической архитектуре

Последовательность, план перехода, цены и преимущества, факторы успеха и рекомендации

[55]:

Заключительное планирование

Переход к реализации совершенствование политик, стандартов,

Окончательный отчет, презентация

процедур, детализация проектных планов

Эти этапы организованы в виде следующей четырехуровневой схемы

− уровень 1 (исходная позиция) – выработка решений, которые необхо-

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

− уровень 2 (анализ текущего состояния) – определение точки отсчета

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

− уровень 3 (планируемая перспектива) – определение технических де-

талей перспективной архитектуры (данные, приложения и технологии);

− уровень 4 – формирование плана реализации перспективной архитек-

туры.

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

Модель TOGAF

Методика описания архитектуры TOGAF (сокращение от The Open Group Architecture Framework) принадлежит консорциуму The Open Group. TOGAF позиционируется ее авторами не как некоторая эталонная модель, а как «средство для разработки архитектур информационных систем». Основное на-

значение – ускорить и облегчить процесс разработки архитектуры конкретной организации, обеспечивая при этом возможность будущего развития [6].

В модели TOGAF архитектура предприятия делится на четыре категории:

1) архитектура бизнеса – описывает процессы, используемые для дос-

тижения бизнес-целей;

2) архитектура приложений – описывает структуру конкретных прило-

жений и их взаимодействие друг с другом;

3) архитектура данных – описывает структуру корпоративных храни-

лищ данных и процедуры доступа к ним;

4) технологическая архитектура – описывает инфраструктуру оборудо-

вания и программного обеспечения, в которой запускаются и взаимодействуют приложения.

В состав модели TOGAF входят две основные компоненты – методика ADM (Architecture Development Method), определяющая процесс разработки архитектуры, и базовая архитектура (Foundation Architecture). Она дополняется соответствующей базой данных ресурсов, включающей описания архитектурных принципов, примеров реализации, а также специализированный язык

ADML.

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

− подготовка: уточнение модели под особенности организации, опреде-

ление принципов реализации проекта;

− фаза A: определение границ проекта, разработка общего представле-

ния (Vision) архитектуры; утверждение плана работ и подхода руководством;

− фаза B: разработка бизнес-архитектуры предприятия;

− фаза C: разработка архитектуры данных и архитектуры приложений;

− фаза D: разработка технологической архитектуры;

− фаза E: проверка возможности реализации предложенных решений;

− фаза F: планирование перехода к новой системе;

− фаза G: формирование системы управления преобразованиями;

− фаза H: управление изменением архитектуры.

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

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

Базовая Архитектура, в свою очередь, включает:

− набор наиболее общих служб и функций, объединенных в Техниче-

скую Эталонную Модель (Technical reference model – TRM);

− набор элементарных архитектурных элементов, которые используют-

ся как «строительные блоки» при построении конкретных решений;

− база данных стандартов (Standards Information Base).

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

Методика META Group

Как отмечают [6], отличительной особенностью методики META Group является более детальное и формализованное описание именно процесса разработки архитектуры и всех его составляющих. Архитектурная методика META

Group включает следующие предметные области (или домены):

1) бизнес-архитектура (EBA – Enterprise Business Architecture);

2) архитектура информации (EAI – Enterprise Information Architecture);

3) технологическая архитектура (EWTA – Enterprise Wide Technical Ar-

chitecture);

4) портфель прикладных систем предприятия (EAP – Enterprise Applica-

tion Portfolio).

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

«Видение общих требований» (CRV – Common requirements Vision) и «Принци-

пы концептуальной архитектуры» (CA – Conceptual Architecture) [6].

Согласно META Group создание архитектуры предприятия включает в себя три этапа (рисунок 4.3):

− Этап 1 представляет собой процесс разработки видения общих требо-

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

− Этап 2 заключается в разработке концептуальной архитектуры, ос-

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

− Этап 3 состоит в разработке плана реализации, обеспечивающего

движение в соответствие с желаемой траекторией развития архитектуры предприятия.

требований

Этап 1: Разработка видения общих

Рисунок 4.3. Организация рабочего процесса разработки архитектуры согласно META Group

архитектуры

Этап 2: Разработка концептуальной

Этап 3: Разработка плана реализации

Модель Gartner

Модель Gartner сформулирована в виде четырех связанных, взаимозави-

симых и усложняющихся уровней [6]:

1) среда бизнес-взаимодействия;

2) бизнес-процессы и стили бизнес-процессов;

3) шаблоны;

4) технологические строительные блоки.

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

4.4 Процесс построения архитектуры предприятия

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

К сожалению, ни одна из существующих методик или стандартов не является однозначным руководством к действию: каждому предприятию придется искать свой собственный путь. Однако, данные методики довольно успешно дополняют друг друга. В [6, 98] приведены сравнительные характеристики наиболее распространенных методологий построения архитектуры предприятия. И для многих компаний оптимальный выбор заключается в использовании всех методологий, смешанных в пропорциях, которые наилучшим образом отвечают условиям самой организации.

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

Еще необходимо учесть следующее: на практике построением архитектуры предприятия занимаются различные группы специалистов. Так, аналитики Gartner выделили четыре группы процессов, которые выполняются различными командами специалистов [92]:

− Тактическая архитектура (Tactical Architecture) – включает в себя ар-

хитектуру локальных проектов, выполняющихся в соответствии с

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

− Тактическая архитектура предприятия (Enterprise Tactical

Architecture) – координирует все проекты предприятия, обеспечивает

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

− Стратегическая архитектура (Strategic Architecture) – обеспечивает

планирование проектов в масштабах всего предприятия и соответствие между стратегией развития предприятия и изменениями в его архитектуре.

− Зрелая архитектура предприятия (Mature Enterprise Architecture) —

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

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

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

<<< < Предыдущая 1 2 3 4 5 6 78 / 158 9 10 11 12 13 14 15 > Следующая >>>

Соседние файлы в предмете [НЕСОРТИРОВАННОЕ]