„Марфа! Марфа! ты заботишься и суетишься о многом, а одно только нужно.
Евангелие от Луки, 10:38
Краткое введение в МАРФА-MARFA: Marcus Aurelius Reference Framework for Architect - российский фреймворк для управления корпоративной архитектурой.
Причины появления: российские архитекторы предприятий не всегда находят возможность использовать TOGAF и Архимейт (Archimate), особенно в доменах мотивации и бизнеса, ввиду того, что российский управленческий дискурс отличается от англосаксонского (западного). В домене бизнеса есть также не до конца четкие для ИТ-специалистов определения понятий (или классы явлений) таких как, процесс, функция, объект. Сложность перехода в российскую парадигму мышления при архитектурировании вызвана также тем, что западные инструменты моделирования не имеют адаптации под российские управленческие онтологии. В связи с появлением в России такой системы моделирования как СиММА, являющейся полностью российским программным продуктом и обладающей открытой метамоделью, возникает инструментальная возможность поддерживать корпоративных архитекторов РФ в ходе моделирования в доменах целеполагания и мотивации, особенно при решении актуальных сегодня задач цифровой трансформации. MARFA не отменяет TOGAF & Archimate, к которым многие из нас еще не доросли. Но адаптирует их под российскую реальность. В конце концов настало время, когда мы можем позволить себе иметь и собственные методологии.
Архимейт® и TOGAF® - зарегистрированные марки консорциума The Open Group®.
Новые онтологии от «Марк Аврелий».
Начнем, как обычно, с определений.
Объект моделирования/анализа/проектирования - любая часть реальности, имеющая заданные границы. Это может быть и предприятие, и группа предприятий, и отдел, и одна информационная систем, и две-три информационных системы в объеме их интеграционных взаимодействий. В общем-то нет отличий от того, что декларирует ИСО МЭК ИЕЕЕ 42010-2022. В рамках МАРФА под объектом моделирования, для простоты словаря, мы будем иметь ввиду предприятие или компанию или орган власти или орган власти и всё, что находится под его управлением или влиянием. Граница - это результат отделения объекта моделирования от окружающего мира. Внутри границ - мы хозяева ситуации, вне границ - мы не можем влиять на происходящее. Вне границ - внешний мир. Внутри границ - наш внутренний мир, который мы можем изощренно моделировать, анализировать, проектировать и трансформировать, управлять, контролировать. Поскольку объектом моделирования/анализа/проектирования может быть и предриятие, и компания, и орган власти, и организация, и одна информацинная система или платформа, то назовем это Z-система, подчеркивая этим названием, что мы будем рассматривать объект моделирования именно с системной точки зрения.
Модель - любое суждение, зарисовка, описание реальности, дающее некое представление о реальности.
Архитектор, Архитектурирование, Архитектура - понятие категории POSIWID. Для начала достаточно понять саму эту триаду: некий специлист → деятельность этого специалиста → результат деятельности. Никак не наоборот. Проверочное суждение: если у вас нет архитектора, то у вас нет и не может быть архитектуры.
Архитектура - это модель. Держите это в голове постоянно [из соображений пропедевтики]. Из тех же соображений думайте о ней, как о ментальной модели, даже если перед вами лежит схема архитектуры. Поскольку чаще всего мы сталкиваемся с анализом архитектуры уже существующей Z-системы или формируем замысел новой Z-системы.
Модель мы будем создавать из классов. Класс - это множество каких-то предметов или явлений физической или виртуальной реальности, а также устойчивых суждений (измышлений) ментальной реальности. Предметы, явления, суждения отбираются в класс на основании концепта, который этот класс отражает. Кому это не ясно - смотрим треугольник Фреге Готлоба (между прочим, математик и философ). Кому повезло и доступно - смотрим концентроид Рудда.
Классы бывают четырех типов (типов может быть и больше, но как минимум нужно различать четыре):
Каждый класс - это группа объектов (предметов, суждений, явлений), подпадающих под определение класса. Таким образом объект реальности - это что-то единичное в реальности, на что можно четко указать или сослаться [через знак, обозначение, ID, имя]. Оно (это атомарно-единичное) может быть предметом, виртуальной единицей, явлением, суждением - при переносе объекта реальности в модель уже не имеет значение чем именно был объект реальности. В модели он будет жить по правилам модели, то есть в речевой модели объекты будут словами, в графической модели объекты будут символами/картинками, в цифровой модели - записями в таблицах СУБД. Главное, что мы должны помнить - слово ОБЪЕКТ четко указывает на что-то в реальности, а не в модели и не в программном коде, как это принято в ООП.
Абстрактное и когнитивное (ментальное). Внесем в русский научный дискурс это различие (ну или подчеркнем его). Требования, ограничения, цели и т.п. - это не абстракции, это когнитивные объекты. Петров, Иванов, Сидоров - это объекты реальности. Хлебо-булочные изделия, ликеро-водочная продукция, стратегические цели, системы класса CRM, процессы продаж, партия товара, функции мониторинга, запасы сырья - это абстракции (иногда говорят тверже - категории). С ними работать нельзя. Это не архитектурно. В архитектуре - как на стройке у рачительного хозяина - все должно быть однозначно идентифицировано и учтено. Работа архитектора, выполненная в категориях или на базе категорий, это не работа архитектора - так работают политики. К сожалению [для проектирования] их среди нас много.
Приводим определения классов, входящих в МАРФА. Определение - это спецификация, по которой в класс отбираются его экземпляры (см. концетроиод Рудда).
Цель. Устремление в будущее; результат или состояние чего-либо, что нужно достичь в будущем. В российском управленческом дискурсе целью является то, что формулируется за пределами рассматриваемой Z-системы, то есть это то, что приходит из внешей по отношению к Z-системе среды. Внутри Z-системы цель формирует конгруэнтные ей задачи. Z-система акцептует цель как достижимую, что может выражаться в ее характеристиках типа SMART, иначе Z-система не примет цель. Возможно (надо подумать на этим) у цели есть только MART-характеристики (так часто случается), а SMART - это уже у цели, принятой к исполнению (акцептованной) Z-системой. Стоит обратить внимание на паттерн вложенности. То есть задачи Z-системы становятся целями для подсистем Z-системы или компонентов Z-системы. И таких вложений может быть несколько.
Задача. В российском управленческом дискурсе задача - это то, что сформулировано в терминах [исполняющей задачу] Z-системы, как достижимое в будущем за счет свойств Z-системы. Фактически задача очень четко соответствует атомарным или агрегатным свойствам, которые присущи Z-системе. Таким образом, [внешняя] цель "распадается" на задачи - так владельцы Z-системы "декомпозируют" цель на понятный для Z-системы набор устремлений. Очевидно, что в общем случае, из одной цели формируется более одной задачи.
Пара "Цель-Задача", как было упомянуто выше, [посредством паттерна вложенности] может повторять себя много раз, углубляясь в подсистемы Z-системы. "Цель - задача" → "Цель - задача" →"Цель - задача" →"Цель - задача". На дне это вложенности находится наименьшая "система" - исполняющее задачу действующее лицо или единица оборудования (Агент, Actor). Задача наименьшего уровня - задача агента/актора - называется Задание. В нотации BPMN - это Task.
Проблема. В российском управленческом дискурсе эквивалент тогафовского CONCERN, то есть некая обеспокоенность, интерес заинтересованного лица (то есть concern не может сущестовать без его носителя). Слово проблема указывает, как правило на тот класс когнитивных явлений, которые не имеют прямого отображения в класс решений [и даже, к сожалению, не указывает на то, чьи это проблемы]. Если такое отображение есть, то проблема была бы отнесена к классу целей. Тем не менее в российской практике любят пары проблема-цель и, нередко, в отношениях многие-ко-многим. Основанием для парного рассмотрения проблема+цель является желание указать нерешаемость проблемы, иногда нужная "решаемость" возникает не сразу, а со временем, поэтому проблема может некоторое время (иногда и длительное) существовать без связанных с нею целей. Здесь следует учитывать, что как только к проблеме добавили цель, значит цель поставлена перед какой-то системой, способной акцептовать цель, а значит и решить проблему. То есть прибавление к проблеме цели переводит проблему в пространство решений. Таким образом проблема специфицируется тремя компонентами:
Нормативка - документ, в котором описаны указания на тему, что делать можно, что делать нужно, что делать нельзя. Указания могут быть разной степени детальности. Нормативка - агрегатный класс, который имеет целью зафиксировать орган, дату, версию принятия нормативного документа. Для применения нормативки в архитектуре она должна быть декомпозирована на:
Приказ, распоряжение - документ, фиксирующий набор целей или задач.
Заинтересованное лицо (стейкхолдер) - лицо, устранение которого из рассмотрения создает нам карьерные проблемы. А может быть у него есть деньги... Если серьезно - это любое лицо, интересы или требования которого вы должны учитывать при проектировании, то есть это может быть и рядовой пользователь.
Приказ, распоряжение, нормативка - зачастую есть агрегатные архитектурные блоки, которые не пригодны для архитектурирования.
Деятельность - весьма сложное явление для моделирования. Однозначных и универсальных способов формализации не существует. Но есть удобные на тот или иной случай. Как минимум следует различать:
Деятельность может быть выражена радоном CAPABILITY (способность).
Полное описание классов этого домена и их онтологии доступно в полной версии МАРФА.
Информационная система - чаще просто система. Не всегда просто установить границы информационной системы и тем самым сложно дать ей определение. ГОСТ 34-й серии толкал нас в АСУ, расширяя понятия системы за пределы программного кода и включая в понятие системы и информацию, и методологию, и персонал, и процедуры. В рамках МАРФА система агрегирует (композирует) то, что может быть каталогизировано в виде слоев архитектуры:
Наш опыт в каталогизации систем показывает, что если на предприятии есть, к примеру 100 систем, то минимум 60-70 из них однозначно вычленяются, то есть все признают их атомарными и конкретными системами. На базе этого множества как раз и получается сформировать критерии или определение на тему, что мы будем относить к системам на данном предприятии. Может оказаться, что на каком-то предприятии и каждая таблица в Excel - тоже отдельная система.
Примечание: в российской практие часто можно услышать такое понятие как "функциональная подсистема". Отложим это на будущее, как вид абстрактного архитектурного блока.
Платформа. В домене информационных технологий - это информационная система.
Функция системы. Наш опыт работы показал, что функция систем - это в большинстве случаев не то, что выполняет система, а та польза, которую получает пользователь от системы или, иными словами, функция, которой наделяет систему пользователь. Так например, стул или пень в лесу не имеет функции "поддерживать сидящего". Точно также и система типа CRM не выполняет функцию типа "учет клиентов" - это пользователь с помощью системы реализует свою потребность в учете. Если же мы хотим зафиксировать именно функции системы, то это чаще всего будут CRUD-методы по классам данных в системе. Использование класса "сервис системы" тоже может быть альтернативой для описания поведения именно системы, а не пользователя. Но наименование сервиса зачастую тоже формулируется с точки зрения потребителя сервиса и слабо (сильно слабее) указывает на само поведение системы.
Мы приводим этот раздел в конце, чтобы зарнее не напугать последовательного читателя, изучающего фреймворк от первой страницы к последней.
Объекты не есть реальность - это плод нашего воображения, точнее сказать, наше коллективное согласие на определенный устойчивый вид воображения. Для начала - см. трактат Витгенштейна. Можно заглянуть и сюда для старта, чтобы понять всю глубину проблемы за 30-60 минут - онтология понятий в ЛФТ.
У кого нет времени - осознайте простой пример. Перед вами на столе стоит кусок стекла такой формы, что в него можно налить что-то. Это предмет или изделие венецианского стеклодува. Кто-то скажет, что это просто стакан. Значит объект - это стакан и из этого факта следуют такие свойства, как возможность пить из стакана воду. Кто-то скажет, что это бокал. Значит объект - это бокал и его можно использовать как для сервировки стола, так и для употребления вина. Кто-то скажет, что это - произведение декоративно-прикладного искусства. Значит объект - это предмет искусства и им стоит любоваться в коллекции других подобных предметов. Как видим, кусок стекла воронкообразной формы - это предмет, который может быть весьма разными объектами, то есть его можно отнести к разным классам в зависимости от потребностей моделировщика.
