Comments 6
Добрый день.
Спасибо за проявленный интерес к статье.
1.1 Да, все верно, подход BIAN предлагает архитектурный фреймворк с методикой покрытия всей деятельности финансового предприятия в виде независимых сервисных доменов и сервисных операций для организации взаимодействия между ними, + ландшафт сервисов. А так же руководств по применению модели.
Ответ на ваш вопрос содержится в самом определении референтной модели.
Моделью является карта сервисов «BIAN Service Landscape»
С опорой на карту сервисов можно и нужно строить коммуникации с бизнесом. Самым высокоуровневым подходом будет выделение на карте тех сервисных доменов, которые в организации реализованы, плохо реализованы, или могут быть взяты на вооружение для дальнейшего развития (как пример). Так же в руководстве "BIAN How-to Guide – DESIGN PRINCIPLES TECHNIQUES V6.0" приводятся другие примеры работы с моделью.
Вы пишите: «нет никаких конечных моделей какого-либо домена» — не очень понимаю, какую именно модель домена Вы ожидаете увидеть. Возможно, рисунок 6 из данной статьи при внимательном рассмотрении Вас удовлетворит.
Так же хочу обратить внимание, что модель является концептуальной. Она не предлагает готовых технических решений. Она задает единый подход. К примеру, реляционная модель данных в свое время позволила решить вопросы с организацией хранения данных без указания того, как должны реализовываться указанные в ней «правила».
1.2 Данный вопрос скорее стоит адресовать разработчикам модели. Но возьму на себя смелость дать ответ за них. eTOM — это карта процессов, это референтная процессная модель, в то время как BIAN — это референтная сервисная (функциональная) модель. Разные типы моделей, разные виды представлений.
2.1 Да, я разделяю мнение разработчиков BIAN.
2.2 Согласно BIAN «непрерывное планирование» осуществляется через паттерн «управление» с наличием артефакта — «плана управления». + ряд сервисных операций. Так же фреймворк представляет Wireframe-ы, пользовательские сценарии, «вспомогательные» диаграммы (в фреймворке, например, BIAN_ISO20022->Helper Diagrams->Management Processes). Хотя стоит отметить, что и не для всех доменов есть доп.структуры. Но модель продолжают развивать.
В чем именно вести проектную деятельность, модель не скажет, но какие минимальные функции у внедряемого/используемого инструмента должны быть, она укажет.
3. Поддерживаемые подходы SOA детально описаны в BIAN How-to Guide – APPLYING THE BIAN STANDARD V6.0 на 12 странице (и далее).
Спасибо за проявленный интерес к статье.
1.1 Да, все верно, подход BIAN предлагает архитектурный фреймворк с методикой покрытия всей деятельности финансового предприятия в виде независимых сервисных доменов и сервисных операций для организации взаимодействия между ними, + ландшафт сервисов. А так же руководств по применению модели.
Ответ на ваш вопрос содержится в самом определении референтной модели.
Референтная модель — концептуальная модель, формализующая рекомендованные практики ведения бизнеса в определенной области.(определение взяла здесь).
Моделью является карта сервисов «BIAN Service Landscape»
С опорой на карту сервисов можно и нужно строить коммуникации с бизнесом. Самым высокоуровневым подходом будет выделение на карте тех сервисных доменов, которые в организации реализованы, плохо реализованы, или могут быть взяты на вооружение для дальнейшего развития (как пример). Так же в руководстве "BIAN How-to Guide – DESIGN PRINCIPLES TECHNIQUES V6.0" приводятся другие примеры работы с моделью.
Вы пишите: «нет никаких конечных моделей какого-либо домена» — не очень понимаю, какую именно модель домена Вы ожидаете увидеть. Возможно, рисунок 6 из данной статьи при внимательном рассмотрении Вас удовлетворит.
Так же хочу обратить внимание, что модель является концептуальной. Она не предлагает готовых технических решений. Она задает единый подход. К примеру, реляционная модель данных в свое время позволила решить вопросы с организацией хранения данных без указания того, как должны реализовываться указанные в ней «правила».
1.2 Данный вопрос скорее стоит адресовать разработчикам модели. Но возьму на себя смелость дать ответ за них. eTOM — это карта процессов, это референтная процессная модель, в то время как BIAN — это референтная сервисная (функциональная) модель. Разные типы моделей, разные виды представлений.
2.1 Да, я разделяю мнение разработчиков BIAN.
2.2 Согласно BIAN «непрерывное планирование» осуществляется через паттерн «управление» с наличием артефакта — «плана управления». + ряд сервисных операций. Так же фреймворк представляет Wireframe-ы, пользовательские сценарии, «вспомогательные» диаграммы (в фреймворке, например, BIAN_ISO20022->Helper Diagrams->Management Processes). Хотя стоит отметить, что и не для всех доменов есть доп.структуры. Но модель продолжают развивать.
В чем именно вести проектную деятельность, модель не скажет, но какие минимальные функции у внедряемого/используемого инструмента должны быть, она укажет.
3. Поддерживаемые подходы SOA детально описаны в BIAN How-to Guide – APPLYING THE BIAN STANDARD V6.0 на 12 странице (и далее).
все что я вижу тут и в репозитории это метамодель с описанием типовых CRUD операций над объектом «Спецификация архитектуры» + функции для отчета по архитектуре.
Да, данный домен не самый заполненный. По-моему мнению, разработчики BIAN больше уделяют внимание доменам, приносящим добавленную стоимость организации, с «каркасами» в BIAN-> Wireframes, а не на процесс управления. При этом стоит понимать, что домены могут переиспользоваться в разных процессах из разных бизнес-направлений. К примеру, домен Document Services (Business Support-> Document Management and Archive) будет переиспользован из других бизнес-направлений, как показано на диаграмме последовательности бизнес-сценария (BIAN-> Wireframes-> Semantic API -> 1st Order Iteractions ->Document Services Invocation — Request Document Verification <>). Whireframes и сценарии значительно расширяют стандарт.
Как организовать нормальную работу над архитектурой? Как же многоуровневостью архитектуры по подразделениям? Как согласовывается архитектора? Кто исполнитель? Где другие сервисные операции? Где работа с архитектурным репозиторием, бизнес-доменами, ABB, SBB?
Для ответов на данные вопросы, могу предложить обратиться к методологии TOGAF в сочетании с BIAN. При таком подходе домен будет раскрыт полностью. И это не противоречит BIAN. Если что-то Вы находите недостаточно описанным, можно сочетать его с другими методологиями/стандартами.
Также сама архитектура BIAN раскладывается на уровни:
Возможно, приведенное представление будет Вам интересно в ваших стремлениях разложения по уровням представлений архитектуры.
Реляционная модель тут не причем, это чисто математическая модель (реляционная алгебра), она замкнута – все операции в ней прописаны.
Согласна, некорректно выразилась: «Концептуальная ER-модель, реализующая реляционную модель».
По остальным вашим комментариям я не отвечаю, т.к. считаю, что это ваша точка зрения, и она имеет право на существование.
Прочитал статью сегодня второй раз, (вчера в первый).
Эту штуку имхо можно было (наверно) продать надцать лет назад.
А сейчас… слабо представляю себе CEO, который бы поизучал подобные схемы и такой: «о-о-о, да у нас формирование стратегии провисло», или «о-о-о, да у нас оценка продуктов и услуг на боку».
Да и в целом, имхо, подход:
переворачивает с ног на голову.
Имхо, слабые места известны, и дальше начинается история по устранению слабых мест с… (тут какие-то ограничения). И если эта история масштабна и растянута по времени, и затрагивает разные уровни предприятия, то тут уже и появляется потребность в формальном описании задействованных в истории артефактов, действующих и будущих. Т.е. не схема выявляет слабые места, а согласно схеме движемся вперед для устранения слабых мест.
Эту штуку имхо можно было (наверно) продать надцать лет назад.
А сейчас… слабо представляю себе CEO, который бы поизучал подобные схемы и такой: «о-о-о, да у нас формирование стратегии провисло», или «о-о-о, да у нас оценка продуктов и услуг на боку».
Да и в целом, имхо, подход:
Применение международного стандарта BIAN позволит «оголить слабые места» в архитектуре всего предприятия
переворачивает с ног на голову.
Имхо, слабые места известны, и дальше начинается история по устранению слабых мест с… (тут какие-то ограничения). И если эта история масштабна и растянута по времени, и затрагивает разные уровни предприятия, то тут уже и появляется потребность в формальном описании задействованных в истории артефактов, действующих и будущих. Т.е. не схема выявляет слабые места, а согласно схеме движемся вперед для устранения слабых мест.
Добрый день.
Спасибо за ваше мнение.
По моему собственному опыту, то, что бывает очевидно мне, не всегда может быть очевидно другим людям. И наоборот.
И опыт же показывает, что, к сожалению, даже такое очевидное утверждение, что «в организации следует планировать, вести проектную деятельность» не всегда бывает очевидно на уровне управления. И привнесение этой мысли с опорой на стандарт может быть принято куда менее болезненно, нежели если это будет исходить только от одного из сотрудников.
Спасибо за ваше мнение.
По моему собственному опыту, то, что бывает очевидно мне, не всегда может быть очевидно другим людям. И наоборот.
И опыт же показывает, что, к сожалению, даже такое очевидное утверждение, что «в организации следует планировать, вести проектную деятельность» не всегда бывает очевидно на уровне управления. И привнесение этой мысли с опорой на стандарт может быть принято куда менее болезненно, нежели если это будет исходить только от одного из сотрудников.
Sign up to leave a comment.
«Референтная модель BIAN» для банковской индустрии или как перестать изобретать велосипед