авторефераты диссертаций БЕСПЛАТНАЯ БИБЛИОТЕКА РОССИИ

КОНФЕРЕНЦИИ, КНИГИ, ПОСОБИЯ, НАУЧНЫЕ ИЗДАНИЯ

<< ГЛАВНАЯ
АГРОИНЖЕНЕРИЯ
АСТРОНОМИЯ
БЕЗОПАСНОСТЬ
БИОЛОГИЯ
ЗЕМЛЯ
ИНФОРМАТИКА
ИСКУССТВОВЕДЕНИЕ
ИСТОРИЯ
КУЛЬТУРОЛОГИЯ
МАШИНОСТРОЕНИЕ
МЕДИЦИНА
МЕТАЛЛУРГИЯ
МЕХАНИКА
ПЕДАГОГИКА
ПОЛИТИКА
ПРИБОРОСТРОЕНИЕ
ПРОДОВОЛЬСТВИЕ
ПСИХОЛОГИЯ
РАДИОТЕХНИКА
СЕЛЬСКОЕ ХОЗЯЙСТВО
СОЦИОЛОГИЯ
СТРОИТЕЛЬСТВО
ТЕХНИЧЕСКИЕ НАУКИ
ТРАНСПОРТ
ФАРМАЦЕВТИКА
ФИЗИКА
ФИЗИОЛОГИЯ
ФИЛОЛОГИЯ
ФИЛОСОФИЯ
ХИМИЯ
ЭКОНОМИКА
ЭЛЕКТРОТЕХНИКА
ЭНЕРГЕТИКА
ЮРИСПРУДЕНЦИЯ
ЯЗЫКОЗНАНИЕ
РАЗНОЕ
КОНТАКТЫ


Pages:     | 1 | 2 || 4 | 5 |

«РОССИЙСКАЯ ФЕДЕРАЦИЯ МИНИСТЕРСТВО ОБРАЗОВАНИЯ И НАУКИ ГОСУДАРСТВЕННОЕ ОБРАЗОВАТЕЛЬНОЕ УЧРЕЖДЕНИЕ ...»

-- [ Страница 3 ] --

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

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

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

Управления архитектурой дает следующий эффект:

• возросшую прозрачность ответственности и информированное делегирование полномочий;

• контролируемый риск менеджмент;

• защиту существующего актива, основанную на максимальном повторном использовании существующих архитектурных компо нентов;

• превентивный35 контроль, мониторинг и механизмы управления;

Превентивный (франц. prventif, от лат. praevenio - опережаю, предупреждаю) предупреждающий, предохранительный, опережающий действия противной стороны /БСЭ/.

PDF created with pdfFactory Pro trial version www.pdffactory.com • повторное использование процессов, концепций и компонентов во всех бизнес - структурах;

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

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

• большая акционерная стоимость, в частности, архитектура пред приятия все чаще представляет основную интеллектуальную соб ственность предприятия;

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

Ключевыми элементами архитектурного фреймворка предприятия (или фреймоворка архитектуры предприятия37) являются:

• описание результата поставки (deliverable)38, которые будут вы явлены при построении архитектуры, Видимость определяет, имеет ли один элемент системы возможность ссылаться на другой элемент, находящийся на другом уровне представления (правильнее сказать - в другом пространстве имен).

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

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

Результат поставки (Deliverable) [Выход/вход] Любой уникальный и проверяемый продукт, результат или способность оказывать услуги, которые необходимо произвести для завершения процесса, PDF created with pdfFactory Pro trial version www.pdffactory.com • описание метода, которым должны быть выявлены планируемые результаты.

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

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

В результате TOGAF может использовать любые, по своему усмотре нию, обобщенные материалы, которых в нем описаны;

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

Метод построения архитектуры (Architecture Development Method ADM) Данный метод является универсальным, поэтому он может использо ваться предприятиями в различных отраслях промышленности с различным географическим положением. Универсальность метода распространяется и на результаты поставки, используемые в нем при построении архитектуры.

Так, например, метод допускает использование практически любых эталон ных моделей, паттернов архитектуры и других архитектурных активов, раз фазы или проекта. Часто используется в более узком значении для обозначения внешнего результата поставки, т. е. результата поставки, требующего утверждения спонсором или заказчиком /PMI PMBOK/. В данном пособии переводится как «материал и результаты».

PDF created with pdfFactory Pro trial version www.pdffactory.com работанных сторонними организациями. Каждый шаг в ADM имеет ссылку на соответствующие активы, описанные в разделах Континуум предприятия и ресурсы.

Основной принцип, используемый в ADM - принцип итерационности.

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

При планировании каждой итерации ADM рекомендует оценить её по следующим параметрам:

• широта охвата предприятия;

• уровень детализации;

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

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

o активы, созданные в предыдущих итерациях ADM, o активы, доступные из других источников индустрии (дру гие структуры, модели систем, отраслевые промышленные модели и т.д.).

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

Основная структура ADM показана циклом разработки архитектуры (рисунок 4.1).

PDF created with pdfFactory Pro trial version www.pdffactory.com Рисунок 4.1 – Цикл ADM.

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

PDF created with pdfFactory Pro trial version www.pdffactory.com Рисунок 4.2 – Метод разработки архитектуры, вложенный цикл.

Ниже приводятся некоторые причины, требующие адаптации архитектуры:

• различные ресурсы, выделяемые на построение архитектуры, • возможность использования унаследованных архитектурных фреймворков, • использование ADM не только для построения архитектуры, но и для выполнения других проектов, PDF created with pdfFactory Pro trial version www.pdffactory.com • масштабы предприятия, использующего данный метод, и т.д.

Континуум предприятия (Enterprise Continuum) Как обобщенный фреймворк и метод, используемый для построения архитектуры предприятия, TOGAF служит дополнением к другим фреймвор кам, которые предназначены для работы с определенными вертикальными отраслями бизнеса, горизонтальными технологическими сферами (безопас ность или управляемость) и прикладными областями (eCommerce). Концеп ция усиления архитектурных активов называется Континуумом предприятия (Enterprise Continuum). Он устанавливает более широкий контекст TOGAF, объясняя различные типы и границы использования артефактов39, архитек туры и активов, которые могут быть получены из него и доработаны.

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

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

