Форма входа

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

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

Поиск

Наш опрос

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

Друзья сайта

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


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

    Я - Аналитик!

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

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

    Размышления о ... С чего начать? Что такое "Предприятие"?

    02 С чего начать? Что такое "предприятие"?

    "А что было раньше, курица или яйцо?"

    Извечный вопрос!

    А для Вас актуален ответ на этот вопрос? Тогда я Вам завидую! У Вас нет других проблем!

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

    Что такое "предприятие" в TOGAF?

    Название "The Open Group Architecture Framework" не содержит упоминания об объекте архитектурной деятельности. Ничего страшного в этом, наверное, нет[1]. Вряд ли кто возьмется за Спецификацию TOGAF, не зная, что речь пойдет об архитектуре предприятия (с интенсивным использованием информационных технологий).

    Правда, этот пробел закрывается уже в первом абзаце главы 1 Спецификации.

    Итак, предметом рассмотрения TOGAF является архитектура предприятия. Обратите внимание: сначала архитектура, а потом предприятие.

    Определение предприятия (см. главу 2, пункт 34) я приводить не буду ввиду его полной несостоятельности.

    Чуть раньше, в главе 1, п. 1.2 понятие "предприятие'' объясняется как "любая коллекция организаций, имеющая общий набор целей. Например, предприятие может быть правительственное учреждение, полная корпорация, часть корпорации, единственный отдел или совокупность географически удаленных организаций, объединенных совместным владением."

    Это уже кое что. С учетом определения термина "архитектура" (см. главу 2, пункт 3.8), есть о чем порассуждать.

    Пример, "притянутый за уши"

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

    Пофантазируйте, пожалуйста, присутствует ли в этом примере предприятие и архитектура предприятия в смысле TOGAF?

    1. Из далекой Сибири в город N приехал криминальный авторитет, отягощенный некоторым богатством, добытым до поездки в Сибирь. Не то, чтобы он "осознал". Но в Сибири он подорвал здоровье и решил сменить образ жизни. Купив мыловаренную фабрику, он стал вполне порядочным буржуем, получающим легальный доход, а фабрика просто сменила хозяина.

    Как по Вашему, есть ли в этом примере предприятие и архитектура предприятия в смысле TOGAF? Если да, то это другое предприятие(я) и архитектура(ы)? Или, в этом смысле, ничего не изменилось?

    Альтернативные понятия предприятия

    Термин "предприятие" традиционно используется в системной инженерии. Однако, даже в системной инженерии, в толковании термина разными авторами нет единообразия.

    Чаще всего, формулировка базируется либо на указании субъекта, например:

    … хозяйствующий субъект, который производит и сбывает товары, выполняет работы, оказывает услуги,

    либо на определении целенаправленной деятельности, например:

    … мероприятие, дело или начинание, связанное с созданием или организацией чего-либо.

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

    "Предприятие" в "нашем интегрированном моделировании"

    Второй вариант подхода к определению предприятия кажется мне более продуктивным. Предлагается для обсуждения следующая формулировка:

    Предприятие – это мероприятие, предпринимаемое заинтересованным лицом (группой заинтересованных лиц), связанное со стремлением обеспечить возможности для получения определенной выгоды (устойчивого преимущества).[2]

    Некоторые свойства предприятия, которые вытекают из определения и рассматриваются как ключевые в этом цикле:

    1. Любое предприятие мотивируется осознанием заинтересованными лицами неудовлетворенности текущим или потенциальным состоянием дел.
    2.  Предприятие начинается (не "создается" и не "разрабатывается", а именно "начинается") с формулирования заинтересованными лицами (или их доверенными лицами) некоторой инициативы выполнения мероприятий, которые должны "снять" имеющуюся неудовлетворенность.
    3. Предприятие имеет начальное состояние (от "чистого листа" до какой-нибудь успешной корпорации, владельцы которой почувствовали потенциальную угрозу своему бизнесу)
    4. Предприятие имеет ресурсы, которые заинтересованные лица готовы затратить на реализацию инициативы.
    5. Начальное состояние и выделенные ресурсы определяют доступные возможности и границы предприятия. Может быть, начальную формулировку придется откорректировать или даже вообще отказаться от предприятия.

    Близкие концепции

    Словарь В.К.Батоврина[3] указывает на термин проект как синоним термина предприятие. Мне это кажется не совсем верным.

    Во-первых, проект, по определению, "временное усилие…", т.е., ограничен во времени. Предприятие явно временем не ограничено.

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

    Наиболее близким по смыслу понятием (но не синонимом) для предприятия, по моему мнению, является бизнес. В этом цикле термин бизнес будет рассматриваться как специализация термина предприятие: любой бизнес является предприятием, но не каждое предприятие – это бизнес.

    А причем здесь курица и яйцо?

    Бог начал с создания Света, и Человек, созданный им несколько позже, смог оглядеться и увидеть, как Свет хорош, и, может быть, делать необходимые ему выборы. Представьте себе, что было бы, если бы Бог создал сначала Человека, а потом Свет!

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

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

    Метамодель архитектурного содержания TOGAF (см. часть IV, главу 34 Спецификации) не содержит модельных элементов для выполнения этой задачи. Причину такой дискриминации можно обсудить позже. Здесь же замечу, что, как почти всегда, выдумывать ничего не надо. "Все уже было в этом мире!". Если Вы посмотрели модель профиля, который я формирую для интегрированного моделирования, м.б. Вы обратили внимание на появление элементов, отсутствующих в метамодели TOGAF. Это стереотипы Stakeholder, Enterprise, Vision, Mission и т.д. Их идеи (а в некоторых случаях, и иконки), "позаимствованы" из моделей BMM и UPIA и др.

    Особенности применения моделирования в TOGAF

    Производители инструментальных средств моделирования активно откликнулись на появление моды на TOGAF и дополнили свои продукты соответствующими методами и инструментами. По моему мнению, лидерами в этом направлении являются IBM Rational System Architect[4] и Sparx  Enterprise Architect. С недавних пор язык моделирования ArchiMate[5] объявлен официальным языком моделирования для TOGAF.

    Я тоже не постеснялся "вставить свои пять копеек" (см., например, три статьи "Расширение моделирования в TOGAF с использованием UML и здравого смысла" на этом сайте).

    Все обнаруженные мной попытки, в том числе "мои пять копеек", имеют один общий недостаток:

    Они моделируют предприятие как проект. В чем разница?

    Цель проекта – получить конечный результат, разработать (спроектировать) и реализовать некоторый продукт, не обязательно материальный. Фокус моделирования – конечный продукт. Моделирование проектной деятельности ограничивается моделированием требований и/или проектных планов. Технологии выполнения проектов хорошо проработаны, обеспечены инструментарием. Пример – Rational Unified Process, который постоянно поддерживается в актуальном состоянии.

    Цель предприятия – обеспечить длительное преимущество. Как то язык не поворачивается сказать: "Разработка предприятия"! Предприятие рождается, развивается и умирает, как и все живое в нашем мире. Конечно, в контексте предприятия могут запускаться проекты, особенно на начальных этапах развития. И эти проекты выполняться с привлечением соответствующих технологий и моделирования, если требуется. Но в фокусе моделирования предприятия, по моему мнению, должна быть поддержка развития предприятия в соответствии с Видением предприятия и его Стратегической миссией.

    Это мое мнение о различиях в моделировании проекта и предприятия, мне кажется, подтверждает не буква, но дух спецификации TOGAF. Обратите внимание на рисунок 5.1. в Спецификации. Цикл разработки архитектуры, - это спираль, которая имеет начало, но не имеет конца[6].

    Можно предположить, почему только "дух", но не "буква": из-за устойчивой убежденности большинства инженеров и архитекторов, что когда объект уже построен, рисовать больше нечего!

    Есть и другие особенности моделирования предприятия, но о них поразмышляем в другой раз в подходящем контексте.

    Заключение. Кое-что о планах

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

    1. Язык должен обеспечивать (но не должен ограничиваться) поддержку моделирования всех концепций и методов TOGAF
    2. Язык должен быть реализован как профиль UML 2
    3. В качестве ближайшего прототипа должен использоваться профиль UPIA
    4. Для поддержки потенциальных пользователей должны быть разработаны рекомендации в виде практик EPF
    5. Опытный образец профиля языка и соответствующие рекомендации должны разрабатываться для интеграции линейки инструментов IBM Software Delivery Platform с технологией Jazz[8]

    Отчет за неделю

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

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

    Сегодня, одновременно с этой статьей я опубликую описание модели новой версии профиля и часть описания метамодели.

    Я заранее прошу читателей извинить меня за, может быть, "корявые" описания: я их не "вылизывал" из-за недостатка времени. И картинки (иконки) для диаграмм тоже, наверное, не все хороши. Все это можно исправить.

    Что дальше

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

    Для себя я принял достаточно жесткое решение – одна публикация в неделю:

    • Обсуждение актуальных вопросов развития нашего предприятия
    • Обновление описаний моделей профиля, метамодели и модели нашего предприятия.

    Напоминаю: если кто-то хочет увидеть эти модели в реальности и попробовать моделировать самим, пишите. Я вышлю модели и сочиню временную инструкцию по использованию. Должно работать на Rational Software Architect, начиная с версии 8. Профиль должен работать почти на всех инструментах (должен, но я не пробовал, времени жалко). Если будет "заказ", могу протестировать на Sparx EA и, м.б., тоже написать инструкцию.

    Читателям – спасибо!

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

     

    [1] В жизни мы часто встречаемся с названиями, из которых невозможно понять, что за ними скрывается. Как пример, название упомянутой в прошлом выпуске концепции Model Driven Architecture. Многие уважаемые специалисты до сих пор путают ее с близкой "по духу" концепцией Model Driven Development.

    [2] Формулировка предлагается на обсуждение. Буду весьма благодарен за критику и предложения. Оставляйте комментарии!

    [3] Батоврин В. К. Системная и программная инженерия. Словарь-справочник. Москва – 2010.

    [4] Не путайте с IBM Rational Software Architect. Эти продукты, хотя и имеют общего владельца и почти одинаковое назначение, имеют разных родителей. Я предпочитаю работать на Rational Software Architect, и не иметь дела с Rational System Architect.

    [5] Скачать Archimate можно здесь: https://www2.opengroup.org/ogsys/catalog/I130

    [6] На самом деле, в фазе Н может быть принято решение о "самоубийстве" предприятия.

    [7] Удивляюсь своему нахальству!

    [8] При появлении дополнительных ресурсов может быть рассмотрена возможность использования продуктов Sparx Systems.

    Категория: Размышления о концепции интегрированного моделирования предприятия | Добавил: lnew (23.05.2016)
    Просмотров: 325 | Рейтинг: 0.0/0
    Всего комментариев: 0
    Имя *:
    Email *:
    Код *: