vrr/doc
2
0
Fork 0
mirror of https://github.com/bpmbpm/doc.git synced 2026-05-13 15:28:51 +00:00
Code Issues Projects Releases Packages Wiki Activity Actions
doc/EA/GOST/version2
History
Dmitry 134bedaa8b
Update readme.md
2025-06-03 13:49:09 +03:00
..
readme.md Update readme.md 2025-06-03 13:49:09 +03:00
ris1.png Add files via upload 2025-05-26 20:38:24 +03:00
ris2.png Add files via upload 2025-05-26 20:38:24 +03:00
ris3.png Add files via upload 2025-05-26 20:38:24 +03:00

readme.md

Enterprise architecture framework-2

Intro

Взглядов на Enterprise architecture framework (EAF) много, см. wiki ; sewiki ; top10 EAF. Одних только xxAF (Architecture Framework) сколько: IAF, E2AF, FEAF, TEAF, DoDAF, MODAF, NAF, TOGAF и другие HEAF.
Есть схожие термины, например, Инженерия предприятия, но в целом это про моделирование Предприятия и его составных частей, прежде всего информационных.
Ниже показан еще один EAF с кодовым названием version 2.
Терминологическое введение

  • Enterprise architecture - архитектура предприятия, корпоративная архитектура. В "широком смысле слова" ("поздний" Захман) - это архитектура всей компании (предприятия). В "узком смысле слова" ("ранний" Захман) - это только архитектура ИТ-системы: A framework for information systems architecture
  • Архитектура, применительно к EA, - это всего лишь "верхнеуровневая структура" (концепт \ онтология \ верхнеуровневая метамодель). В ГОСТ Р 57100-2016/ISO/IEC/IEEE 42010:2011 : "3.2 архитектура (системы) (architecture): Основные понятия или свойства системы" и далее "Концептуальная модель структуры архитектуры ... Концептуальная модель элементов и связей описания архитектуры" в целом про тоже.
    Итого: a. = architecture = top-level structure
    Не путать с Чистая архитектура - подход к разработке программного обеспечения
  • Framework - элалонная модель, концептуальный шаблон. "Мир идей" - как одна из идей (онтологий) подхода к описанию EA.
    На основе какой-либо EAF (прототипе) строится EA конкретной компании, т.е. от эталонной "верхнеуровневой структуры" к описанию конкретной "верхнеуровневой структуры" конкретной компании ("Мир вещей в крупную клетку"). Следующий шаг - детализация этого описания ("Мир вещей подробно"), например, детализация каталога верхнеуровневых процессов каталогом детальных процессов или детализация архитектуры ИТ-системы в CMDB и т.д. Пример показан на рис. 2.
  • IT-system - общая ("единая", даже если представлена "зоопарком" подсистем) Информационная система (ИС) компании, "он же": автоматизированная система (АС), IT-ландшафт, экосистема, Информационно-телекоммуникационная система компании (ИТКС). Вместо "компании" можно расширить: корпорации, министерства, правительства, государства.
  • Инфраструктура (лат. infra — «ниже, под» + лат. structura — «строение», «расположение») - обеспечение базиса. Лучше уточнять название инфраструктуры и название базиса: инженерная инфраструктура ИТ-системы (обеспечение функционарования ИТ-системы), ИТ-инфраструктура процессной архитектуры (обеспечение ИТ-инструментарием для выполнения бизнес-процессов). Обычно под Технологической Архитектурой подраумевают Инфраструктуру для реализации Прикладного уровня (ППО, Application, Application layer). Иногда технологическую Инфраструктуру называют технической Инфраструктурой.
  • Mission & Business model
    • Бизнес-модель, framework / шаблон деятельности (структура), например, интернет-магазин, Uber, франчайзи, маркетплейс и т.п.
      Описание БМ (framework / шаблон формализации), например, Business model canvas
    • Бизнес-стратегия (стратегия долгосрочная \ краткосрочная), например, А) демпингуем рынок -> разоряем конкурентов –> потом взвинчиваем цены; Б) Продаем продукт ниже себестоимости, но зарабытываем на его поддержке и доработке.
    • Mission / strategic objectives Стратегические цели - ключевой итог дейятельности на определенный период времени (обычно долгосрочный), например, А) Войти в ТОР-10 лидеров рынка (определнного сегмента) ; Б) Получить такой - то объем прибыли; В) Создаем бизнес, можно даже убыточный, главное – легализация нового (созданного) актива.