Артефакт (artifact) – спецификация физического элемента информации, используемого или порождаемого в процессе разработки программного обеспечения (например, им может быть внешний документ или рабочей продукт). Артефактом может быть модель, описание или программный продукт /ЮМЛ/.

PDF created with pdfFactory Pro trial version www.pdffactory.com Примером "активов предприятия" являются результаты поставки, кото рые были разработаны ранее при построении архитектуры, и которые дос тупны для многократного использования. Примером "активов в ИТ индуст рии" является широкий спектр существующих и вновь появляющихся про мышленных эталонных моделей и шаблонов архитектуры. К ним можно отнести:

• универсальные, как например, собственная Эталонная техниче ская модель TOGAF (Technical Reference Model TRM);

• специализированные для определенных ИТ областей, как, на пример, архитектура Web-сервисов или универсальная архитек тура управляемости (generic manageability architecture);

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

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

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

Сам TOGAF предоставляет две эталонные модели, которые могут быть включены конкретной организацией в Континуум предприятия: базовая ар хитектура TOGAF (TOGAF Foundation Architecture) и эталонная модель объ PDF created with pdfFactory Pro trial version www.pdffactory.com единенной информационной инфраструктуры (Integrated Information Infra structure Reference Model - III-RM).

Базовая архитектура TOGAF включает:

• TRM (Technical Reference Model – Техническая эталонная модель) уни версальных служб и функций, которая предоставляет основу для по строения более специализированных архитектур и архитектурных ком понентов;

• информационная база стандартов (Standards Information Base -SIB) информационное ядро соответствующих спецификаций и стандартов.

Эталонная модель объединенной информационной инфраструктуры (III-RM) представляет специально перепроектированную базовую архитекту ру TOGAF. Она создана для предоставления помощи в реализации архи тектур, которые создают возможность использовать и поддерживать виде ние40 информационных потоков (Boundaryless Information Flow vision).

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

Континуум предприятия служит фреймворком ("оболочка в пределах обо лочки") для классификации и определения этих активов.

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

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

Цель создания видения - структурированное описание основных требований к продукту.

В нашем случае продуктом является описание информационных потоков.

PDF created with pdfFactory Pro trial version www.pdffactory.com пользуемых архитектурных активов. Континуум архитектуры непосредст венно поддерживается Континуумом решений. В нем показаны связи между основополагающими фреймворками (например, TOGAF), общими архитек турными системами (например, III-RM), промышленными архитектурами и архитектурами предприятий. Континуум Архитектуры - полезное инстру ментальное средство, которое позволяет обнаружить общность и устранить не нужную избыточность.

Континуум решений предоставляет непротиворечивый способ описать и понять реализацию Континуума архитектуры. В нем определяются Стан дартные блоки решений (Solutions Building Blocks - SBBs) – объекты, дос тупные в организационной среде для повторного использования. Решение является результатом соглашения между клиентами и бизнес - партнерами, в котором реализованы правила и связи, определенные в пространстве архи тектуры. Континуум решений изучает общность и различие продуктов, сис тем и сервисов реализованных систем.

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

TRM (Technical Reference Model – Техническая эталонная модель) Любая техническая эталонная модель (TRM) имеет два основных ком понента:

• таксономия41 (иерархическое представление), которая определяет терминологию и предоставляет последовательное описание кон Taxonomy – таксаномия, систематика, систематическое описание, систематизация, классификация / www.multitran.ru/.

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

Термин (предложен в 1813 швейцарским ботаником О. Декандолем) длительное время употреблялся как PDF created with pdfFactory Pro trial version www.pdffactory.com цептуальной структуры и компонентов информационной систе мы;

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

Цель TOGAF TRM - представить широко принятую основную система тизацию и соответствующее визуальное представление этой таксономии.

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

В общем виде TRM можно представить (рисунок 4.3) в виде трех глав ных уровней (приложения, платформа приложений и коммуникационная ин фраструктура), соединенных двумя интерфейсами (интерфейс платформы приложений и интерфейс коммуникационной инфраструктуры ).

Эталонная техническая модель дает возможность реализовать две главные архитектурные цели:

• переносимость приложения обеспечивается интерфейсом плат формы приложения, который предоставляет стандартный метод идентификации множества сервисов платформы.

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

синоним систематики. В 60-70-х гг. XX в. возникла тенденция, определять таксономию как раздел систематик. /Социально-гуманитарное и политологическое образование. http://194.226.215.181/db/msg/ / PDF created with pdfFactory Pro trial version www.pdffactory.com Приложения Интерфейс платформы приложений Платформа приложений Интерфейс коммуникационной инфраструктуры Коммуникационная инфраструктура Многообразие Рисунок 4.3 – TRM – представление высокого уровня.

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

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

Коммуникационная инфраструктура представляет основные механиз мы, которые предоставляют услуги передачи данных между системами. Она PDF created with pdfFactory Pro trial version www.pdffactory.com включает: аппаратные и программные элементы, например, коммутаторы и маршрутизаторы;

физические линии связи;

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

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

На рисунке 4.4 приведена детализированная модель TRM.

Качество Приложения Бизнес инфраструктуры приложения Интерфейс платформы приложений Сервисы работы с графикой Сервисы функционирования в интернациональной среде Сервисы пользовательского Сервисы обмена данными Сервисы разработки ПО и сетевого менеджмента обработки транзакций Сервисы обеспечения Сервисы размещения управления данными Сервисы системного и изображением и директорий безопасности интерфейса Сервисы Сервисы Качество Качество Сервисы операционной системы Сетевые сервисы Интерфейс платформы приложений Коммуникационная инфраструктура Качество Рисунок 4.4- Детализированная схема TOGAF TRM.

PDF created with pdfFactory Pro trial version www.pdffactory.com Помимо набора компонентов, составляющих TRM, есть ряд атрибутов или качеств, которые соответствуют всем компонентам. Например, для того, чтобы служба управления была эффективной, управляемость должна быть качеством, присущим всем службам платформы, приложениям и коммуни кационной инфраструктуре. Эта концепция демонстрируется на детализиро ванной модели общей платформой «Качество».

