воскресенье, 16 февраля 2020 г.

Corruption by design? Запланированная коррупция?

Интересный блогпост от Анатолия Казакова https://pmo-virtual.blogspot.com/2014/01/blog-post.html с моделями организации бизнеса и упоминанием «тезиса о разделении собственности и контроля, как условия для решения задачи противодействия злоупотреблениям и коррупции». Также интересно, что «Исследователи сосредоточили свои усилия на выявлении институциональных механизмов, которые были бы способны, несмотря на отделение собственности от контроля, дисциплинировать поведение наемных менеджеров в интересах собственников.» См. https://works.doklad.ru/view/jcG2qWt2tkc.html

Также интересна картинка с разными моделями по странам из https://www.hse.ru/data/2010/05/04/1216402505/WP1_2005_03.pdf.


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

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

Thanks,
AS

четверг, 29 августа 2019 г.

Общий стэк эталонных архитектур

Проблема эталонных архитектур, которые суть международные стандарты, хорошо известна – это то, что эти эталонные архитектуры создаются разными способами. Поэтому эти эталонные архитектуры не могут работать вместе по своему архитектурному созданию (by-design). Например, для Умного Города (УГ) требуются Интернет Вещей (ИВ), Большие Данные (БД), Искусственных Интеллект (ИИ), Блокчейн и т.п., а они все задуманы по-разному.


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

Результаты этой встречи еще не окончательны, но есть надежна на приемлемое решение этой проблемы. Сейчас обсуждается «Общий стэк эталонных архитектур», который состоит из следующих элементов: 
  • стандарта ISO/IEC/IEEE 42010:2011 (42010)
  • мета эталонной архитектуры (mRA)
  • общей эталонной архитектуры (generic-RA)
  • доменной эталонной архитектуры (DS-RA)
  • эталонной архитектуры решения (solution-RA)
  • архитектуры решения (solution architecture)
  • реализации (implementation)
При этом все эталонные архитектуры являются архитектурами, разработанными по правила 42010. Иллюстрация ниже показывает взаимосвязи между этими элементами. Отметим, что solution-RA задумано для создания вариантов доменной архитектуры, например, эталонная архитектура ИВ для УГ или создания более детальной эталонной архитектуры. При этом, generic-RA может содержать общие архитектурные элементы (например, схемы данных) для всех доменов.

Получается, что Программное Обеспечение (ПО) БД на основе DS-RA Big Data будет стыковаться с ПО УГ на основе DS-RA Smart Cities (SC), a ПО ИВ на основе solution-RA IoT for SC будет стыковаться с ПО УГ на основе DS-RA Smart Cities (SC).



В случае использования этого стэка для Цифровой Трансформации страны, generic-RA может соответствовать национальному уровню, который определит, например, национальные схемы данных. DS-RA может соответствовать Сквозным Цифровым Технологиям (СЦТ), министерствам и национальным программам. А solution-RA может соответствовать типичным приложениям.

По крайней мере, все архитекторы будут разговаривать на одном языке.


Thanks,
AS

пятница, 28 декабря 2018 г.

Особенности Национальной Цифровизации: История одного города

Известному выражению «рожденный ползать летать не может» соответствует одна из системных эвристик (см. ниже), которая гласит: If the politics don’t fly, the system never will. Это означает, что конечный успех большОй, сложной системы определяется в бОльшей степени социальными и политическими факторами, чем техническими характеристиками. Проиллюстрируем эту эвристику на ведомственной программе «Умный Город».



Эвристика - совокупность приёмов и методов, облегчающих и упрощающих решение познавательных, конструктивных, практических задач.

1 Ведомственная программа «Умный Город»


Благодаря активности МинСтроя широко обсуждается ведомственная программа «Умный Город». При этом вокруг этой программы наблюдается «вихрь» переплетающихся и противоречивых суждений:

