Архитектура предприятия.-7

228Глава 4. Обзор моделей и методик построения…

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

•построение функционального иерархического дерева;

•оценка качества декомпозиции и ее улучшение;

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

Шаг 3 — документирование бизнес-модели и ее распространение для верификации. Основными задачами шага являются:

•формирование отчетов по бизнес-модели;

•распространение отчетов и проведение презентации;

•сбор замечаний и предложений.

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

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

•когда функция выполняется;

•где и кем функция выполняется;

•как часто функция выполняется;

•какие улучшения возможны.

Этап «Формирование снимка организации» включает в себя следующие 3 шага: 1) планирование, подготовку и проведение интервью; 2) построение бизнес-модели; 3) анализ бизнесмодели.

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

построение детальной модели, ее анализ, формирование пакета отчетов и проведение презентации.

Целью этапа «Описание текущих систем и технологий»

является документирование всех используемых в организации системных и технологических платформ, т. е. создание так называемого каталога информационных ресурсов IRC (Information Resource Catalog), по-другому — системной энциклопедии, являющейся высокоуровневым объектом (а не детальным словарем данных).

Построение каталога информационных ресурсов включает четыре шага.

Шаг 1 — определение видов данных для IRC и проектирование форм для сбора данных. Основные задачи шага включают:

•определение видов данных по приложениям;

•определение видов данных по входам, выходам, файлам

иБД приложений;

•идентификацию технологических платформ и определение их декомпозиции по видам (например, принтеры — матричные, лазерные; языки — Си, Паскаль и т. п.);

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

•подготовку детальных инструкций по заполнению форм. Шаг 2 — сбор данных для IRC и их ввод (заполнение

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

•сбор системной документации;

•сопоставление приложений и бизнес-функций и формирование соответствующей матрицы;

•сопоставление приложений и технологических платформ

иформирование соответствующей матрицы;

•ввод информации в инструментарий.

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

На этапе «Формирование архитектуры приложений» оп-

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

Основными шагами этапа являются:

1)формирование списка потенциальных приложений (трудозатраты — 10 %);

2)определение приложений (трудозатраты — 50 %);

3)сопоставление приложений и функций (трудозатраты —

15 %);

4)анализ применимости существующих приложений (трудозатраты — 15 %);

5)анализ результатов (трудозатраты — 10 %).

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

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

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

•определение состава каждого приложения (имя, номер, цель, общее описание и возможности, бизнес-преимущества);

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

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

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

•оценка качества архитектуры приложений (понимаемость, полнота и состоятельность, прочность-устойчивость).

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

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

•определение мест размещения бизнес-функций;

•распределение данных и приложений;

•определение конфигурации технологических платформ (рабочих станций, сети, архитектуры бизнес-систем);

•оценка концептуальной технологической архитектуры. Цель третьего шага — обоснование технологических плат-

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

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

Этап «Разработка плана реализации» включает:

1)формирование последовательности реализации прило-

жений;

2)оценку трудозатрат и ресурсов, построение плана;

3)оценку стоимости и достоинств плана;

4)определение факторов успеха и рекомендаций по их достижению.

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

Основными задачами первого шага являются:

•сопоставление приложений и сущностей на основе биз- нес-функций;

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

234Глава 4. Обзор моделей и методик построения…

•формирование критериев (количественных и качественных) последовательности реализации;

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

Остальные шаги этапатрадиционны для задачи планирования.

На этапе «Заключительное планирование» осуществляет-

ся подготовка окончательного отчета по архитектуре предприятия, подготовка и проведение презентации.

Этап «Переход к реализации» включает следующие шаги: 1) планирование перехода (спецификацию целей перехода, формирование плана перехода, назначение ответственности за

переход, определение руководителя-лидера); 2) адаптацию подхода (методологии, инструменты);

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

4) чистку архитектуры (ревизию, добавление деталей и обновление);

5) изменение организационно-штатной структуры;

6) набор персонала;

7) проведение обучения;

8) введение стандартов на программирование;

9) введение процедурных стандартов;

10) разработку детальных планов по приложениям;

11) определение и утверждение даты завершения перехода. Эти шаги являются традиционными и не рассматриваются в

рамках данного учебника.

Данный подход помог многим компаниям и государственным ведомствам в организации процесса моделирования, стратегического бизнес-планирования, реорганизации деловых процессов, проектирования различных систем, выработки стандартов на данные, управления проектами. В частности, этой методикой пользовались такие организации, как Federal Express, Министерство энергетики США, Штаб Военно-воздушных сил США. Например, в Министерстве энергетики США основная фаза процесса разработки архитектуры заняла примерно 6 месяцев [1].

Если «наложить» метод EAP Спивака на модель Захмана, то можно сказать, что метод EAP является руководством по заполнению первых двух строк таблицы Захмана, которые описывают контекст архитектуры и концептуальную модель бизнеса предприятия. Проектирование систем, которое начинается с третьей строки таблицы Захмана, остается за рамками метода Спивака [1].

4.10.Краткое сравнение различных методик

Несмотря на формальное наличие стандартов в области опи-

сания архитектуры (ISO, IEEE, The Open Group и т. д.), ни одна из известных методик не имеет доминирующего положения в плане своего использования. Например, опрос, проведенный в 2003 г. Институтом разработки корпоративной архитектуры (Institute for Enterprise Architecture Developments), показал, что соб-

ственные методики использовали около 32 % организаций, модель Захмана — 20 %, остальные методики — не более 5–6 % респондентов [1]. Таким образом, основная рекомендация состоит в использовании всего лучшего, что предлагается различными методиками, с учетом их достоинств и недостатков. При этом процесс разработки архитектуры предприятия необходимо начинать с четкого осознания целей по организации бизнеса.

Из множества существующих методик и моделей разработки архитектуры предприятия модель Захмана является наиболее используемой. Она имеет безусловную ценность для архитекторов, хотя и с явными ограничениями. Для многих клеток матрицы Захмана корпоративные архитекторы определяют, в лучшем случае, шаблоны проектирования, а не продукты описания архитектуры в полном смысле этого слова. Например, в клетке на пересечении столбца «ЧТО» и строки «Физический уровень» определение архитектуры заканчивается стандартным сервером приложений. Есть также некоторые относящиеся к описанию архитектуры документы, которые непонятно куда помещать с

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

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

Сильными сторонами архитектурных методик Microsoft является их практическая близость к предметной области разработки архитектуры и эксплуатации сложных программных систем. В данных методиках реализованы командные способы организации работы при построении архитектуры предприятия. Описание представлений об архитектуре в соответствии с методиками Microsoft в какой-то мере основано на модели Захмана. Документы находятся в публичном доступе, что усиливает привлекательность данных методик для разработчиков.

Метод планирования архитектуры организации EAP так-

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

В табл. 4.6 приведены сравнительные характеристики вышеперечисленных методов и моделей построения архитектуры предприятия. На практике находят применение и другие средства представления архитектуры предприятия.

Методика Федеральной архитектуры правительства США

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