Приложения (прикладное ПО) разделяют на две категории :

• бизнес-приложения42 - программное обеспечение, интегрирован ное в бизнес-процессы данного предприятия или же в конкрет ные отрасли промышленности;

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

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

TOGAF TRM основное внимание уделяет платформе приложений. Ее "высокоуровневой функцией" является предоставление набора прикладного программного обеспечения, продиктованного производственными потребно стями предприятия. Платформа приложений в TOGAF TRM является единст венным, универсальным, концептуальным объектом, который содержит все к этой категории ПО можно отнести: управление отчетами пациентов в медицине;

служба управления запасами в розничной торговле;

сервисы моделирования геологических данных в нефтяной промышленности.

К этой категории ПО можно отнести приложения, обладающие следующими характеристиками:

широкое распространение (как коробочное ПО);

взаимодействие системы с пользователем;

реализация на инфраструктурных сервисах;

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

PDF created with pdfFactory Pro trial version www.pdffactory.com возможные службы. В определенной целевой архитектуре платформа прило жения будет содержать только тот набор служб, который обеспечивает необ ходимый функционал.

Пакеты сервисов представлены в технологической архитектуре в форме "унифицированных блоков". При продвижении от концептуальной платфор мы приложения TRM к определенной технологической архитектуры для предприятия, ИТ архитектор должен рассматривать вопросы построения ар хитектуры, не привязываясь к множеству платформ, существующих на пред приятии. Он должен проанализировать требуемые службы для обеспечения ИТ инфраструктуры, оптимально соответствующей бизнес - потребностям предприятия, а также определить набор оптимальных унифицированных блоков решений (Solution Building Blocks - SBBs), которые составляют ре альные "платформы".

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

обмена данными;

управления данными;

работы с графикой и изображением;

функционирования в интернациональной среде;

размещения и директорий;

сетевой;

операционной системы;

разработки программного обеспечения;

обработки транзакций;

пользовательского интерфейса;

безопасности;

PDF created with pdfFactory Pro trial version www.pdffactory.com системного и сетевого менеджмента.

В качестве примера приведем сервисы, относящиеся к службе систем ного и сетевого менеджмента (System and Network Management Services):

управления пользователями;

управления конфигурированием (СМ);

управления производительностью;

доступности и защиты от ошибок и неисправностей;

управления учётом сетевых ресурсов;

управления безопасностью;

управления печатью;

управления сетью;

резервного копирования и восстановления;

управления сетевыми дисками;

менеджмента лицензий;

управления мощностями;

инсталляции программных систем;

идентификации неисправностей.

Для того, чтобы показать, что службы организованы объектно ориентированным способом, выделяется категория объектно ориентированного обеспечения сервисов (Object-Oriented Provision of Servic es). Данная категория не входит в эталонную техническую модель (TRM), так как все объектные сервисы являются составными частями сервисов, представленных выше.

Под объектом понимается идентифицируемая и инкапсулированная сущность, которая оказывает по требованию клиента одну или более услуг.

Объекты реализуют парадигму ООП, которая способствует:

модульной организации системы;

сокращению ошибок;

PDF created with pdfFactory Pro trial version www.pdffactory.com облегчению отладки.

Управление объектной службой предоставляет способы создания, по иска и идентификации объектов, что дает возможность управлять их взаимо действием в распределенной среде. Объектные службы включают: брокер за просов к объектам (Object Request Broker - ORB);

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

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

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

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

Качество сервиса определяется в TRM следующей таксономией (ие рархии терминов).

• Доступность (степень доступности для использования) включает:

управляемость - способность собрать информацию о состоянии объекта и возможность управлять этим со стоянием;

PDF created with pdfFactory Pro trial version www.pdffactory.com ремонтопригодность - способность идентифициро вать проблемы и внести корректирующие действия;

производительность - способность компоненты вы полнить задачу за приемлемое время;

надежность или устойчивость к выходу из строя;

восстанавливаемость или способность восстановить систему в рабочее состояние после сбоя;

локализация (Locatability) - способность обнаруже ния системы.

• Гарантирование (Assurance), которое включает:

безопасность или защиту информации от несанкцио нированного доступа;

целостность или гарантию того, что данные не были повреждены;

надежность или уровень доверия целостности систе мы и ее данных.

• Практичность или легкость в пользовательском управле нии, включает:

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

• Адаптируемость включает:

интероперабильность или функциональную совмес тимость в пределах одной или нескольких ИС;

масштабируемость - возможность изменения произ водительности компонента в зависимости от требо ваний окружающей среды;

PDF created with pdfFactory Pro trial version www.pdffactory.com переносимость данных, персонала, приложений и компонентов;

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

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

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

Эталонная модель интегрированной информационной инфра структуры (Integrated Information Infrastructure Reference Model – III-RM) Эталонная техническая модель TOGAF (TRM) акцентирует свое вни мание на пространстве платформы приложения. В Континууме предприятия данная модель называется «Базовой архитектурой». Эталонная модель интег рированной информационной инфраструктуры (III-RM) фокусируется на об ласти программного обеспечения приложений. В терминах Континуума предприятия данная модель называется «общей системной архитектурой».

Фактически, III-RM рассматривает подмножество терминов, определенных в TOGAF TRM. В частности, углубленно рассматриваются модули бизнес приложений и приложений инфраструктуры. Это дает возможность решить PDF created with pdfFactory Pro trial version www.pdffactory.com одну из ключевых задач, стоящих при построении архитектуры предпри ятия: создание интегрированной информационной архитектуры. При этом, для информационных потоков реализуется концепция, которая по предло женнию Jack Welch, была названа «the Boundaryless Organization»44. Приме нительно к информационным потокам она звучит, как «Boundaryless Informa tion Flow»45. Непротиворечивость информационных потоков означает: полу чение информации теми людьми, кто в ней нуждается, в нужное время, безо пасным и надежным способом, в порядке, который способствует поддержке операций, являющихся основой расширенного предприятия.

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

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

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

Chief Information Officer - директор по информационным технологиям.

