МАРФА-MARFA: российский архитектурный фреймворк


„Марфа! Марфа! ты заботишься и суетишься о многом, а одно только нужно.
Евангелие от Луки, 10:38

Краткое введение в МАРФА-MARFA: Marcus Aurelius Reference Framework for Architect - российский фреймворк для управления корпоративной архитектурой.

Причины появления: российские архитекторы предприятий не всегда находят возможность использовать TOGAF и Архимейт (Archimate), особенно в доменах мотивации и бизнеса, ввиду того, что российский управленческий дискурс отличается от англосаксонского (западного). В домене бизнеса есть также не до конца четкие [для ИТ-специалистов] определения таких понятий (или классов явлений) как процесс, функция, объект.  Сложность перехода в российскую парадигму мышления при архитектурировании вызвана также тем, что западные инструменты моделирования не имеют адаптации под российские управленческие онтологии. В связи с появлением в России такой системы моделирования как СиММА, являющейся полностью российским программным продуктом и обладающей открытой метамоделью, возникает инструментальная возможность поддерживать корпоративных архитекторов РФ в ходе моделирования в доменах целеполагания и мотивации, особенно при решении актуальных сегодня задач цифровой трансформации. Конечно МАРФА не ограничивается только управленческими доменами, переосмысливая также домен деятельности и ИТ.

MARFA не отменяет TOGAF & Archimate, до которых многие из нас еще не доросли. Но адаптирует их под российскую реальность. В конце концов настало время, когда мы можем позволить себе иметь и собственные методологии. 

Архимейт® и TOGAF® - зарегистрированные марки консорциума The Open Group®. 

Содержание.

Истоки МАРФА-MARFA, что лучшего мы берем из мирового опыта:

  • NATO Framework. Цель архитектуры – достижение согласованного взаимодействия участников из различных культурных сред.
  • TOGAF. Цель архитектуры – достижение консенсуса между менеджментом и ИТ.
  • Язык Архимейт. Цель языка – эффективная коммуникация и основа совместной деятельности участников проектирования.
  • MOF (мета-язык для UML, Archimate, BPMN). Цель MOF – сопряжение разнородных систем, заложенное на уровне их мета-моделей.
  • Матрица Захмана. Цель переосмысления работ Захмана: понимание стадий проектирования от замысла до реализации.
  • GERAM.
  • Пи-исчисление: переосмысление процессного моделирования.
  • 10 книг Витрувия по архитектуре: мы далеко не первые, перед кем встала задача архитектурирования!
  • Работы философов: Аристотель (категории, присущее и акцидентное), Платон, Витгенштейн (язык и реальность, вещь и объект), Фреге Готлоб (знак, значение, означаемое), Жан Бодрийяр (концептуализация вещей) - учимся концептуализации, учимся строить новые парадигмы.
  • Членство в TM FORUM, практика и преподавание методологий eTOM, SID, TAM, Open API, ODA. Зачем? – преодолеть отставание российской школы цифрового проектирования.
     

Какой вклад привносим мы?

Новые онтологии от «Марк Аврелий»:

  • Адаптация и развитие Архимейт под российский управленческий дискурс и складывающуюся практику проектирования процессов и информационных систем.
  • Ввод в архитектурную практику новых арх. компонентов.
  • Радонимы – базис проектного мышления.
  • Различение абстрактного и ментального.
  • EMIX – учет эмоций в проектировании.
     

Архитектор и Модель

Начнем, как обычно, с определений.

Объект моделирования/анализа/проектирования - любая часть реальности, имеющая заданные границы. Это может быть и предприятие, и группа предприятий, и отдел, и одна информационная систем, и две-три информационных системы в объеме их интеграционных взаимодействий. В общем-то нет отличий от того, что декларирует ИСО МЭК ИЕЕЕ 42010-2022. В рамках МАРФА под объектом моделирования, для простоты словаря, мы будем иметь ввиду предприятие или компанию или орган власти или орган власти и всё, что находится под его управлением или влиянием.  Граница - это результат отделения объекта моделирования от окружающего мира. Внутри границ - мы хозяева ситуации, вне границ - мы не можем влиять на происходящее. Вне границ - внешний мир. Внутри границ - наш внутренний мир, который мы можем изощренно моделировать, анализировать, проектировать и трансформировать, управлять, контролировать. Поскольку объектом моделирования/анализа/проектирования может быть и предриятие, и компания, и орган власти, и организация, и одна информационная система или платформа, то назовем это Z-система, подчеркивая этим названием, что мы будем рассматривать объект моделирования именно с системной точки зрения.