- МинСтрой предлагает несколько исполнителей (отечественных и зарубежных) для различного функционала «умного города» ( см. http://www.minstroyrf.ru/press/rossiya-i-frantsiya-opredelili-proekty-dlya-dvustoronnego-sotrudnichestva-v-sfere-umnykh-gorodov/ )

- Города настаивают на своей уникальности, требуют самостоятельности в контроле за ресурсами ( см. https://www.znak.com/2018-12-19/v_rossii_razvernulas_diskussiya_o_tom_kakim_dolzhen_byt_smart_siti ).

- Вице-премьер по цифровизации подчеркивает необходимость тиражируемых решений ( https://www.youtube.com/watch?v=EcPdNajWM3E&feature=youtu.be ). При этом предлагается подождать появления «хорошего российского кода».

- Тиражирование, с точки зрения Совета Федерации, состоит в технологическом аспекте. Например, типовых технологических решений, обязательных для внедрения ( https://www.youtube.com/watch?v=zfyHekaxsTs ).

- Режим «ожидания у моря погоды» также полностью поддерживается МинСтроем, который создал каталог хороших решений, и заявил, что Минстрой не будет настаивать на вводе единой платформы для «умных городов» в России (см. https://tass.ru/nedvizhimost/5925601 ).

- В декабре 2018 года Президент сказал: «Нам нужен прорыв и новый технологический уклад, иначе у страны нет будущего». Понятно, что стратегия «ждем у моря походы» не приведет к требуемому технологическому прорыву.

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

2 Сравнение вариантов построения «Умных Городов»


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

Вариант построения
Заинтересованные стороны
Граждане
Общество
Города
ИТ стартапы
Средние ИТ компании
Большие ИТ компании
МинСтрой
Государство
Кастомизация
--
--
--
--
-+
++
+-
-+
Конкуренция
--
--
--
--
-+
-+
--
-+
По-европейски
--
--
--
-+
-+
+-
-+
-+
По-индийски
+-
+-
+-
+-
+-
+-
--
+-
Системно
++
++
++
++
++
++
++
++


-- очень негативно
-+ негативно
+- позитивно
++ очень позитивно

3 Кастомизация


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

Анализ

Затраты на эксплуатацию «умного города» лежат на самом городе. Если создается уникальная версия для какого-то города, то затраты на ее эксплуатацию возрастают в разы. Поэтому-то и разрабатывается эталонная (референтная) архитектура, чтобы избежать насколько возможно такие кастомизации. Тут выгоднее потратить несколько больше усилий на реализацию параметризуемого, тиражируемого решения. Поэтому легко тиражируемое решение несколько дороже просто решения – см. https://egov-tm.blogspot.com/2018/08/blog-post.html ). Естественно, что фирма-разработчик более заинтересована в кастомизации, а все города и государство – в широких возможностях по параметризации.

4 Конкуренция


Меньше ограничений – больше возможностей. Для любого бизнеса важны клиенты готовые покупать, т.е. имеющие потребность в приобретении того или иного продукта. Любой бизнес существует потому, что у клиентов есть потребности за которые они готовы платить деньги. Государство в лице Минстроя «создало» таких клиентов, точнее «инициировало» появление потребностей у большого числа клиентов. Круг этих клиентов определен и известен почти поименно. А вот потребности у этих клиентов туманны – это неопределенные потребности.

Такая ситуация слишком уж хороша для бизнеса. И глупо проходить мимо неё. Почему? Так всё очень просто. Неопределенные потребности– это когда Клиенты уже хотят купить «Умный город», им очень нужен этот самый «Умный город», но они не знают пока какой именно. Из чего он состоит, сколько он стоит, какой эффект приносит, какие технологии являются самыми лучшими, как правильно финансировать такой проект и т.п. Множество вопросов, на которые у клиентов сегодня нет ответов. См. http://www.cnews.ru/special_project/2018/krok/index.shtml

Анализ

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

5 По-европейски - интероперабельность


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

Анализ

Интероперабельность превозносится в Европе, потому что каждая страна защищает свой рынок – "я делаю у себя что хочу, но согласен общаться по общим правилам". В результате, аналогичный функционал реализуется почти 30 раз, что очень хорошо для ИТ компаний, но не для налогоплательщиков. Похожий вариант построения систем был в Швейцарии, когда каждый кантон делал все по-своему, но с этим постепенно борются путем создания общих сервисов. В случае страны, на такую роскошь нет ни денег, ни времени и технологического прорыва из этого не получится.

6 По-индийски - стандартизация ИТ инфраструктуры


В Индии давно поняли  ( https://egov-tm.blogspot.com/2018/12/blog-post.html ) – нужна единая ИТ инфраструктура, которая позволит адаптироваться к местным условиям и перенимать хорошие разработки (легкая тиражируемость). Хотя это взаимно противоречивые требования, их можно совместить. Вот он путь – для возможного технологического прорыва. И этого в больших проектах никто еще не умеет делать, значит есть экспортный потенциал.

Анализ

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

7 Системное создание цифровых тиражируемых «Умных Городов»


Хорошо известно, что легкая тиражируемость не получается автомагически, а требует определенных усилий ( см https://egov-tm.blogspot.com/2018/08/blog-post.html ). Также, нужно достичь баланса между использованием индивидуальных (все города разные) и унифицированных (всегда есть что-то общее между городами) решений. Поэтому постепенно создается и развивается Цифровой Инструментарий Цифровой Трансформации (ЦИЦТ), который состоит из:
  1. системы онтологий (или формальных терминологий); 
  2. единой методологии разработки цифровых тиражируемых систем (например, типа «Умный Город»); 
  3. общей архитектуры цифровой тиражируемой системы; 
  4. эталонной цифровой тиражируемой системы (единая цифровая платформа, перечень ИТ продуктов и набор платформенных решений); 
  5. единых практик доработки, управления, руководства и эксплуатации цифровой тиражируемой системы; 
  6. правил привязки цифровой тиражируемой системы к реалиям клиентов; 
  7. практики выполнения проектов типа «Умный Город», которые учитывают индивидуальность города, включая его граждан и их общества. 

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


Анализ

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

Важно, что этот вариант учитывает интересы всех заинтересованных сторон. (Как мы все помним еще одну системную эвристику, для социо-технических систем часто КАК делается более важно, чем ЧТО делается.)

8 Заключение


Умные Города – это уникальный шанс для улучшения жизни миллионов людей, технологического прорыва и выхода на внешние рынки.


Thanks,
AS


“Особенности Национальной Цифровизации” это серия блогпостов с тагом #ОсобенностиНациональнойЦифровизации

вторник, 18 декабря 2018 г.

Краткий обзор международной конференции по «Умным Городам» в г. Варанаси, Индия

10 декабря 2018 года, в городе Варанаси (Индия) прошла однодневная конференция по стандартизации в области Умных Городов «Smart standards – Smarter Cities». Соорганизаторами были Индийское Бюро по Стандартизации ( bis.gov.in ) и МЭК ( iec.ch ). Не случайно для этой конференции был выбран город Варанаси, который является старейшим на Земле местом постоянного проживания людей (возраст города около 3 000 лет).

Формат конференции (две организации по стандартизации как соорганизаторы) был выбран, чтобы помочь Индии с ее амбициозной программой «100 Умных Городов (УГ)», которая продвигается Премьер-Министром Индии. Отметим, что программа «100 УГ» – это только одна из 6 национальных программ урбанизации Индии ( см. https://smartnet.niua.org/missions ).



Программа «100 УГ» (см http://smartcities.gov.in/content/ ) построена на основе хороших и проверенных практик руководства программами и проектами (programme and project governance). В каждом городе, который участвует в этой программе, есть принадлежащее городу предприятие по УГ, которое и ответственно за выполнение программы в данном городе. Эти предприятия подчиняются секретарям министерств по жилищам и городам в каждом штате и секретарю федерального министерства по жилищам и городам. Этот секретарь федерального министерства и руководители примерно 40-а предприятий по УГ присутствовали на конференции. Все докладчики из программы «100 УГ» выступали «не по бумажке» и продемонстрировали очень уверенное владение темой.

Главной проблемой на текущий момент для программы «100 УГ» является тиражирование программных решений, которые были разработаны в разных УГ. Так, один из руководителей предприятия по УГ оценил, что примерно 50-70% бюджета идет на разработку программного обеспечения, а это значит, что возможность беспроблемного тиражирования даст кратную (примерно в 2-3 раза) экономию средств. Подчеркивание этой проблемы показывает, что Индия, со своим мощным сектором ИТ, не может, автомагически, создавать тиражируемые программные решения.

Вторая группа выступающих была из группы «Smart Infrastructure Sectional Committee - LITD 28» Индийского Бюро по Стандартизации, которая разрабатывает стандартную инфраструктуру, включая информационные технологии, операционные технологии и интернет-вещей. Выступление лидера этой группы (Dr Kishor Narang) показывает, что Индия хочет построить единую вычислительную инфраструктуру для «100 УГ». Однако, по признанию руководителя группы, в индийском секторе ИТ отсутствуют архитекторы цифровых тиражируемых систем, которые бы могли увязать:
  • практики местных разработчиков программного обеспечения и 
  • потребности «100 УГ» в тиражируемых решениях. 
Третья группа выступающих была из системного комитета МЭК по УГ. Докладчики рассказали о прогрессе в разработке международных стандартов УГ. Дополнительно было показано расширение системного подхода МЭК, которое позволяет индийским и другим ИТ-архитекторам уверенно создавать цифровые тиражируемые системы для программы «100 УГ» (см. https://www.facebook.com/groups/252568801952249/permalink/389142408294887/ ). Также появляется возможность построения экосистемы разработчиков из стартапов, местных ИТ компаний и международных ИТ гигантов.

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

Thanks,
AS




четверг, 1 ноября 2018 г.

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

Несколько дискуссий на 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

четверг, 25 октября 2018 г.

Особенности Национальной Цифровизации: Магия данных

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

1 Однобокая архитектура


Недавно в Сколково было анонсировано создание «Общенациональной архитектуры данных» ( см. https://www.youtube.com/watch?v=amB7cFSlR9o ). Признание необходимости архитектуры – это очень серьезный и позитивный шаг вперед, однако видение всей сложности цифрового государства как только набора данных, является крайне однобоким.

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


Заявления «Цифровизация - это не про ИТ, а про перестроение бизнес-процессов под воздействием данных.» (см. http://www.comnews.ru/content/115369/2018-10-16/ekonomiku-rf-ocifruyut-ministerstva#ixzz5UjjGv9Lc) как-то не соответствуют с однобокостью архитектуры.

2 Даже SAP еще это не умеет


Так SAP EVP Database and Data Management Franz Faeber в июне 2017 сказал, наличие «больших данных» пока не гарантирует получение информации, ценной для руководства компании и ее клиентов – «Most important from our point of view , when we speak with the customers and what we see also internally is: the missing link between the enterprise world and the big data world!» [SAPPHIRE] 

3 Определения у официальных цифровизаторов еще не проработаны


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

данные 
символы и сигналы, которые представляют характеристики объектов, людей, событий и т.п. ( см. Ackoff http://faculty.ung.edu/kmelton/documents/datawisdom.pdf )

информация
структурированные данные, наделенными смыслом и целью

Заметим, что данные и информация могут быть в различных представлениях: материальном, аналоговом, цифровом и т.п.

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

Когда-то давно, современные ИТ департаменты назывались "Data Processing Division". Сейчас же нормальные люди заинтересованы в информации и знаниях, а, также, в мудрости ( см https://ru.wikipedia.org/wiki/DIKW ).


Разницу между данными и информацией можно объяснить следующим образом:

  • Символ: «T» - это только данные
  • Текст: «Клавиша "T" – это томаты» на весах в супермаркете – это информация (вспоминаем классику - "информация к размышлению")
  • Википедия: «Томаты -- это ягода» -- это знание
  • Из личного опыта «Томаты не для фруктового салата» -- это мудрость


4 Системы существенно сложнее


Если посмотреть какие типы артефактов есть в, практически, любой конторе, то увидим следующий «торт Наполеон».
  1. Клиенты 
  2. Товары и услуги 
  3. Жизненные циклы товаров и услуг 
  4. План предпринимательства 
  5. Бизнес-процессы 
  6. Бизнес-решения 
  7. Бизнес-партнеры 
  8. Взаимодействия с партнёрами и клиентами 
  9. Технологии 
  10. Информация 
  11. Данные 
Идеально, каждый слой – это какой-то «взгляд» на (или какая-то «модель») всю контору. Например, кто-то «видит» контору как связанный набор бизнес-процессов, а кто-то другой «видит» ту же контору как массив данных. Переход с какого-нибудь слоя на более нижний – это серьёзная работа по созданию хорошо функционирующей конторы. Прыжки в обратном направлении да еще через несколько слоев – это магия.


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

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

5 Заключение


Достижение целей, поставленных вице-премьером ( см. http://d-russia.ru/v-skolkovo-prezentovali-natsionalnuyu-programmu-tsifrovaya-ekonomika.html ) «1) создать «национальную архитектуру данных», она должна отвечать потребностям бизнеса и государства, обеспечить семантическую возможность общения систем, а также цифровую идентичность (управление разрешениями, управление цифровых профилем человека) и 2) решить вопрос правового регулирования данных – т.е. обеспечить здоровую конкуренцию за счёт недискриминационного доступа к данным.» требует нормального развития всех архитектур. Зашоренность на «магии данных» становиться «мафией данных», при которой другие точки зрения не принимаются.

https://openknowledge.worldbank.org/bitstream/handle/10986/30437/9781464813252.pdf

Thanks,
AS

“Особенности Национальной Цифровизации” это серия блогпостов с тагом #ОсобенностиНациональнойЦифровизации

Особенности Национальной Цифровизации: Тендер, однако

Смотрим на документ - Извещение о проведении открытого конкурса на право заключения договоров на выполнение работ по реализации мероприятий плана по направлению "Информационная безопасность" программы "Цифровая экономика Российской Федерации", утвержденной распоряжением Правительства Российской Федерации от 28 июля 2017 г. № 1632-р  http://ru-ikt.ru/temp/izv.pdf

Так, 16 лотов по очень серьезной теме -- информационная безопасность. Смотрим на важные даты.
  • Начало конкурса : 4 октября 2018 г. 
  • Окончание конкурса : 19 октября 2018 г. 
  • Подведение итогов конкурса: 19 октября 2018 г. 
  • Срок исполнения: 10 декабря 2018 г. 
Однако сразу возникает три вопроса.

1) После объявления результатов обычно дается 2 недели для возможных протестов по результатам конкурса. Почему не указана эта дата? Что-то тут подозрительно.

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

3) Интересно, как будет достигаться взаимосогласованность результатов этих лотов? Считая, что разные компании могут выиграть разные лоты, то построение целостной картины от 16 ответов, написанных на разными компаниями, является неподъёмной задачей. Что-то тут подозрительно.

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

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


Thanks,
AS

“Особенности Национальной Цифровизации” это серия блогпостов с тагом #ОсобенностиНациональнойЦифровизации