PDF created with pdfFactory Pro trial version www.pdffactory.com интегрированная информация, т.е. одна и та же информация в различных системах не должна быть различной или потенциаль но противоречивой, интегрированный доступ к информации, т.е. доступ к информа ции осуществлялся в одном удобном интерфейсе.

Область продажи Техническая поддержка при реализации Внутренняя область Производство Бюджет Монтаж Область закупок Онлайн системы Обеспечение Системы планирования ERP системы Системы поддержки требований Системы Системы снабжения Рисунок 4.5 – Подход к непротиворечивости информационных потоков (порталы предприятия).

Инфраструктура, которая позволяет выполнить данные условия, назы вается «интегрированной информационной инфраструктурой». В качестве примера такой организационной инфраструктуры приведем порталы пред приятия (рисунок 4.5). Эта организация позволяет реализовать интегриро ванный доступ к информации из различных приложений масштаба предпри ятия, через удобный, с сетевой поддержкой, интерфейс. На рисунке 4.3 ин терфейсы показаны цветными сегментами в конце цилиндра.

PDF created with pdfFactory Pro trial version www.pdffactory.com III-RM - модель категорий главных компонентов, используемых для разработки, управления и эксплуатацией интегрированной информационной инфраструктурой. Она представляет собой модель ряда приложений, кото рый находится на верхнем уровне платформы приложений. Как уже отмеча лось, модель III-RM является подмножеством TOGAF TRM, но при этом рас сматриваются объекты модели немного с другой стороны. TOGAF сравнива ет различие в моделях с различными проекциями здания (рисунок 4.6). При этом вид сбоку соответствует TRM модели, а вид сверху - модели III-RM.

Качество Качество Приложения Бизнес инфраструктуры приложения Коммуникационная инфраструктура Интерфейс платформы приложений Сервисы работы с графикой в интернациональной среде Сервисы пользовательского Сервисы функционирования Сервисы обмена данными Интерфейс платформы приложений Сервисы разработ ки ПО и сетевого менеджмента обработки транзакций Сервисы размещения Сервисы обеспечения управления данными Сервисы системного и изображением Сетевые сервисы и директорий безопасност и интерфейса Сервисы Сервисы Качество Качество Сервисы операционной системы Платформа приложений Интерфейс платформы приложений Приложения Бизнес инфрастр. приложения Сервисы операционной системы Сетевые сервисы Интерфейс платформы приложений Коммуникационная инфраструктура Качество вид сбоку вид сверху Рисунок 4.6 – Различный взгляд на модель TRM.

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

PDF created with pdfFactory Pro trial version www.pdffactory.com Качество Качество Приложения Бизнес инфраструктуры приложения Коммуникационная инфраструктура Интерфейс платформы приложений Сервисы работы с граф икой в интернациональной среде Сервисы пользовательс кого Сервис ы функционирования Сервисы обмена данными Интерфейс платформы приложений Сервисы разработ ки ПО и сетевого менеджмента обработки транзакций Сервисы размещения Сервисы обеспечения у правления данными Сервисы сис темного и изображением Сетевые сервисы и директорий безопасност и интерфейса Сервисы Сервисы Качество Качество Сервисы операционной системы Платформа приложений Интерфейс платформы приложений Приложения Бизнес инфрастр. приложения Сервисы операционной системы Сетевые сервисы Интерфейс платформы приложений Коммуникационная инфраструктура Качество вид сбоку вид сверху Рисунок 4.7- Компоненты TRM, рассматриваемые в III-RM.

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

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

Модель, показанная на рисунке 4.8, включает:

• бизнес- приложения, к которым относятся:

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

PDF created with pdfFactory Pro trial version www.pdffactory.com o информационные провайдер – приложения, задача которых состоит в обеспечении ответа на клиентские запросы и в доступе к данным, которыми управляют специальные сер вера;

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

Качество Безопасность Переносимость Платформа приложений Информационные приложения-клиенты Приложения Утилиты Инструмент брокеры управления разработки Информационные провайдер-приложения Выполнение SLA Качество Политика управления Рисунок 4.8 – Обобщенная схема III-RM.

• приложения инфраструктуры состоят их двух типов приложе ний:

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

o утилиты управления, которые обеспечивают все необходи мые утилиты, чтобы понять, эксплуатировать, настраивать, PDF created with pdfFactory Pro trial version www.pdffactory.com и управлять системой реального времени, удовлетворяю щей требованиям быстро меняющегося бизнеса, способом, совместимым со стандартами среды.

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

На рисунке 4.9 показано обычное положение с информационным дос тупом кросс-функциональных команд.

Рисунок 4.9 - Выделение цилиндров данных отвечает информационным потребностям кросс-функциональных групп предприятия.

PDF created with pdfFactory Pro trial version www.pdffactory.com Информация, используемая в различных приложениях предприятия, по мнению TOGAF, является «заложником» тех приложений, в которых она ис пользуется (на рисунке это схематично показано расположением цилиндров данных в «бункерах»). Следовательно, идентификация данных (или как пока зано на схеме цилиндров данных), является первым шагом для обеспечения информационного доступа кросс-функциональным командам, или лучше сказать, первым шагом в построении интегрированной информационной ин фраструктуры.

Информационные провайдер – приложения (Information Provider Appli cations - IPA) и являются теми приложениями, которые "освобождают" дан ные из их «бункеров» (рисунок 4.10). IPA организует два вида интерфейсов:

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

специализированный интерфейс с данными конкретного приложения (справа от блока IPA).

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

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

Брокер - приложения (BA - Brokerage Applications) обращаются к ин формационным провайдер - приложениям (IPA), используя открытые интер фейсы, предоставляемые IPA. В тоже время, интегрируя информацию от множества IPA, они передают ее к информационным приложениям клиен там, используя открытый интерфейс. Брокер - приложения дают доступ к информации стратегическим партнерам предприятия.

PDF created with pdfFactory Pro trial version www.pdffactory.com Рисунок 4.10- Информационные провайдер – приложения (IPA) выде ляют данные для обеспечения открытого интерфейса к цилиндрам данных.