1.1 EAF Samples & MataModel

Подборкка примеров Frameworks собрана в domen_EA.md.
За основу возьмем схему из itarch.info, но схему EAF сделаем процесс-центричной, т.е. в центре "Бизнес-процесс" (базис). Выше него надстройка (superstructure), скорее "идеологическая надстройка". Для реализации бизнес-процессов (целевой выход целевого процесса - продукт компании) требуются ресурсы: исполнители (роли, реализуемые через HR) и инструменты (инструментальные ресурсы процесса): от ИТ-системы до дырокола. Три указанных сущности образуют Business architecture.
В том же TOGAG "Бизнес-процесс" "размыт", см. 30. Content Metamodel, chap30, включая B.capabilities, B.Service, Function, value stream.
Метамодель Процесса можно интерпретировать как математическую функцию, для вычисления которой (для исполнения процесса, где результат - выход процесса) требуются аргументы: HR (role), it-system (или дырокол), входные данные и события. Классический BPM (Scheer, ARIS 1992) определял process = function, т.е. как синонимы.

1.2 EAF version 2

ЕА фреймворк №2 показан на рис 1. ris1
Рис. 1 Фреймворк №2 корпоративной архитектуры

Ключевым инструментом бизнес-процесса является ИТ-система (ИТ-подсистемы). Логика бизнес-процесса "руками" ИТ-системы "перемалывает" входные данные (Data Architecture, Data Catalog, Documents, etc) в выходные: в целевом случае в содержание Продуктового каталога компании (Company Products Catalog).
it2it = IT для IT: мониторинг (Zabbix), архивирование, отказоустойчивость и т.п. Фактически it2it - это выделенная "спец ИТ-компания" для Компании (государство в государстве). У этой "спец ИТ-компании" не Каталог ИТ-услуг (в понимании ITIL \ ITSM), а "технологические сервисы", которые нужны (напрямую) только самому ИТ-подразделению. На примере мониторинга: если бизнесу нужен BAM (Businesses activity monitoring), то ИТ-службе мониторинг сети \ оборудования (HP OpenView, Zabbix и т.п.). Как составная часть выделяется Development & Operations (разработка, тестирование, развертывание, можно добавить и проектную деятельность / ИТ-проекты). В отдельный домен также "традиционно" выделен security: от политики ИБ компании, моделей угроз до ПАК (програмно-аппратные комплексы).

1.3 Detailed design

Идея: EA framework (эталонная модель)-> EA конкретной компании (верхнеуровневая модель)-> Детальный дизайн (детальная модель) поеказана на рис. 2. ris1
Рис. 2 EAF + архитектура компании + Детальный дизайн

Указанный в примере подход к формализации "Состав ИС / АС" уже требует регулятор, например, ЦБ как в формате 0409072 формы (пример "кракозябры GRC\CMDB" см. 18-МР Приложение 1), так и в формате ФТК , Папка по ФТК. Для этого сделаны справочники, см. 18-МР, 850П (787П/779П), Приказ Минцифры от 22.09.20 № 486 Классификатор программ для электронных вычислительных машин и баз данных.
EAF - это тоже своего рода классификатор (таксономия / онтология), основная проблема в его качестве (логичности), детальности (подробности) и практичности: применимости и полезности для реальной работы по формализации архитектуры ("леса") и детальных элементов ("деревьев", Detailed design) комапнии и ее ИТ-системы. Картинки типа Иерархия описаний архитектур я бы изобразил иначе, см. рис. 3.

ris1
Рис. 3 МетаБлоки описания Архитектуры

Смысл в том, что процессы определяют прикладной уровень (ППО), а сами процессы (процесс = бизнес-процесс) могут быть универсальными или специфичными для отрасли. Специфичные процессы для отрасли требуют специфичного ПО - специального ПО (например, Автоматизириванная банковская система вместо, ДБО), а универсальные процессы (сross Industry) реализуются "Общим" ПО (CRM, HR, СЭД), см. ГОСТ 34.003-90 ОПО vs СПО

1.4 Business architecture

В слое (уровне, домене) Бизнес-архитектура наиболее понятными и объективными является Каталог продуктов и Архитектура процессов (см. направление BPM). Основная надстройка над ними (Каталог продуктов как связующее звено) - слой мотивации, миссия, цели и т.п. - не подлежат объктивному контролю и поэтому субьективны (т.е. рисовать можно все, что угодно, "бумага все стерпит").
См. также: https://github.com/bpmbpm/doc/blob/main/EA/BizArch/

