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

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

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

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

1. Блок элементарных объектов организации, а именно:
1. описания (представления) элементарных объектов (например, конкретного продукта/услуги, производимого организацией в настоящее время);
2. средства, используемые для порождения таких представлений (т.е. данных по объектам) согласно определенным правилам (например, ERP, SCM, CRM, СУБД).
2. Блок моделей архитектуры организации, а именно:
1. собственно модели различных видов (процессно-функциональные, информационные, ресурсные, организационные и другие), состоящие из элементов, абстрактно отображающих элементарные объекты;
2. средства моделирования, обеспечивающие анализ, проектирование и использование моделей.
3. Блок языков и методологий моделирования, включая:
1. общемодельные конструкции;
2. процессы моделирования архитектуры организации;
3. средства, поддерживающие процесс определения и модификации методологий и языков.
4. Блок языков мета-моделирования и методологий определения методологий моделирования (мета-методологий), соответственно, для описания концепции, синтаксиса и семантики языков моделирования, и методологий их применения, а также для описания процессов построения этих языков и методологий.

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

1. определение бизнес-целей и требований, охватывающих направления бизнеса, миссию, цели, критические факторы успеха, критические бизнес-результаты, видение, выявление требований различных типов (функциональных, системных, технологических) и их документирование;
2. моделирование бизнеса с позиции менеджера, включающее построение концептуальных диаграмм с использованием графических образов (пиктограмм) для представления бизнес-объектов и событий;
3. моделирование бизнес-процессов;
4. моделирование бизнес-функций;
5. моделирование оргструктуры, включая ее нисходящую логическую схему, а также логические схемы принятия решений;
6. моделирование репсурсов;
7. преобразование бизнес-моделей в модели приложений и технологической архитектуры.

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

1. универсальные интегрирующие среды (например, Zachman Framework, GERAM),
2. языки моделирования организаций (например, семейство IDEF, DFD-технология, ARIS, BPML),
3. программные среды моделирования (например, ARIS 6 Collaborative Suite, Popkin System Architect, METIS, Casewise Corporate Modeler),
4. мета-модели и языки мета-моделирования (например, UML Profile for Business Process Definition, UEML).

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

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

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

Среда Zachman Framework базируется на методе Захмана, широко известном в мировой практике. Суть этого метода сводится к формализованному представлению модели организации в виде матрицы. В строках этой матрицы показываются различные представления архитектуры организации с использованием различных типов моделей. Для простоты понимания эти представления соотносятся с категориями специалистов, определенным образом связанных с деятельностью любой организации (например, " владелец" организации, проектировщик, разработчик и субподрядчик). По столбцам матрицы разнесены основные аспекты деятельности (объекты - " что", действия - " как", местоположения - " где", люди - " кто", время - " когда" и мотивы - " почему"). Структура этой матрицы приведена в таблице 2.1.

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

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

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

Конкурирующая среда GERAM (Generalised Enterprise Reference Architecture and Methodology) определяет комплекс концепций, методов и моделей, необходимых для проектирования и сопровождения современной организации (любого типа) в течении всего времени ее существования. GERAM обеспечивает поддержку всех вышепредставленных элементов среды моделирования архитектуры, базируясь при этом на:

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

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

Следует отметить, что в настоящее время прослеживается тенденция к обогащению подходов в части покрытия среды моделирования, например, одна из последних разработок университета г.Бордо GRAI Integrated Methodology (GRAI-GIM) обеспечивает референсную модель с концепцией, языком, графическим формализмом и инженерным методом реализации методологии

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

Так основными недостатками семейство IDEF являются:

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

ARIS в целом преодолевает перечисленные недостатки IDEF, однако его методология по сути является методологией-оболочкой: нет четко описанных регламентов действий, не предлагается уникального подхода к проблеме моделирования архитектуры организации. Сам язык включает более 100 типов моделей, 90% из которых для целей архитектурного моделирования практически никогда не используются, инструментальная поддержка осуществляется продуктом той же компании – разработчика методологии. Этот продукт имеет цену, на порядок превышающую стоимость инструментов аналогичного класса для аналогичных платформ, и огромные трудозатраты на его разработку, что вряд ли позволит создать когда-либо конкурирующий инструментарий, поддерживающий данный язык.