Рисунок 4.11- Брокер – приложения (BA) интегрируют информацию от информационных провайдер - приложений (IPA).

PDF created with pdfFactory Pro trial version www.pdffactory.com Информационные приложения – клиенты (ICA - Information Consumer Applications) предоставляют информацию конечным пользователям в нужной форме, в нужное время и защищенным способом. Текстовая или мультиме диа информация может потребоваться на различных языках и т.д. ICA под держивают связь с брокер – приложениями и провайдер - приложениями, ис пользуя, предоставляемые ими, открытые интерфейсы. Безопасность обеспе чивается через систему сетевых файерволов и/или сервисы защиты (на ри сунке 4.12 они отображается в виде кирпичных стен).

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

Как уже отмечалось выше, инфраструктура приложений (рисунок 4.4) представлена в модели двумя типами приложений: инструментарием разра ботки и утилитами управления.

В качестве инструментальных компонентов модель включает приложе ния, которые используются для моделирования, проектирования и создания интегрированной информационной инфраструктуры. III-RM описывает типы PDF created with pdfFactory Pro trial version www.pdffactory.com инструментальных средств в зависимости от их назначений: бизнес- модели рование, построение моделей проектирования, реализация и разработка, мо делирование данных, развертывание. Кроме того, описана возможность при менения единого каталога, позволяющего одному инструменту использовать данные другого. Использовать библиотеки, в которых рекомендуется хра нить ПО многократного применения, использующие стандарты оперативной среды.

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

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

OA&M (Operations, Administration, and Management – эксплуатация, админи стрирование и управления)47, качество Service Manager, управления копиро ванием и управление хранилищами данных.

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

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

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

PDF created with pdfFactory Pro trial version www.pdffactory.com • усилить влияние единой оперативной среды, • обеспечить гарантированную эффективную и непротиворе чивую передачу данных между процессами, • поддерживать быструю и эффективную разработку, развер тывание и управление приложениями.

Компонент платформы приложения включает приведенные ниже кате гории служб.

Службы разработки ПО:

• языки;

• библиотеки;

• системный реестр.

Сервисы безопасности:

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

Службы размещения и каталогов:

• каталог;

• регистрация;

• публикация/абонирование;

• обнаружение;

• обозначение;

• установление/ разрыв ссылки.

PDF created with pdfFactory Pro trial version www.pdffactory.com Эти службы предоставляют средства доступа для идентификации, оп ределения местоположения, описания и отношений данных, которые описы вают интегрированную информационную инфраструктуру.

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

Рисунок 4.13 – Положение служб размещения и каталогов в отношении с другими компонентами.

Службы взаимодействия с персоналом:

• представление;

• преобразование;

• браузер;

• метаиндексация;

• портал и персонализация.

PDF created with pdfFactory Pro trial version www.pdffactory.com Данная служба обеспечивает представление данных конечному пользо вателю в нужном формате.

Службы обмена данными:

• информационный формат;

• электронные формы (e-form);

• мгновенный обмен сообщениями;

• обмен сообщениями приложений;

• коммуникация от приложений к приложениям;

• интеграция приложения предприятия.

Службы управления данными:

• информация и данные доступа;

• карта преобразований;

• распространение запроса;

• агрегация;

• поиск;

• формирование файлов.

Дополнительные службы операционной системы включают сервисы рабочих процессов (Workflow) и сервисы посреднических событий. Данные службы запускают рабочие процессы (рисунок 4.14).

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

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

PDF created with pdfFactory Pro trial version www.pdffactory.com Компонент качества модели поддержан соответствующими сервисами.

Это дает возможность обеспечить качество работы системы в соответствии с Соглашениями об уровне услуг (SLAs - Service Level Agreements).

Рисунок 4.14 - Службам технологических процессов инициируют ин формационные потоки.

Модели построения архитектуры, построенные на парадигме «зрелости процессов» Architecture Maturity Models История развития моделей зрелости управления качеством Модели зрелости процессов впервые были описаны Филиппом Кросби в его книге «Quality is Free». Модели зрелости управления качеством, приве денные Кросби, описывают пять уровней внедрения системы управления ка чеством. Эта структура зрелости была адаптирована к производственным процессам Роном Радиком (Ron Radice) и его коллегами, работающими под руководством Уотса Хэмфри (Watts Humphrey). Уотс Хэмфри предложил свою структуру зрелости в 1986 г., добавив концепции уровней зрелости и разработав основу для их текущего использования. Ранние версии структуры PDF created with pdfFactory Pro trial version www.pdffactory.com зрелости процессов разработки, предложенные Хэмфри, описаны в техниче ских отчетах Институтом программной инженерии (SEI - Software Engeneer ing Institute), статьях и в его книге «Managing the Software Process».

Институт программной инженерии, который входит в состав Универ ситета Карнеги-Меллона (Carnegie-Mellon University - CMU), финансируе мый Министерством обороны США (Department of Defense - DoD), в 1993 г.

Опубликовал первую официальную версию Capability Maturity Model for Software (CMM) – модель зрелости процессов разработки программного обеспечения.

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


Уровень зрелости производственного процесса – это степень, до кото рой тот или иной процесс определен, управляем, измеряем, контролируем и эффективен. Зрелость подразумевает потенциал для роста продуктивности и отражает как полноту производственного процесса организации, так и посто янство, с которым организация применяет этот процесс во всех своих проек тах.

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

Концептуальная структура зрелости производственного процесса, предло женная Хэмфри еще в 1987г., упорядочивает эти стадии таким образом, что усовершенствования на каждой предшествующей стадии являются фунда ментом усовершенствований последующей стадии. Таким образом, стратегия усовершенствования, предлагаемая концептуальной структурой зрелости PDF created with pdfFactory Pro trial version www.pdffactory.com производственного процесса, обеспечивает наиболее прямой путь постоянно го улучшения производственного процесса.

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

