Отображение методологических концепций с помощью языка ArchiMate

Сегодня предлагаем вашему вниманию третью обучающую статью нашего коллеги, Александра Тетеркина, системного архитектора отела Сервиса и Консалтинга на тему использования языка ArchiMate от.

В первой статье Александр рассказал, как использовать ArchiMate при разработке нового программного продукта.

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

Сегодня Александр разобрал статью Фила Дельгядо «Методология как конструктор: инструкция по сборке» на примере ArchiMаte.

Из нее вы узнаете:

- как выстроить методику для старта проекта

- как запустить, развивать проект

- что сделать, если методику нужно сменить

Будет интересно!

PS: по ссылке вы найдете все схемы в хорошем качестве.

Содержание

Отображение методологических концепций с помощью языка ArchiMate

ArchiMate

Задача

Строим методику для старта проекта

Запуск

Развитие проекта

Смена методики

Заключение

"Я «визуал», поэтому, когда прихожу в лес, в первую очередь обращаю внимание какой он красивый, какое чудесное небо и какая офигенная трава! Поэтому, когда я встречаю на Хабре классную статью с большими фрагментами чистого текста, меня так и тянет перерисовать всё это в ArchiMate (ведь только тогда я смогу всё запомнить и, самое главное – полностью понять).

Сегодня я хочу разобрать одну из таких статей: статью Фила Дельгядо «Методология как конструктор: инструкция по сборке». В предисловии к ней написано:

Я возьму статью Фила за основу и отображу описанные им концепции с помощью визуального языка моделирования ArchiMate 3.1 (созданного и поддерживаемого промышленным консорциумом The Open Group, в который входят крупнейшие международные производители и потребители сферы информационных технологий, в т.ч. и правительственные агентства).

Если вы «аудиал», «кинестетик» или «дискрет», вам может и не понравиться то, что вы увидите в статье, всем остальным – добро пожаловать! Будет много картинок! Как говорится: «лучше 1 раз увидеть, чем 100 раз услышать»…

ArchiMate

