SVBR или семантика делового словаря и семантика бизнес-правил

Полезен для использования в рамках BPMN.

Данная заметка пересказ заметки (в момент написания она была только на английском языке) -
https://en.wikipedia.org/wiki/Semantics_of_Business_Vocabulary_and_Business_Rules

SBVR предназначен для формализации сложных правил, таких как операционные правила, политика безопасности, соответствие стандарту или нормативные правила соответствия применяемые в бизнес-среде или на предприятиях. Премимущества формализации в том, что формальные словари и правила могут интерпретироваться и использоваться компьютерными системами.

SBVR является неотъемлемой частью MDA - управляемой моделью архитектуры OMG (MDA - концепция модельно ориентированного подхода к разработке программного обеспечения).

С помощью бизнес-правил организация может направлять свою деятельность, определяя способы достижения своих целей, а также способы выполнения бизнес-операций.

Основанный на правилах подход к управлению бизнесом и информацией, является способом определения и формулирования правил, которые определяют структуру предприятия и управляют его фукционированием. Это довольно новый способ описания предприятия. Бизнес-правила могут играть важную роль в определении бизнес-семантики: они могут влиять на поведение, управлять поведением, обеспечивать реализацию политик, организовывать реакции на события и реагирование в соответствии с экономической ситуацией. Семантика бизнес-словаря и бизнес-правил (SBVR) - это реализация OMG подхода к конструированию бизнес-правил.

SBVR с одной стороны использует естественный язык в моделировании, а с другой, явно предоставляет собой модель формальной логики. SBVR - это слияние лингвистики, логики и информатики, и все это используется для сбора и созданий спецификаций, изложенных на естественном языке и представленных средствами формальной логики.

Методологии, используемые при разработке программного обеспечения, обычно применяются только тогда, когда проблема уже сформулирована и хорошо описана. Но трудность возникает именно на уровне формулирования и описания проблемы. Заинтересованные стороны, участвующие в разработке программного обеспечения, конечно могут выражать идеи, обычно не могут формализовать эти идеи ясным и однозначным способом. Поэтому нужен навык и большие усилия по интерпретации изложенных идей, "вскрытия" реальных значений и понятий, скрытые в словах. В чем то могут помочь специальные синтаксические ограничения и предопределенные лингвистические структуры, позволяющие продвинуться в деле представления и формализации проблем и требований.

Основная цель моделирования на естественном языке - сделать естественный язык пригодным для концептуального моделирования. Основное внимание уделяется семантическим аспектам и общим значениям. Синтаксис рассматривается с точки зрения перспектив формального логическом отображении исследуемых явлений.

Концептуализация и представление играют фундаментальную роль в мышлении, общении и моделировании. Концент может "разложен" на

1. концепт в наших умах, 
2. вещи реального мира, отображаенмые в концепте,
3. представление концепта, которое мы можем использовать,  о котором думать, которое сообщать.

Концептуальная модель - это формальная структура, представляющая возможный мир, состоящая из концептуальной схемы и набора фактов, которые создают концептуальную схему.

Концептуальная схема - это сочетание понятий и фактов того, что

• возможно, 
• необходимо, 
• допустимо, 
• обязательно 

в каждом возможном мире.

Множество фактов создает концептуальную схему путем утверждений (предложений) о возможным мире.

Правило - это факт, который утверждает либо логическую необходимость, либо обязательство.

SBVR содержит словарь для концептуального моделирования и "сборку" выражений, основываясь на словаре. Выражения представляют собой формальные логические структуры.

Словарь SBVR позволяет формально определять представления концепций, определений, экземпляров и правил в любой области знаний  с испльзованием естественного языка. Эти функции делают SBVR приемлемым инструментом описания бизнес-областей, требований к бизнес-процессам и информационным системам.

Люди сообщают факты и факт является единицей общения. Фактно-ориентированный подход обеспечивает многомерную категоризацию.