Objective control

Можно проектировать системы (любые) "сверху-вниз" или "снизу-вверх". Архитектуру ИТ-системы можно собрать инструментальным (с помощью инструментов) способом, например, архитектуру сети. Выполняем раскрытие сети / сканирование и визуализацию сети (Network discovery, Network detector), например, через HP OpenView Network Node Manager и др., и далее через обощение и агрегацию формируем сетевую архитектуру.
С процессами (с высоким уровнем автоматизации) аналогично: Запускаем "раскрытие процессов" - Process Mining и далее детальные полученные процессы агрегиуем в верхнеуровневые (т.е. формируем архитектуру процессов). Есть программы, позволяющие автоматически формировать схемы процессов верхнего уровня.
Это примеры "объективного контроля", осуществляемого "инструментальным способом". Такие техники позволяют как инструментальным способом (снизу-вверх) через обобщение строить архитектуру или как при проектировании "снизу-вверх" инструментальным способом подтверждать (хотя бы частично) построенную.
Пока подобных техник для superstructure (условно "Mision Mining"), которые бы вычисляли реальные мисиии или цели компании (не декларируемые), - не встречал. Не удивлюсь, если появлнение Mision Mining у многих компаний на экран выдаст результат: "300% по Марксу".

2 Business capabilities

2.1 Говоря о Business architecture постоянно употребляют странное название business capabilities. Лучше бы его вообще не использовали, т.к. оно только больше запутывает и приносит вреда, чем пользы: провоцирует многочисленные дискуссии по его поводу и вообще отказ от его перевода (оправдывая сложностью перевода).
Capability - Способность/Возможность предприятия делать или преобразовывать нечто, помогающее достичь бизнес-цели или целевого показателя бизнеса.
Иногда их переводят бизнес-компетенции см. Экспресс-курс по моделированию бизнес-компетенций например, модель бизнес-компетенций – это как бы BIAN Service Landscape, где есть Business Capability по имени Loans (Кредиты), см. BIAN Framework for Banking Или карта бизнес-возможностей страховой компании.
Где-то рядом с «business capabilities» и «business functions» (но мы то знаем, что function = process).

2.2 Чтобы просто рассказать, что такое Бизнес способность\возможность\компетенция зайдем из далека. Есть детальные процессы, в основе которых workflow - см. workflowpatterns.com и docflow. Они агрегируются в верхнеуровневые процессы компании, которые называются в

  • BIZBOK: Value Streams, поток ценности;
  • Lean / BABOK: VSM, Value Stream Mapping, картирование потоков создание ценности;
  • BPM / CBOK: VAD, value added chain diagram (Michael Porter) - цепочка добавленной ценности).

Верхнеуровневые процессы обычно не имеют логику ветвления (AND\OR\XOR) и представляют собой шаги: сделай раз, сделай два … Если убрать сведения о шагах, то получим предельный уровень декомпозиции, где будет только название процесса. У процесса всегда есть вход и выход, а все эти три компонента образуют «модель черного ящика», где нам важны только входные элементы и выходные и название самого «черного ящика». Часто нам и входные элементы не важны, поэтому остаётся связка: Название процесса (название «черного ящика») и его выход. Это и есть Бизнес способность\возможность. В общем случае – это не уровень иерархии «верхнеуровневости», а тип абстракции, т.е. на любом уровне можно говорить об этой сущности. Не путать с "атомарной операцийе" (элементарной операцийе, элеиментарным действием), когда считается, что оепрация \ активность уже далее недекомпозируемая.
Процесс («черный ящик», без содержания ящика \ процесса) связан со своим результатом (выходом), т.е. продуктом процесса, продуктом компании. Например, Продукт «Перевод» - есть выход Процесса «Перевод», поэтому business capability «Перевод» (процесс перевода денег) может иметь одноименную позицию в каталоге продуктов «Продукт «Перевод». Или процесс (business capability): «HR Mgmt», продукт «HR».
Для чего это выдумали? Кроме того, чтобы всех запутать (можно было просто применить тип процесса «Черный ящик» и не придумывать непонятные сущности) чтобы обыграть следующую ситуацию, когда не важно, как реализован процесс, т.е. достаточно считать его «черным-черным ящиком». Объединяются два банка, у каждого свой ДБО (ПО дистанционного банковского обслуживания или процесс «ДБО» – не важно). Варианты объединения: а) в каждом оставить «как было», т.е. у каждого банка будет (хотя бы первое время) свой ДБО (и будет зоопарк из двух вендоров), б) заменить на один из существующих или в) внедрить третий (новый). Во всех случаях будет «business capability» = «ДБО», т.е. вывод: Нужен какой-нибудь ДБО.