Таблица 4.1 – Перечень моделей основанных на модели зрелости про цессов/49/ Название Описание стандарта Ориентирован на вопросы системного инжиниринга – разработку System Engineering продуктов (анализ требований, проектирование систем продукта и CMM (SE-CMM) их интеграция) и их производство (планирование производствен ных линий и функционирование) Предназначен для обслуживания чувствительных и закрытых про Trusted CMM (T граммных систем, которые требуют гарантии высокого качества CMM) ПО Сфокусирован на аспектах безопасности программной инженерии, System Security En обеспечивает безопасный процесс разработки, в том числе и безо gineering CMM пасность членов команды создателей (SSE-CMM) Рассматривает вопросы развития персонала в софтверных органи People CMM (P зациях CMM) Охватывает вопросы приобретения программных продуктов у Software Acquisition внешних организаций CMM (SA-CMM) Служит средой для интеграции усилий по разработке на всех эта Integrated Product пах жизненного цикла и со стороны каждого отдела компании Development CMM (IPD-CMM) В CMM определяются уровни зрелости процесса разработки про граммного обеспечения. Впоследствии, Институтом программной инжене рии эта модель с успехом была расширена на другие процессы. В таблице 4. представлены различные модели, разработанные на основе CMM. В качестве примера рассмотрим модель развития функциональных возможностей персо PDF created with pdfFactory Pro trial version www.pdffactory.com нала (People Capability Maturity Model - People СММ (СММ персонала)), направленную на решение вопросов организации процессов управления и развития персонала. Р-СММ помогает организациям охарактеризовать воз можности их практик. На рисунке 4.15 представлено пять уровней модели, а в таблице 4.2 приводится описание основных процессов на каждом уровне зрелости.

Практическое применение стандартов серии CMM показало следую щие недостатки:

• сложное одновременное внедрение различных модификаций CMM;

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

• спрос на сертифицированные организации породил предложение по «быстрой и безболезненной сертификации».

Рисунок 4.15 – Модель P-CMM.

http://www.sei.cmu.edu/cmm-p/version2/ PDF created with pdfFactory Pro trial version www.pdffactory.com Таблица 4.2 – Уровни модели P-CMM Уровень Фокус Ключевые процессы Непрерывное усовершенствование Развитие индивидуальной ком Оптимизационн методов развития компетентность петентности ый на уровне организации и на ин- Переподготовка кадров дивидуальном уровне Постоянные инновации персо нала На основе количественных пока- Менторство Управляемый зателей управлять организацион- Создание группы ным ростом менеджерских спо- Практика коллективной работы собностей людей и групп, объе- Управление компетентностью в диненных по уровню компетент- организации ности Согласование производитель ности в организации Определить основные компетен- Анализ знаний и навыков Определенный ции, требуемые в организации, и Планирование трудовых ресур управления трудовыми ресурсами сов на основе этого. Развитие компетентности Профессиональное развитие Практика, основанная на ком петентности Развитие общей культуры Привить персоналу основные пра- Производственные условия Повторяемый вила дисциплины труда Коммуникация Комплектование персоналом Контроль производительности Обучение Оплата Начальный Для решения этих проблем Институт программной инженерии разра ботал интегрированную модель CMM – Capability Maturity Model Integrated (CMMI). Стандарт CMMI создавался с целью интеграции существующих ва риантов CMM, что давало возможность исключить какие-либо противоречия при его практическом применении в различных сферах деятельности высоко технологичных компаний.

PDF created with pdfFactory Pro trial version www.pdffactory.com Большая популярность перечисленных выше моделей инициировала работу, направленную на разработку фреймворков, основанных на идеях Ф.

Кросби и У. Хемфри. В качестве примера, можно привести, как минимум три модели, реализующие парадигму «зрелости процессов» в области по строения архитектуры.

• NASCIO Enterprise Architecture Maturity Model /52/ (NASCIO EAMM) - модель зрелости построения архитектуры уровня пред приятия. Разработана национальной ассоциацией CIO49 США (National Association of State Chief Information Officers - NASCIO) • A Framework for Assessing and Improving Enterprise Architecture Management (EAMMF) /50/ – Фреймворк оценки и совершенствования архитектуры уровня предприятия. Модель представлена Главным бюджетно-контрольным управлением США (U.S. Government Accountability Office - GAO).

• IT Architecture Capability Maturity Model (ACMM) – модель зре лости процессов построения ИТ архитектуры. Модель разработа на и поддерживается Министерством торговли США (United States Department of Commerce – US DoC)/51/.

Первые фреймворки относятся к области построения архитектуры уровня предприятия, а последний фреймворк (ACMM) – к области ИТ архи тектуры. ACMM состоит из трех секций:

• Модель зрелости архитектуры ИТ (DoC IT Architecture Maturity Model);

• Характеристика процессов рабочих подразделений ИТ архитек туры на различных уровнях зрелости;

• Оценочная ведомость модели зрелости процессов построения ИТ архитектуры.

CIO - директор по информационным технологиям PDF created with pdfFactory Pro trial version www.pdffactory.com Первые две секции описывают уровни зрелости процессов построения архитектуры и соответствующие характеристики ИТ архитектуры для каждо го уровня зрелости.

ACMM – Модель уровней зрелости архитектуры ACMM состоит из шести уровней и девяти характеристик архитектуры.

Определены следующие уровни зрелости процессов построения архитектуры:

0. Неопределенный (None).

1. Начальный (Initial).

2. В процессе разработки (Under Development).

3. Определенный (Defined).

4. Управляемый (Managed).

5. Измеряемый (Measured).

Определены девять характеристик ИТ архитектуры:

1. Процесс архитектуры50.

2. Построение архитектуры.

3. Взаимозависимость с бизнесом.

4. Вовлечение высшего руководства.

5. Участие рабочего подразделения.

6. Обмен информации.

7. Безопасность ИТ.

8. Управление.

9. Инвестиции в ИТ и стратегия приобретения.

Существует дуализм термина «архитектура». С одной стороны «архитектура – это описание некоторой сложной системы в определенный момент времени», а с другой стороны «архитектура – это процесс, т.е. набор руководств, правил и/или стандартов, который применяется в процессе построения новых систем /17/. Иногда, чтобы подчеркнуть, что речь идет о процессе, используется оборот «процесс архитектуры».

