Архимейт по-русски: метод описания информационной структуры
Введение
Мало прочесть коротенькую спецификацию Архимейта (http://pubs.opengroup.org/architecture/archimate2-doc/m/index.html), ее нужно ухитриться понять. Ее краткость сродни краткости формул. Понятность обманчива, ибо и без того сверхабстрактные понятия используются в непривычных смыслах. Все эти вроде бы знакомые до замыленности "процессы", "данные", "программы" в тот момент, когда вы пытаетесь что-то записать на Архимейте, вдруг становятся загадочными.
Про стиль моделирования известно только, что непогружение в детали является сильной стороной Архимейта. Поэтому детальности нет ни в спецификации, ни в имеющихся в Сети немногих примерах (некоторое количество ссылок можно найти в http://ailev.livejournal.com/940819.html). Читая чужие описания на Архимейте, обучаться не получается, ибо читать почти нечего -- кто на нём пишет, тот не публичит имеющиеся у него диаграммы в силу понятных причин: в них слишком много конфиденциального.
Русскоязычной терминологии для Архимейта тоже еще нет (если не считать наших работ). Тем самым немногие разработанные в России на сегодня архимейтовские диаграммы не становятся пока "средством организации коммуникации между менеджерами и айтишниками", как это должно происходить с архитектурными описаниями. Впрочем, как указывают сами авторы Архимейта, коммуникация с топ-менеджментом и другими специалистами идет не столько по диаграммам Архимейта, сколько по специально подготовленным презентациям (на прилагающихся картинках этих авторов легко узнаётся PowerPoint), диаграммы же Архимейта должны использоваться только самими архитекторами и использоваться для "вгрызания в детали". Но есть и опыт быстрого распространения Архимейта по организациям, безо всякого PowerPoint -- просто к названиям объектов на диаграммах начали добавлять названия типов его элементов -- не в виде картинки-обозначения, а прямо текстом, в скобочках за именем (в стандарте добавлять название типа рекомендуется только для сервисов -- для какой-нибудь практики "пережёвывание" реализуемый ею оргсервис будет "сервис пережёвывания").
Если в качестве Соглашения об архитектурном описании на предприятии принять буквальный перевод на русский текст спецификации Архимейта, это не решит проблем понимания, а только добавит непонимания (хотя все учителя информатики и говорят, что дети осваивают языки программирования с русскими ключевыми словами быстрее, чем с англоязычными -- но какая разница, на каком языке вы не понимаете, что такое "объект бизнеса"?).
Тем не менее, проверено: разобраться в том, как разрабатывать архитектурные описания на Архимейте тоже можно, только это требует времени. И даже свободный редактор Archi поддерживает русскоязычные диаграммы и русифицирован (http://ailev.livejournal.com/988360.html), он вполне удобен в работе: чтобы начать использовать Архимейт.
Я решил написать серию разъяснений для тех, кто начинает осваивать Архимейт и хочет обсуждать архитектурные описания на нём по-русски. Переводить спецификацию я считаю пока бессмысленным занятием, но я постараюсь что-то во ней разъяснить и дать предложения по терминологии. Текст, тем не менее, не предназначен для изучения Архимейта с нуля: предполагается, что читатель хотя бы прочел спецификацию и ознакомился с тамошними примерами.
Как всегда, мои терминологические предложения могут показаться смелыми -- от транскрипции "Архимейт" вместо банального "АркиМейт" до "объектов деятельности" вместо "бизнес-объектов" (ну, какие такие "бизнес-объекты" в АХО, научных или инженерных подразделениях? Мне уже клиенты делали за это "бизнес" замечания, когда я оговаривался вслед за англоязычным оригиналом).
Метод описания информационной структуры
Методы описания (viewpoints) Архимейта представляют собой фильтры, наложенные на полное архитектурное описание из всех типов архимейтовских элементов и отношений (модель) -- они оставляют видимыми в соответствующем частном тематическом описании (view) только небольшую из имеющихся в полной модели часть архимейтовских типов элементов и отношения только между ними. Эта фильтрация делается, чтобы еще больше упростить и так предельно упрощенные диаграммы архитектурного описания. Архимейт рекомендует использовать 18 основных методов описания (basic viewpoints, пункты 9.4.x в спецификации http://pubs.opengroup.org/architecture/archimate2-doc/chap08.html), то есть 18 сочтенных авторами стандарта методов фильтрации полного набора архитектурных объектов и отношений между ними. Дополнения Архимейта добавляют к этому числу (http://ailev.livejournal.com/978200.html).
Архимейтовский метод описания информационной структуры (Information Structure Viewpoint, пункт 8.4.15 в http://pubs.opengroup.org/architecture/archimate2-doc/m/chap08.html) оставляет для рассмотрения только объекты, данные и информобъекты, плюс рабочие продукты для объектов деятельности, а также возможность указать значение.
Вот мета-модель (понятия и их связи) метода описания информационной структуры и пример ее использования:
Вот пример полного описания простейшей архитектуры ("я готовлю архитектурные описания"):
А вот как из него образуется описание информационной структуры:
Информационная структура состоит главным образом из информации, в разной степени воплощенной в реальности (т.е. на разных уровнях работы с этой информацией по-разному реализованной), т.е. в ней представлены документы, газеты, накладные, фотографии, базы данных, карты, матрицы, данные, аналоговые и цифровые записи на носителях, файлы и т.д..
С точки зрения Архимейта вся эта информация представляет собой объекты -- те "логические объекты", с чем и над чем работают живые люди, компьютерные программы и компьютерное оборудование. Это "пассивные объекты работы" -- они сами никакой работы не выполняют, и не могут сами запустить другую работу на выполнение. Программа в момент её разработки -- пассивные "данные", а когда программа уже работает, то она является уже выполнителем, элементом "программа" (наряду с другими выполнителями работ -- ответственными и ролями, "железом"). И данные и программы тем не менее реализуются своими информобъектами, которые менее абстрактны (менее "логические", как говорит о них спецификация, они более реальны и привязаны к физическому "железу"), а выполнителем работ по изменению информобъектов считается оборудование. Слово "структура" противопоставляется в Архимейте "работам" (behaviour) -- для Архимейта важно различать, является ли какое-нибудь отглагольное "управление" выполнителем работы (например, подразделением) или объектом работы (например, данными) или собственно работой. Русский язык в этом плане весьма хитёр и опасен отклагольными существительными: управление поставками может означать как имя роли (профессионализации в управлении практики), имя департамента (ответственное подразделение), так и имя практики (работы). Впрочем, и имя программ ("софта"), так и имя функционала программы (потенциальная работа, которая будет выполняться этой программой) -- они тоже попадают в эту ловушку отглагольных существительных. Нужно различать, говорится ли о работе или выполнителе этой работы, или объекте, с которым работают.
Информация в Архимейте одновременно рассматривается на разных уровнях ее воплощения в физическом мире (на носителе). Базовых уровней намеренно всего три (Архимейт, как всегда, упрощает): деятельности (людей), работы "софта" и работы "железа". Одна и та же информация на этих уровнях, представленная в них типами элементов "объекты", "данные", "информобъекты", связана между уровнями отношениями реализации (realization), т.е. отношениями приближения к реальности, воплощению в физическом мире. На одном же уровне работ отражающие информацию элементы обычно между собой связаны отношениями специализации (specialization, подклассы-надклассы или род-вид или категория-подкатегория), состава (часть-целое, composition), объединения (включения в какое-то множество, aggregation).
Тем самым информация на диаграммах выстраиваются в цепочки отношений реализации, проходящие через разные уровни Архимейта. Более абстрактный объект деятельности ("описание местности", "информация о бюджете" -- как говорят люди об этих объектах) представляется на уровне "софта" много менее абстрактными данными ("данные карты в полярных координатах", "данные дебетовых и кредитных счетов" -- как говорят об этом программисты, подразумевая какой-то формализм описания данных), которые в свою очередь могут описывать на уровне "железа" конкретное структурирование информации на носителе в виде информобъектов ("записи карты в GIS логистического подразделения", "подраздел бюджета на файловом сервере" -- так говорят системные администраторы, и обычно можно ткнуть пальцем на то устройство, где расположены эти информобъекты).
Архитектура в Архимейте делается в терминах классов (видов объектов, подразумевающих наличие многих экземпляров в реальности), а не экземпляров (имеющих "серийный номер"). То есть любая Архимейт-архитектура делается как "типовая", несмотря на то, что она обычно разрабатывается для уникального предприятия. Это означает, что на диаграммах показываются только типизированные виды информации, но не экземпляры соответствующих видов. Каждый объект Архимейта по определению является "типовым", и в реальности ему соответствуют множество экземпляров объектов -- но с этим легко смириться, если это "множество" считать состоящим из ровно одного экземпляра. Особо отметим, что названия этих видов (т.е. множеств) объектов пишется в единственном числе, а не во множественном -- это не соответствует русскоязычной традиции именования множеств, но в Архимейте имеет свои преимущества.
Итак, три уровня (layer) работ Архимейта:
1. Уровень деятельности
Деятельность (в Архимейте это businsess, "дело") -- это в чем-то повторяющиеся (типизированные -- то есть с возможностью выделить паттерны повторений, т.е. описать класс для этих повторений) работы людей в области бизнеса, инженерии, науки, бухгалтерских расчетов, разработки софта и т.д.. Работа людей предметна, она описывается обычно в терминах предметов окружающего мира: бизнесмены говорят о сделках, бухгалтеры о планах счетов, программисты о кусках кода и архитектурах, инженеры об оборудовании и технологиях. Люди в Архимейте -- это "ответственные", не сами люди, а их должностная позиция (помним, что в Архимейте работют с классами, а не экземплярами класса). Людей в позиции "ответственных" (actors) не волнуют все эти "данные" и оборудование для "информобъектов". Ответственных не волнует обычно "трек" как файл на флешке, их волнует содержание, важное для деятельности: песня и её жанр, логические объекты. Их не волнуют данные о громкости -- их волнует сама громкость. Люди обычно не говорят "листы бумаги, на которых напечатаны чертежи", или "данные чертежей". Они даже не говорят "чертежи", а сразу обсуждают нарисованные на них трубы и стены.
Уровень деятельности сам по себе можно специализировать -- называть его по типу деятельности: инженерный, бухгалтерский, исследовательский, торговый и т.д. Собственно, и объекты деятельности тоже можно специализировать в инженерные, бухгалтерские, исследовательские, торговые и т.д.. -- отражающие разные интересы разных стейкхолдеров (заинтересованных сторон).
Если люди начинают обсуждать то, как их информация записана или на каком она носителе -- то в этот момент они уже не люди самой организации (ученые, инженеры, бухгалтеры, клерки), а поддерживающие их айтишники, чей уровень -- работа программ (программисты, инженеры данных, электронщики, системные администраторы и администраторы баз данных). Даже "чертежи" как предмет своей деятельности говорят не инженеры, а поддерживающие их чертёжники, которые сами по себе замаскированные айтишники прошлого поколения IT-технологий. Впрочем, для таких разговоров людей об их восприятии носителей информации есть специальный тип -- представление (representation). Представление информации её также реализует (воплощает в реальности).
Уровень деятельности полной архитектуры предприятия (enterprise architecture) сам по себе называют архитектурой деятельности (business architecture), а два остальных уровня вместе -- "софта"/application и "железа"/technology -- называют архитектурой IT-решения (solution architecture). Архимейт является одним из первых архитектурных языков, который поставил задачу совместного описания по единым принципам и в едином языке как архитектуры деятельности, так и архитектуры IT-решения. Число типов элементов Архимейта для архитектуры деятельности -- 17, а для архитектуры IT-решения -- тоже 17. Этот паритет не случаен, ибо именно так и задумывалось авторами: поддержание равноправного диалога между теми, кто организует работу людей и теми, кто организует работу "софта" и "железа".
Работы людей ведутся с логическими объектами деятельности, которые в Архимейте, как указано в спецификации, обязательно имеют информационную природу (объекты представляют собой только информацию о настоящем объекте, а не железный или даже бумажный объект -- объекты это не "рабочие продукты"). В Архимейте нельзя показать саму гайку, которая лежит на складе, но можно показать информацию об этой гайке (например, в складском учёте).
Тем не менее, мы рекомендуем именовать объект так же, как реальный объект. То есть вы пишете
-- "счёт" (подразумевая выписанную вам сумму -- неважно в каком рабочем продукте (representation) хоть на бумажке, хоть в кассовом аппарате, хоть устно сказанную, хоть в базе данных. Формально имеется ввиду информация о выставленной вам для платежа сумме),
-- "АЭС" (формально имеется ввиду информация, описывающая АЭС, а не сама железка),
-- "архитектура предприятия" (формально имеется ввиду "архитектурное описание предприятия", но слово "описание" люди любят опускать -- они обсуждают описанное на диаграммах, их много меньше интересует сами диаграммы).
На формальную сторону вопроса можно при этом не обращать внимания, пусть этими "формальностями" занимаются учёные-онтологи. Для знающих про альфы из OMG Essence -- объект это, конечно, альфа -- не рабочий продукт!
На уровне деятельности действуют сотрудники предприятия (инженеры, клерки, специалисты), а не айтишники. Они поэтому говорят не о данных и их представлении/реализации в оборудовании (информобъектах), а о реальных объектах -- и поэтому называют сами эти объекты, а не их описания. Имя объекта деятельности лучше делать существительным.
Люди обсуждают только содержательные проблемы своих работ, связанные с положением дел в реальном мире (например, для извещения -- о чем это извещение, для отчета о прибылях и убытках -- какие были прибыли и каковы убытки, для технологической части проекта АЭС -- какие давления в каких трубопроводах, какой емкости резервуары). Ответственные за те или иные работы не ведут разговоров о моделях данных, физических носителях информации, если их не вынуждают к этому айтишники. Разговор о "бумажной странице в годовом отчете" (рабочий продукт для годового отчёта, их для объекта "отчёт" может быть десяток разных видов) -- это больше о том, какое можно ожидать "оформление" и оценку связанного с этим оформлением содержательного поведения, нежели попытка обсудить носитель данных для данных годового отчёта и связанную с ним физическую логистику.
Но нельзя сказать, чтобы архитектора предприятия не волновал сам вид, в котором эта "АЭС" или "счет" или даже "архитектура предприятия" воспринимались бы работающими в предметной области предприятия людьми (а не программистами и сисадминами, ответственными за IT-решение для работы таких людей). Для указания воспринимаемого людьми вида представления объекта деятельности служит специальный тип Архимейта: "рабочий продукт" (representation). Если нужно показать, в каком виде инженеры работают с геометрической коллизией, можно в диаграмме Архимейта так и записать: "инженерная коллизия в 3D (инженерный объект)" "ассоциирована с" "изображение на экране с подсветкой конфликтующих элементов (рабочий продукт)". Объект "логический", рабочий продукт -- "физический". Если речь идет о "счёте", то он может быть представлен на экране, а может быть распечатан. Обратите внимание, во всех этих случаях речь не идет о данных счёта (данные интересуют айтишников). Речь идет лишь о способе, которым абстрактный объект деятельности может быть воспринят людьми, способе выражения логического объекта в жизни.
На уровне деятельности важны лишь рабочие продукты, которые воспринимаются людьми непосредственно (или при помощи простейших инструментов). Примеры:
-- объект деятельности: извещение. Возможные представления в виде рабочего продукта: поп-ап окно, письмо, громкий вой сирен, распечатка на бланке.
-- финансовый объект: отчет о прибылях и убытках. Возможные представления в виде рабочего продукта: страница в годовом отчёте, страница вебсайта, электронное письмо, ".pdf документ" (который отличается от вордового документа по важным для людей признакам -- и "внешний вид" при просмотре специальной программой, и невозможность отредактировать), MS Word документ (который наблюдаем человеком только в окошке специальной программы, понимающей файлы этого формата).
-- инженерный объект: технологическая часть проекта АЭС. Возможные рабочие продукты: сдаваемые в архив тома документации, совокупность баз данных.
Поскольку рабочий продукт является более конкретным, нежели абстрактный объект деятельности, то говорят, что он "реализует" объект -- и поэтому связь между объектом и его рабочим продуктом на диаграммах выражается отношением реализации.
Последний элемент Архимейта, допустимый в описании информационной структуры -- это "значение" ("смысл", meaning). Этот "смысл" появился из-за того, что в разных ситуациях у одной и той же информации бывают разные значения/смыслы (так, объект "договор" для одной ситуации означает обязанность заплатить, а для другой -- обязанность поставить сервис). Это "значение" может быть приписано к любым архимейтовским объектам, чтобы уточнить их смысл в изображаемой ситуации.
Доступ к объекту (например, создание, чтение и запись) могут быть у оргработ (работ уровня деятельности) -- процесса, практики (business function), коллегиального процесса, события или оргсервиса.
Объект может иметь отношения связи (просто "связь" -- без уточнения содержательной сути отношения), специализации, объединения или состава с другими объектами деятельности.
2. Уровень "софта"
Уровень "софта" (application layer) -- это вотчина программистов, модельеров данных и разнообразных "аналитиков", которые обеспечивают вычисления, формальные трансформации данных, автоматизированную генерацию отчётов, преобразование форматов данных, выполнение программами производственных функций и прочую работу компьютерных программ над данными. Термин "программа" (вместо очевидного "приложения") мной специально был выбран так, чтобы показать суть -- тонкости айтишного языка не предмет заботы ответственных (actors) подразделений предприятия, если это не ответственные айтишные подразделения. Ибо в программах (на своих айпадах), футболе и сексе разбираются уже все люди (и начальники, и исполнители), а вот в приложениях "обработки данных" в промышленных масштабах -- уже нет.
Данные -- это представление (реализация) информации логических объектов формальным способом, подходящим для обработки компьютером. Сам этот формальный способ определяется моделью данных (схемой базы данных, форматом файла, принятым соглашением о кодировании, метаданными и т.д.). Разные модели данных -- разные данные. Но эти разные данные вполне могут соответствовать одному объекту. Примеры данных : запись о клиенте, база данных, репозиторий PLM, записи измерений датчика давления и т.д..
Архимейт рекомендует, чтобы объект данных имел какое-то значение для людей-ответственных, а не был просто важен для работы программ (этим еще раз подчеркивается, что Архимейт хочет совместить архитектуру деятельности и архитектуру IT-решения, а не быть просто средством записи только архитектуры IT-решения). Имя данных должно быть преимущественно существительным. То, что данные как-то обособлены (набор данных, объект данных, порция данных и т.д.), это очевидно и не требует отражения в названии.
Архимейт не имеет штатных средств для указания каким-то данным их модели данных, различения справочных или иных данных в их взаимосвязи. Это всё можно показать отношениями связи (которыми можно показывать любые отношения) между разными элементами данными, отображающих эти важные для обсуждения уровня обработки данных виды данных. Нет и средств детального моделирования данных (указания атрибутов, таблиц, спец.отношений для данных и т.д.), но данные могут иметь с другими данными отношения связи, специализации, объединения или состава.
Данные сами по себе абстрактны, у них может быть множество реализаций на разных носителях (и даже "на разных местах" одного физического носителя). Две копии на разных носителях реализуют один и тот же объект данных. Тем самым данные на уровне обработки данных никак не зависят от носителя -- связь данных с носителем (отношение реализации) при надобности прописывается явно, как и связь данных с объектом деятельности (также отношение реализации).
Наличие в Архимейте как рабочих продуктов для людей, так и данных-информобъектов (рабочих подуктов для программ) как двух вариантов реализаций для объектов деятельности существенно путает. Я предлагаю простой критерий: наличие или отсутствие модели данных (схемы базы данных, метамодели, онтологического описания и т.д.) -- т.е. наличие или отсутствие формализма кодирования информации в цифровой (биты и байты) вид. Так, "поп-ап-окно", "распечатка" и даже ".pdf файл" (если никого не волнует модель данных .pdf, чтобы какое-то приложение с этой моделью данных разбиралось) -- это не данные для "софта", а рабочий продукт для людей-"ответственных". А вот если модель данных есть, и программы что-то тематическое вычисляют/обрабатывают с использованием этой модели (а не просто "отображают" или "конвертируют" из одного формата в другой), то это именно данные -- понятные для программ.
3. Уровень "железа"
Уровень "железа" (technology layer) -- это вотчина сисадминов и электронщиков. Никакой деятельности, никакой обработки данных -- зато сервера, системный софт, логические линии связи и реализующие их физические сети, запасы носителей данных, размещение по площадкам. Это наиболее конкретный ("физический") из трех уровней Архимейта, он реализует информационные абстракции двух других уровней -- программ и деятельности.
На этом уровне данные привязаны к месту, на которое можно показать пальцем (иногда говорят "погрузить в тачку" или даже "пнуть", имея ввиду принадлежность физическому миру). Именованный кусочек носителя данных в Архимейте -- это информобъект (artifact). Примером информобъекта может быть файл, дисковая директория, репозиторий PLM -- понимаемые как часть физического мира, т.е. части носителей данных с каким-то физическим положением магнитных доменов или распределением электрического потенциала.
Информобъекты на носителе реализуют не только данные, но и программы (как исполняемые данные -- программный код, развернутый на серверах). Более того, данные и программы могут быть реализованы многими информобъектами. Пример:
Повторимся: указание типа объекта после его имени существенно добавляет к пониманию диаграмм Архимейта, не пренебрегайте этим.
Если известно имя файла, то им и можно обозначать объект на носителе (например, "файл piping.vue").
* * *
UPDATED для новой версии русскоязычной терминологии -- http://ailev.livejournal.com/988360.html (и там ссылки на остальные тексты "Архимейт по-русски"), и даже версии 1.1 (http://ailev.livejournal.com/1205591.html) но картинки в данном постинге не адаптированы к новой версии терминов