Зачем нужна архитектура

Несколько дискуссий на Facebook в группе «Архитектура Цифровой Страны как цифровой системы» показали необходимость уточнения понятия «архитектура», т.е. какой смысл подразумевается под этим словом. В группе говорим об архитектуре «цифровых» и «умных» систем типа Цифровая Страна, Цифровой Регион и Умные Города. Эти системы включают в себя различные «цифровые» и «умные» направления, такие как Цифровое Государственное Управление, Цифровое Законодательство, Умные Здания, Умные Жилища, Цифровое Здравоохранение, Умная Энергия, Умное Производство и т.п. Все эти направления - также весьма крупные цифровые системы, результат созидательной работы человека.

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

1 Факторы сложности построения цифровых систем

Упрощенная логика развития любой системы состоит из следующих трех шагов:

1. ЦЕЛЕУКАЗАНИЕ. Определяется какой будет система через некоторое время. Например, через 3-5-10 лет. Такое описание «целевой системы» называется «видение». Это «видение» уточняется несколькими «стратегическими направлениями», которые имеют измеряемые «стратегические показатели» и их «целевые значения». Например, за 10 дет повысить среднюю продолжительность жизни в стране до 80 лет. 
2. СТРАТЕГИЧЕСКОЕ ПЛАНИРОВАНИЕ. Определяется то, как будут достигаться поставленные целевые значения стратегических показателей. Для этого, по каждому стратегическому направлению определяются задачи (уже знакомые работы) и порядок их выполнения. Можно изложить задачи, как «дорожную карту» (план-график, стратегический план и т.п.). Например, каждый год вводить в эксплуатацию по 10 млн. кв. метров жилья. На основе дорожной карты вычисляется оценочная стоимость построения целевой системы. 
3. ИСПОЛНЕНИЕ. Осуществляется реализация дорожной карты, путем выполнения указанных задач. 

Про систему известно, что

• система – это совокупность взаимодействующих элементов (возможно уже существующих); 
• взаимодействие элементов системы создает эмерджентные (приобретённые) характеристики системы; (Примеры эмерджентных характеристик – фактическая производительность, уровень защищённости и т.п.), и 
• эмерджентные характеристики системы необходимы и достаточны для достижения целей, поставленных перед системой. 

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

Если в системе около 1000 элементов, то потенциальных связей между ними будет N*(N-1)/2, где N=1000, т.е. довольно много. Поэтому, разработка стратегии становится сложным делом, как для одного человека, так и для группы неспециалистов. Ситуация усугубляется тем, что типичные требуемые эмерджентные характеристики для цифровых систем обычно примерно такие, как:

• способность к взаимодействию, интеграции (interoperability), 
• безопасность (safety), 
• защищенность, включая конфиденциальность, целостность и доступность информации (security, including information confidentiality, integrity and availability), 
• защита частной информации (privacy), 
• устойчивость (resilience), 
• низкая стоимость эксплуатации, 
• способность к быстрой адаптации, 
• короткое время выхода на рынок. 

Цифровая природа цифровых систем делает их чрезвычайно «хрупкими». Малейшая ошибка системы есть крах, который быстро распространяется с огромным ущербом, как с карточным домиком. С этим недостатком можно и нужно бороться, но это есть фактор сложности.

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

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

2 Хорошо продуманная архитектура, как средство для борьбы со сложностью

По определению в стандарте ISO/IEC/IEEE 42010:2011, архитектура системы представляет собой то, что существенно для системы, рассматриваемой в ее окружении. Другими словами, архитектура – это коротко о главном. Этим главным может быть что-то или все из следующего списка:

• элементы системы; 
• расположение и взаимосвязь элементов системы; 
• принципы организации или проектирования системы; 
• принципы, регулирующие эволюцию системы в течение ее жизненного цикла. 

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

