Хабр Курсы для всех
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 12
Благодарю, за Ваши статьи!
Очень познавательно!
Если уж ставите тег "IT-стандарты", то хотя бы указывайте их... и не Способности, а Возможности...
Спасибо за отсылку, читателям будет полезно, хотя указанный Вами ГОСТ не про корпоративную и бизнес-архитектуру (именно в этом контексте указан тег "ИТ-стандарты"), а про системную и программную инженерию (как указано в его наименовании). Соответственно и не "возможность" (согласно указанному ГОСТу, "возможность - это совокупность обстоятельств, которая обсуславливает разработку или изменение программной системы"), хотя и такой вариант встречается, а БС как способность бизнеса к определённым действиям, которая необходима для достижения конкретной цели или результата (по TOGAF). Термин "бизнес-способность" достаточно устоялся в русскоязычном варианте в среде корпоративной архитектуры.
Термин "бизнес-способность" достаточно устоялся в русскоязычном варианте в среде корпоративной архитектуры.
Так себе, среда, выходит... как он может устояться, если он ещё не отлежался)))... может в каких то забегаловках термины и переводят в гугле, но в нормальных организациях используют словари терминов и определений... для этого даже нормоконтроль придумали...
по TOGAF
указанный Вами ГОСТ не про корпоративную и бизнес-архитектуру (именно в этом контексте указан тег "ИТ-стандарты"), а про системную и программную инженерию (как указано в его наименовании)
Те Корп Архитектура, у вас, работает без инструментов Системной инженерии.... интересно даже)))) Если что, то указанный мной стандарт - это 7 альф системной инженерии... Если сложно работать со ссылочными стандартами, то хотя бы пользуйтесь ИИ..
Скрытый текст
Вне всяких сомнений, Ваше оценочное суждение очень интересно, но я на вопрос уже ответил) Но давайте ещё раз - приводимый Вами ГОСТ (о нём, кстати, здесь уже была статья с определёнными выводами https://habr.com/ru/articles/459992/?ysclid=mhachgeeu0450867267) имеет указанный в его наименовании контекст. Он может применяться в рамках этого контекста, но не является истоником истины для всех возможных участников архитектурного проектирования. Например, на рынке есть такие архитектурные роли: Корпоративный архитектор, Архитектор решений (Solution), Системный архитектор, Программный архитектор (software), Процессный архитектор, Интеграционный архитектор, Технологический архитектор, Функциональный архитектор, Архитектор данных, а есть ещё аналитики по направлениям: бизнес, системные, процессные, данных (на некоторые роли есть даже свои ГОСТы, далеко не всегда адекватные, но есть. Ссылки приводить не стану - оставлю это Вам, как человеку, которому либо не сложно работать со ссылочными материалами, либо использующему ИИ). Больше того, у каждой роли есть уровень (абстракции) проектирования и определённый набор ИТ-стандартов, устоявшийся в их среде, в рамках которых они работают. Например, ЕА работает с архитектурой организации (о чём, например, TOGAF), Архитектор данных - с данными (о чём, например, DAMA), а Программный архитектор - с объектами только одного домена приложений (если по тому же TOGAF). Соответственно, для первого и второго будет полезно ознакомиться с приводимым Вами ГОСТом, а для третьего будет целесообразным его каким-то образом использовать в своей работе. Но использовать все трое могут его по своему усмотрению, т.к. ГОСТ (вот тут меня поправьте как специалист, если не прав) является рекомендательным документом, тем более что в области архитектуры единой системы (с выделением областей, уровней, декомпозиции) ГОСТов не существует. Возвращаясь к статье, её архитектурный контекст - это корпоративная и бизнес-архитектура, о чём проставлены теги, концептуальная модель - метамодель archimate, а контекст приводимого Вами ГОСТа, согласно его же терминам - "программная система: Система, состоящая из программного и аппаратного обеспечения и данных, главная ценность которой создается посредством исполнения программного обеспечения. "
на некоторые роли есть даже свои ГОСТы, далеко не всегда адекватные, но есть.
Да, есть профстандарты (https://profstandart.rosmintrud.ru/), из них можно много чего подчеркнуть, но к сожалению, без грамотной оценки персонала (его квалификации) это, на мой взгляд, создаст лишнюю бюрократию... пс тоже относится и к стандартам, я, в одну каску, применять стандарты не буду... Я не настаиваю на их применении, знаю что они добровольные, но если стандарт существует, то его нужно указать... Если он плох, то указать почему (или ссылочку, статей достаточно)... ну хотя бы тот же togaf указать, остальное я сам.
Скрытый текст
Больше того, у каждой роли есть уровень (абстракции) проектирования и определённый набор ИТ-стандартов
Согласен, прям в точку, но на это тоже есть ГОСТ))) И не только ИТ-стандартов, собственно, исо 9001 и подразумевает "распределение" уровней . Роль корп архитектора не подразумевает разработку управленческих д-тов (кроме д-тов отдела). Для этого и связаны одной цепью Системная и Программная инженерии. Корп архитектурой, без ПО, оч сложно заниматься...
Скрытый текст
Но использовать все трое могут его (ГОСТ Р 57100) по своему усмотрению,...
Вот это самое страшное... Управление НСИ и нормоконтроль... Если нет системы управления стандартами, то, по "своему усмотрению" - нельзя)) нужно все стандарты адаптировать под предприятие, внедрять в управление... и на это тоже есть ГОСТ
Скрытый текст
Возвращаясь к статье, её архитектурный контекст - это корпоративная и бизнес-архитектура
Хорошо, но эти стандарты в основе имеют управленческие стандарты (то же 9000 или 21500), вот если бы карта бизнес-способностей была, как инструмент оценки персонала в рамках СМ, то да... но, архимейт это уже не инструмент "Менеджеров" (хз как их назвать), это, пока, ИТ инструмент.
пс :на мой взгляд, лучший пример применения archi у https://bian.org (и как это всё поддерживать без ПО???)
Скрытый текст
Скрытый текст
Да, ПО несомненно очень важно с точки зрения КА, но для бизнес-аналитика (и бизнес-архитектора) важно выполнять бизнес-проектирование без оглядки на существующее ПО. Хотя здесь для многих спорная тема. В любом случае, сновная цель моих статей - популяризация подходов КА, применения TOGAF и Archimate как языка для ролей, связанных с проектированием ИТ-решений и управления бизнесом, я не ставлю цель указать всю систему нормативки в этой области, тем более что её много и помимо ГОСТов. Но есть ощущение, что Вы могли бы полезную статью написать на тему систематизации понятия "архитектура". Уверен, что для многих архитекторов это вызовет интерес и отклик.
Кратко: Capability = «абстрактный процесс», а Процесс «реализует» не Способность \ Возможность, а продукт. Подробнее тут.
Когда подобные вопросы можем обсуждать на языке математики – все станет проще, прозрачнее, понятнее, логичнее. Пока же больше путаницы, чем понимания.
интересный разбор, спасибо. Но БС нельзя приравнять к процессу (в т.ч. абстрактному) в прямом смысле, если говорить про эти сущности в рамках TOGAF. БС это статика ("что" делает организация, потенциал), процесс - динамика ("как" делает, последовательность). А процесс да, реализует в т.ч. продукт.
БС это статика ("что" делает организация, потенциал), процесс - динамика ("как" делает, последовательность).
Для более четкого сравнения хотелось бы список всех предикатов для БС (кроме реализуется Процессом и реализует Цель), а также список свойств (параметров).
Возможных связей множество, можно воспользоваться archi и посмотреть (если от практики), по теории - сам стандарт версии 9.2/10 (особенно фаза В в ADM цикле), отдельно по свойствам (и связи с БП) БС можно тут посмотреть: https://governance.foundation/assets/frameworks/togaf/g189 - Business Capbility.pdf
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Карта бизнес-способностей. Просвечиваем корпоративные боли и лечим их архитектурно: эволюция бизнес-аналитика