2.3 Why (strategy) / How (process) / What (capabilities) Пол Хармон.
«Business capability» – это то, [что делает предприятие] (https://www.ins-pi.com/blog/business-capabilities), как в процессной формулировке «Производство табуретки» (что делать, какую обобщенную операцию) или в продуктовой «Продукт - табуретка» (what, что сделать, какой результат) - не важно. Утверждения, что способность – это совсем не результат (не результат процесса), видятся мне ошибочными, т.к. они не только часто одноименны, но и в целом концепт «черного ящика» - это в основном про результат. How (process) – как делать (табуретку) – это уже детализация шагов процесса (VAD, VSM), включая Who / Where / When (кто – исполнитель, где / когда). На вопрос почему и зачем (why) отвечает стратегия.
В целом: «Business capability» - это лишняя сущность, которая нечего не проясняет, но возбуждает споры. Ее можно заменить на «Процесс верхнего уровня» или Карта процессов верхнего уровня (Capability Map) = Архитектура процессов компании. Или процесс «как черный ящик» - как некая абстракция «способности производить результат» (продукт), при этом «способность производить результат» это как раз про процесс \ функцию. При этом «производить результат» напрямую связно с названием результата (именем продукта, при необходимости с обобщённым названием, группой).

2.4 Интерпретации Бизнес-способности от

2.5 Link

3 Отдельные уточнения

Process Framework

Архитектура процессов:

  • Process Architecture Framework, Эталонная Архитектура процессов. Есть отраслевые, есть универсальные. Примеры APQC Process Classification Framework (PCF), CoreStream Process Framework, BIAN (банковский);
  • Архитектура процессов реальной компании - вырхнеуровневое описание процессов компании (реестр, схемыб RACI и т.п.). Не путать Архитектурe процессов (процессную архитектуру) с Метамоделью процесса.

Формализация декомпозиции (документирование)

Каждый компонент архитектуры и детального дизайна должен быть классифицирован и идентифицирован (иметь идентификатор / децимальный номер) и желательно паспорт (паспортизация). Вариант оформления декомпозиции - ЕСКД ГОСТ 2.711-82 СХЕМА ДЕЛЕНИЯ ИЗДЕЛИЯ НА СОСТАВНЫЕ ЧАСТИ.

Блок из ru-нормативки

  • Критичная архитектура (не путать с критической информационной инфраструктурой в терминах 187-ФЗ «О безопасности критической информационной инфраструктуры»), введенная 850П (787П / 779П), см. рисунок ниже: ris
  • Основные уровни информационной инфраструктуры ГОСТ Р 57580.1-2017 см. п. 6.2:
    • системные уровни:
      • аппаратное обеспечение;
      • сетевое оборудование;
      • сетевые приложения и сервисы;
      • серверные компоненты виртуализации, программные инфраструктурные сервисы;
      • операционные системы, СУБД, серверы приложений;
    • уровень АС и приложений, эксплуатируемых для оказания фин услуг в рамках бизнес-процессов и технологических процессов фин организации

Плохие сочетания и определения

  • Системная архитектура. Лучше говорить "information systems architecture" (Захман), т.е. Архитектура IT-системы компании. Эта архитектура будет включать Архитектуру приложений, Архитектуру системного ПО, оборудование и далее IT-инфраструктуру (сети, СХД и т.п.), а всем им нужна еще и инфраструктура следующего слоя - инженерная (охлаждение, бесперебойное питание и др.)
  • Информационная архитектура. То ли про архитектуру информации, данных, хранилищ, то ли про архитектуру информационной системы.
  • Архитектура инфраструктуры (инфраструктурная архитектура). Не понятно о какой инфраструктуре речь, т.к. любая система, слой\уровень является инфраструктурным для для более верхнеуровневого. Сама IT-система (архитектура IT-system) - это инфраструктура для Архитектуры процессов (процессной архитектуры) или Бизнес-архитектуры.

notes

Enterprise architecture vs Enterprise engineering

link

Archimate