Для понимания, есть такие крутые ребята из консалтинга в области ИТ, как Gartner. Они придумали термин ERP в 1990 еще. И именно на них много ссылаются в процессе разговора. Я старался передать слова докладчика дословно.
Информация системная. Может начать пригорать в середине, но к концу будет понятно, что рассматриваем один вопрос с разных сторон.
Есть пара известных терминов Лустина, типа чем сложнее, тем дешевле. Мир комплексный, это всегда сложно, но зато горизонтально масштабно и ваще. Географически распределенный значит дешевый по железу. Если сделать замкнутую распределенную систему, то получается готовая система и предварительная автоматизация.
Лустин системный архитектор, кодит много на чём, основная среда visual studio code. Началось все в 2002-2004 с TRAC системы управления проектами на Питон. Участвовал в проекте 1С++. На 7ке делал проект по хранению в базе Firebird. В 2008 делал свою убийцу 1С на базе Apache Cayenne. Делал управление проектами в Redmine со стероидами. Когда увлекся Ruby понял что бизнес-требования проще описывать в Behavior driven концепции, отсюда ноги у BDD растут. В 2015 доклад про статический анализатор систем 1С. Возникло положение о людях Серебряной Пули. И вброс что в 1С все плохо и Agile нет (см скрин)
Методика объяснения странная. Пересмотреть, перечитать два раза, что непонятно, можно спросить в телеге Желтого Клуба.
Все, что Лустин говорил, он поднял в докере, попробовал в пилоте. Например ClickHouse и Tarantool не рекомендует, отдельно можно узнать почему.
Лустин про вширь, а не вглубь, он любит охватывать максимально широкий спектр тем. Вглубь это другие ребята, им надо понять, куда копать вглубь, и они дают при копании информацию, куда еще вширь.
Если есть возражение “я не согласен”, значит Лустин куда-то попал, скорее всего в уже сделанное решение, признать тяжело, а выкинуть жалко. Плюс есть модель образования “школа 2100”. Цитата Саши Кунташова “Польза всех докладов Алексея Лустина - записать кучу аббревиатур и терминов, которые он произносит, а потом по очереди начинать гуглить, и его энергетика”.
Есть модель мышления разных “шапок” для оценивания контента. Управление, Информация, Позитив, Критика, Креатив, Эмоции. Надевая каждую из них, можно с разных точек зрения рассмотреть проблему. Главное в позитиве.
Есть публичная информация у Гартнера - топ технологических трендов 2021. Гартнер заявляет, что все продукты должны быть
1) человеко-центричные, продукт делаешь для людей
2) географически независимые
3) устойчивая поставка (24\7\365 с низкой задержкой).
Ускоряем операционное принятие решений, плечо операционных решений должно быть минимальным. Все привыкли думать монолитами, а теперь все должно быть распределенно-мультимастерно (все главные).
Что дальше, берем гартнеровский вброс, и переводим его термины. Например, Internet of Behavior - ключевой термин поведение. Все должно быть приватно, распределенно, мультиагентно (Mesh-сети). Исполняется везде на любом девайсе, при помощи AI, без человека (хватит вбивать приходные накладные с бумажек блин). Композитные - не будет больше одной службы, одной монолитной программы. Как композитный материал состоит из кучи подсистем, микросервисы это не то же самое, они превращаются в монолит. Пример DJango. Команде микросервиса хочется всегда захватить мир. Про создающее актив в конце. Теперь Айтишники создают актив и начинают им торговать. Полностью связанное тоже разберем позже.
Итого, любое техническое решение, даже на 1С, теперь должно иметь возможность 1) определять только поведение, а не конфигурацию 2) быть распределенным и включаться в распределенную систему в режиме онлайн 3) обеспечить максимальную безопасность данных 4) самоорганизовываться 5) не быть написанным на одном языке 6) иметь в себе исполняемые функции AI 7) Обучать своего пользователя до ведущего специалиста 8) не быть монолитом (ERP в топку) 9) в процессе своей работы создавать цифровой актив 10) иметь возможность встроиться куда угодно по открытым протоколам (API, XML, JSON, вот это всё, есть такая штука для этого, как Zapier.
В мире около 6 миллионов мидл-программистов, только тех, о которых знает Гартнер, и куча из них может написать интересные опенсорсные аналоги вашего вендор-лок монолита. У бизнеса вопрос, он может опенсорсное встроить в свою систему.
Минцифры. Что они придумали. Есть методические рекомендации по цифровой трансформации госкорпораций и корпораций с госучастием. Внезапно Минцифры говорит, что будет КПЭ “оценка доли выручки по цифровым бизнес-моделям”. Будет КПЭ “число активных пользователей цифровых решений физлиц (человекоцентрично опять-таки)”. “Число активных пользователей API” - даже на госуровне поняли, что все должно быть интегрировано “доля доменов данных, управляемых в соответствии со стандартом”. - data-management body of knowledge (DMBOK), это оттуда. “Доля руководителей, специалистов и служащих, обладающих знаниями в области цифровой трансформации” - даже служащих припахали.
Мы понимаем, что это коснется всех, многие работают с господрядами. Председатель Правительства технократ Мишустин инженер-системотехник, обучался на САПР специальности. Компании должны отчитываться по графику, мероприятия в любом случае будут. И эта вся методика сильно повлияет (см скрин).
Кстати, по KPI нет больше издержек на поддержку госсистем:) Если система имеет постоянные линейные затраты на поддержку это выгодно кому-то и всё. Мнение, что можно нанять 5 любых рабочих и это дешевле, чем менять систему, устарело на 20 лет, это выгодно только здесь и сейчас, а на перспективе год уже нет. Система должна самоорганизоваться и самонастраиваться, надо создавать продукты, а не перезапускать конфигуратор. Должны быть функции AI точно. Пользователь любой системы должен при помощи этой системы обучаться до ведущего специалиста. Должны быть открытые протоколы обмена.
Диффузия инноваций. Эверетт Роджерс. Есть уровень бабла, консерваторы и тревожные зарабатывают меньше всего. Уже даже реалисты внедрили ESB, их давно внедрили с начала 2000х.
Можно объединить консервативный 1С, тесты и современный TensorFlow и получить что-то посовременнее. AI и ИИ разные вещи, AI это исследование артефактов, математические оптимизационные функции. Типа по методу стохастического линейного спуска можно посчитать будущую цену исходя из плана продаж. Есть даже Oscript обертка над Тензорфлоу. Обученная модель ИИ это файл и их можно переиспользовать и переобучать и продавать модель:). Можно внедрять по модели “ползучий способ внедрения инноваций снизу”, инициатива программиста. Условно 3 разраба и 2 специалиста могут посчитать цепочку поставок для большого холдинга по торговле мобилками теперь по Economic order quantity.
От ESB идем к EIP (enterprise integration platform). Как было в ESB, есть две системы, конструктор интеграций и охреневающий от количества интеграций архитектор, протоколы всякие (REST\SOAP\AMQP).
В последней версии 1С есть даже СервисИнтеграции и можно воткнуть адаптер и передавать EnterpriseData формат. И вдруг у какого-то пхпшника в битриксе этот формат не разбирается. ЭнтерпрайзДата не про веб. Данным нужна трансформация. Типа из XML в GraphQL. Причем трансформировать на адаптере нельзя. И в ESB возникает трансформация данных и управление доступом и возникает код (datareon компания).Плюсы шины: позволяет построить в одном месте консоль управления данными и интеграционными потоками с трансформацией. Структуризатор бардака. Минусы - скорость интеграции на каждый поток увеличивается, рождение нового монолита. Архитекторы шин (системные аналитики) получают эксклюзивный доступ к этому монолиту. Масштабирование типа поставьте стойку рядом.
Как альтернатива придумали EIP. Есть верхний внешний доступ, точки подключения по разным протоколам, логика интеграции и транспорт данных. Системы делишь на условно белый ящик, где ты имеешь доступ к исходному коду и можно ее поправить, серый ящик, где какой-то штатный протокол (типа gitlab, там есть АПИ и надо патчить ядро для изменений) и черный ящик типа Outlook без ничего и красный ящик за периметром. (см скрин)
А есть вариант у Гартнера, все интеграции должны быть на потоках, а не файлами по почте обмениваться (в смысле ты начал запись, подписчик получил сразу старт потока и начал читать данные). Должна быть платформа интеграции для обеспечения трансформации, брокер управления событиями, управление АПИ. И сторонние разрабы могут дописать свои приложения. Ты расшил свой монолит на докер-кластеры, и нет больше главного архитектора.
Ты прекращаешь быть архитектором и становишься автором продукта для своего пользователя (например, для программиста 1С которому надо передать данные в другую систему). Главный архитектор - это тип, который ходит в костюме и покупает SAP.
(тут конец первого часа)
Даже в маленькой компании гендир это архитектор своих ИТ приложений. Надо начинать относиться к шине как к продукту, продавать сервисы изнутри компании наружу.
Есть еще такой Мартин Фаулер, автор многих книг по рефакторингу кода. И он как раз тот, кто топит за микросервисы, а сейчас за DataFabricMesh. Считается, что должно быть Federated Computational Governance, то есть правительство над данными. (скрин)
Наверху у тебя есть владельцы доменов (главный методолог по всему). А снизу есть Automated Schema creation, automated injections of APIs. Есть некий слой данных, где живут типа “номенклатуры”, “контрагенты”, “документы” и прочее, и если метаданные изменили свою схему, оно всех об этом оповестило и все в курсе, что у вас поле “вес” появилось. У тебя Odata изменилась, Swagger стал новое АПИ выдавать. Живет хранилище как менялась схема данных. Крутые парни уже не используют слова типа метаданные и структура СУБД, понятно, оно в деталях осталось.
Как на практике с MDM. Есть домен. Вот есть 1С ЕРП. Ты ее дробишь на конфигурации, типа ПрихНакл, Чек, Складской Ордер, Физлицо Наименования Документов. У всех конфигураций есть своя модель данных ODATA.
Ты в своем 1С чеке хранишь информацию о схеме данных ПрихНакла, потом у них чего-то как в GIT обновилось, они говорят, что у тебя новая модель, ты мигрируешь на новую схему данных, тесты. И получается - может быть несколько моделей, у тебя старая, у них новая. Типа ты хранишь у себя номер схемы, от которой ты отпочковался, как в Git, а потом тебя оповещают, что их схема изменилась и ты ее себе засасываешь, через тесты. Децентрализованный граф (или репозиторий) изменений модели данных по компании, ну надо понимать, как Git репозитории устроены. И это не утопия.
Опять идет отказ от монолитов. Слово для гугления - Data Lake. У них целый консорциум по выработке стандартов типа “граф-ориентированная субд”, graphQL, openCypher. Интеграцию можно хранить на файлопомойке, хранить на MINIO. Допустим есть ЕРП и Трейд базы. Есть штука “обновлять историю данных после записи” и “выполнять обработку после записи версии истории” в 1С, это событийная интеграция, ложится на Kafka хорошо. Внезапно 1С хранит стрим изменений любого метаданного, ну кроме регистра сведений возможно. Появляется понятие Офицер Данных, есть обертка на Oscript над Spark. (скрин кода)
И можно подписаться на всю историю изменений номенклатуры (номенклатура это домен предметной области). Neo4j гуглить графовую СУБД, она уже много где используется по миру. А в конце года Лустин пересоберет ядро Postgres для этого, можно почитать его телеграм канал.
Переход от SOA к FucntionMesh. Опять Фаулер говорит, что есть переход к operation data plane. Что когда дата сатанисты и дата аналитики пытаются себе всё выгрузить, это плохо. Из Микросервиса получается Макросервис с огромной СУБД, дата сатанисты долго ковыряют в носу и говорят 42. А если добавить концепцию “function as a service”. Правильные пацаны, чтобы микросервис не превратился в макро, расшиваем его на функции. Ну по сути сервис это АПИ, поднятое на каком-то порту, вместо этого регистрируем функции. Функциональная Mesh-сеть, мультиагент (см скрин кода)
Ну по сути это реестр микрофункций внутри своего предприятия. И говоришь потом аналитикам, сходите там в свое DWH типа Data lake и сделайте универсальную функцию. И потом мы эту функцию ищем просто в MESH сети по наименованию (см скрин кода). Место где живут функции - Istio, или там яндекс.клауд функции. Ты типа говоришь всем в сети, я ерп, я живу тут, у меня есть вот такие функции, если чё вызывайте меня. Гуглить openFAAS. Вот видос Лустина на тему https://www.youtube.com/watch?v=8sF-oGGVa9M
Почему монолит плохо. Нет масштабирования. Терабайтная база - надо уже покупать сервак за 50к долларов. А у Лустина петабайт разлит по 112 хостам и железо стоит 72000 рублей и всё. Утилизация 82-85% получается.
Считать двое суток себестоимость в ЕРП плохо, про скользящее бюджетирование никто не слышал, а можно потоково ее считать. Себестоимость это Система линейных уравнений от многих критериев. Причем функции такие для Spark есть на питоне уже готовые и можно на Oscript переписать.
UX\UI дорого - переходим к MiniApp. Сколько стоит сделать фронт. На 1С проще но все равно.
Линейному персоналу не нужен такой избыточный интерфейс. Бизнес хочет все на одном экране. WeChat и Facebook пилят мини-аппы, выдаем функции, которые у нас есть. Тут можно посмотреть, что Низамов Илья делает. Гуглить Vue mini-app. Верстальщики и методологи дешевле, чем программисты, пусть программисты фронтендеры лучше платформу мини-апп делают.
Ссылка на вторую часть вот тут
Оригинал доклада: https://www.youtube.com/watch?v=F6dpmZ4ftUU
Вы всегда можете поделиться в комментариях своим мнением.