Одной из последних разработок в данной области является создание специального языка, ориентированного на моделирование бизнес-процессов BPML (Business Process Modeling Language). Этот язык обеспечивает построение абстрактной исполняемой модели взаимодействующих процессов на основе концепции конечного автомата (машины конечных состояний). BPML представляет бизнес-процессы посредством объединения описания взаимодействий управляющих потоков, потоков данных и потоков событий с дополнительными ортогональными средствами моделирования бизнес-правил, ролей, контекста взаимодействия. Он поддерживает синхронные и асинхронные распределенные транзакции, поэтому может быть использован как исполняемая модель для встраивания существующих приложений в качестве процессных компонент внутрь е-бизнес-процессов.

Собственно бизнес-процессы описываются с использованием BPMN (Business Process Modeling Notation), обеспечивающего графическую нотацию для описания процессов BPD (Business Process Diagram), а также внутренние связи между элементами нотации и внешние связи с конструкциями других компонентов BPML (в частности, с конструкциями BPEL4WS - Business Process Execution Language for Web Services). Отметим, что BPMN обеспечивает моделирование не только бизнес-процессов, но и веб-сервисов как между организациями, так и между подразделениями организации.

BPD-диаграммы моделирует события бизнес-процессов организации, концентрируя основное внимание на том, где процессы выполняются и где события имеют место. Эти диаграммы включают следующие основные объекты:

1. события перед запуском процесса;
2. активности (бизнес-процессы, бизнес-функции, бизнес-операции);
3. конечные результаты выполнения процесса;
4. информационные объекты (данные, документы и т.п. - все, что обновляется при выполнении процесса), привязанные к потокам;
5. специальные узлы (шлюзы) для моделирования ветвлений;
6. специальные объекты (плавательные дорожки и бассейны), используемые для уточнения модели и демонстрации того, в какой организационной единице происходит событие или процесс, с целью визуального разделения обработки потоков по организациям и организационным единицам (например, организация – бассейн, организационные единицы – дорожки).

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

Этапы моделирования с использованием BPML определяются методологией BEM (Business Enterprise Modeling) и включают:

1. Определение бизнес-целей и требований:
1. определение направлений бизнеса (включая миссию, цели, критические факторы успеха, критические бизнес-результаты, видение, ключевые бизнес-политики), установление целей деятельности организации и преобразование их в цели бизнес-процессов, достижение которых должно обеспечиться в результате их проектирования;
2. построение набора матриц, покрывающих все аспекты бизнес-моделирования, но предшествующих детальному анализу (например, выражение бизнес-целей через организационные цели, формулирование стимулов достижения требуемого бизнес-поведения, увязка с приложениями, обеспечивающими достижение целей);
3. выявление требований различных типов (функциональных, системных, технологических) из различных источников (документы, интервью и т.п.) и их документирование.
2. Моделирование бизнеса с позиции менеджера: построение концептуальных потоковых бизнес-диаграмм с использованием графических образов (пиктограмм) для представления бизнес-объектов и событий.
3. Моделирование бизнес-процессов с помощью BPMN
4. Моделирование бизнес-функций с помощью диаграмм функциональной иерархии (дерева функций) с дополнительным использованием перекрестных ссылок по процессам (либо с помощью таблиц, либо напрямую на диаграмме).
5. Моделирование организационно-штатной структуры (кто что делает, кто перед кем отчитывается, как принимаются и исполняются решения и т.д.) с использованием:
1. логических схем организационно-штатной структуры (Logical Organizational Chart) сверху-вниз по организационным единицам;
2. логических схем принятия решений (Logical Decision Chart) на основе двух типов объектов: организационных единиц и потоков движения решений.
6. Отображение бизнес-моделей в приложения с использованием DFD-технологии.

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

Решением данной проблемы занимается рабочая группа, созданная компаниями – производителями языков моделирования, целью деятельности которой является создание унифицированного языка моделирования UEML (Unified Enterprise Modeling Language) с четко определенными синтаксисом, семантикой и правилами взаимоотношений (отображений) между различными языками моделирования архитектуры организаций. Проект UEML включает разработку:

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

В настоящее время рынок инструментальных средств архитектурного моделирования достаточно развит, в таблице 2.2 приведен перечень лидирующих по объемам продаж пакетов (в алфавитном порядке по вендорам - в среднем, каждый из вендоров осуществляет продажи программного обеспечения на сумму от 7 до 15 миллионов долларов в год):

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

В основе инструмента лежит методология «Casewise Framework», базирующаяся на модифицированной схеме (матрице) Захмана, столбцы которой характеризуют различные аспекты ЕА (мотивации, процессы, люди, местоположения, данные, время), а строки соответствуют уровням абстракции моделирования (бизнес, организация, системы, технологии, детали). При этом методология позволяет расширять предложенную схему, в частности, может быть увеличено количество уровней абстракции. Дополнительно на начальном этапе могут использоваться модели " Инициация проекта" и " Определение стандартов моделирования", определяющие, соответственно, цели, задачи, факторы успеха, ключевые роли и документы, а также нотации моделирования (типы диаграмм и их синтаксис, типы и категории объектов и т.п.).

