Архимейт по-русски: ошибки начинающих
UPDATED для версии локализации 1.0 -- http://ailev.livejournal.com/988360.html
UPDATED для версии русификации 1.1 -- http://ailev.livejournal.com/1205591.html
Как и в любом другом языке, в Архимейте можно влёгкую вместо "мама мыла раму" написать "рама мыло мамы", или вообще неправильно использовать слова для обозначения реалий окружающего мира. Увы, чтения спецификации недостаточно, чтобы избежать этих ошибок: в спецификации написано, как нужно -- и не предупреждается, как не нужно моделировать. Так что я приведу тут несколько наиболее распространенных ошибок, которые делают новички. Считайте, что это своеобразный чеклист: проверяйте, есть ли эти ошибки на ваших и чужих диаграммах.
1. Описывается только один уровень архитектуры -- чаще всего уровень "софта". Большинство любителей Архимейта вышли из программистов, обозвали себя "бизнес аналитиками" (даже не задумываясь над тем, причем тут вообще "бизнес") и воспарили мыслью над рутиной "железа" -- поэтому на их диаграммах обычно изображены только абстрактные программы и данные, никак не связанные с деятельностью, и не реализованные ни на каком "железе". Это главная ошибка многих и многих "архитекторов предприятия" -- и именно для борьбы с этой ошибкой был придуман Архимейт.
Очень трудно, почти невозможно удерживать в голове и деятельность людей, и работу "софта", и работу "железа" со связью и системным софтом. Но если вы этого не делаете, то вы не архитектор. Извинений для этой ошибки "одноуровневости" нет, следствия ужасны.
Редко-редко бывает и другой вариант: Архимейт используется только для отображения деятельности людей, без учета работы программ. Такая "человечная одноуровневость" не менее плоха, чем одноуровневость отображения только работы программ -- ведь информационные технологии и правильные приложения существенно меняют сам способ работы, существенно меняют деятельность. Организация работы с использованием программ-экскаваторов существенно отличается от организации работы с программами-лопатами (не меньше, чем организация работы землекопов в аналогичном случае), но именно это не будут учитывать те немногие "бизнес-аналитики", которые вышли не из программистов, а из выпускников программ MBA -- и которые не утруждают себя разбирательством с возможностями софта и их влиянием на организацию дела.
Чтобы кто-то изобразил в качестве архитектуры предприятия только один уровень "железа" -- этого почти не бывает, но все учебники и блоги практикующих архитекторов предупреждают о пагубности игнорирования этого уровня при изображении двух других. Более того, они советуют моделировать оборудование и системный софт довольно детально, иначе не избежать проблем с производительностью и масштабированием.
Почему важно отображение всех этих уровней Архимейта одновременно? Потому что вам придется отвечать на очень и очень неудобные вопросы про несоответствие деятельности, её поддержки "софтом" и поддержки софта "железом". Ибо на диаграммах это несоответствие и отсутствие надлежащей поддержки становится хорошо видным и самые разные люди начинают задавать самые разные вопросы. Отвечать на эти вопросы архитектурными решениями (менять диаграммы с учётом базисов "as is" на "to be", а затем планировать пакеты работ по переходу к "to be") -- это и есть работа архитектора предприятия.
2. Очень много ошибок связаны с непониманием сервис-ориентированности Архимейта. Вы должны понимать, что на предприятии все кого-то обслуживают, а не самодостаточны. Архимейт требует сформулировать в явном виде: чем занят тот или иной кусок предприятия (часть системы!), отображенный в архитектуре -- какой сервис он предоставляет "наружу" (чем бы эта "наружа" не была), и как этот кусок предприятия устроен "внутри", чтобы иметь возможность предоставлять этот сервис.
Первая из ошибок, которую делают новички -- это попытка использовать "оргсервис-продукт" (product) вместо "объекта" (business object). Самое маленькое следствие этой ошибки -- это отказ редактора диаграмм прописывать необходимые отношения. Реакция на это архитектора-новичка: "ваш софт сломался". Ещё бы! Продукт в Архимейте -- это набор оргсервисов и соглашение об уровне сервиса (договор, контракт). То есть продукт в Архимейте -- это по сути работы (сервисы), а не объекты или данные! Это не "чугунная чушка", а "поставка и обслуживание чугунной чушки", это не "кредит", а "предоставление кредита".
Любой кусок архитектуры зачем-то нужен -- деятельность предприятия обслуживает (service) каких-то клиентов, работа программ обслуживает (service) работу ответственных и работу других программ, "железо" обслуживает (service) работу программ и работу другого "железа". Явное указание сервисов заставляет трижды подумать, зачем нужен тот или иной кусок предприятия, какая это подсистема предприятия как системы -- и результаты этого размышления часто бывают нетривиальны и заставляют менять архитектуру (а потом менять предприятие в соответствии с этими изменениями архитектуры).
Большинство новичков-архитекторов вообще не использует сервисов на диаграммах, что строго противоречит подходу Архимейта. Отсутствие явно прописанных сервисов верный знак, что в голове архитектора нет разделения на "внутренний-внешний", то есть его архитектура несистемна (она может быть продумана, но не в терминах систем, без мыслимой "границы системы", без размышлений о целевой и использующей системе), немодульна -- со всеми негативными последствиями. Модуль-подсистема отличается прежде всего тем, что его можно заменить, не трогая всю целевую систему. Модульная архитектура позволяет заменять "внутреннее", не меняя "внешнего" и поддерживать такой стиль мышления, поощряющий замену реализаций по мере получения новой информации и открытия новых возможностей. Если использовать сервисы, то можно легко заменить архитектуру IT-решения, не меняя деятельности, можно заменить одно интеграционное решение на другое, не меняя всей архитектуры IT-решения, можно заменить "железов", не меняя обработки данных, можно добавить еще пару-тройку каналов предоставления оргсервиса и т.д.). Если не использовать сервисы, то такие замены очень трудно сформулировать и выделить из паутины объектов и отношений полной архитектуры.
Сервисы можно оказывать по разным каналам взаимодействия (в случае программ -- по разным интерфейсам) -- электронная почта, прилавок, веб-сервис и т.д.. Если есть сервис, то можно думать, как его доставить потребителям -- ибо дорог сервис доставленный, а не просто существующий в природе ("за границей телушка полушка, да рубль перевоз"). Если есть сервис, то хотя бы на мгновение можно будет подумать и о том, кому этот сервис нужен -- и учесть потребительский интерес, независимо от того, внешний этот потребитель или внутренний по отношению к предприятию, формализовано ли соглашение об уровне обслуживания (SLA), или неформально, оказывается ли этот сервис людям или программам. Если сервиса нет, то на диаграмме ничто не указывает на эти "внешние" интересы -- и резко возрастает вероятность получить никому не нужный кусок деятельности, или прикупить ненужную/неподходящую софтинку, или закупить ненужное/неподходящее оборудование в порядке реализации такой "бессервисной" архитектуры.
3. Неразличение тематического описания и полной модели в ходе редактирования диаграмм. Полная модель -- это элементы и отношения всех типов, которые есть в компьютере в данном проекте моделирования предприятия. Тематическое описание(например, описание информационной структуры, или даже описание "всего") -- это отфильтрованные для изображения на диаграмме каких-то элементов и связей из полной модели. Программы моделирования на Архимейте умные -- они умеют поддерживать общую модель предприятия, показывая разные его части на разных диаграммах. Новички часто это игнорируют -- и поэтому вместо использования в разных описаниях одного и того же элемента модели порождают новый в каждом новом описании, причем с одним и тем же именем. И модель содержит в итоге несколько штук самых разных "серверов баз данных", хотя подразумевается один и тот же, только на разных вариантах диаграмм. Да и не только новички это делают! В примере архитектурной модели для редактора Archi тоже встречается такая ошибка: один и тот же элемент архитектуры в разных группах описаний оказывается не одним и тем же, а разным.
Не нужно забывать, что по итогам архитектурной работы в редакторе (моделере) можно получить отчёт (текстовый документ с описанием всех элементов). Каково же будет ваше удивление, когда в отчете у вас окажется не одна потребная база данных, а целых пять -- по количеству дублей, которые вы сотворили в разных группах описаний. Существующие отношения не будут автоматом попадать из одной группы описаний в другую. Для этих "дублей" не будут доступны свойства и комментарии, которые вы пропишете в данном элементе (ибо не только картинками диаграмм живет архитектор, он много чего пишет про каждый элемент, кроме его графического обозначения -- и все редакторы это поддерживают).
Моделер ArchiMate пытается предотвратить такую ошибку, и при копировании не связанных с моделью элементов добавляет в имя "(копия)" -- если вы хотели просто вынести из модели элемент в новое описание, а не сдублировать его в модели, эта добавка в имя должна вас насторожить.
Удаление элемента происходит либо из модели, либо только из одной группы описаний -- и редактор предлагает два варианта операции удаления, не перепутайте их! Если вы случайно удалили элемент из архитектурной модели, то вам нужно его завести на диаграмме этой группы описаний заново, "с нуля". Если вы случайно удалили элемент из группы описаний, то вам его нужно вытащить из модели на полное описание -- создание с нуля как раз и породит дублирование.
Элементы дерева модели, которые в Archi даны курсивом, означают такие элементы, которые просто не были выведены ни в одной из тематических групп описаний. Но они не удалены из модели! Их просто отфильтровали из всех диаграмм и курсив означает только то, что они не показываются -- но хранятся. Новичкам к такому поведению редактора нужно привыкнуть, но пока этой привычки не появилось, управление конфигурацией вашего архитектурного описания по мере его разрастания будет проблематичным.
4. Новички (которым к этому моменту обычно промыли мозги "процессным подходом") начинают архитектурную работу с выявления (или придумывания) внутренних работ (процессов и практик). Как ни странно, это ошибка (см., например, http://ailev.livejournal.com/867599.html). Начинать всегда лучше с событий (http://ailev.livejournal.com/1202776.html), объектов работы и данных, а также как можно раньше предаваться размышлениям о предоставляемых вовне работах -- сервисах. Процессы и практики, функционал программ и оборудования появляются потом, когда вы понимаете, что нужно делать (какие работы выполнять) с объектами и данными, чтобы добиться внешней пользы от сервиса.
И только в самую последнюю очередь нужно назначать на работы выполнителей (когда работа понятна, можно думать, кто способен её выполнить -- а не придумывать работы под первого попавшегося пока недогруженного или уже перегруженного выполнителя). Помним, что выполнитель работы тут может быть -- это и ответственный с ролью, и программа, и "железо".
UPDATED для версии русификации 1.1 -- http://ailev.livejournal.com/1205591.html
Как и в любом другом языке, в Архимейте можно влёгкую вместо "мама мыла раму" написать "рама мыло мамы", или вообще неправильно использовать слова для обозначения реалий окружающего мира. Увы, чтения спецификации недостаточно, чтобы избежать этих ошибок: в спецификации написано, как нужно -- и не предупреждается, как не нужно моделировать. Так что я приведу тут несколько наиболее распространенных ошибок, которые делают новички. Считайте, что это своеобразный чеклист: проверяйте, есть ли эти ошибки на ваших и чужих диаграммах.
1. Описывается только один уровень архитектуры -- чаще всего уровень "софта". Большинство любителей Архимейта вышли из программистов, обозвали себя "бизнес аналитиками" (даже не задумываясь над тем, причем тут вообще "бизнес") и воспарили мыслью над рутиной "железа" -- поэтому на их диаграммах обычно изображены только абстрактные программы и данные, никак не связанные с деятельностью, и не реализованные ни на каком "железе". Это главная ошибка многих и многих "архитекторов предприятия" -- и именно для борьбы с этой ошибкой был придуман Архимейт.
Очень трудно, почти невозможно удерживать в голове и деятельность людей, и работу "софта", и работу "железа" со связью и системным софтом. Но если вы этого не делаете, то вы не архитектор. Извинений для этой ошибки "одноуровневости" нет, следствия ужасны.
Редко-редко бывает и другой вариант: Архимейт используется только для отображения деятельности людей, без учета работы программ. Такая "человечная одноуровневость" не менее плоха, чем одноуровневость отображения только работы программ -- ведь информационные технологии и правильные приложения существенно меняют сам способ работы, существенно меняют деятельность. Организация работы с использованием программ-экскаваторов существенно отличается от организации работы с программами-лопатами (не меньше, чем организация работы землекопов в аналогичном случае), но именно это не будут учитывать те немногие "бизнес-аналитики", которые вышли не из программистов, а из выпускников программ MBA -- и которые не утруждают себя разбирательством с возможностями софта и их влиянием на организацию дела.
Чтобы кто-то изобразил в качестве архитектуры предприятия только один уровень "железа" -- этого почти не бывает, но все учебники и блоги практикующих архитекторов предупреждают о пагубности игнорирования этого уровня при изображении двух других. Более того, они советуют моделировать оборудование и системный софт довольно детально, иначе не избежать проблем с производительностью и масштабированием.
Почему важно отображение всех этих уровней Архимейта одновременно? Потому что вам придется отвечать на очень и очень неудобные вопросы про несоответствие деятельности, её поддержки "софтом" и поддержки софта "железом". Ибо на диаграммах это несоответствие и отсутствие надлежащей поддержки становится хорошо видным и самые разные люди начинают задавать самые разные вопросы. Отвечать на эти вопросы архитектурными решениями (менять диаграммы с учётом базисов "as is" на "to be", а затем планировать пакеты работ по переходу к "to be") -- это и есть работа архитектора предприятия.
2. Очень много ошибок связаны с непониманием сервис-ориентированности Архимейта. Вы должны понимать, что на предприятии все кого-то обслуживают, а не самодостаточны. Архимейт требует сформулировать в явном виде: чем занят тот или иной кусок предприятия (часть системы!), отображенный в архитектуре -- какой сервис он предоставляет "наружу" (чем бы эта "наружа" не была), и как этот кусок предприятия устроен "внутри", чтобы иметь возможность предоставлять этот сервис.
Первая из ошибок, которую делают новички -- это попытка использовать "оргсервис-продукт" (product) вместо "объекта" (business object). Самое маленькое следствие этой ошибки -- это отказ редактора диаграмм прописывать необходимые отношения. Реакция на это архитектора-новичка: "ваш софт сломался". Ещё бы! Продукт в Архимейте -- это набор оргсервисов и соглашение об уровне сервиса (договор, контракт). То есть продукт в Архимейте -- это по сути работы (сервисы), а не объекты или данные! Это не "чугунная чушка", а "поставка и обслуживание чугунной чушки", это не "кредит", а "предоставление кредита".
Любой кусок архитектуры зачем-то нужен -- деятельность предприятия обслуживает (service) каких-то клиентов, работа программ обслуживает (service) работу ответственных и работу других программ, "железо" обслуживает (service) работу программ и работу другого "железа". Явное указание сервисов заставляет трижды подумать, зачем нужен тот или иной кусок предприятия, какая это подсистема предприятия как системы -- и результаты этого размышления часто бывают нетривиальны и заставляют менять архитектуру (а потом менять предприятие в соответствии с этими изменениями архитектуры).
Большинство новичков-архитекторов вообще не использует сервисов на диаграммах, что строго противоречит подходу Архимейта. Отсутствие явно прописанных сервисов верный знак, что в голове архитектора нет разделения на "внутренний-внешний", то есть его архитектура несистемна (она может быть продумана, но не в терминах систем, без мыслимой "границы системы", без размышлений о целевой и использующей системе), немодульна -- со всеми негативными последствиями. Модуль-подсистема отличается прежде всего тем, что его можно заменить, не трогая всю целевую систему. Модульная архитектура позволяет заменять "внутреннее", не меняя "внешнего" и поддерживать такой стиль мышления, поощряющий замену реализаций по мере получения новой информации и открытия новых возможностей. Если использовать сервисы, то можно легко заменить архитектуру IT-решения, не меняя деятельности, можно заменить одно интеграционное решение на другое, не меняя всей архитектуры IT-решения, можно заменить "железов", не меняя обработки данных, можно добавить еще пару-тройку каналов предоставления оргсервиса и т.д.). Если не использовать сервисы, то такие замены очень трудно сформулировать и выделить из паутины объектов и отношений полной архитектуры.
Сервисы можно оказывать по разным каналам взаимодействия (в случае программ -- по разным интерфейсам) -- электронная почта, прилавок, веб-сервис и т.д.. Если есть сервис, то можно думать, как его доставить потребителям -- ибо дорог сервис доставленный, а не просто существующий в природе ("за границей телушка полушка, да рубль перевоз"). Если есть сервис, то хотя бы на мгновение можно будет подумать и о том, кому этот сервис нужен -- и учесть потребительский интерес, независимо от того, внешний этот потребитель или внутренний по отношению к предприятию, формализовано ли соглашение об уровне обслуживания (SLA), или неформально, оказывается ли этот сервис людям или программам. Если сервиса нет, то на диаграмме ничто не указывает на эти "внешние" интересы -- и резко возрастает вероятность получить никому не нужный кусок деятельности, или прикупить ненужную/неподходящую софтинку, или закупить ненужное/неподходящее оборудование в порядке реализации такой "бессервисной" архитектуры.
3. Неразличение тематического описания и полной модели в ходе редактирования диаграмм. Полная модель -- это элементы и отношения всех типов, которые есть в компьютере в данном проекте моделирования предприятия. Тематическое описание(например, описание информационной структуры, или даже описание "всего") -- это отфильтрованные для изображения на диаграмме каких-то элементов и связей из полной модели. Программы моделирования на Архимейте умные -- они умеют поддерживать общую модель предприятия, показывая разные его части на разных диаграммах. Новички часто это игнорируют -- и поэтому вместо использования в разных описаниях одного и того же элемента модели порождают новый в каждом новом описании, причем с одним и тем же именем. И модель содержит в итоге несколько штук самых разных "серверов баз данных", хотя подразумевается один и тот же, только на разных вариантах диаграмм. Да и не только новички это делают! В примере архитектурной модели для редактора Archi тоже встречается такая ошибка: один и тот же элемент архитектуры в разных группах описаний оказывается не одним и тем же, а разным.
Не нужно забывать, что по итогам архитектурной работы в редакторе (моделере) можно получить отчёт (текстовый документ с описанием всех элементов). Каково же будет ваше удивление, когда в отчете у вас окажется не одна потребная база данных, а целых пять -- по количеству дублей, которые вы сотворили в разных группах описаний. Существующие отношения не будут автоматом попадать из одной группы описаний в другую. Для этих "дублей" не будут доступны свойства и комментарии, которые вы пропишете в данном элементе (ибо не только картинками диаграмм живет архитектор, он много чего пишет про каждый элемент, кроме его графического обозначения -- и все редакторы это поддерживают).
Моделер ArchiMate пытается предотвратить такую ошибку, и при копировании не связанных с моделью элементов добавляет в имя "(копия)" -- если вы хотели просто вынести из модели элемент в новое описание, а не сдублировать его в модели, эта добавка в имя должна вас насторожить.
Удаление элемента происходит либо из модели, либо только из одной группы описаний -- и редактор предлагает два варианта операции удаления, не перепутайте их! Если вы случайно удалили элемент из архитектурной модели, то вам нужно его завести на диаграмме этой группы описаний заново, "с нуля". Если вы случайно удалили элемент из группы описаний, то вам его нужно вытащить из модели на полное описание -- создание с нуля как раз и породит дублирование.
Элементы дерева модели, которые в Archi даны курсивом, означают такие элементы, которые просто не были выведены ни в одной из тематических групп описаний. Но они не удалены из модели! Их просто отфильтровали из всех диаграмм и курсив означает только то, что они не показываются -- но хранятся. Новичкам к такому поведению редактора нужно привыкнуть, но пока этой привычки не появилось, управление конфигурацией вашего архитектурного описания по мере его разрастания будет проблематичным.
4. Новички (которым к этому моменту обычно промыли мозги "процессным подходом") начинают архитектурную работу с выявления (или придумывания) внутренних работ (процессов и практик). Как ни странно, это ошибка (см., например, http://ailev.livejournal.com/867599.html). Начинать всегда лучше с событий (http://ailev.livejournal.com/1202776.html), объектов работы и данных, а также как можно раньше предаваться размышлениям о предоставляемых вовне работах -- сервисах. Процессы и практики, функционал программ и оборудования появляются потом, когда вы понимаете, что нужно делать (какие работы выполнять) с объектами и данными, чтобы добиться внешней пользы от сервиса.
И только в самую последнюю очередь нужно назначать на работы выполнителей (когда работа понятна, можно думать, кто способен её выполнить -- а не придумывать работы под первого попавшегося пока недогруженного или уже перегруженного выполнителя). Помним, что выполнитель работы тут может быть -- это и ответственный с ролью, и программа, и "железо".