Модель - любое суждение, зарисовка, описание реальности (Z-системы), дающее некое представление о реальности.

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

Архитектура - это модель. Держите это в голове постоянно [из соображений пропедевтики]. Из тех же соображений думайте о ней, как о ментальной модели, даже если перед вами лежит схема архитектуры. Почему именно модель, а не план и не метод или там процесс? - потому что чаще всего мы сталкиваемся с анализом какой-то существующей Z-системы, то есть создаем первоначальное или углубленное представление (образ) этой Z-системы. Этот образ (общий, начальный, углубленный или детальный) не есть сама реальность, а лишь ее репрезентация. Поэтому и модель.  Почему нужно думать о ней в первую очередь, как о ментальной модели? - потому что любая модель создается согласно каким-то правилам или формализмам, по которым у заказчика и исполнителя должно быть полное согласие. 
И даже если перед нами нет реальной Z-системы, мы формируем образ/замысел новой Z-системы по тем же правилам и формализмам, как и для существующей. То есть и образ будущей реальности тоже есть ментальная модель. Собственно ни для архитектора, ни для модели неважно, какую реальность она отражает: существующую или будущую.

Модель мы будем создавать из классов. Почему так? - пока оставляем за кадром. Класс - это множество каких-то предметов или явлений физической или виртуальной реальности, а также устойчивых суждений (измышлений) ментальной реальности. Предметы, явления, суждения отбираются в класс на основании концепта, который этот класс отражает. Кому это не ясно - смотрим треугольник Фреге Готлоба (между прочим, математик и философ). Кому повезло и доступно - смотрим концентроид Рудда.

Классы бывают четырех типов (типов может быть и больше, но как минимум нужно различать четыре):

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

Каждый класс - это множество/подмножество объектов (предметов, суждений, явлений), подпадающих под определение класса. Таким образом объект реальности - это что-то единичное в реальности, на что можно четко указать или сослаться [через знак, обозначение, ID, имя]. Атомарно-единичный объект может быть предметом, виртуальной единицей, явлением, суждением; при переносе объекта реальности в модель уже не имеет значение чем именно он был в реальности. В модели он будет жить по правилам модели, то есть в речевой модели объекты будут словами, в графической модели объекты будут символами/картинками, в цифровой модели - записями в таблицах СУБД. Главное, что мы должны помнить - слово ОБЪЕКТ четко указывает на что-то в реальности, а не в модели и не в программном коде, как это принято в ООП.

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

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

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

Абстрактное и ментальное

Абстрактное и когнитивное (ментальное). Внесем в русский научный дискурс это различие (ну или подчеркнем его). Требования, ограничения, цели и т.п. - это не абстракции, это когнитивные объекты. Петров, Иванов, Сидоров - это объекты реальности. Хлебо-булочные изделия, ликеро-водочная продукция, стратегические цели, системы класса CRM, процессы продаж, партия товара, функции мониторинга, запасы сырья - это абстракции, но обычно мы их называем словами "виды", "типы" (а часто и "категории", но не стоит это путать с категориями Аристотеля). С ними работать нельзя. Это не архитектурно. В архитектуре - как на стройке у рачительного хозяина - все должно быть однозначно идентифицировано и учтено. Работа архитектора, выполненная на базе типов или видов, это не работа архитектора - так работают политики. К сожалению [для проектирования] их среди нас много.

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

Абстрактный объект - группа, тип, вид, род, категория, классификат - в общем, любые надуманные или обоснованные группировки элементов (хорошо еще, если элементов одного класса, а то бывает и из разных классов). Абстрактный объект чаще всего рекурсивен на неопределенное число уровней. Абстрактный объект (если он базируется на двух или более классах) имеет аспекты. Аспект - не очень хорошее слово, лучше использовать русское - ипостась.

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

Изложение абстрактных объектов следует дополнить материалом по:

  • по истинным сущностям
  • по классифицирующим и группирующим сущностям (пока см. здесь >>>)

Классы в МАРФА-MARFA. Домен мотивации и целеполагания

Приводим определения классов, входящих в МАРФА. Определение - это спецификация, по которой в класс отбираются его экземпляры (см. концентроиод Рудда).

