blogs.trust.ua/levenchuk/

Как и в любом другом языке, в Архимейте можно влёгкую вместо "мама мыла раму" написать "рама мыло мамы", или вообще неправильно использовать слова для обозначения реалий окружающего мира. Увы, чтения спецификации недостаточно, чтобы избежать этих ошибок: в спецификации написано, как нужно -- и не предупреждается, как не нужно моделировать. Так что я приведу тут несколько наиболее распространенных ошибок, которые делают новички. Считайте, что это своеобразный чеклист: проверяйте, есть ли эти ошибки на ваших и чужих диаграммах.

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

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

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

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

Почему важно отображение всех этих уровней одновременно? Потому что вам придется отвечать на очень и очень неудобные вопросы про несоответствие деятельности, обработки данных и оборудования. Ибо на диаграммах это несоответствие становится хорошо видным и самые разные люди начинают задавать самые разные вопросы. Отвечать на эти вопросы архитектурными решениями (менять диаграммы с "as is" на "to be", а затем планировать работы по переходу к "to be") -- это и есть работа архитектора предприятия.

2. Очень много ошибок связаны с непониманием сервис-ориентированности Архимейта. Вы должны понимать, что на предприятии все кого-то обслуживают, а не самодостаточны. Архимейт требует сформулировать в явном виде: чем занят тот или иной кусок предприятия, отображенный в архитектуре -- какой сервис он предоставляет "наружу", и как этот кусок предприятия устроен "внутри", чтобы иметь возможность предоставлять этот сервис.

Первая из ошибок, которую делают новички -- это попытка использовать "продукт" (product) вместо "объекта деятельности" (business object). Самое маленькое следствие этой ошибки -- это отказ редактора диаграмм прописывать необходимые отношения. Реакция на это архитектора-новичка: "ваш софт сломался". Ещё бы! Продукт в Архимейте -- это набор сервисов и контракт. То есть продукт в Архимейте -- это по сути поведение (сервисы), а не структура! Это не "чугунная чушка", а "поставка и обслуживание чугунной чушки", это не "кредит", а "предоставление кредита".

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

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

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

3. Неразличение группы описаний (view) и полного описания в ходе редактирования диаграмм. Полное описание -- это все элементы и связи. Тематическая группа описаний (например, группа описаний информационной структуры) -- отфильтрованные из полного описания элементы. Редакторы Архимейта умные -- они умеют поддерживать общее описание, показывая разные его части на разных диаграммах. Новички часто это игнорируют -- и поэтому вместо использования в разных группах описаний одного и того же элемента порождают новый в каждой группе описаний, причем с одним и тем же именем. Да и не только новички это делают! В примере архитектурного описания для редактора Archi тоже встречается такая ошибка: один и тот же элемент архитектуры в разных группах описаний оказывается не одним и тем же, а разным.

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

Удаление элемента происходит либо из полного описания (в Archi это delete from model), либо только из группы описаний (delete from view). Если вы случайно удалили элемент из архитектурной модели, то вам нужно его завести на диаграмме этой группы описаний заново, "с нуля". Если вы случайно удалили элемент из группы описаний, то вам его нужно вытащить из модели на полное описание -- создание с нуля как раз и породит дублирование.

Элементы дерева модели, которые в Archi даны курсивом, означают такие элементы, которые просто не были выведены ни в одной из тематических групп описаний. Но они не удалены из модели! Их просто отфильтровали из всех диаграмм. Новичкам к такому поведению редактора нужно привыкнуть, но пока этой привычки не появилось, управление конфигурацией вашим архитектурным проектом по мере его разрастания будет проблематичным.

4. Новички (которым к этому моменту обычно промыли мозги "процессным подходом") начинают архитектурную работу с выявления (или придумывания) процессов. Как ни странно, это ошибка (см., например,http://ailev.livejournal.com/867599.html). Начинать всегда нужно с элементов пассивной структуры и предоставляемых сервисов. Процессы появляются потом, когда вы понимаете, что вам нужно делать с пассивной структурой, чтобы добиться полезной работы сервиса.

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