Форма входа

Категории раздела

Моделирование интегрированной архитектуры [8]
UPIA и связанные материалы
Архитектурные каркасы [3]
TOGA, DoDAF и т.п.
Размышления о концепции интегрированного моделирования предприятия [3]
Статьи о разработке технологии интегрированного моделирования и управления предприятием

Поиск

Наш опрос

Интересны ли Вам статьи цикла "Повышение производительности аналитика"?
Всего ответов: 25

Друзья сайта

  • Официальный блог
  • Сообщество uCoz
  • FAQ по системе
  • Инструкции для uCoz
  • Статистика


    Онлайн всего: 1
    Гостей: 1
    Пользователей: 0
    Четверг, 18.01.2018, 04:33
    Приветствую Вас Гость
    Главная | Регистрация | Вход | RSS

    Я - Аналитик!

    Каталог статей

    Главная » Статьи » Архитектура предприятия » Размышления о концепции интегрированного моделирования предприятия

    Размышления о концепции интегрированного моделирования предприятия

    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

     

    [1] Название этого и следующего разделов "заимствованы" из статьи В.Темненко.

    [2] Допускаю, что перевод слова "framework" – "инфраструктура" в данном случае звучит уместнее. Но я уже давно использую термин "каркас", использовал его во множестве публикация, и не я один! Так и оставим!

    [3] Я неоднократно писал, что поставщики инструментов, предлагающие "моделирование для технологии TOGAF", на самом деле предлагают инструмент для "урезанной" разработки архитектуры в фазах А – С, хотя на самом деле требуется он-лайн моделирование РАЗВИТИЯ.

    [4] В этом пункте могут возникнуть "психологические" трудности. Апологеты научных течений часто готовы отстаивать свои подходы, не прибегая к логике! Из-за этого у меня есть сомнение в возможности OMG сделать эту работу.

    [5] Я прошу не использовать мою публикацию спецификации TOGAF на русском как неудачный пример использования SPEM2. Форма представления выбрана специально, как "заготовка" текстов для будущего использования в той работе, которую мы обсуждаем сейчас.
    Каждая страница (раздел оглавления) – это элемент многоразового использования, хранящийся в библиотеке. Его можно использовать в различных контекстах, причем, в каждом контексте дополнять, изменять и заменять. Что важно: при изменении основного (базового) элемента изменения отражаются в "дочерних" элементах, но не затрагивают локальные изменения.
    А из "Спецификации" можно получить вполне обычную книгу в форматах .doc, .pdf или .html.

    [6] Требуется регистрация на сайте Open Group.

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

    [8] Кстати, архитектурная поставка – это тоже продукт.

    Категория: Размышления о концепции интегрированного моделирования предприятия | Добавил: lnew (04.06.2016)
    Просмотров: 302 | Комментарии: 2 | Рейтинг: 0.0/0
    Всего комментариев: 2
    1  
    framework, особенно в рамках понятия архитектурного описания, переводят и как подход (метод)

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

    Имя *:
    Email *:
    Код *: