спасибо за комментарий! в идеале этот подход для РП во многих вопросах действительно может сильно помочь, но требует небольшого погружения в архитектурную методологию) другое дело, что её "приземление" на практику в конкретной организации - это в том числе задача руководителей и методологов, и в некоторых случаях достаточно непростая
дополню ещё комментарий личной практикой - уже в нескольких российских компаниях archimate используется как корпоративный стандарт и нотация моделирования и БП как компонента бизнес-архитектуры, и ИТ-ландшафта (во всех слоях, включая интеграционный), инструмент в этом смысле зарекомендовал себя очень хорошо. Нужно только внедрять на уровне СОМ/СОП по компании.
Спасибо за статью, недавно на эту тему тоже писал. На мой взгляд, архимейт - универсальный язык и для различного вида архитекторов, и аналитиков, покрывающий не меньше 80% рабочих задач.
Насчёт операторов могу сказать из личной практики, что их использование даёт практически ту же результативность, что и другие нотации моделирования БП, разве что BPMN побогаче в этом смысле (но и читать такие развилки в нём уже не все могут так же, как стандартные и/или).
интересный разбор, спасибо. Но БС нельзя приравнять к процессу (в т.ч. абстрактному) в прямом смысле, если говорить про эти сущности в рамках TOGAF. БС это статика ("что" делает организация, потенциал), процесс - динамика ("как" делает, последовательность). А процесс да, реализует в т.ч. продукт.
Да, ПО несомненно очень важно с точки зрения КА, но для бизнес-аналитика (и бизнес-архитектора) важно выполнять бизнес-проектирование без оглядки на существующее ПО. Хотя здесь для многих спорная тема. В любом случае, сновная цель моих статей - популяризация подходов КА, применения TOGAF и Archimate как языка для ролей, связанных с проектированием ИТ-решений и управления бизнесом, я не ставлю цель указать всю систему нормативки в этой области, тем более что её много и помимо ГОСТов. Но есть ощущение, что Вы могли бы полезную статью написать на тему систематизации понятия "архитектура". Уверен, что для многих архитекторов это вызовет интерес и отклик.
Вне всяких сомнений, Ваше оценочное суждение очень интересно, но я на вопрос уже ответил) Но давайте ещё раз - приводимый Вами ГОСТ (о нём, кстати, здесь уже была статья с определёнными выводами https://habr.com/ru/articles/459992/?ysclid=mhachgeeu0450867267) имеет указанный в его наименовании контекст. Он может применяться в рамках этого контекста, но не является истоником истины для всех возможных участников архитектурного проектирования. Например, на рынке есть такие архитектурные роли: Корпоративный архитектор, Архитектор решений (Solution), Системный архитектор, Программный архитектор (software), Процессный архитектор, Интеграционный архитектор, Технологический архитектор, Функциональный архитектор, Архитектор данных, а есть ещё аналитики по направлениям: бизнес, системные, процессные, данных (на некоторые роли есть даже свои ГОСТы, далеко не всегда адекватные, но есть. Ссылки приводить не стану - оставлю это Вам, как человеку, которому либо не сложно работать со ссылочными материалами, либо использующему ИИ). Больше того, у каждой роли есть уровень (абстракции) проектирования и определённый набор ИТ-стандартов, устоявшийся в их среде, в рамках которых они работают. Например, ЕА работает с архитектурой организации (о чём, например, TOGAF), Архитектор данных - с данными (о чём, например, DAMA), а Программный архитектор - с объектами только одного домена приложений (если по тому же TOGAF). Соответственно, для первого и второго будет полезно ознакомиться с приводимым Вами ГОСТом, а для третьего будет целесообразным его каким-то образом использовать в своей работе. Но использовать все трое могут его по своему усмотрению, т.к. ГОСТ (вот тут меня поправьте как специалист, если не прав) является рекомендательным документом, тем более что в области архитектуры единой системы (с выделением областей, уровней, декомпозиции) ГОСТов не существует. Возвращаясь к статье, её архитектурный контекст - это корпоративная и бизнес-архитектура, о чём проставлены теги, концептуальная модель - метамодель archimate, а контекст приводимого Вами ГОСТа, согласно его же терминам - "программная система: Система, состоящая из программного и аппаратного обеспечения и данных, главная ценность которой создается посредством исполнения программного обеспечения. "
Спасибо за отсылку, читателям будет полезно, хотя указанный Вами ГОСТ не про корпоративную и бизнес-архитектуру (именно в этом контексте указан тег "ИТ-стандарты"), а про системную и программную инженерию (как указано в его наименовании). Соответственно и не "возможность" (согласно указанному ГОСТу, "возможность - это совокупность обстоятельств, которая обсуславливает разработку или изменение программной системы"), хотя и такой вариант встречается, а БС как способность бизнеса к определённым действиям, которая необходима для достижения конкретной цели или результата (по TOGAF). Термин "бизнес-способность" достаточно устоялся в русскоязычном варианте в среде корпоративной архитектуры.
Наверняка преимущества EPC в совокупности с ARIS как методологии/инструмента есть, нужно смотреть в контексте конкретных задач моделирования. Но на мой взгляд, с точки зрения метамодели в том же BPMN аналогичных объектов не меньше, а читаемость лучше (думаю, это следствие того, что BPMN является преемником нескольких языков/методологий, в т.ч. EPC и выполняет схожие задачи не хуже).
По-моему это очень распространённая практика, кастомизацию тоже очень часто встречал, как и нотации собственного избретения) поэтому и хотелось бы порекламировать архимейт как универсальный и достаточно простой инструмент для многих ролей, не только для БА.
BS последней версии я только пробник поюзал, да, там всё работает нормально.
С4 это всё-таки методология скорее системной архитектуры со своей семантикой, а архимейт - это производная от TOGAF, то есть от методологии корпоративной архитектуры. Но оба варианта позволяют описать участие систем, но в рамках своего контекста.
Насчёт draw.io - это простая рисовалка. Можно бесплатно использовать Bizagi для BPMN и Archi для архимейта:
Целью данной статьи было приведение небольшого практического материла в виде визуального упражнения заинтересованных из разряда "найти 10 отличий" для быстрого старта использования инструмента, а не более глубокий разбор с таблицами (хоть и "кривыми"). Ваше предложение было принято к сведению.
Насчёт семантической корректности связи Business Actor и Business Event через Assignment deepseek ответил правильно. Здесь я намеренно допустил такую связь для полной считываемости информации и маппингом на схему bpmn (а именно - с "дорожками" ролей). Подобные комментарии насчёт правильности семантики тоже полезны для цели конкретно этой статьи, благодарю.
Насчёт EPC - что имеется в виду под "лучшей механикой"?
Спасибо за комментарий, вот завтра как раз планирую показать короткий пример со сравнением схем в bpmn и archimate с одинаковым набором объектов. Думаю, это будет полезно для популяризации - инструмент универсальный и на нём можно смоделировать очень многое, хотелось бы чтобы его чаще было видно.
Кажется, что речь про возможность переиспользования объектов - например, шаг процесса со схемы BPMN как аналогичный объект вставить на диаграмму в архимейте. В таблице со сравнением как раз и про это тоже. BS такое точно позволяет. По крайней мере, я так понял вопрос)
спасибо, наверное нужно будет написать отдельную статью про архимейт и уже с ним сравнивать прочие нотации. Связи между объектами (за исключением динамических, имеющихся в других нотациях) это его большой плюс
спасибо за комментарий! в идеале этот подход для РП во многих вопросах действительно может сильно помочь, но требует небольшого погружения в архитектурную методологию) другое дело, что её "приземление" на практику в конкретной организации - это в том числе задача руководителей и методологов, и в некоторых случаях достаточно непростая
Спасибо за отзыв!
дополню ещё комментарий личной практикой - уже в нескольких российских компаниях archimate используется как корпоративный стандарт и нотация моделирования и БП как компонента бизнес-архитектуры, и ИТ-ландшафта (во всех слоях, включая интеграционный), инструмент в этом смысле зарекомендовал себя очень хорошо. Нужно только внедрять на уровне СОМ/СОП по компании.
Спасибо за статью, недавно на эту тему тоже писал. На мой взгляд, архимейт - универсальный язык и для различного вида архитекторов, и аналитиков, покрывающий не меньше 80% рабочих задач.
https://habr.com/p/955332/
https://habr.com/p/954280/
Насчёт операторов могу сказать из личной практики, что их использование даёт практически ту же результативность, что и другие нотации моделирования БП, разве что BPMN побогаче в этом смысле (но и читать такие развилки в нём уже не все могут так же, как стандартные и/или).
Возможных связей множество, можно воспользоваться archi и посмотреть (если от практики), по теории - сам стандарт версии 9.2/10 (особенно фаза В в ADM цикле), отдельно по свойствам (и связи с БП) БС можно тут посмотреть: https://governance.foundation/assets/frameworks/togaf/g189 - Business Capbility.pdf
интересный разбор, спасибо. Но БС нельзя приравнять к процессу (в т.ч. абстрактному) в прямом смысле, если говорить про эти сущности в рамках TOGAF. БС это статика ("что" делает организация, потенциал), процесс - динамика ("как" делает, последовательность). А процесс да, реализует в т.ч. продукт.
Скрытый текст
Да, ПО несомненно очень важно с точки зрения КА, но для бизнес-аналитика (и бизнес-архитектора) важно выполнять бизнес-проектирование без оглядки на существующее ПО. Хотя здесь для многих спорная тема. В любом случае, сновная цель моих статей - популяризация подходов КА, применения TOGAF и Archimate как языка для ролей, связанных с проектированием ИТ-решений и управления бизнесом, я не ставлю цель указать всю систему нормативки в этой области, тем более что её много и помимо ГОСТов. Но есть ощущение, что Вы могли бы полезную статью написать на тему систематизации понятия "архитектура". Уверен, что для многих архитекторов это вызовет интерес и отклик.
Вне всяких сомнений, Ваше оценочное суждение очень интересно, но я на вопрос уже ответил) Но давайте ещё раз - приводимый Вами ГОСТ (о нём, кстати, здесь уже была статья с определёнными выводами https://habr.com/ru/articles/459992/?ysclid=mhachgeeu0450867267) имеет указанный в его наименовании контекст. Он может применяться в рамках этого контекста, но не является истоником истины для всех возможных участников архитектурного проектирования. Например, на рынке есть такие архитектурные роли: Корпоративный архитектор, Архитектор решений (Solution), Системный архитектор, Программный архитектор (software), Процессный архитектор, Интеграционный архитектор, Технологический архитектор, Функциональный архитектор, Архитектор данных, а есть ещё аналитики по направлениям: бизнес, системные, процессные, данных (на некоторые роли есть даже свои ГОСТы, далеко не всегда адекватные, но есть. Ссылки приводить не стану - оставлю это Вам, как человеку, которому либо не сложно работать со ссылочными материалами, либо использующему ИИ). Больше того, у каждой роли есть уровень (абстракции) проектирования и определённый набор ИТ-стандартов, устоявшийся в их среде, в рамках которых они работают. Например, ЕА работает с архитектурой организации (о чём, например, TOGAF), Архитектор данных - с данными (о чём, например, DAMA), а Программный архитектор - с объектами только одного домена приложений (если по тому же TOGAF). Соответственно, для первого и второго будет полезно ознакомиться с приводимым Вами ГОСТом, а для третьего будет целесообразным его каким-то образом использовать в своей работе. Но использовать все трое могут его по своему усмотрению, т.к. ГОСТ (вот тут меня поправьте как специалист, если не прав) является рекомендательным документом, тем более что в области архитектуры единой системы (с выделением областей, уровней, декомпозиции) ГОСТов не существует. Возвращаясь к статье, её архитектурный контекст - это корпоративная и бизнес-архитектура, о чём проставлены теги, концептуальная модель - метамодель archimate, а контекст приводимого Вами ГОСТа, согласно его же терминам - "программная система: Система, состоящая из программного и аппаратного обеспечения и данных, главная ценность которой создается посредством исполнения программного обеспечения. "
Спасибо за отсылку, читателям будет полезно, хотя указанный Вами ГОСТ не про корпоративную и бизнес-архитектуру (именно в этом контексте указан тег "ИТ-стандарты"), а про системную и программную инженерию (как указано в его наименовании). Соответственно и не "возможность" (согласно указанному ГОСТу, "возможность - это совокупность обстоятельств, которая обсуславливает разработку или изменение программной системы"), хотя и такой вариант встречается, а БС как способность бизнеса к определённым действиям, которая необходима для достижения конкретной цели или результата (по TOGAF). Термин "бизнес-способность" достаточно устоялся в русскоязычном варианте в среде корпоративной архитектуры.
спасибо за отзыв, очень мотивирует!
Наверняка преимущества EPC в совокупности с ARIS как методологии/инструмента есть, нужно смотреть в контексте конкретных задач моделирования. Но на мой взгляд, с точки зрения метамодели в том же BPMN аналогичных объектов не меньше, а читаемость лучше (думаю, это следствие того, что BPMN является преемником нескольких языков/методологий, в т.ч. EPC и выполняет схожие задачи не хуже).
По-моему это очень распространённая практика, кастомизацию тоже очень часто встречал, как и нотации собственного избретения) поэтому и хотелось бы порекламировать архимейт как универсальный и достаточно простой инструмент для многих ролей, не только для БА.
BS последней версии я только пробник поюзал, да, там всё работает нормально.
С4 это всё-таки методология скорее системной архитектуры со своей семантикой, а архимейт - это производная от TOGAF, то есть от методологии корпоративной архитектуры. Но оба варианта позволяют описать участие систем, но в рамках своего контекста.
Насчёт draw.io - это простая рисовалка. Можно бесплатно использовать Bizagi для BPMN и Archi для архимейта:
https://www.archimatetool.com/download/
Целью данной статьи было приведение небольшого практического материла в виде визуального упражнения заинтересованных из разряда "найти 10 отличий" для быстрого старта использования инструмента, а не более глубокий разбор с таблицами (хоть и "кривыми"). Ваше предложение было принято к сведению.
Насчёт семантической корректности связи Business Actor и Business Event через Assignment deepseek ответил правильно. Здесь я намеренно допустил такую связь для полной считываемости информации и маппингом на схему bpmn (а именно - с "дорожками" ролей). Подобные комментарии насчёт правильности семантики тоже полезны для цели конкретно этой статьи, благодарю.
Насчёт EPC - что имеется в виду под "лучшей механикой"?
Добрый, следующий будет подлиннее, спасибо)
Спасибо за комментарий, вот завтра как раз планирую показать короткий пример со сравнением схем в bpmn и archimate с одинаковым набором объектов. Думаю, это будет полезно для популяризации - инструмент универсальный и на нём можно смоделировать очень многое, хотелось бы чтобы его чаще было видно.
есть анонсы помимо БС, а вдруг там будет не хуже, чем ЕА?)
Тогда из отечественных систем точно могу бизнес-студио рекомендовать, а в целом есть ещё до 5 аналогичных, но нужно смотреть функционал что позволяет.
Кажется, что речь про возможность переиспользования объектов - например, шаг процесса со схемы BPMN как аналогичный объект вставить на диаграмму в архимейте. В таблице со сравнением как раз и про это тоже. BS такое точно позволяет. По крайней мере, я так понял вопрос)
спасибо, наверное нужно будет написать отдельную статью про архимейт и уже с ним сравнивать прочие нотации. Связи между объектами (за исключением динамических, имеющихся в других нотациях) это его большой плюс