Проблема. В российском управленческом дискурсе эквивалент тогафовского CONCERN, то есть некая обеспокоенность. Но это не интерес (concern) заинтересованного лица, так как concern не может сущестовать без его носителя. Слово проблема указывает, как правило на тот класс когнитивных явлений, которые не имеют прямого отображения в класс решений [и даже, к сожалению, не указывает на то, чьи это проблемы]. Если такое отображение есть, то проблема была бы отнесена к классу целей. Тем не менее в российской практике любят пары проблема-цель и, нередко, в отношениях многие-ко-многим. Основанием для парного рассмотрения проблема+цель является желание указать нерешаемость проблемы, иногда нужная "решаемость" возникает не сразу, а со временем, поэтому проблема может некоторое время (иногда и длительное) существовать без связанных с нею целей. Здесь следует учитывать, что как только к проблеме добавили цель, значит цель поставлена перед какой-то системой, способной акцептовать цель, а значит и решить проблему. То есть прибавление к проблеме цели переводит проблему в пространство решений. Таким образом проблема специфицируется тремя компонентами:

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

Еще раз обращаем внимание, что основное отличие проблемы от condern состоит в том, что она как бы никому не принадлежит. Она ничья.

Driver (драйвер) - движущая сила (из внешней среды), обстоятельство или фактор внешней среды, влияющий на Z-систему. Например, цифровизация, COVID, импортозамещение, экологичность бизнеса. Наиболее точное значение этого слова в российской его специфике - это предпосылка. На основании такой предпосылки возникает что-то в классе ПРОБЛЕМ. Возможно в качестве хорошего примера можно отнести к драйверам бизнеса 17 UN SDGs (United Nations Sustainable Development Goals) или саму необходимость им соответствовать. 

Цель. Устремление в будущее; результат или состояние чего-либо, что нужно достичь в будущем. В российском управленческом дискурсе целью является то, что формулируется за пределами рассматриваемой Z-системы, то есть это то, что приходит из внешей по отношению к Z-системе среды. Внутри Z-системы цель формирует конгруэнтные ей задачи. Z-система акцептует цель как достижимую, что может выражаться в ее характеристиках типа SMART, иначе Z-система не примет цель. Возможно (надо подумать на этим) у цели есть только MART-характеристики (так часто случается), а SMART - это уже у цели, принятой к исполнению (акцептованной) Z-системой. Стоит обратить внимание на паттерн вложенности. То есть задачи Z-системы становятся целями для подсистем Z-системы или компонентов Z-системы. И таких вложений может быть несколько.

Задача. В российском управленческом дискурсе задача - это то, что сформулировано в терминах [исполняющей задачу] Z-системы, как нечто достижимое в будущем за счет свойств Z-системы. Фактически задача очень четко соответствует атомарным или агрегатным свойствам, которые присущи Z-системе. Таким образом, [внешняя] цель "распадается" на задачи - так владельцы Z-системы "декомпозируют" цель на понятный для Z-системы набор устремлений. Очевидно, что в общем случае, из одной цели формируется более одной задачи.

Пара "Цель-Задача", как было упомянуто выше, [посредством паттерна вложенности] может повторять себя много раз, углубляясь в подсистемы Z-системы. "Цель - задача" → "Цель - задача" →"Цель - задача" →"Цель - задача".  На дне этой вложенности находится наименьшая "система" - исполняющее задачу действующее лицо или единица оборудования (Агент, Actor). Задача наименьшего уровня - задача агента/актора - называется Задание. В нотации BPMN - это Task.

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

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

  • ограничения типа "что делать нельзя" - твердые ограничения.
  • ограничения типа "как делать нужно" - твердые указания.
  • ограничения типа "как делать можно" - мягкие указания или советы.

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

Приказ, распоряжение - документ, фиксирующий набор целей или задач.

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

Принцип - разделяемое всеми убеждение, оказывающее влияние на принимаемые решения. 

Решение - принятый способ действия, принятый способ декомпозиции, принятый состав проектируемого изделения или системы и т.п. Ключевое слово - ПРИНЯТЫЙ и оказывающий влияние на проектирование. Хорошо, если все приказы, распоряжения, нормативные положения и ограничения будут сведены к набору решений. В основании решения может быть как распорядительный или нормативный документ, так и коллегиально выработанное согласие. В основании решения может быть также один или несколько принципов.

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

Интерес [х] - такой класс мы не берем в МАРФА. Интересы есть только у Стейкхолдеров. В российском управлеченческом дискурсе не принято говорить о чьих-то интересах. Вместо этого говорят о проблеме (она, как правило никому не принадлежит), о целях, спущенных откуда-то сверху. Реальным же основанием для действий являются лишь распоряжения/указания.

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

Требование. Здесь происходит тенденция к расслоению требования и превращения требований в отдельный домен. Компонентами домена будут намерения, ожидания, ограничения и прочее (см. TMF).