• Ориентированный на фактах подход поддерживает изменчивость времени.
• Фактно-ориентированный подход обеспечивает семантическую стабильность.
• Подход, основанный на фактах, обеспечивает расширяемость и повторное использование.
• Подход, ориентированный на фактах, включает разбиение составных или сложных фактов на элементарные.

Концептуальная формализация описывает бизнес-область и состоит из
1) концептуальной схемы (структуры фактов) и
2) совокупности (группы, множества) основных фактов.
Бизнес-область включает те аспекты бизнеса, которые представляют интерес.

Схема объявляет:

• соответствующие типы фактов
• соответствующие бизнес-правила

Факт - это предложение, принятое бизнесом за истину. Совокупности или группы фактов (множества фактов) состоят их элементарными фактов. На совокупности, или группы могут быть наложены ограничения, которые описывают свойства совокупностей. Они же, ограничения, определяют, какие факты могут быть включены в совокупность.

Вывод фактов.

• Вывод означает либо то, как один тип факта может быть получен из другого.
• Или, как понятие может быть определено в терминах других типов объектов и типов фактов

Подход к управлению, основанный на правилах, направлен на пользователей двух разных типов:

• для бизнес-сообществ в целях обеспечения структурированного подхода к деятельности, основанного на четком наборе понятий;
• для ИТ-специалистов для обеспечения глубокого понимания бизнес-правил, а также для содействия в деле создания моделей.

В определенном смысле SBVR - формальная логика с интерфейсом на естественном языке. Основанный на лингвистике и формальной логике, SBVR предоставляет способ представления утверждений на контролируемых естественных языках.Логические структуры представляют собой семантические формулировки. SBVR предназначен для выражения деловой лексики и бизнес-правил, а также для определения бизнес-требований к информационным системам на естественном языке. Модели SBVR являются декларативными, а не императивными или процедурными.

Логика, поддерживаемая SBVR, - это типизированная логика предикатов первого порядка. Интерпретация семантических формулировок SBVR основана на теории моделей.

SBVR фиксирует бизнес-факты и бизнес-правила, которые могут быть выражены в неформальной или формальной форме. Выражения бизнес-правил являются формальными только в том случае, если они выражаются исключительно в терминах типов фактов в предварительно объявленной схеме, в терминах определенных логических/математических операторов и квантификаторов. Формальные правила преобразуются в логическую формулировку, которая используется для обмена с другими инструментами. Неофициальные правила могут быть заменены как не интерпретированные комментарии. Имеется также подход к автоматической генерации бизнес-правил SBVR.

Спецификация SBVR определяет метамодель и позволяет использовать ее для создания различных словарей и определения соответствующих бизнес-правил; также возможно дополнить эти модели данными, подходящими для описания конкретной организации.

Подход SBVR предоставляет средства (то есть правила отображения) для перевода артефактов естественного языка в артефакты, совместимые со специфакаций мета-объектной модели MOF.

BPMN

https://en.wikipedia.org/wiki/Business_Process_Model_and_Notation

BPMN (англ. Business Process Model and Notation, нотация и модель бизнес-процессов) — система условных обозначений (нотация) и их описания в XML для моделирования бизнес-процессов.

BPMN не используется для построения:

• моделей данных,
• организационных структур,
• схем информационных потоков.

Для моделирования используются графические элементы, которые можно разделить на 4 категории:

• Объекты потока управления: события, действия и логические операторы (развилки)
• Соединяющие объекты: поток управления, поток сообщений и ассоциации
• Роли: пулы и дорожки
• Артефакты: данные, группы и текстовые аннотации.

Основные графические примитивы

• кружки - это события
• прямоугольники - это действия
• ромбы - логические операторы. которые определяют развилки
• стрелки - соединения перечисленного выше
• полосы, описываеме как "пулы" и "дорожки" - это роли
• всякие другие графические значки, типа скобки, выноски, изображения документов - это "прочие артефакты".

