В TOGAF всегда было 3 архитектурных слоя: business-information-technology.
zachman хорошо представляет таксономию объектов с помощью различных типов моделей, но не является процесным подходом. TOGAF - напротив, это процесным подход и в стадии B как раз определены шаги подразумевающие разработку моделей бизнес процессов, организационных моделей и прочих, относящихся к бизнес-архитектуре. Более того, стадия A (vision) предполагает разработку kpi, идентификацию бизнес- драйверов, принципов и органичений.

Спасибо за Ваши соображения, но стоит ли тут подсчитывать миллиметры? Для меня это скорее качественные оценки. Что с весами, что без весов главные выводы останутся те же: 1) всю палитру применений не покрывает ни одна нотация, к сожалению; 2) у BPMN область применения самая широкая.

Например, если стоит задача проработать верхнеуровневую архитектуру процессов для акционеров или высшего руководства, то наибольший вес будет у первого критерия, а у остальных могут быть вообще нули. И из этого будет следовать, что для этой задачи IDEF0, DFD и EPC рулят - так и есть. А вот если задача проработать детальные процессы и межпроцессное взаимодействие, подготовить качественные требования к их автоматизации с учетом всех мелочей и нюансов, имеющихся в этих процессах, или вообще реализовать исполняемые бизнес-процессы (пусть не сразу, но заложиться на такую перспективу), то более высокие веса буду у нижних критериев, а верхний критерий - “Архитектурные картинки” - будет менее значимым. И для архитектуры на верхнем уровне, в крайнем случае, берется другая нотация - тот же IDEF0 или DFD. И пусть переход из IDEF0 или DFD в BPMN при понижении уровня абстракции придется выполнить вручную - эта поблема меркнет с учетом того, что BPMN зато позволит на нижнем уровне все очень подробно и при этом наглядно прорисовать и качественно автоматизировать. Если правильно расставить веса, то станет видно, что BPMN еще сильнее отрывается от остальных нотаций при решении таких задач.

Кстати, по критерию “Процессные картинки” - я считаю, надо либо полбалла отнять у EPC (но что тогда останется у IDEF0 и DFD ), либо полбалла-балл накинуть BPMN. Потому что многие нюансы межпроцессного взаимодействия, которые в BPMN легко показываются, в EPC либо очень условно можно изобразить, либо крайне громоздко и не читаемо. Специально пробовали один и тот же процесс в этих двух нотациях отрисовать, и на практике получили подтверждение этому утверждению.

Спасибо за наводку.

Interesting. But 1) converse is not true and 2) it’s “exessively suitable” i.e. an overkill, which is rather common cause for criticism.

Workflow notations, which I saw, were “directly executable” thus suitable also for “workflow automation”.

Thanks,
AS

Согласен, нарисовать табличку так, чтобы с ней все согласились, вряд ли получится. В оправдание скажу, что эту табличку мы нарисовали на семинаре по бизнес-процессам (не по BPMN) в Екатеринбурге в результате обсуждения примерно 20 участниками.

1. Архитектурные картинки
Чем Вам не подходит TOGAF или, если попроще, RM-ODP
Имеются даже картинки уровня бизнеса. Если тогаф более подходит большим конторам, то RM-ODP вполне себе средним тоже может использоваться.

2. Процессные картинки
Тоже есть. Палитра хоть и меньше BPMN, но позволяет сделать всё тоже самое.

3. Автоматизация
Не понял о чём идёт речь.

4.Непосредственное исполнение
Тоже никто не запрещает это делать.
Execuable UML не расматриваю в силу откровенной слабости и академичности.
Инструментов из коробки нет, поэтому это скорее замечание общего характера.