Классы в МАРФА-MARFA. Домен деятельности

Деятельность - весьма сложное явление для моделирования. Однозначных и универсальных способов формализации не существует. Но есть удобные на тот или иной случай. Как минимум следует различать:

  • представление о деятельности в виде процессов
  • представление о деятельности в виде функций
  • представление о деятельности в виде взаимодействий
  • представление о дятельности компании глазами клиента (CJM)
  • HTA
  • Case Management
  • движение документов
  • Data Flow
  • алгоритмы действий
  • структурирование деятельности в виде таксономий (и как следствие необходимость определения смысла для уровня у таксона)
  • state-машины
  • потоки событий.

Деятельность может быть выражена радоном CAPABILITY (способность). 

Полное описание классов этого домена и их онтологии доступно в полной версии МАРФА.

Классы в МАРФА-MARFA. Домен информационных технологий

Информационная система - чаще просто система. Не всегда просто установить границы информационной системы и тем самым сложно дать ей определение.  ГОСТ 34-й серии толкал нас в АСУ, расширяя понятия системы за пределы программного кода и включая в понятие системы и информацию, и методологию, и персонал, и процедуры. В рамках МАРФА система агрегирует (композирует) то, что может быть каталогизировано в виде слоев архитектуры:

  • объектный программный код, представленный компонентами для развертывания системы;
  • физические структуры данных, которыми оперирует программный код (например, таблицы базы данных);
  • программные структуры данных, которыми оперирует программный код;
  • логические структуры данных, которыми оперируют аналитики, проектировщики, пользователи системы;
  • функции или методы, включенные в состав программного кода, включая API-методы для доступа к функциям и данным системы.  

Наш опыт в каталогизации систем показывает, что если на предприятии есть, к примеру 100 систем, то минимум 60-70 из них однозначно вычленяются, то есть все признают их атомарными и конкретными системами. На базе этого множества как раз и получается сформировать критерии или определение на тему, что мы будем относить к системам на данном предприятии. Может оказаться, что на каком-то предприятии и каждая таблица в Excel - тоже отдельная система.

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

Платформа. В домене информационных технологий - это информационная система.

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

Таким образом, в МАРФА "функция системы" из Архимейт заменяется на два ABB:

  • польза/полезность от системы: ожидаемое пользователем поведение или полезность от системы. Формулировка этого ABB позволяет понять, что именно пользователь будет делать с помощью системы или что система автоматически должна произвести за пользователя. Более правильно было бы отнести этот ABB к домену деятельности. Но это не принципиальная позиция, а лишь метод упорядочивания компонентов архитектуры. Полезность можно также представить как сервисы или capability, предоставляемые приложением для бизнеса (или можно сказать так - спроектрованные для бизнеса). Полезность - она всегда в глазах потребителя.
  • метод системы - ABB, указывающий на разработанные в программном продукте процедуры, методы, функции. Объединение методов в сервисы, микросервисы, модули не относится к этому типу ABB. То есть метод - это то, что в системе есть независимо от того, будет ли им кто-то пользоваться или не будет и как именно.

В контексте российского ГОСТ 34-й серии функция системы - это не функция приложения, а функция, которую выдает АСУ, как человеко-машиннная система, то есть это сплав (композиция) системных возможностей (разработанных методов) и обязанностей человека ими пользоваться.

Объекты в нашем воображении и реальность

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

Объекты не есть реальность - это плод нашего воображения, точнее сказать, наше коллективное согласие на определенный устойчивый вид воображения. Для начала - см. трактат Витгенштейна. Можно заглянуть и сюда для старта, чтобы понять всю глубину проблемы за 30-60 минут - онтология понятий в ЛФТ.

У кого нет времени - осознайте простой пример. Перед вами на столе стоит кусок стекла такой формы, что в него можно налить что-то. Это предмет или изделие венецианского стеклодува. Кто-то скажет, что это просто стакан. Значит объект - это стакан и из этого факта следуют такие свойства, как возможность пить из стакана воду. Кто-то скажет, что это бокал. Значит объект - это бокал и его можно использовать как для сервировки стола, так и для употребления вина.  Кто-то скажет, что это - произведение декоративно-прикладного искусства. Значит объект - это предмет искусства и им стоит любоваться в коллекции других подобных предметов. Как видим, кусок стекла воронкообразной формы - это предмет, который может быть весьма разными объектами, то есть его можно отнести к разным классам в зависимости от потребностей моделировщика. 


Цифровая архитектура предприятия. Основы создания (1,3 МБ) Скачать


Список всех проектов