Отдельное пояснение касательно "пулов" и "дорожек", описывающих роли. Хорошая аналогия - бассейн с плавательными дорожками. Пул соответствует бассейну, дорожка - с пловцом.

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

И здесь возникает довольно много ошибок, состоящих в том, что "пловцы" из разных бассейнов вдруг оказываются на соседних дорожках или даже все на одной дорожке.

В линейке продуктов SAP имеется приложение для построения BPMN диаграмм - SAP Power Disigner. Изложение деталей  построения BPMN диаграмм проведем опираясь на документацию этого продукта.

SAP PowerDesigner предоставляет поддержку двух вариантов BPMN 2.0:

• Описательная BPMN 2.0 —  предназначена для бизнес-пользователей и содержит подгруппу объектов BPMN 2.0, годных для конструирования и анализа бизнес-процессов
• Исполняемая BPMN 2.0 — предназначена для разработчиков технических моделей.

Ниже приводится описание основных графических элементов, которые позволяют построить законченную схему бизнес-процесса. Перечень всех графических элементов - в документации.

Условно, подчеркну, условно разобьем описание элементов на шаги. Эти шаги примерно будут описывать порядок осмысления и формализации бизнес-процесса.

Первый шаг при построении диаграмм - определение пулов и дорожек.

Второй шаг - определение стартового и, желательно, конечного события.

Третий шаг - опеределение задач.
Бизнес-правила в большинстве случае определяются в рамках задач.

В описательной BPMN 2.0 доступны различные типы задач. Из основных - следующие:

• Cтандартная задача.
• Сервисная задача.
• Пользовательская задача.
• Действия вызова. Эта задача описывает целый процесс, который может вызываться повторно, а также использоваться в разных процессах.
• Подпроцесс. Показывает, что данное действие состоит из подзадач и на схеме эти задачи "свернуты".

Четвертый шаг, который выполняется параллельно с третьим, - определение шлюзов.
Шлюзы контролируют поток операций процесса и могут разделять или объединять поток, чтобы показать, что требуется несколько решений или одновременных действий.
В описательной BPMN 2.0 доступно два вида шлюзов.

Пятый шаг, выполняемые одновременно при выполнении третьего и четвертого шагов - определение потоков управления и потоков сообщений.

• Потоки управления — это сплошные линии со стрелками на одном конце, которые соединяют элементы процесса на диаграмме или в отдельном пуле и отображают порядок их выполнения. 
• Потоки сообщений — это пунктирные линии со стрелками на одном конце, которые соединяют два отдельных пула (или элементы двух отдельных пулов) и отображают направление отправки сообщений.

Шестой шаг - соединение задач с документами и данными.

В описательной BPMN 2.0 доступны свои типы данных, и испольнительной - свои.

Исполнителная часть BPMN гораздо сложнее описательной.

В определенной степени эта сложность уже проявляется на постере BPMN. Это постер достаточно "известный" и может быть найден в интернете.

Бизнес-логика

Бизнес-логика кодирует бизнес-правила, которые определяют, каким образом данные могут быть созданы, сохранены и изменены.

Бизнес логика:

• Предписывает, как бизнес-объекты взаимодействуют друг с другом.
• Обеспечивает применение маршрутов и методов доступа и обновления бизнес-объектов.

Бизнес-правила же являются логическими моделями (высказываниями) о реальных бизнес-объектах.

Бизнес логика включает в себя рабочие процессы, которые являются упорядоченными задачами передачи документов или данных от одного участника (человека или системы программного обеспечения) другому.

Бизнес-логика - это часть корпоративной системы, которая определяет, как данные преобразуются или рассчитываются и как они передаются людям или программному обеспечению (рабочим процессам). Бизнес-правила являются формальным выражением деловой политики.