Согласно стандарту ISO/IEC/IEEE 42010:2011, архитектурные описания используются для выражения архитектуры конкретной системы (как существующей, так и целевой). Архитектурные описания создаются в процессе создания архитектуры конкретной целевой системы. Неформально говоря, архитектурное описание – это согласованный набор архитектурных положений (decisions) относительно конкретной системы. Правильные положения, принятые в правильные моменты существенно упрощают создание системы (по времени, бюджету и нервам).  Идеально, эти архитектурные положения делают целевую систему:

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

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

Архитектурные положения могут быть стратегическими (так же называемыми «архитектурные принципы» для всей конторы), операционными (например, процедуры утверждений, список используемых стандартов) и тактические (например, типовые архитектуры решения). Главное, чтобы все эти архитектурные положения были:

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

Архитектурные положения могут быть:

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

Все архитектурные положения должны быть:

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

Архитектурное описание целевой системы используется в следующих целях:

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

Все это выглядит очень сложно, но есть бонус для цифровых систем – некоторые архитектурные описания могут быть машинно-исполняемыми и являться элементами целевой системы. Таким образом, такие архитектурные описания не надо дополнительно «интерпретировать» человеком для их реализации. Этот подход известен как Model-Based System Engineering. 

3 Создание архитектурного описания

По стандарту ISO/IEC/IEEE 42010:2011 архитектурное описание состоит из архитектурных моделей (architecture models), которые назывались -архитектурные положения. Архитектурные модели связывают вместе какие-то архитектурные артефакты. А архитектурные модели сгруппированы в архитектурные виды (architecture views).

Например, бизнес-процесс – это архитектурная модель, которая связывает следующие архитектурные артефакты: события, роли, правила, данные, документы, отчеты, работы, и т.п. А все бизнес-процессы создают архитектурный вид «контора, как система процессов» (см. http://improving-bpm-systems.blogspot.com/2014/03/enterprise-as-system-of-processes.html ).

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

На рисунке ниже, крупные прямоугольники – архитектурные виды, а мелкие – архитектурные модели.

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

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

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

4 Создание архитектурного описания для цифровых тиражируемых систем

Все цифровые системы типа Цифровая Страна, Цифровой Регион и Умные Города обязаны быть тиражируемыми, чтобы их можно бы было легко реализовать в разных странах, разных регионах и разных городах. Понятно, что типовая система для «Умного Города» не подходит всем города, т.к. каждый город в чем-то уникален.

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

Эталонная архитектура «Умного Города» разрабатывается комитетом МЭК по «Умным Городам». Она содержит более чем 60 разных архитектурных моделей, сгруппированных в 10 архитектурных видов.

Более подробно это представлено в https://egov-tm.blogspot.com/2018/10/blog-post.html и https://egov-tm.blogspot.com/2018/05/blog-post_29.html . 

5 Архитектура в национальной программе ЦЭ

В национальной программе ЦЭ, архитектура цифровых систем представлена довольно однобоко – только как архитектура данных (см https://egov-tm.blogspot.com/2018/10/blog-post_31.html ). Это соответствует точке зрения официальных цифровизаторов о том, что ЦЭ – это «использование зрелых технологических решений» (большие данные, блокчейн, искусственных интеллект), которые интенсивно используют данные.

Неудивительно, что программа подготовки CDTO или «Руководителя цифровой трансформации» соответствует уровню руководителя цифрового проектного офиса.

Остается только один вопрос, – кто же будет проектировать ЦЭ? Похоже, считается, что внедрение некоторый цифровых технологий обработки данных автомаГически создаст ЦЭ. Про эмерджентные характеристики ЦЭ остается только мечтать. 

6 Заключение

Увлеченность только данными показывает, что подходы официальных цифровизаторов соответствуют состоянию дел на Западе с отставанием на 20-30 лет. Сейчас, на Западе пришло понимание важности использования корпоративной архитектуры для выполнения цифровой трансформации. Полное игнорирование корпоративной архитектуры для ЦЭ вызывает большие сомнения в успехе национальных программ.

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



Thanks,
AS