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

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

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

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

1. Блок элементарных объектов организации, а именно:

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

2. Блок моделей архитектуры организации, а именно:

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

3. Блок языков и методологий моделирования, включая:

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

4. Блок языков мета-моделирования и методологий определения методологий моделирования (мета-методологий), соответственно, для описания концепции, синтаксиса и семантики языков моделирования, и методологий их применения, а также для описания процессов построения этих языков и методологий.

 

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

 

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

1. универсальные интегрирующие среды (например, ZachmanFramework, GERAM),

2. языки моделирования организаций (например, семейство IDEF, DFD - технология, ARIS, BPML),

3. программныесредымоделирования (например, ARIS 6 Collaborative Suite, Popkin System Architect, METIS, Casewise Corporate Modeler),

4. мета-модели и языки мета-моделирования (например, UML ProfileforBusinessProcessDefinition, UEML).

 

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

1. поддерживают лишь отдельные компоненты среды моделирования,

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

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

4. поддерживают лишь отдельные виды моделирования.

 

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

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

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

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

 

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

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

2. процессо-ориентированных концепциях для описания бизнес-процессов,

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

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

 

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

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

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

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

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

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

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

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

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

2. стандартизованных, независимых от инструментов механизмов передачи знаний (моделей) между проектами;

3. репозитория моделей организаций.

 

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

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

В качестве расширений могут использоваться нотации языков IDEF0 и UML, а также нотация BPMN (Business ProcessModeling Notation) – основа современного языка моделирования бизнес-процессов BPML (BusinessProcess ModelingLanguage), являющего в настоящее время стандартом де-факто в рассматриваемой области.

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

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

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

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

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

51.Модель определения компонент стратегии, основные элементы и этапы разработки ИТ –стратегии

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

Трехуровневая модель определения компонент стратегии включает в себя:

1. описание конечного состояния (видение, цель);

2. описание ограниченного набора способов достижения цели (основная стратегия);

3. шаги к достижению цели (тактика или конкретные проекты).

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

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

• ресурсы,

• способности,

• потенциал,

• ключевая область компетенции организации

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

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

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

1. видение ("куда мы идем"),

2. стратегию ("как мы достигаем цели")

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