PDF created with pdfFactory Pro trial version www.pdffactory.com В секции 3 используются два дополнительных метода для вычисления рейтинга зрелости рабочего подразделения. С помощью первого метода ра бочее подразделение получает средневзвешенную оценку уровня зрелости.

Во втором методе определяют каждую из девяти характеристик в процентах, в соответствии с уровнями зрелости. На основе полученных данных получа ют оценку уровня зрелости ИТ архитектуры.

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

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

PDF created with pdfFactory Pro trial version www.pdffactory.com 0. Неопределенный Не определены действия.

1. Начальный (выполняется неофициальный процесс архитектуры ИТ В стадии реализа ции) Характеристики Описание Процесс архитектуры Процессы являются случайными и ограниченными. Определены некоторые процессы ИТАрхитектуры ИТ. Для различных технологий или бизнес - процессов нет унифицированного архитектурного процесса. Успех зависит от индивидуальных Построение Процессы, документация и стандарты ИТ архитектуры, установ архитектуры ленные множеством случайных средств. Они ограничены или неофициальны.

Взаимозависимость с Установлена минимальная или неявная связь с бизнес – страте бизнесом гиями и со стимулами бизнеса Вовлечение высшего Ограниченное понимание менеджерской группой или ограничен руководства ное участие в процессах создания архитектуры.


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

Управление. Не существует никакого явного управления архитектурными стандартами.

Инвестиции в ИТ и Персонал стратегического планирования и приобретения редко стратегия приобрете- и/или вообще не вовлекается в процесс построения архитектуры ния предприятия. Исполнение стандартных профилей практически не соблюдается PDF created with pdfFactory Pro trial version www.pdffactory.com 2. В процессе разработки (разработка процесса архитектуры) Характеристики Описание Процесс архитектуры Основная ИТ программа процесса архитектуры оформлена в соответствии с Руководством OMB Circular A -130 Министерства торговли. Процесс архитектуры определил ясные роли и обязанности.

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

Установлена эталонная техническая модель и стандартный профиль фреймворк.

Взаимозависимость с Установлена явная связь со стратегией предприятия.

бизнесом.

Вовлечение высшего Управление понимает объем работы по созданию архитектуры.

руководства Участие рабочего Назначены обязанности и работа находится в стадии реализации.

подразделения.

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

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

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

PDF created with pdfFactory Pro trial version www.pdffactory.com 3. Определенный (Определение архитектура ИТ, включая детально описанные процедур и эталонной технической модели) Характеристики Описание Процесс архитектуры Архитектура выбрана оптимально, обязанности рабочих подразделений ИТ доведены до сведения, как ИТ работников, так и до управления предприятием. Процесс сопровождается в значительной степени.

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

Идентифицированы цели и методы ИТ. Архитектура согласована с DoC и федеральной архитектурой предприятия.

Взаимозависимость с Архитектура ИТ интегрирована с генеральным планом и инвести бизнесом. ционным контролем и поддерживает электронное правительство.

Вовлечение высшего Группа высшего руководства знает и одобряет процесс архитекту руководства ры в масштабах предприятия. Управление активно поддерживает архитектурные стандарты.

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

Обмен информации. Документы архитектуры обновляются регулярно на Web страницы архитектуры ИТ.

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

Управление. Явное задокументированное управление большинством ИТ инве стиции.

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

PDF created with pdfFactory Pro trial version www.pdffactory.com 4. Управляемый (Управляемый и измеряемый процесс архитектуры ИТ) Характеристики Описание Процесс архитектуры Процесс архитектуры ИТ - часть культуры. Зафиксированы каче ственные показатели, связанные с процессом архитектуры.

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

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

Участие рабочего Все рабочие подразделения воспринимают и активно участвуют в подразделения. процессе архитектуры ИТ.

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

Безопасность ИТ Зафиксированы показатели производительности, связанные с ар хитектурой безопасности ИТ.

Управление. Явное управление всеми инвестициями ИТ. Формализована об ратная связь отклонений в управлении к архитектуре ИТ.

Инвестиции в ИТ и Планируются все ИТ приобретения, покупки управляются и оп стратегия приобрете- ределяются в соответствии с архитектурой ИТ.

ния PDF created with pdfFactory Pro trial version www.pdffactory.com 5. Измеряемый (Оптимизация - непрерывное усовершенствование процесса архитектуры ИТ) Процесс архитектуры Прилагаются совместные усилия для оптимизирования и непре рывного улучшения процесса архитектуры.

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

Взаимозависимость с Чтобы оптимизировать и управлять согласованием с бизнесом бизнесом. используются метрики процесса архитектуры. Бизнес вовлечен в процесс непрерывного усовершенствования ИТ архитектуры.

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

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

Обмен информации. Документация архитектуры ЛПР используется для принятия ре шений, связанных с ИТ.

Безопасность ИТ Используется обратная связь по метрикам архитектуры безопасности ИТ, для управления совершенствованием процесса архитектуры.

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

Инвестиции в ИТ и Отсутствуют незапланированные инвестиции в ИТ или действия стратегия приобрете- при приобретении.

ния PDF created with pdfFactory Pro trial version www.pdffactory.com NASCIO EAMM – Модель уровней зрелости архитектуры предпри ятия /52/ Данный фреймворк разработан с целью создания адаптивной архитек туры предприятия. Построение такой архитектуры обосновано следующими требованиями:

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

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

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

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

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

PDF created with pdfFactory Pro trial version www.pdffactory.com Рисунок 4.16 - Жизненный цикл архитектуры предприятия и ее компо нентов.

Enterprise Architecture Development Tool-Kit V2.0 фреймворка архитек туры предприятия определяют три высокоуровневых компонента, которые обеспечивают правила и форм-факторы рабочего проекта интеграции ин формации и сервисов. Компоненты содержат большое количество элементов, каждый из которых в любое время может быть рассмотрен на различном уровне зрелости. Ниже приведены эти высокоуровневые компоненты.

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

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

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

Технологическая архитектура обеспечивает процессы и шаблоны до кументирования продуктов и критерии согласования, используемые в преде лах организации. Технологическая архитектура включает части фреймворка архитектуры предприятия, которые задают руководящие принципы по ис пользованию и внедрению ИТ сервисов. Архитектура предприятия гаранти PDF created with pdfFactory Pro trial version www.pdffactory.com руют, что технические решения выполняют бизнес - потребности организа ции.

