03 Быть или не быть TOGAF?

"Быть или не быть TOGAF: распространение
 архитектуры  предприятия за границы RUP"

Очень полезная статья:

http://www.ibm.com/developerworks/ru/library/r-temnenco/index.html

Хороший анализ ситуации, но …

Рабочий день начинается с экспресс-ознакомления с новостями. Знакомство завершается набором в поисковой строке: "TOGAF на русском".

Рисунок 1. TOGAF на русском.

76 тысяч результатов – это много. Ограничиваюсь первой страницей. Картина изменяется чрезвычайно редко. Уже довольно долго на втором месте – "Быть или не быть TOGAF".

Динамика не радует: интерес к TOGAF начинает спадать, "прорывные" материалы не публикуются. Почему?

Статья В.Темненко хоть и старая (ей уже почти 10 лет), но и сегодня очень актуальная. И она содержит указание на некоторые причины угасания интереса практикующих специалистов к TOGAF. Но изложены эти причины мягко, со свойственной Западу "толерантностью". И я не был бы "автором", если бы не нашел, к чему придраться!

"Возможные препятствия для реализации TOGAF"[1]

Давайте сразу условимся, что TOGAF – это не стандарт и, тем более, не технология. Это "каркас" (в статье – "инфраструктура"[2]). Это RUP нужно (можно) адаптировать. А TOGAF, чтобы начать хоть как-то его использовать, нужно "инструментализировать"!

"… Адаптация (и, тем более, инструментализация (прим. авт.)) предполагает глубокое знание модели бизнеса и методологии – специалиста с такими качествами не всегда легко найти…"

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

Рисунок 2. План-график реализации TOGAF (к цитате выше)

"… Среди прочих потенциальных угроз успешной реализации TOGAF – отсутствие стандартного инструмента для фиксации и управления артефактами архитектуры предприятия и отсутствие стандартной нотации…."

Вы можете представить себе коммерческое предприятие, которое согласится потратить деньги на это "мероприятие", отнюдь не гарантирующее 100%-й результат? Я – не могу.

Так все же, "Быть или не быть TOGAF?"

У меня на этот счет сомнений нет. Конечно, быть! Но …

TOGAF проживет долгую и счастливую жизнь, только, если Open Group, или кто-то другой, предоставит ТЕХНОЛОГИЮ архитектуры предприятия, охватывающую все, или почти все, аспекты TOGAF[3].

Мне кажется, TOGAF – это наиболее подходящий фундамент. Но он имеет изъяны, иногда – противоречия. Некоторые аспекты лучше представлены в других каркасах. Виталий в своей статье сделал хороший анализ. Представленные в ней каркасы не противоречат друг-другу. Они просто рассматривают проблемы развития предприятия с разных точек зрения и фокусируются на разных аспектах.[4]

Вот, когда мы будем иметь, пусть не полную, технологию, включающую:

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

тогда TOGAF и архитектура предприятия будут жить.

Для последнего элементе списка ("рекомендации") есть прекрасный прототип, получивший почти всеобщее признание специалистов. Это – RUP, который реализован на языке SPEM2. Язык содержит все необходимое для создания руководства для технологии архитектуры предприятия. Знаю, что говорю. Я неоднократно использовал SPEM2 для описания процессов и создания документации при внедрении технологий[5].

Резюме раздела

Я очень рекомендую прочитать или перечитать эту статью В.Темненко: http://www.ibm.com/developerworks/ru/library/r-temnenco/index.html

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

Продвижение: Расширение профиля и связанные темы

Архитектурные поставки

Итак, в конце прошлого выпуска я сообщил, что приступил к исследованию способности профиля UML для TOGAF, выполненного по метамодели содержания(см. главу 34 Спецификации), обеспечить информацию, необходимую для завершения Предварительной фазы ADM.

Результатами выполнения каждой фазы ADM являются Архитектурные поставки (официальные документы), и дополнительно могут включаться некоторые артефакты. Полный список и краткие описания архитектурных поставок опубликованы в главе 36 Спецификации, артефактов – в главе 35.

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

Например, для поставки Архитектурный репозиторий в разделе 6.5 записано: "Начальный архитектурный репозиторий, заполненный содержанием каркаса."

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

Список выходной информации Предварительной фазы представлен в главе 6, разделе 6.5.

Список выходной информации и краткие описания поставок сформулированы "размыто", хотя при простом прочтении это незаметно. Таким образом, использование только спецификации явно недостаточно для формирования точной модели информации TOGAF.

Была привлечена дополнительная информация: шаблоны документов архитектурных поставок[6].

Шаблоны документов архитектурных поставок, относящихся к Предварительной фазе были переведены на русский язык и добавлены к спецификации TOGAF.

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

TOGAF позиционирует себя как каркас, и рекомендует приспосабливать этот каркас к специфическим потребностям.

Ну, что-же, назовем это "приспосабливанием", посмотрим другие каркасы, сделаем, как поняли, и так, чтобы нигде не противоречить спецификации.