Язык моделирования ArchiMate (/’ɑːrkɪmeɪt/ AR-ki-mayt; происходит от «Architecture Animate», т.е. «Ожившая архитектура») – это открытый и независимый язык моделирования архитектуры предприятия, поддерживаемый различными поставщиками программных инструментов моделирования, а также консалтинговыми фирмами. Спецификация языка ArchiMate (стандарт консорциума The Open Group – инструмент, позволяющий Корпоративным архитекторам однозначно описывать, анализировать и визуализировать взаимоотношения между различными бизнес доменами предприятия.

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

В консорциум The Open Group, поддерживающий стандарт ArchiMate, входят крупнейшие международные производители и потребители сферы информационных технологий, а также правительственные агентства, такие как: Capgemini, Fujitsu, Oracle, HPE, Orbus Software, IBM, Huawei, Philips, U.S. Department of Defense, NASA и другие.

Ранее я уже публиковал 2 статьи по тематике ArchiMate в применении к различным аспектам ИТ архитектуры:

1.          «Использование ArchiMate в разработке нового программного продукта»

2.          «Хорошая архитектура и ArchiMate»

Надеюсь, и эта статья по ArchiMate вам будет полезна.

Официальный обзор и описание языка, а также ссылки на все связанные ресурсы можно посмотреть на официальной странице ArchiMate (English).

Итак, перейдём, к статье «Методология как конструктор: инструкция по сборке» Филиппа Дельгядо.

Задача

Если вы ещё не прочитали статью Фила , самое время сделать это сейчас!

Также можете посмотреть видео на YouTube.

Если вы не прочитали статью и не посмотрели видео, многое вам может быть не понятным. Эта статья в первую очередь о применении ArchiMate.

Фил в статье задаёт вопросы: «С чего начать работу, если ничего нет?», «что собственно нужно от методики?», а затем, начинает отвечать: «…первое, что стоит сделать — выяснить у бизнеса, чего он боится».

В ArchiMate и TOGAF, подобный мотивационный элемент называется английским словом «драйвер».

Драйверы — это основные интересы к системе со стороны участвующих сторон.

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

Для системных инженеров:

«Соответствие интересам участвующих сторон» - основное требование при приемке системы в эксплуатацию.

Итак, в статье Фил выделяет главный драйвер – «страх», а затем, декомпозирует его на составляющие.

Представим Страхи Бизнеса, показанные Филом, в виде диаграммы ArchiMate:

Изображение 1: Страхи Бизнеса

Надо заметить, в этом разделе Фил делает большой упор на страхи, только вскользь упомянуты другие желания. Действительно страхи – один из мощнейших драйверов, но есть и другие драйверы у бизнеса (не только страх) – оставим это на совести автора статьи. Лишь добавлю, в качестве шутки, слова гранд-мастера Ордена джедаев:

Как я уже писал выше, другие желания Бизнеса раскрыты недостаточно полно. Тем не менее представим эти Пожелания Бизнеса в виде диаграммы ArchiMate:

Изображение 2: Пожелания Бизнеса

Также в разделе упомянуты Ограничения бизнеса, покажем их снова в формате ArchiMate:

Изображение 3: Ограничения

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

Итак, вот Общая схема Драйверов (в соответствии с текстом статьи):

Изображение 4: Общая схема Драйверов

Изображение можно открыть в отдельной вкладке, чтобы рассмотреть подробнее.

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

При использовании специализированного ПО (например, ПО с открытым исходным кодом Archi), можно делать ссылки на разные виды:

Изображение 5: Начальный вид со ссылками на другие виды

Чтобы сделать такой вид я:

1.          Добавил новый вид (View) в Archi.

2.          Создал там группу «Драйверы».

3.          Перетащил мышкой на созданную группу виды «Драйверы (общая схема)», «Страхи», «Пожелания» и «Ограничения».

4.          Выделил виды разными цветами (в их свойствах).

Выводы по разделу статьи:

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

2.          Описаны драйверы не для всех заинтересованных сторон (кого-то забыли);

3.          Приведены не все драйверы заинтересованных сторон (забыли про другие их желания);

4.          Не для всех драйверов указаны соответствующие требования (т.е. про эти страхи просто забыли).

5.          Не для всех требований показан конечный результат (практически нет измеряемых целей).

6.          Параметр вес (strength) при расчете влияния «страхов» или «пожеланий» позволяет более точно подобрать нужную методику.

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

Строим методику для старта проекта

Далее в статье Фила идет «прекрасная картинка Алистера Коуберна с кучей пунктов», но он из неё выбирает «только важное»: людей, процессы и артефакты.

Подготовим диаграмму ArchiMate с учетом выбранных элементов:

Изображение 6: Методика для старта проекта

Изображение можно открыть в отдельной вкладке, чтобы рассмотреть подробнее.

В статье описывается Матрица сложности проекта, созданная Алистером Коуберном, формат матрицы очень подходит для подобных материалов – совершенно нет необходимости оформлять это в ArchiMate!

По диаграмме данного этапа видно, что процессы «разобраться в большой задаче» и «проверить выполненное» выглядят очень абстрактно. Скорее всего процессов было больше (это подтверждает большое количество практик, называемых принципами в терминологии ArchiMate/TOGAF).

Запуск

На стадии запуска меняются требования, ограничения и драйверы Бизнеса. Отобразим новую картину в формате ArchiMate:

Изображение 7: Методика для запуска проекта

Изображение можно открыть в отдельной вкладке, чтобы рассмотреть подробнее.

Подготовив уже третью диаграмму методик в ArchiMate для статьи Фила, начинаю понимать, что нужна методика для создания методики:

1.          Слишком уж всё выглядит как изобретение велосипеда на ходу.

2.          Больно уж часто процессы не связаны явно с требованиями.

3.          А требования, в свою очередь с драйверами.

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

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

Развитие проекта

Итак, у Фила всё запущено, работает в промышленной эксплуатации. В промышленной эксплуатации меняются основные драйверы Бизнеса (какие-то ослабевают, какие-то становятся сильнее), меняется и наша диаграмма в ArchiMate:

Изображение 8: Методика для развития проекта

Изображение можно открыть в отдельной вкладке, чтобы рассмотреть подробнее.

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

Смена методики

Далее Фил рассказывает о том, как поменять методику и при этом не убить проект.

Отобразим это в виде процесса в формате ArchiMate:

Изображение 9: Смена методики проекта

Обратите внимание, что сама смена методики состоит из нескольких подпроцессов:

Распишем смену методики чуть подробнее (в соответствии со статьей Фила):

Изображение 10: Смена методики (подробности)

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

Заключение

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

Изображение 11: Заключение, наблюдения и манифест Филиппа

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

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