Как некоторые отдельные детали, рассматриваемые на уровне пред приятия, так и различные дисциплины архитектуры, включают следующие компоненты:

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

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

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

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

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

Интеграция - способность различных объектов (внутренних или внешних) координировать свои усилия для получения большего эффекта.

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

PDF created with pdfFactory Pro trial version www.pdffactory.com Участие должно быть частью программы архитектуры предприятия.

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

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

Модель EAMM NASCIO определяет шесть уровней зрелости, подобно моделям, описанным выше51. Каждый уровень зрелости содержит утвержде ния, которые характерны для программы архитектуры предприятия на этом уровне. Утверждения организованы в следующие категории архитектуры предприятия:

администрирование - роли управления и их обязанности;

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

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

рабочий проект - коллекция фактических стандартов и специфи каций;

коммуникация - обучение и распространение АП и деталей рабо чего проекта;

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

PDF created with pdfFactory Pro trial version www.pdffactory.com интеграция – точка общения процессов управления в АП;

участие - поддержка программы АП во всей организации.

Уровень 0 Категории Описание категорий Нет программы.

администрирован Нет управления архитектурой Нет зарегистрированного архитектурного фрейм ворка. Решения разработаны без знания стандар стью уверена в разобщенных знаниях сотрудни ков. Несколько групп решают одну и ту же про тов и практических основ. Организация полно ие планирование Нет плана разработки архитектуры предпри ятия фреймворк Архитектурные процессы и шаблоны не за регистрированы рабочий проект Стандарты ИТ технологий не зарегистриро ваны коммуникация Высшее руководство не знает об архитекту ре предприятия и ее задачах согласование Процесс согласования не работает интеграция нет программ – нет интеграции блему участие Нет программы, в которой кто-либо участ вует PDF created with pdfFactory Pro trial version www.pdffactory.com Уровень 1 Категории Описание категорий Неофициаль ная программа Администри- Потребность в комитетах для определения стандартов и ально. Есть общее согласие, что эти шаги должны быть выполнены, однако они не могут быть прослежены Основные архитектурные фреймворки и стандарты были определены, но обычно выполняются неофици и сопровождаться. Организации со структурой Архитектуры Предприятия на этом уровне - все еще зави рование идентификации процессов Планирование - Определена необходимость построения архитектуры предприятия, - Действия в АП являются неофициальными и неструк турированными Фреймворк - Процессы непродуманны и не являются официальны ми, процесс сопровождения, возможно, противоречив, - Нет унифицированного процесса архитектуры для раз личных технологий и бизнес - специализаций Рабочий про- Документация бизнес - факторов, технологических сит от знаний индивидуальных сотрудников.

ект стандартов и т.д. Является неофициальной и непоследо вательной Коммуникация -Существует потребность в большем понимании АП, - Редкое обсуждается процесс АП или возможное усо вершенствование его процессов Согласование - Идентифицирована потребность согласования стан дартов - Согласование выполняется неофициально и неструкту рированно - Согласование не может эффективно измеряться, т.к.

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

Некоторые группы не поддерживают усилия и могут вы звать волнение в организации PDF created with pdfFactory Pro trial version www.pdffactory.com Уровень 2 Категории Описание категорий Повторяем ая программа Админист- - Установлена необходимость управления архитектурой повторно используются шаблоны. Согласована необходимость соответствия продуктов и компонентов стандартам Основная архитектура и стандарты были определены, прослеживаются и проверяются. В процессах программы рирование - В программе АП определены роли и их обязанности - Начинают формироваться комитеты по управлению Планирова- - Организация начала разрабатывать видение архитектуры ние предприятия и требованиям. Используются показатели для мониторинга производительности процессов.

- Организация начала идентифицировать задачи АП и тре бования к ресурсам.

- Выбрана методология и начата разработка плана про граммы АП Фреймворк - Зарегистрирована основная программа АП - Процессы планируются и прослеживаются - Организация начинает итерационно применять методы для того, чтобы фиксировать критическую информацию АП Рабочий - Идентифицированы бизнес - факторы и стратегическая проект информация - Определена необходимость сохранения АП в репозитории и распространении зафиксированной информации Коммуни- - Потребность в архитектуре предприятия доводится до кация сведения Высшего руководства - Начинают появляться или развиваться действия по осоз нанию АП Согласова- - Организация начала создавать процесс согласования, что ние позволит гарантировать совместимость проектов и расши рений функционала со стандартами АП Интеграция - Идентифицирована потребность интеграции в программ ный фреймворк АП (Процесс жизненного цикла архитек туры) - Были выявлены различные точки соприкосновения меж ду процессами управления и программными фреймворками АП (однако, нет никаких подробностей относительно того, как интеграция будет осуществляться) Участие - Организация начала разрабатывать планы по проведению обучения и организации учебных материалов, с целью дос тижения понимания АП и ее процессов - Начинают вводиться понятия АП, а также более последо вательно обсуждаются эти вопросы в обычных ежедневных встречах PDF created with pdfFactory Pro trial version www.pdffactory.com Уровень 3 Категории Описание категорий Определен ная програм ма Админист- - Определены комитеты по управлению архитектурой, а также ванные версий шаблонов. Процессы, проходящие через организацию, задокументированы. Показатели производи Структура архитектуры предприятия хорошо определена;

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

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

- Действия АП выполняются согласно определенному плану Фреймворк - Жизненные циклы архитектурных процессов были определе ны и зарегистрированы - Настраиваются универсальные процессы архитектуры для ис пользования агентствами, отделами и т.д.



Pages:     | 1 | 2 || 4 | 5 |
 





 
© 2013 www.libed.ru - «Бесплатная библиотека научно-практических конференций»

Материалы этого сайта размещены для ознакомления, все права принадлежат их авторам.
Если Вы не согласны с тем, что Ваш материал размещён на этом сайте, пожалуйста, напишите нам, мы в течении 1-2 рабочих дней удалим его.