Модели для цифрового мира

1 Выражение «Все модели ошибочны…» ошибочно

«Все модели ошибочны» -- это известный афоризм из статистики (приписываемый математику George Box 1976), который был перенесен в другие дисциплины. Одна современная книга о системной инженерии утверждает, что «Карта не территория, меню не едят, на чертежах не летают, исходный код не хранит значения своих переменных в ходе исполнения».

Давайте проанализируем эти утверждения. Территория существовала до появления карты. Карта – это информационный (цифровой, в наше время) «двойник» территории. Так как территория – это натуральный (сделанный природой) объект, то ее цифровой «двойник» (сделанный человеком) вторичен и приблизителен.

Меню – это план шеф-повара и, одновременно, информационный (цифровой, а наше время) «двойник» услуг кухни. Услуги кухни планируются по нескольким причинам – обсудить их со всеми вовлеченными лицами, организовать работу, оптимизировать затраты и уменьшить риски. То есть меню (как инструмент планирования) помогает в достижении результата, но оно не необходимо для оказания услуг. В этом случае, информационный (цифровой, а наше время) «двойник» возможно появляется раньше своего физического «двойника».

Понятно, что на чертежах не летают, но и без них тоже не летают. Т.е. чертежи – это необходимая «часть» самолета, изготовленного по этим чертежам. Понятно, что сами по себе чертежи не являются достаточной «частью» самолета – от чертежа до рабочего экземпляра очень большой путь. Однако, можно считать, что чертежи – это информационные (цифровые, в наше время) «предки» самолетов. В этом случае, информационный (цифровой, а наше время) «двойник» обязательно появляется раньше своего физического «двойника».

Ну и, наконец, программа и ее исходный код. Какие между ними отношения? Без исходного кода нет программы. Исходный код может быть выражен в нескольких представлениях – на языке высокого уровня и в языке машинных инструкций (т.е. ассемблере). Это широко распространено, но не обязательно – исходный код может интерпретироваться непосредственно без перевода на ассемблер. На что же это похоже? Ба, да это же генетический код для бионической программы! В геноме нет всех деталей, но он определяет (хотя и частично) будущую бионическую систему. Конечно, это адаптивная система со сложной процедурой «bootstrap». (Отметим также, что современные программные системы обязаны быть высоко-dependable.)

То есть, цифровым способом мы повторяем матушку-природу – создаем цифровой генокод (на каких-то языках программирования) и из него создаем программу при помощи цифровой среды. Таким образом, исходных код – это главная часть программы. И то и другое – цифровые артефакты. В этом случае, существует только информационный (цифровой, а наше время) «двойник». Ну тогда он не «двойник», а «оригинал»! И это цифровая модель.

	Физическая форма	Цифровая форма
Первично	1. Территория	2. Меню (возможно) 3. Чертеж (обязательно) 4. Программа (неизбежно)
Вторично	2. Еда 3 Самолет	1. Карта

2 Стирание различий между архитектурой и ее описанием в цифровом мире

Для цифрового мира, мы обязаны слегка подправить некоторые положения стандарта ISO/IEC/IEEE 42010 Systems and software engineering — Architecture description, который явно разделяет собственно архитектуру системы и описание архитектуры. Последняя и состоит из моделей, которые в цифровом мире не только средство описания архитектуры, но и неотъемлемые элементы самой (т.е. реальной) системы.

Применение цифровых моделей:

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

Такие цифровые модели являются машинно-читаемыми и машинно-исполняемыми. Например, бизнес-процесс– это не только иллюстрация, но и фрагмент исходного кода системы. Это повышает интерес к Domain-Specific Languages (DSLs), с помощью которых некоторые элементы системы можно определять в понятиях бизнеса. Снова, BPMN – это типичный пример DSL. (Как много лет назад с появлением SGML и HTML стали говорить: программа становиться документом, в документ – программой.) Ну а появление машинно-исполняемых элементов системы на ранних этапах ее жизненного цикла позволяет говорить о зарождении культуры BizDevOps как естественного расширения культуры DevOps.

Логика «точек зрения» (viewpoints) меняется – они предназначены для систематического создания моделей (models), некоторые из которых будут цифровыми, т.е. машинно-исполняемыми элементами или машинно-читаемыми элементами (или номенклатурами, например, списком всех ролей). «Точки зрения» становятся, своего рода колоннами акведука, которые поддерживают логику создания цифровых моделей.

Фрагмент самого длинного (132 км) римского акведука, Тунис.
(кстати, некоторые части этого сооружения все еще работают и используются местными жителями)

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

Все это частично изложено в подборке https://improving-bpm-systems.blogspot.com/search/label/%23BAW


Thanks,
AS