Основными графическими нотациями являются организационные диаграммы (организационно-штатная структура и ее связи с бизнес-слоем и ИТ-слоем), диаграммы потоков данных (функциональные модели), диаграммы " сущность-связь" (информационные модели), диаграммы динамики процессов (модели поведения), а также матрицы межобъектных связей. В качестве расширений могут использоваться нотации языков IDEF0 и UML, а также нотация BPMN (Business Process Modeling Notation) – основа современного языка моделирования бизнес-процессов BPML (Business Process Modeling Language), являющего в настоящее время стандартом де-факто в рассматриваемой области.

Важным компонентом методологии является возможность применения (и адаптации под специфику конкретной организации) референсных моделей. В частности, имеется возможность использования модели федеральной архитектуры США FEA (Federal Enterprise Architecture), включающей в себя следующие компоненты:

1. Perfomance Reference Model;
2. Business Reference Model;
3. Service Component Reference Model;
4. Data& Information Reference Model;
5. Technical Reference Model.

Также имеется референсная модель процессов ITIL (IT Infrastructure Library), описывающая предоставляемые ИТ-услуги, включая техническую поддержку, управление приложениями, безопасностью, а также планирование и мониторинг внедрения ITIL. Соответствующие диаграммы отражают все компоненты ИТ-инфраструктуры: ресурсы, базы данных, приложения и оборудование.

Еще одной референсной моделью является eTOM (The Enchanced Telecom Operation Map) - модель деятельности телекоммуникационных компаний, воплощающая собой весь опыт мирового сообщества, накопленный в этой отрасли. Модель eTOM применяется в качестве основы организации работ при проектировании и оптимизации архитектур телекоммуникационных компаний, она может быть интегрирована с моделью ITIL.

Одним из достоинств методологии является возможность интеграции не только бизнес-слоя и ИТ-слоя, но и стратегического слоя архитектуры. Для этой цели предлагаются методики и инструменты управления ИТ-инфраструктурой организации (IT Architecture Accelerator) и ее стратегией на основе системы сбалансированных показателей (Balanced Scorecard Accelerator). Так, например, с помощью IT Architecture Accelerator можно управлять проектом реализации ИТ-стратегии: осуществлять оценку проектов, устанавливать их приоритеты по степени срочности, важности и стратегической значимости, планировать сроки и осуществлять контроль за их реализацией.

В качестве репозитария, непосредственно реализующего интеграцию, используется как собственная база данных DP4 Corporate Modeler Suite, так и другие СУБД - Oracle, MS SQL.

В заключении отметим, что решения Casewise обладают возможностью интеграции с инструментом управления требованиями IBM-Rational RequsitePro, объектно-ориентированными инструментами разработки IBM-Rational Rose, инструментами моделирования баз данных Oracle Designer, Sybase PowerDesigner и ERWin.

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

Данный раздел посвящен описанию одного из наиболее известных методов формирования архитектуры организации EAP (Enterprise Architecture Planning), разработанного Стивеном Спиваком (детальное описание метода изложено в книге: Steven H. Spewak. Enterprise Architecture Planning. N.Y.: John Wiley& Sons Inc., 2003).

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

ЕАР декларирует 10 этапов (таблица 2.3), определяющих состав и структуру слоев и элементов архитектуры, а также план ее проектирования, обеспечивающий реализацию как традиционных требований к архитектуре, так и специфических требований конкретной организации. Эти этапы организованы в виде следующей четырехуровневой схемы EAP (рис. 2.2):

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

Рис. 2.2. Схема EAP.

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