Добавление к профилю новых модельных элементов

Не вызывает сомнений, что документы – архитектурные поставки создаются на основе обобщения существующей на данный момент информации. Эта информация может содержаться либо в более гранулированных продуктах архитектурной работы, например – в моделях, либо "объективно существовать в мозгу" архитектора[7].

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

Метамодель TOGAF (и, соответственно, наш с вами профиль моделирования) включает единственный элемент, который может потенциально использоваться как источник информации для архитектурных поставок. Это "Продукт" (Produkt)[8]. В принципе, его достаточно, но ужасно неудобно: различные продукты имеют разные свойства, могут иметь разные допустимые связи, и т.д.

На рисунке ниже представлен фрагмент метамодели профиля моделирования. Полную (текущее состояние) метамодель и профиль можно посмотреть по ссылкам. Эту диаграмму я помещаю здесь для удобства обсуждения.

Рисунок 3. Метамодель продуктов архитектурной работы.

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

Прототипом для представленного набора стереотипов для моделирования продуктов архитектурной работы является спецификация Метамодели процессов инженерии программ и систем 2.0 (SPEM 2.0). Оттуда же "заимствованы" значки элементов (стереотипов), увы, без запроса надлежащего разрешения на использования. Кроме значков и названий (и то переведенных на русский) все остальное – интерпретация и "приспосабливание" к TOGAF.

Стереотип "Продукт" объявлен абстрактным. Ни один класс или экземпляр класса в моделях предприятия не может иметь стереотип "Продукт". При необходимости он должен иметь стереотип одной из его специализаций: "Артефакт", "Слот продуктов" или "Результат".

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

"Артефакт" также является абстрактным. Его специализации см. на рисунке 3.

Стереотип "Слот продуктов" – это коллекция продуктов, сформированная в соответствии с регламентом или по конкретному случаю. Пример – набор артефактов, периодически передаваемых заинтересованному лицу.

Стереотип "Результат" – это что-то нематериальное, например, важное событие, которое должно быть зафиксировано.

Некоторые специализации стереотипа "Артефакт".

Стереотип "Шаблон". Можно выделить шаблоны проектов, моделей, документов, отчетов и т.д.
Шаблоны должны содержаться в хранилищах активов предприятия и извлекаться при необходимости. Я представляю себе активные и пассивные шаблоны. Активные шаблоны, ассоциированные с модельным элементом, автоматически собирают требуемую информацию об элементе и представляют ее в нужной форме (например, шаблон BIRT).

Стереотипы "Документ" или "Отчет". По сути, эти элементы отличаются только степенью официальности и ответственности за содержание. Документы могут выполняться вручную заполнением граф шаблона пассивного типа или активного типа с возможностью редактирования. Отчет должен генерироваться с использованием шаблона активного типа без возможности редактирования.

Специализация стереотипа "Слот продуктов".

Стереотип "Поставка" – это коллекция продуктов, поставляемая официально, например, заказчику или регулятору.

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

Для этого мы имеем уникальные возможности. Не забудьте о "замечательных свойствах моделей программного обеспечения"!

Заключение

В детстве, едва научившись плавать, мы с двоюродным братом решили переплыть реку Белую (в городе Уфе). Речка не маленькая. К середине реки уже устали. Но вперед ближе! И, о, ужас, почувствовали под собой водоросли! До берега метров пятнадцать, но дружно повернули обратно.

Руки-ноги уже еле шевелились! Не знаю, писал бы я сейчас этот текст. Но ближе к середине реки на лодке плыл рыбак. Он нас вытащил и отвез на берег. Просто, повезло. Бывает.

Мораль.

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

Трудности, конечно, есть

Уже в Предварительной фазе для "правильного" моделирования процесса TOGAF требуется хранилище активов.

Нет проблем! Беру транспортный диск, создаю виртуальную машину под именем RAM_Server. Скачиваю с сайта IBM нужные компоненты: сервер Rational Asset Manager, сервер приложений WebSphera, базу данных DB2 и, для управления всем этим, Jazz Team Concert, плюс (на русском языке!).

Я по характеру и менталитету не системный администратор, и я не каждый день и, даже, не каждый год устанавливаю и настраиваю подобные интеграции!

Началось с того, что окошки на компьютере не совпадают с картинками в инструкции. Мастер инсталляции RAM не запросил установку WS и DB2, как было обещано. А сам без WS устанавливаться не захотел! Это я потом догадался, а сначала искал, почему, и ругался нехорошими словами. Прости меня, Господи!

Установил вручную WS и DB2. Пошел RAM. И встал! Диск на машине не нашел! Инсталлировал через веб. 10 часов! До 20 кб/сек. 21 век!

И, в результате, он мне не ответил!

Ребята! Может быть проконсультирует кто-нибудь? Крутятся у меня WS и DB2? И лицезии, нужны ли они?. Обычно триалы работают установленный срок без установки лицензий.

Буду очень благодарен!

Спасибо всем, кто дочитал до этого места!

Л. Новиков
lnew@yandex/ru