ArchiMate

оборудование, на котором работают программы. Все эти три уровня показаны на одной диаграмме, это и было главным достижением предложенного подхода и языка.

В 21 веке предприятия координируются уже не столько непосредственной коммуникацией людей, которые держат основной объем координационной информации в головах, сколько опосредованной компьютерами коммуникацией и хранящейся в компьютерах координационной информацией. Архимейт (как и вся дисциплина архитектуры предприятия) учитывает этот факт — но Архимейт стимулирует архитекторов не забывать о том, что кроме компьютеров и программ на предприятии есть ещё и люди (удивительно, но чаще архитекторы предприятия забывают про людей, прописывая подробно решения IT-архитектуры, а не забывают про IT-архитектуру, прописывая подробно деятельность людей. Якобы “архитекторы предприятия”, а на самом деле “айтишники” иногда забываются до того, что “архитектура предприятия” воспринимается ими чуть ли не как синоним “архитектуры IT-решения”. Это неправильно!).

Далее рассказ про Архимейт будет намеренно упрощён и в нём будет максимально использована неспецифическая терминология. В качестве упражнения попробуйте рассказать о всём том же самом с использованием понятийного аппарата настоящего курса (и заодно обратите внимание: все терминологические сложности настоящего курса системноинженерного мышления вполне можно обходить, если обращаться к определённой аудитории — но при этом сразу будет теряться общность мышления о самых разных системах!).

Зачем нужен Архимейт

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

Архитектор не гроссмейстер — он не умеет играть без доски, он использует диаграммы, чтобы смотреть на них и думать. Тем самым работа его двухтактна: писать диаграммы и затем читать их. Эти диаграммы для него — "экзокортекс", продолжение его мозга, участвующее в размышлении. Он думает, ставя перед собой (или перед другими — если организуемое им размышление коллективное) вопросы, появляющиеся от соприкосновения формализма Архимейта с неформально устроенной жизнью предприятия. Тут неважно, это только проектируемая будущая жизнь, или реальная уже идущая жизнь (всё одно мы и об одной, и о другой узнаём только то, что думают об этой жизни люди, а не то, что было или есть "на самом деле"). Мысль — диаграмма — вопрос — мысль.

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

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

Механизм типов подразумевает задание главным образом одного простого вопроса, ответ на который обычно очень сложно получить. Для каждого встречающегося в жизни объекта спросите "что это?!", "часть чего это?", "с чем это связано?". Подберите тип Архимейта. Получите удовольствие: до вас мало кто задумывался, "что это". Ответ на этот вопрос может оказаться очень нетривиальным, а получение этого ответа заставит задать десятки других вопросов.

Вторым механизмом является предписанное именование. Если у вас практика — то это отглагольное существительное, например, "полевой инжиниринг" (а хоть эта "отглагольность" и идёт тут от английского). Существительные плохо ассоциируются с "последовательностью выполнения", кооперативными цепочками работ разных людей. А вот процессы — это глагол, и придётся написать "инжинирить в поле". Вы этого хотели? Если нет — то у вас действительно процесс, вы уверены? Если правильный вопрос к объекту не "что делать?" — то придется признать, что речь идет не о процессе, а о чём-то другом (практике? роли? — это все "промежуточные" типы между чистой работой и чистым выполнителем).

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

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

— а не гадать. А потом исправлять диаграмму.

Моделирование идёт циклически: поглядел на жизнь и что-то про неё понял, затем записал понятое на диаграмме. Поглядел на диаграмму — нашёл ошибки. Поглядел на жизнь — исправил ошибки в диаграмме. Поглядел на диаграмму — понял что-то про жизнь. Записал понятое на диаграмме — и опять начал искать ошибки. Результат такого процесса довольно неожиданный: архитектор вдруг начинает чтото понимать про жизнь предприятия едва ли не глубже, чем непосредственно участвующие в деятельности люди. Архитектор находит в действующих предприятиях бессмысленные работы (activity, кстати, рекомендую переводить как "работы" — родовой термин для всех вариантов поведений), странные группировки объектов деятельности, лишних деятелей. Он же находит их в проектах предприятий — как своих проектах, так и в проектах других людей. Формализм Архимейта заставляет продумывать то, что прошло бы мимо внимания. Ошибки и

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

Особенностью моделирования на Архимейте является его кажущаяся аскетичность. Моделирование делается намеренно неподробно (при всех заявлениях, что "при потребности вы сможете выразить все нужные детали). Типов объектов и отношений в Архимейте намеренно мало, авторы заявляют что сознательно пошли на удовлетворение только 20% потребностей архитекторов в выразительных средствах (эти 20% покрывают 80% всех случаев, а остальные 80% "выразительности" ушли бы на оставшиеся 20% случаев — эти "остальные выразительности" просто убрали из языка). Но вся эта неподробность и аскетичность кажущаяся. Архимейт заставляет писать суть дела — как бы банально и просто эта суть ни выглядела на диаграмме. И — чудо, чудо — эта банальная суть дела всегда вызывает много банальных вопросов как к жизни, так и к диаграмме. Архимейт создан так, чтобы задавать правильные вопросы. Ответы на эти вопросы почему-то оказываются небанальными, и в этом главная сила Архимейта.

Обратите внимание, я тут удержался, и ничего не говорил про "онтологию". Но для тех, кому это слово не чуждо, я таки скажу: типы Архимейта таки представляют собой онтологию предприятия — понимание авторов Архимейта того, что можно найти на любом предприятии. Это означает, что на любом предприятии можно найти объекты деятельности и деятелей, процессы и данные, функционал программ и узлы IT-оборудования. Архимейт заставляет находить в окружающем мире именно эти (а не какие-то другие — например, "трансакции DEMO") объекты и отношения. Именно задание этой формальной онтологии и порождает вопросы, прежде всего классический онтологический вопрос про обнаруженный в жизни объект: "что это?!".

Формальные диаграммы из типизированных объектов и отношений и предписанные виды имён направляют архитектурное мышление, они ведут его по рельсам (да, так жестко!), предусмотренным авторами Архимейта. Это не так плохо, ибо если никак не ограничивать мышление архитектора, оно будет крайне нетехнологично, т.е. хорошие результаты не будут предсказуемо повторяться: один раз из ста у одного архитектора вдруг получится гениальный результат в сто раз лучше, чем с использованием Архимейта (обычно такие гении как раз и создают Архимейты и другие архитектурные языки), а девяносто девять раз у девяносто девяти архитекторов из ста получатся результаты сильно хуже. "Неограниченные Архимейтом архитекторы" в меру своей гениальности найдут на предприятиях "организационный флогистон", отношение "духоподъёма" между людьми, да и вместо "людей" неожиданно могут обнаружить какое-нибудь "быдло" или "ангелоидов". Плюс нужно будет для этих "флогистона" и "ангелоидов" придумывать графическую нотацию. Архимейт даёт специальные понятийные очки, через которые предприятие видится исключительно предписанным авторами этого стандарта способом. Способ это современен: сервисы, трехуровневость реализационного описания; различение объектов работы, работ и выполнителей (людей, программ, оборудования); и т.д. Это всё контринтуитивно, и не соответствует интуиции людей, хорошо знакомых с предприятиями и хорошо знакомых с программированием. Контринтуитивность предлагаемого Архимейтом взгляда на предприятие порождает много вопросов — неформальное предприятие не укладывается в новомодные формулы. Но формальность диаграмм позволяет их хоть как-то проверять, а также соотносить с жизнью.