1. Назначение первого шага состоит в формальном определении области и целей планирования архитектуры для понимания участниками проекта того, что будет достигнуто. К его результатам относятся перечень согласованных и утвержденных целей, а также список причастных к проекту подразделений организации. Основными задачами шага являются:
1. обзор организации и определение ее контекста (системных входов/выходов);
2. оценка благоприятствующих и неблагоприятствующих проекту характеристик организации (например, существующие информационные системы не отвечают требованиям и дороги в сопровождении, существует необходимость в интеграции и распределении данных, имеются в наличии неуспешные ИТ-проекты по причинам ограничения менеджмента по времени и бюджету и т.п.);
3. формирование перечня и определений целей и их достижимости;
4. формирование перечня подразделений, затрагиваемых грядущими изменениями ИТ-стратегии и корпоративной культуры.
2. Целью шага 2 является исследование организации, системных входов/выходов и вариантов на основании встреч с менеджментом. Результатами являются согласованное и утвержденное видение организации, а также политическая поддержка менеджмента. Основными задачами шага являются:
1. изучение всех исходных материалов по бизнесу (заказчики, продукты, сотрудники, цели и т.д.);
2. определение влиятельных персон, для которых необходима архитектура;
3. анализ организаций, успешно выстроивших свои архитектуры;
4. формирование видения организации, демонстрирующего ИТ-среду, обеспечивающую достижение целей.
3. Целью шага 3 является адаптация методологии планирования и создание руководства по методологии. Основными задачами шага являются:
1. формулирование принципов и требований к методологии;
2. оценка существующих в организации методов и стандартов;
3. изучение имеющихся на рынке подходов;
4. принятие решения об исполнителе (внутренние ресурсы или внешний консультант);
5. создание методологии, отвечающей нуждам данной организации;
6. разработка содержания каждого из отчетов, создаваемого на каждом из последующих этапов.
4. Целью шага 4 является наведение порядка с компьютерными ресурсами и оценка инструментария создания ЕА. Основными задачами шага являются:
1. определение требований к инструментарию;
2. определение требований к аппаратуре;
3. оценка альтернатив для репозитария проекта;
4. выбор и приобретение подходящего программного инструментария;
5. разработка регламентов и процедур, обеспечивающих надлежащее использование продуктов;
6. разработка проектов отчетов, экранных форм и т.п.;
7. оценка трудозатрат на " канцелярскую" поддержку большого объема документации по ЕА;
8. доведение решений по инструментарию до всех подразделений – потенциальных пользователей ЕА
5. Цель данного шага – создание проектной команды. Основными задачами шага являются:
1. определение квалификационных требований по каждой из фаз создания ЕА;
2. оценка трудозатрат по каждой фазе создания ЕА;
3. определение необходимого числа участников;
4. спецификация ролей и областей ответственности каждого члена команды;
5. подбор персонала;
6. обучение персонала (методологии и инструментарий);
7. выбор внешних консультантов, включая определение направлений их использования.
6. Целями шагов 6 и 7 являются подготовка рабочего плана и его презентация и утверждение. Основные задачи этих шагов традиционны, их рассмотрение выходит за рамки настоящей книги. В результате должен быть сформирован рабочий план и утвержден бюджет выполнения работ.

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

Предварительная бизнес-модель идентифицирует функции, дает их описания и идентифицирует организационные единицы – исполнителей функций. По оценкам ряда экспертов этап " Предварительное бизнес-моделирование" требует 25-30% всех трудозатрат на моделирование, он осуществляется в 3 шага:

1. Шаг документирования организационной структуры в качестве результатов имеет обновленные организационные схемы, перечень ролей и мест их выполнения, оценку количества сотрудников по ролям. Основными задачами шага являются:
1. формирование (редактирование) организационных схем и фиксация их в инструментарии;
2. идентификация деятельностей в разрезе организационных единиц;
3. формирование отчетов по полученным результатам.
2. Шаг определения структуры бизнес-модели (идентификации и определения бизнес-функций) в качестве результатов имеет определенные функции, каждая из которых:
1. имеет имя;
2. имеет краткое описание или декомпозирована на подфункции;
3. является результатом работы по крайней мере одной организационной единицы.

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

1. определение основных деятельностей и бизнес-процессов;
2. функциональная декомпозиция процессов;
3. развитие функциональной декомпозиции до уровня бизнес-операций;
4. построение функционального иерархического дерева;
5. оценка качества декомпозиции и ее улучшение;
6. сопоставление функций и исполняющих их организационных единиц, построение соответствующей матрицы.
1. Целью третьего шага является документирование бизнес-модели и ее распространение для верификации. Основными задачами шага являются:
1. формирование отчетов по бизнес-модели;
2. распространение отчетов и проведение презентации;
3. сбор замечаний и предложений.

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

1. Какая информация используется при выполнении функций?
2. Когда функция выполняется?
3. Где и кем функция выполняется?
4. Как часто функция выполняется?
5. Какие улучшения возможны?

Этап " Формирование снимка организации" включает в себя следующие 3 шага:

1. планирование, подготовка и проведение интервью;
2. построение бизнес-модели;
3. распространение и анализ бизнес-модели.

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

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

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

