QPR Enterprise Architect — инструмент создания и управления архитектурой предприятия

27.04.2016

Автор: Валентин Рагозин

0. Введение или проблема моделирования архитектуры.

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

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

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

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

В данной статье я не ставлю себе целью провести сравнительный анализ и выявить лидера. Если вам интересны обзоры, можете поискать их в Интернете. Я хочу рассмотреть лишь один программный продукт — QPR EA (Enterprise Architect) — со всеми его возможностями и недостатками.

Итак, прежде чем перейти к статье о инструменте QPR EA, давайте разберемся в назначении всех продуктов финской компании QPR. А их у финов несколько:

1. QPR Metrics — это программное средство моделирования показателей и построения dashbord’ов. Позволяется задавать и визуализировать различные параметры, характеризующие предприятие (например количество Заказов на продажу в час, срок рассмотрения жалоб, ARPU и так далее). Сами метрики задаются в толстом клиенте, а визуализация происходит на WEB портале. Для использования необходимо будет купить сервер метрик.
2. QPR Process Analyzer — это средство позволят по данным полученным из системы Work Flow восстановить ход рабочего процесса со всеми его ветвлениями и определить узкие места. Используя дополнительные параметры можно провести более детальный анализ процесса и найти причины отклонений от нормы (например, можно добавить менеджеров и посмотреть кто является слабым звеном). Может использоваться как stand alone приложение, так и как облачная платформа.
3. QPR Process Designer (PD) — средство моделирования бизнес процессов. Включает в себя нотацию BPMN, ограниченную UML (расширение можно сделать самостоятельно) и базовый набор элементов из нотации EPC (расширение можно доработать самостоятельно или заказать эту работу консультантам). QPR PD может использоваться как stand alone средство моделирования, так и как средство для командной работы. Для командной работы требуется приобретение серверной части.
4. QPR Enterprise Architect (EA) — средство моделирования любых объектов и явлений, включая полный аналог Process Designer. Позволяет прямо из коробки использовать шаблоны ArchiMate 1.0 и 2.0 для построения архитектуры предприятия. Так же как и Process Desinger может использоваться в индивидуальном или коллективном режиме.
5. QPR WEB Portal — из названия понятно, что это web приложение. А точнее это сервер, на который можно опубликовать модели из толстого клиента. Так же на портале можно публиковать Dash bord’ы и показатели из Metrics.

Использование Metrics, Analyzer и EA позволяет эффективно решать такую не простую задачу как бизнес-трансформация. С помощью Analyzer вы можете построить картину As Is процессов по фактическим логам системы, автоматизирующей процесс, найти bottle neck, определить влияющие факторы. Затем в процесс-дизайнере или в EA вы можете спроектировать To Be процесс, который должен изменить ситуацию. После чего в Metrics сформировать набор показателей, характеризующих эффективность нового процесса. И, наконец, привязать показатели из Metrics к целевому процессу в EA. При этом, используя Analyzer, вы можете проводить сравнение того, как процессы протекают в реальности, с тем, как они должны протекать.

В данной статье я коснусь только одного продукта — QPR EA.

1. Diagram View в QPR Enterprise Architect

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

Коллективная работа выполняется в режиме ≪он-лайн≫, все пользователи серверной модели могут одновременно вносить изменения в модель и видеть изменения других пользователей. При этом пользователь так же имеет возможность забрать модель для ≪офф-лайн≫ работы, для этого существует функционал check in/out с помощью которого пользователь может сохранить модель локально, сделать необходимые изменения, а затем загрузить эти изменения на сервер.

Ролевая модель доступа позволяет ограничить доступ пользователей в модель до конкретной диаграммы, при этом пользователь не увидит объектов этой диаграммы даже в табличном представлении Navigator View (о котором я расскажу чуть дальше в данной статье). Эта функциональность существенно упрощает разделение зон ответственности в больших командах.

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

Рис.1. Рабочая область моделирования

Как я уже и говорил ранее, интерфейс проектирования не сложнее чем Visio. Моделирование происходит в рабочей области в которую drag and drop’ом переносятся объекты из палитры. В QPR EA есть возможность ограничить палитру для каждой конкретной диаграммы. Так, например, на рисунке 1 видно, что палитра логической модели данных ограничена соответствующими элементами, которые релевантны для данного типа диаграммы.

Если вы создаете сложную структуру диаграмм (что в том же Visio выглядит как набор листов), они автоматически выстраиваются в иерархию, которая отображается в соответствующем окне.

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

Рис.2. Графическое представление объектов

Все эти возможности приятны и полезны, однако ключевой особенностью QPR EA, на мой взгляд, является наличие еще одного набора представлений данных — представлений в табличном виде — Navigator View.

2. Navigator View в QPR Enterprise Architect

Navigator View и Diagram View используют одну и туже базу объектов, что позволяет использовать их вместе для двухстороннего взгляда на одни и те же объекты. Digram View представляет модель в виде графических элементов, в то время как Navigator View представляет их в виде объектов данных и выводит в виде таблиц.

Рис.3. Вид Навигатора

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

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

Как я уже говорил, оба представления «смотрят» на одни и те же объекты, потому создав объекты через Navigator View, вы всегда можете создать для них диаграмму и отобразить графически. Для этого достаточно в меню View выбрать пункт «разделить представления», выбрать ориентацию (вертикально/горизонтально) и drag and drop’ом нанести объекты из Navigator в нужную вам диаграмму. При наличии связей между объектами они будут построены автоматически в виде стрелок соответствующего типа.

Работает и обратное представление: объекты, созданные в Diagram View, можно найти через Navigator View.

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

Рис.4. Навигатор — представление иерархии объектов.

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

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

Раз уж речь зашла о больших объемах данных, стоит упомянуть о том, что у QPR EA есть средства загрузки данных из Excel, что делает процесс занесения данных намного проще, если вы предварительно агрегируете их в Excel. Так же существуют и API для интеграции с другими системами. Надо признать, что средства эти развиваются отдельно от продукта, потому как реализуются под конкретные запросы клиентов и особенности метамоделей последних. Однако QPR предоставляет услуги по кастомизации продукта под нужды клиента. Так что у вас всегда есть возможность заказать доработки системы под ваши нужны за дополнительную плату, при этом вам не придется ждать нового релиза продукта.

В этой статье уже не раз звучало слово метамодель, пришло время рассказать, что я имею в виду и чем на мой взгляд хорош QPR EA.

3. Метамодель архитектуры

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

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

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

Рис.5. Использование атрибутов

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

1. Разрешить устанавливать связь со всеми элементами модели

Рис.6. Связь с любыми типами объектов

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

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

Рис.7. Связь с конкретным элементом

В этой ситуации с помощью связи можно связывать только элементы, заявленные в строке Select model element type. При таком использовании уже можно строить строго структурированные иерархии.

Как я уже писал выше, при наличии у вас серверной части вы сможете публиковать все эти представления на портале и давать пользователям права на просмотр и комментирование. QPR Portal это отдельная тема для повествования и я не буду касаться ее в этой статье, потому как это средство представления результатов моделирования широкой аудитории, а не средство создания результатов.

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

============

В заключении хочется сказать, что QPR EA — это очень гибкий и удобный инструмент для построения архитектуры предприятия и выявления сложных зависимостей между всеми его элементами. В сочетании с Portal’ом, Analyzer’ом и Metrics его можно использовать для решения задач как построения архитектуры, так и ее трансформации. При этом стоимость продукта не так высока в сравнении с конкурентами, а дополнительные услуги по кастомизации позволяет адаптировать продукт именно под Ваши задачи.

Список статей