Все, что является процессом или процедурой, является бизнес-логикой, а все, что не является ни процессом, ни процедурой, является бизнес-правилом.

Пример. Приветствие нового посетителя - это процесс (рабочий процесс), состоящий из шагов, которые необходимо предпринять, в то время как высказывание, что каждый новый посетитель должен приветствоваться, является бизнес-правилом. Кроме того, бизнес-логика является процедурной, тогда как бизнес-правила декларативны.

Бизнес-логика и уровни/слои
Бизнес-логика может быть где угодно в программе. Например, учитывая определенный формат для адреса, можно создать таблицу базы данных, в которой есть столбцы, которые точно соответствуют полям, указанным в бизнес-логике, для этих полей добавлена проверка типаю

Бизнес-логика часто меняется. Например, набор допустимых форматов адресов может измениться, когда интернет-магазин начнет отправлять товары в новую страну.

В силу это стараются разбить код на слабосвязанные части, которые позволят делать изменения в коде в соответствии с изменениями в бизнес-логики засчет небольшого и хорошо контроллируемого числа модификаций.

Это реализуется посредством многоступенчатой архитектуры, - путем создания слоев и уровней. Каждый слой отделен от других слоев, и каждый слой имеет минимальное количество кода в других слоях.

Наиболее общая архитектура, состоящая из трех слоев: слоя пользовательского интерфейса, слоя функциональной логики и слоя храннеия данных.

Бизнес-правила

Бизнес-правила описывают операции, определения и ограничения, которые применимы в организации. Бизнес-правила могут применяться к людям, процессам, корпоративному поведению, к вычислительным системам. 

Бизнес-правило определяет элементы (можно сказать, аспекты) бизнес-процесса.

"Определяет" можно отождествить с определением области допустимых значений и условий выполнения, поэтому бизнес-правила ограничивает некоторые аспекты бизнес-процесса.

Бизнес-правило может быть структурировано так:

                   Когда                           <условие (А)> 

                   Тогда                           <true> 

                   В противном случае <false>

То есть, на выходе бизнес-правила булевое значение: истина или ложь.

Бизнес-правила описывают способ преобразования стратегии в действия и мероприятия. Поэтому сами по себе бизнес-правила не могут квалифицироваться как операционные или стратегические. Бизнес-правила - это просто директивы,

Пример бизнес-правила. 

"Проверка кредита не должна выполняться для постоянных клиентов".
Или в формальной записи:

Нужно ли выполнять проверку кредита: Если клиент не относится к категории постоянных клиентов, то "TRUE", иначе "FALSE".

Бизнес-правила могут быть формальными или неформальными, задокументированными или н задокументированными.

В определенных условиях процесс описания и документирования бизнес-правил значим и важен для организации. А именно, если соблюдение бизнес-правил способствует достижению целей организаций, устраняет препятствия, уменьшает дорогостоящие и не очень дорогостоящие ошибки, улучшает коммуникацию, способствует росту рынка, то ценность описания и внедрения бизнес-правил несомненна.

Организации могут заблаговременно описать свои методы и способы ведения бизнеса и создать базу данных бизнес-правил. Хотя эта деятельность может быть полезной, но она может также быть дорогой и трудоемкой. И последнее - серьезное препятствия для документирования бизнес-правил.

Сбор бизнес-правил может быть организован различными способами.

• Бизнес-правил может извлекать бизнес-аналитик или консультант. Правила могут извлекаться из ИТ документации (как прецеденты, спецификации или код системы). Могут проводиться семинары и интервью с экспертами в соответствующих областях деятельности.
• Сбор правил могут ускорить программные технологии, разработанные для сбора бизнес-правил посредством анализа программного кода или фактического поведения пользователя.