1. Целью первого шага является определение видов данных для IRC и проектирование форм для сбора данных. Основные задачи шага включают:
1. определение видов данных по приложениям;
2. определение видов данных по входам, выходам, файлам и БД приложений;
3. идентификация технологических платформ и определение их декомпозиции по видам (например, принтеры – матричные, лазерные; языки – кобол, фортран и т.п.);
4. проектирование форм для сбора данных;
5. подготовка детальных инструкций по заполнению форм.
2. Целью второго шага является сбор данных для IRC и их ввод (заполнение форм), а также сопоставление приложений и функций. Основные задачи шага включают:
1. сбор системной документации;
2. сопоставление приложений и бизнес-функций и формирование соответствующей матрицы;
3. сопоставление приложений и технологических платформ и формирование соответствующей матрицы;
4. ввод информации в инструментарий.
3. Цель третьего шага состоит в интегрировании и верификации информации по текущим приложениям и технологическим платформам, разработке потоковых диаграмм по каждой системе. Основными его результатами являются верифицированный IRC и пакет отчетов по IRC, а также предложения по его улучшению на основе проведенных обсуждений.
4. На четвертом шаге осуществляется подготовка к администрированию и сопровождению IRC для его поддержки в актуальном состоянии. Здесь разрабатывается регламент поддержки, политики и процедуры сопровождения IRC, назначается ответственный по его сопровождению.

На этапе " Формирование архитектуры данных" идентифицируются и определяются основные разновидности данных, поддерживающих бизнес-функции. Архитектура данных представляется с помощью ER-модели и состоит из сущностей данных, каждая из которых имеет атрибуты и отношения с другими сущностями. Этап содержит 4 шага:

1. формирование списка кандидатов в сущности (трудозатраты - 10%);
2. определение сущностей, атрибутов и отношений (трудозатраты - 60%);
3. сопоставление сущностей и бизнес-функций (трудозатраты - 20%);
4. анализ результатов (трудозатраты - 10%).

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

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

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

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

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

1. формирование списка кандидатов в приложения (трудозатраты - 10%);
2. определение приложений (трудозатраты - 50%);
3. сопоставление приложений и функций (трудозатраты - 15%);
4. анализ применимости существующих приложений (трудозатраты - 15%);
5. анализ результатов (трудозатраты - 10%).

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

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

1. распределение приложений между членами команды;
2. определение каждого приложения (включая имя, номер, цель, общее описание и возможности, бизнес-преимущества);
3. упрощение сложных приложений и ликвидация избыточности;
4. выработка предварительных предложений по применимости имеющегося на рынке ПО и технологических платформ;
5. построение схемы архитектуры приложений;
6. оценка качества архитектуры приложений (понимаемость, полнота и состоятельность, прочность-устойчивость).

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

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

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

Этап " Формирование технической архитектуры" определяет основные виды технологий, необходимых для обеспечения окружения приложений, управляющих данными. Техническая архитектура не является ни проектом сетевого оборудования и ПО, ни детальными требованиями к ним. Она только определяет виды технических платформ, поддерживающих бизнес. Основными шагами этапа являются:

1. идентификация технических принципов и платформ (трудозатраты - 15%);
2. определение платформ и их распределение (трудозатраты - 50%);
3. сопоставление платформ с приложениями и бизнес-функциями (трудозатраты - 20%);
4. анализ результатов (трудозатраты - 15%).

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

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

1. определение мест размещения бизнес-функций;
2. распределение данных и приложений;
3. определение конфигурации технических платформ (рабочие станции, сеть, архитектура бизнес-систем);
4. оценка концептуальной технический архитектуры.

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

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

Этап " Разработка плана реализации" включает следующие основные шаги:

1. формирование последовательности реализации приложений;
2. оценка трудозатрат и ресурсов, построение плана;
3. оценка стоимости и достоинств плана;
4. определение факторов успеха и рекомендаций по их достижению.

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

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

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

На этапе " Заключительное планирование" осуществляется подготовка окончательного отчета по ЕА, подготовка и проведение презентации.

Основными шагами этапа " Переход к реализации" являются:

1. планирование перехода (спецификация целей перехода, формирование плана перехода, назначение ответственности за переход, определение руководителя-лидера);
2. адаптация подхода (методологии, инструменты);
3. наведение порядка с компьютерными ресурсами (приобретение необходимого, обеспечение надежности хранилища);
4. чистка архитектуры (ревизия, добавление деталей и обновление);
5. изменение организационно-штатной структуры;
6. рекрутинг персонала;
7. проведение обучения;
8. введение стандартов на программирование;
9. введение процедурных стандартов;
10. разработка детальных планов по приложениям;
11. определение и утверждение даты завершения перехода.

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