Форма входа

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

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

Поиск

Наш опрос

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

Друзья сайта

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


    Онлайн всего: 1
    Гостей: 1
    Пользователей: 0
    Воскресенье, 27.05.2018, 00:13
    Приветствую Вас Гость
    Главная | Регистрация | Вход | RSS

    Я - Аналитик!

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

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

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

    Поводы для размышлений

    Первый повод

    Не так давно познакомился "по переписке" с человеком, который называет себя Bipiem. На почве общих интересов к BPM. Ну, так показалось. Хотя, потом выяснилось, что Bipiem интересуется управлением бизнес-процессами, а я занимаюсь моделированием, в том числе – и моделированием бизнес-процессов, в основном – для поддержки разработки информационных систем.

    Bipiem познакомил меня со своей статьей (рекомендую!) Бизнес-процессы: Как все запущено и запутано (http://club.cnews.ru/blogs/entry/biznesprotsessy_kak_vse_zapushcheno_i_zaputano_glava_pervaya).

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

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

    Если же я прав, то, со своей стороны, я почти со всем согласен. Почти!

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

    В каждом новом продукте (инструменте, технологии) мы ищем серебряную пулю! Отсюда метания, поиски чего-то лучшего и разочарования. А ее нет (серебряной пули), и сделать ее невозможно! Кстати, и сами поставщики это подтверждают. Они говорят о необходимости адаптации инструментов и технологий к специфическим условиям (консультанты этому рады). И даже термин придумали подходящий – "каркас" (Framework). И этим облегчили себе жизнь.

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

    Второй повод

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

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

    По вполне понятным причинам, я не могу и не буду продолжать обсуждение этой НИР.
    Дело прошлое, но участие в ней навеяло мне множество "философических" мыслей о современном состоянии технологий ИТ для поддержки бизнеса, что и стало мотивом написания этого цикла статей со странным названием "Размышления о …".

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

    Цель этой статьи – объяснить свое понимание того, что я подразумеваю под унифицированной технологией интегрированного моделирования и управления предприятием.

    Ключ – в расширении предметной области MDA

    Моделирование как средство проектирования – отнюдь не изобретение в области IT. Скорее это плагиат из традиционной технической инженерии. Но ….

    Как работают инженеры при создании реальных технических систем?

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

    Рисунок 1. Фрагмент модели моста

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

    • Отличие свойств фактических материалов от проектных
    • Погрешности методов конструирования
    • Эффекты масштабирования и т.д.

    Да, в конце концов, и "эффект понедельника" пока никто не отменял!

    Рисунок 2. Семантический промежуток между моделью технической системы и ее реализацией

    Наличие этого семантического промежутка может привести к серьезным ошибкам в реализации.

    Замечательное свойство моделей в области программного обеспечения

    Вернемся к началу этой главы: что же это за таинственное "Но…"?

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

    Управляемая моделью архитектура

    Осознание "замечательного свойства моделей ПО" и современный опыт использования моделирования не могли не натолкнуть специалистов индустрии на идею управляемой моделью архитектуры (Model Driven Architecture – MDA).

    MDA – это набор открытых стандартов OMG. В основе представления OMG на MDA лежат, в частности, следующиее принципы:

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

    OMG идентифицировала четыре типа моделей для MDA:

    Рисунок 3. Типы моделей для MDA

    Интегрированное моделирование предприятия как расширение концепции MDA

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

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

    Без "ложки дегтя" не обойтись. Серебряную пулю MDA тоже не предлагает.

    1. Множество моделей ПО (в интересующем нас случае – предприятия) должны уметь "разговаривать" между собой (имеются ввиду преобразования "модель-модель") на общем языке.
    2. Реальная жизнь многообразна! Невозможно представить, что поставщики инструментов и технологий разработают и поставят структуры моделей и преобразования "модель-модель", пригодные всегда для всех случаев жизни.
    3. Существующие инструменты, обеспечивающие возможности MDA (а при соответствующей доработке – и интегрированного моделирования и управления) сегодня дороги.

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

    Ну, и что же делать?

    А я решил попробовать!

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

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

    Некоторые технические детали:

    Базовые методы и технологии

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

    Причин несколько:

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

    Другие методические источники включают RUP, библиотеки лучших практик в формате SPEM 2 от IBM и EPF, доступные статьи из интернета.

    Рабочие инструменты

    Главный рабочий инструмент – IBM Rational Software Architect (RSA).

    На RSA можно делать почти все, по крайней мере, пока команду разработчиков представляю я один: создавать профили UML, шаблоны, мастера, преобразования и даже управлять процессом разработки, если уметь. К сожалению, невозможно настоящее управление активами предприятия, для этого нужен IBM Rational Asset Manager (RAM). Но моделировать управление активами можно. А когда понадобится управлять активами, может быть и спонсор найдется&

    Другие инструменты – генератор отчетов BIRT и инструмент описания процессов RMC.

    Все перечисленные инструменты интегрированы.

    Языки разработки

    Принимается единственный язык моделирования – UML.

    В RSA включено большое число профилей UML для моделирования в специфических прикладных областях.
    Некоторые профили придется разрабатывать. В основном, для экзотических диаграмм, перечисленных в спецификации TOGAF.

    Основную разработку инструментальных средств (профилей, мастеров, преобразований) можно выполнять в графическом режиме. Для программирования всяких тонкостей, не предусмотренных мастерами RSA, используется Java.

    Заключение

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

    А кому это может быть нужно?

    1. Крупным софтверным компаниям, которые смогут стать "фабриками" с отлаженным процессом и складами полуфабрикатов (справочными библиотеками)
    2. Крупным производственным и торговым компаниям, которые несут потери из-за неповоротливости их IT служб
    3. Специализированным консалтинговым компаниям, которые смогут сдавать в аренду ресурсы своих экземпляров реализации технологии, размещенных на доступных платформах ("в облаках"?)

    Что касается меня, то для меня это почти мечта человечества – коммунизм – "свободный труд свободного человека".

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

    Приглашаю к сотрудничеству всех желающих. Критикуйте. Предлагайте.

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

    А сегодня я публикую модель профиля UML для архитектурного содержания TOGAF (см. часть 4, главу. 34 Спецификации). По индивидуальному заказу могу выслать профиль в формате обмена UML2. Он должен пониматься всеми инструментами UML, поддерживающими этот стандарт от OMG.

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

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

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


    [1] Если, конечно, мне удастся заинтересовать читателей и подвигнуть их к участию в дискуссии.

    [2] Название условное

    Категория: Размышления о концепции интегрированного моделирования предприятия | Добавил: lnew (16.05.2016)
    Просмотров: 305 | Комментарии: 2 | Теги: Моделирование архитектуры предприят, TOGAF, Интегрированное моделирование предп | Рейтинг: 0.0/0
    Всего комментариев: 2
    1  
    Правая часть текста обрезана к сожалению. :(

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

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