Задача - “написать эссе «Цифровая нить нашего проекта». То есть указать информационные системы проекта. Определить, описания каких систем на какой стадии жизненного цикла эти ИС содержат. И как обмениваются между собой информацией в свете ISO 11354-1”.
КТО ВООБЩЕ ПОНИМАЕТ О ЧЁМ РЕЧЬ?
Во-первых и в главных, спасибо курсу, что стала понятна разница между нитями, тенями и двойниками. Снова тот случай, когда курс за 15 минут прояснил сложное понятие, которое не поймешь ни черта из целой книги.
Для примера приведу цитату из “Руководства по цифровой трансформации производственных предприятий”.
“В своих докладах Алексей Боровков отмечает, что многие до сих пор путают понятия цифровой тени и цифрового двойника. Говоря простым языком, цифровая тень может использовать трехмерные модели с заданными параметрами, но при этом не способна прогнозировать то, что может случиться с изделием при определенных условиях эксплуатации. Таким образом, цифровая тень может предсказать поведение реального объекта только в тех условиях, в которых осуществлялся сбор данных (Big Data), но не позволяет моделировать ситуации, в которых реальный объект не эксплуатировался. В основе цифровой тени лежит, как правило, 3D геометрическая модель (электронный макет изделия), уровень адекватности которой пытаются повысить за счет длительных и дорогостоящих натурных испытаний или режимов эксплуатации и поступающих данных с избыточного количества датчиков на реальном объекте. Кроме того, важным представляется комплексирование цифрового двойника изделия (DT-1) и цифрового двойника производственных и технологических процессов (DT-2) в рамках единой цифровой модели на основе выполнения десятков тысяч виртуальных испытаний в процессе «цифровой сертификации», что ведет к формированию «умного» цифрового двойника первого уровня (Smart Digital Twin)”.
Если вы, как и я, и до, и после прочтения этой цитаты по прежнему продолжите путать понятия цифровой тени и цифрового двойника, скорее бегите на курс “СМС”.
УДАВИТЬ ПЕРФЕКЦИОНИЗМ
Во-вторых, от информационных систем я сильно далёк. Поэтому упростил себе задачу и решил для поста по цифровой нити взять лёгкую ИТ-систему. Выбор пал на приложение учёта личных расходов.
На задании “версионирование систем” стало ясно, что “капитал” - это тоже инженерно проектируемая, создаваемая и эксплуатируемая система. Целевое состояние описано в Кода. То есть Кода в данном случае будет простейшей PLM.
Одни части капитала уже соответствуют проекту, а другие нет, их требуется создать. Например, в брокерском терминале создаю одну из частей: приобретаю биржевые активы нужного свойства. Но на стадии ЖЦ “Создание” важно иметь описание капитала целиком. В моем случае на помощь приходит ИС “Дзен-мани”.
Приложение описывает целевую систему и подсистемы, а также их изменения. Выходит, что “Дзен-мани” в данном случае есть система версионирования для капитала.
КАК ПЕРЕСТАТЬ БЫТЬ БАБУШКОЙ-УЧЁТЧИЦЕЙ
Самая засада в учёте денег - это ручной ввод. Изменений много, они частые, незначительные и нудные. А такая рутина часто идет побоку, и возникают конфигурационные коллизии. Утром после пьянки в приложении числится 10 тысяч рублей, в кармане же лежит только 3 тысячи!
Поэтому восхитительная функция “Дзен-мани” - это авто-синхронизация с приложениями банков для импорта информации о транзакциях. Не сочтите за рекламу, я обычный пользователь, никакого конфликта интересов, а инфо - из открытых источников.
На заре становления приложения приходилось делать неофициальные плагины, и даже запускать конкурсы разработчиков. Задачей было логиниться на сайты банков и парсить там информацию, необходимую приложению. По сути, создавать неофициальный коннектор. Понимаю это как классический пример integrated-подхода. Долго, дорого, ох... чего же эти банки не шевелятся сами?!
И вот некое стороннее приложение просит ввести пароль от банковского аккаунта и ломится в ЛК. Понятно, что банки подобное не приводил в восторг. Поэтому со временем стали появляться официальные API банков. Например, в сер. 2018 таковые предоставили Тинькофф-Бизнес, ЯДеньги и Киви-кошелек. Тем не менее, даже сейчас, с использованием этих типовых коннекторов подключение каждого банка проходит в ручную. Такой подход к организации взаимодействия есть федерирование.
ВСЕХ К НОГТЮ
Для завершения задания по поиску примеров разных подходов не хватало еще унификации. Кто ищет, тот, как говорится, обрящет.
Чтобы забрать из финансового клиента информацию., нужны 2 подсистемы:
- импорта данных в учётное приложение - одностороннее движение данных
- авторизации входа в финансовое приложение - а это уже send и push данных
Понимаю так, что в этой части авторизации работа ведётся на принципах унификации. К примеру, российские банки в API для авторизации используют open-source протокол OAuth. Это всемирно принятый протокол, по которому работают Google, Facebook, Yandex, Mail.ru и т.д.
В Европе пошли дальше. Там разработали платежную директиву Европарламента PSD2, которая среди прочего стандартизирует и вопросы аутентификации пользователей. Вместо программ-коннекторов появились аж организации-коннекторы. Например, платформа Nordigen одним махом обеспечиваеи обмен данными с 2 500 банков. Заодно эта платформа гарантирует, что подключающийся соответствует требованиям PSD2.
Пусть не смущает слово “коннекторы” - думаю, что этот случай относится именно к Unified-варианту. Ведь разработчики приложений могут сразу запроектировать совместимость согласно представленной открытой архитектуре данных.
Потом я заприметил еще один любопытный пример унификации. На этом принципе построена функция распознания QR-кода на чеке с онлайн-кассы. Выходит, это тоже интеграция данных, но уже для наличных операций и наличной части капитала. То есть между учётным приложением и фискальной ИТ-системой ФНС. А стандарт обмена данными описан в двух местах:
- 54-ФЗ, который среди прочего регламентирует набор обязательных данных, зашитых в QR-код
- ГОСТ Р ИСО/МЭК 16480-2017 «Информационные технологии. Технологии автоматической идентификации и сбора данных. Считывание и отображение оптических носителей данных мобильными устройствами», который устанавливает минимальные характеристики четкости и оптимальные геометрические размеры изображения QR-кода
БОЛЬШЕ ПРИМЕРОВ БОГУ ПРИМЕРОВ
Я прямо разошелся в ходе работы над этим постом. Интеграция данных - это ведь попытка состыковать онтологии, язык описания кусочков мира. Единый язык - это очень хорошо, но в статике живет плохо. Отсюда и вечная проблема поддержания порядка.
Лет 5 назад узнал, насколько по-разному поддерживают порядок разные сервисы объявлений:
- Яндекс Маркет: даёт стандарт описания. Всех к ноге. Унифайд. Благо в наличии рыночная сила, чтоб диктовать требования.
- Пульс цен: пишите что хотите у себя, а мы переведем и выложим в приемлемом для потребителя виде. Кастом каждого объявления! Интегрейтед.
- Авито: пишите что хотите где хотите, мы потом наведем порядок. Нужна годная эталонная модель для обучения нейросетки, которая будет наводить порядок. Нейросетка тут выступала коннектором. Федерирование. Но потом пришла рыночная сила, а с ними и стандартизация требований.
Надеюсь, пост поможет кому-то уловить разницу в подходах к организации взаимодействия информационных систем.