Чаще всего бизнес-правила идентифицируются и документируются на начальных этапах проекта. Кроме того, некоторые бизнес-проекты, такие как запуск нового продукта или реорганизация сложного процесса, могут привести к определению новых бизнес-правил. Такой сбор бизнес-правил в определенном смысле является случайным. И эта "случайность" может приводить к созданию непоследовательных или противоречивых бизнес-правил в как в разных организационных единицах, так и пределах одной организационной единицы. Это несоответствие создает проблемы, которые в будущем трудно идентифицировать и трудно исправить.

Осознав недостатки практики сбора бизнес правила, эксперты по бизнес-анализу выдвинули методологию создания бизнес правил ((https://en.wikipedia.org/wiki/Business_rules_approach)

Кое-что о методологии создания бизнес-правил

Методология создания бизнес-правил определяет процесс идентификации и описания бизнес-правил на естественном языке проверяемым и понятным способом. Такой процесс не сложен в освоении, его можно выполнять в режиме реального времени, и он дает заинтересованным сторонам возможность согласованно управлять своими собственными бизнес-правилами.

В рамках данной методологии фигурируют следующие концептуальные объекты:

• Типы бизнес-правил.
• Категории бизнес-правил.
• Отношения бизнес-правил.

Типы бизнес-правил
Для определения типов бизнес-правил нужно учитывать несколько предпосылок (утверждений):

• Структурные предположения. Описания структуры, где и посредством которой регистрируются факты о предприятии, которые в последствии используются для принятия решений.
• Предположения о деятельности. Ограничения и условия, которым подчиняется или контролируется бизнес.
• Деривация или извлечение знаний. Дополнительные знания, которые вытекают из первичных знаний о бизнесе.

Принимая во внимания эти предпосылки, бизнес-правила можно разделить на:

• Правила координации. Правила, обеспечивающие деятельность без непроизводительных остановок.
• Правила квалификации/дисквалификации. Эти правила используются для определения того, что должно быть вовлечено в деятельность, а что нет. Это может быть тождественно работе фильтров.
• Правила принятия решения.

Категории
Бизнес-правила подразделяется на одну из четырех категорий:

• Определения бизнес-терминов

Бизнес-правила выражаются посредством языка. Определение термина само по себе является бизнес-правилом, которое описывает, как люди думают и как говорят о вещах. Таким образом, определение термина устанавливает категорию бизнес-правила. Термины традиционно документируются в глоссарии или описываются как объекты в соответсвующей концептуальной модели бизнес-процесса.

 

• Отношения фактов

Характер или структура деятельности организации могут быть описаны фактами, которые соотносят термины и факты друг с другом.

Например, сказать, что клиент может сделать заказ, это НЕ бизнес-правило, а факт. 

Факты могут быть задокументированы как предложения на естественном языке. Могут быть представлены графическими моделями как отношения, атрибуты и структуры обобщения.

 

• Ограничения (также называемые «действиями»)

Каждое предприятие каким-то образом ограничивает поведение, и это тесно связано с ограничениями того, какие данные могут обновляться или не обновляться. Предотвращение создания записи во многих случаях препятствует выполнению действия.

 

• Правила преобразования знаний

Бизнес-правила (включая законы природы) определяют, как знания в одной форме могут быть преобразованы в другие знания, возможно, в другую форму.

Пакеты программ
Пакеты программ автоматизируют бизнес-правила, используя бизнес-логику.

Термин бизнес-правило иногда используется взаимозаменяемо с термином бизнес-логика; однако последний термин ассоциируется с практикой - инженерная или деловой.

В ходе сбора правил организация может столкнуться с проблемой существования коллективных знаний, которые представляют собой «недокументированную" информацию, процессы и правила, которые существуют только в умах определенных сотрудников. Наличие таких бизнес-правил может привести разрывам связей и несовместимости с производством, с процессами, качеством и опытом работы.

Формальные спецификации описания бизнес-правил

Бизнес-правила могут быть выражены с использованием подходов моделирования, таких как

• унифицированный язык моделирования (UML), 
• язык выполнения бизнес-процессов (BPEL), 
• нотация моделирования бизнес-процессов (BPMN), 
• модель принятия решений и нотация (DMN), 
• семантика бизнес-словаря и Деловые правила (SBVR),
• нотация Z.

Бизнес-правила, закодированные в компьютерном коде в операционной программе, называются бизнес-логикой.

Программные системы управления бизнес-правилами

BRMS или система управления бизнес-правилами включает в себя политики, требования и условные операторы, которые используются для определения действий, выполняемых в приложениях и системах.

BRMS включает, как минимум::

• Репозиторий, предназначенный для ведения логики бизнес-правил, и соответственно, логики принятия решений.
• Инструменты, позволяющие как техническим разработчикам, так и бизнес-экспертам определять бизнес-правила и управлят ими.
• Среду выполнения, позволяющая приложениям вызывать логику принятия решений, управляемую BRMS, а также выполнять бизнес-правила.

Стоит упомянуть от встроенной в продукты SAP системы управления бизнес-правила - BRFplus. Что в некоторых случаях существенно облегачает кастомизацию конкретного решения.

Фундаментальные вопросы для прорывных технологий после того. как кризис закончится

Быстрое глобальное распространение COVID-19 - большой шок.

Кризис кризисом, но уже есть признаки творческого построения бизнеса. Компании по необходимости реагируют на кризис инновационными решениями.

Способность предвидеть новые способы работы будет иметь решающее значение для преодоления кризиса. Успешные зададут тон последователям. И если диффузия инноваций наберет силу, возникнут новые шаблоны или даже парадигмы поведения потребителей и корпораций. В этом случае можно говорить о появлении новой операционной структуры.

Те, кто надеется лидером в новом мире, должны задать себе несколько фундаментальных вопросов:

• Как изменятся потребности клиентов в посткризисное новом установивщемся состояние?
• Как будет осуществляться взаимодействие с клиентами?
• Как будет осуществлять послепродажное обслуживание (например, ремонт) клиентов (например, если не будет доступа к оборудованию клиента)?
• Как будет наниматься персоанал с учетом удаленного доступа к рабочей сили по всему миру и где угодно?
• Как создать устойчивость своей цепочки поставок без чрезмерного вложения капитала?
• Какие затраты и операции станут переменными?
• Какие организациионые структуры и бизнес-операции станут переменные в силу постоянно меняющегося и динамичного мира?
• Как вы будете производить цифровой контент в сравнении с аналогичными действиями ваших конкурентов?

Конструктивные ответы на эти вопросы могут послужить мотивов и причиной развития прорывных технологий. Отсутствие ответов может быть причиной увядания. В самом деле, кризис масштаба первой половины 2020 года приносит сейсмические сдвиги, изменяет ожидания бизнеса и создает новые возможности для инноваций.
Стоит подумать, как не упустить возможности, которые откроются после того, как кризис будет преодолен. А также ответить на угрозы, которые также изменяться, но тем не менее будут присутствовать.

Источником данной заметки послужила публикация:
Инновации по необходимости: императив делового строительства в условиях нынешнего кризиса

Прошло некоторое время с момента публикации это статьи и вопросы, поставленные в статье, по прежнему актуально.

Роль и место военной силы в системе безопасности

Роль и место военной силы в системе безопасности Российского государства определяются двумя основными обстоятельствами:

• во-первых, применение военной силы есть наиболее решительный и жесткий способ достижения политических целей, хотя в ряде случаев и не самый эффективный. Впрочем, вопрос эффективности силовых решений представляет собой отдельную проблему: многое здесь зависит от конкретных условий и степени отлаженности механизма осуществления
• силовых акций.
• Во-вторых, войны и военные конфликты в течение неопределенно долгой перспективы будут неотъемлемой частью мировой политики. Это объясняется многими обстоятельствами. В том числе и тем, что идея насилия отнюдь не является неприемлемой для абсолютного большинства людей, особенно когда речь идет об их жизненно важных интересах.

В ядерный век реализация прямой функции военной силы в полном ее объеме маловероятна, поскольку это чревато широкомасштабной войной, которая может перерасти в ракетно-ядерную с неизбежным катастрофическим исходом. Вместе с тем абсолютных гарантий того, что события не могут развиваться по такому сценарию, нет.

...пока значение косвенных функций военной силы представляется преимущественным. Выделим наиболее важные из них.

Функция сдерживания состоит в том, что вооруженные силы, обладая необходимым потенциалом и соответствующим уровнем боевой готовности, находятся в состоянии нанести
потенциальному агрессору неприемлемый для него ущерб, что и является эффективным фактором предотвращения войн и вооруженных конфликтов.

Функция политической и военной стабилизации тесно связана с предыдущей. Дело в том, что военная сила выступает как элемент региональных и глобальных систем безопасности. Она может использоваться для прекращения уже идущих военных конфликтов, разграничения враждующих сторон и т.д.

Функция принуждения агрессора к миру и его наказания, по сути, производна от функций сдерживания и стабилизации.

Функция создания выгодного для государства соотношения сил в международных отношениях реализуется не только наращиванием собственной военной мощи, но и объединением ее с военной силой других государств путем создания военнополитических союзов и блоков.

Функция борьбы с терроризмом и организованной преступностью.

Функция демонстрации статуса государства. В современном мире экономическая мощь и политическое влияние государства сочетаются с его военной силой. Эти три составляющие его
статуса являются взаимодополняющими и необходимыми.

Холодная война: В 2 т. — (Военная история Российского государства / Под ред. В.А. Золотарева). — М.: ИНЭС, РУБИН, 2014.
Т. 2: От Потсдама до Мальты / Илиевский Н.В. — 584 с.

Теоретические моменты ИТ-архитектуры

Итак, имеем разрыв в "пользовательском удовлетворенности" программными решениями.
80% ИТ-специалистов уверены, что они предоставляют "супер решения", но с этим согласны только 8% процентов пользователей.

Видимо, такой разрыв все-таки осознается поставщиками программных решений. В самом деле, изменяется подход к разработки приложений. Уже не приемлемо просто разрабатывать приложения. Приложения нужно "вписывать" в бизнес-архитектуру.

Результат - видение новой, "многоэтажной" архитектуры:

Развертывание архитектуры во времени дает "пространственное" представление.

Разработка приложений с учетом архитектурных требований требует особого управления ИТ-процессами.

Понятия данной модели.

Прозрачность

• Метамодель.
• Модели (ландшафт, модели предметной области, справочники и т.д.).
• Специфические виды анализа.
• KPI.

Планирование

• Целевая модель.
• Дорожная карта.
• Планы трансформации (проекты, порфель проектов).
• Координация требований и координация заинтересованных лиц.

Правила.

• Принципы (стандарты, регламенты и т.д.).
• Методы.
• Структура управления.

Коммуникации.

• Маркетинг/Продажи.
• Тренинги.
• Обмен опытом и лучшие практики.

Реализация.

• Представление проекта.
• Поддержка проекта.
• Мониторинг проекта.

Все это может быть представлено также и такой схемой проекта:

Отдельный вопрос - координация интересов стейкхолдеров. Стейкхолдеры как минимум это вовлеченные в ИТ-процессы лица. И надо отметить, что список стейкхолдеров (заинтересованных лиц) в процессе цифровой трансформации расширяется:

Вовлеченность заинтересованных лиц в процессы цифровой трансформации может быть расписана таким образом:

Перевод:

Меняется навсегда

Франк Диана провел анализ футуристической статьи и собрал предсказания в одну таблицу в этой заметке 30 ведущих экспертов рассказывают о том, что изменится навсегда

Вот эта табличка, созданная Франком Диана Frank Diana