00:00:07 Событийное моделирование и его преимущества по сравнению с традиционными реляционными базами данных.
00:00:31 Событийное моделирование и его основная концепция.
00:01:52 Развитие реляционных баз данных и программного обеспечения CRUD в 70-х годах.
00:04:29 Ограничения и предположения, внесенные CRUD-системами.
00:06:10 Преимущества событийного моделирования при устранении ошибок и обслуживании системы.
00:08:00 Фрустрация от работы с изменяемыми системами и квантовыми ошибками в программной инженерии.
00:09:02 Событийное моделирование как решение проблем цепочки поставок и его связь с дешевым хранением данных.
00:12:38 Внедрение событийного моделирования в крупных компаниях и его преимущества для прозрачности и эффективности.
00:14:36 Событийное моделирование как альтернативная перспектива к грубой методологии в проектировании программного обеспечения для управления цепочкой поставок.
00:15:37 Будущее распространение событийного моделирования и потенциальные преграды для его широкого принятия.
00:17:18 Сравнение принципов событийного моделирования с принципами бухгалтерии и их важность.
00:19:22 Необходимость быть ориентированным на данные в управлении цепочкой поставок.
00:20:25 Предположения о будущем росте Amazon и его потенциальных ограничениях.
00:21:07 Заключение и завершающие замечания.
Резюме
В интервью с Жоаннесом Верморелем, основателем Lokad, ведущий Киран Чандлер исследует концепцию событийного моделирования и его преимущества в управлении цепочкой поставок. Событийное моделирование предполагает представление состояния компьютерной системы в виде последовательности событий, что обеспечивает более прозрачное и неизменное представление прошлых событий, что упрощает их воспроизведение и устранение проблем. Верморель отмечает, что популярность модели CRUD, которая позволяет пользователям создавать, читать, обновлять и удалять данные, иногда затрудняет распознавание потенциальных преимуществ событийного моделирования. Однако он считает, что с удешевлением хранения данных событийное моделирование станет более распространенным, под влиянием роста технологически ориентированных компаний, таких как Amazon.
Расширенное резюме
В этом интервью ведущий Киран Чандлер и Жоаннес Верморель, основатель Lokad, обсуждают концепцию событийного моделирования и его все более популярное использование по сравнению с традиционными реляционными базами данных. Событийное моделирование представляет собой подход, при котором состояние компьютерной системы является только отражением серии событий, идея заключается в том, что нет прямого представления данных, кроме самих событий. Например, в программном обеспечении для управления запасами нет конкретного уровня запасов, а есть поток движений запасов, которые, когда они объединяются, предоставляют синтетическое число, представляющее текущий уровень запасов.
В 1970-х годах были приняты решения о том, как представлять данные компании в электронном виде. Реляционная модель стала популярной, и большинство программного обеспечения для управления цепочкой поставок теперь относится к категории приложений CRUD (create, read, update, delete). CRUD-программное обеспечение основано на таблицах с полями, позволяющих пользователям добавлять, читать, изменять или удалять строки в таблице. Эта простая модель была успешной и широко принята во всех отраслях.
Однако Верморель отмечает, что существуют альтернативные подходы к представлению данных, такие как событийное моделирование. Он предлагает, что популярность CRUD иногда может затруднить распознавание потенциальных преимуществ других методов. Одно из значительных отличий между CRUD и событийным моделированием - это идея изменяемости; в CRUD прошлое изменяемо, что может вызывать философские затруднения. В отличие от этого, событийное моделирование предлагает более прозрачное представление прошлых событий и изменений, произошедших в системе.
Обсуждение подчеркивает растущий интерес к событийному моделированию в качестве альтернативы традиционным реляционным базам данных для управления цепочкой поставок и других приложений. Хотя CRUD был широко принят, он не всегда является лучшим подходом, и исследование альтернативных методов представления данных, таких как событийное моделирование, может потенциально обеспечить более ясное и понятное представление прошлых событий.
Верморель объясняет, что подавляющее большинство программных систем, используемых для управления цепочкой поставок, таких как ERP-системы и MRP-системы, построены с изменяемым прошлым, что может привести к сложным и контринтуитивным ситуациям. Однако он предлагает более лучший подход - рассматривать прошлое как неизменное, так как это может помочь избежать таких проблем.
Одним из значительных преимуществ использования событийного моделирования, по мнению Вермореля, является его полезность при устранении ошибок. Он отмечает, что в больших системах программного обеспечения для управления цепочкой поставок часто возникают многочисленные ошибки и нежелательные функции, которые могут сохраняться на протяжении многих лет и вызывать разочарование при работе с ними. С помощью событийного моделирования вся информация в системе представлена в виде серии событий. При отладке инженеры могут просто воспроизвести события одно за другим, чтобы воссоздать точную ситуацию, которая вызвала проблему, и исправить ее.
Верморель противопоставляет эту ситуацию альтернативной, где состояние системы изменяемо, что затрудняет возможность воспроизвести и исправить проблемы для команд IT. Это может привести к разочаровывающему циклу отчетов об ошибках и попыток исправления, при котором ошибки часто повторяются через некоторое время. С другой стороны, событийное моделирование предоставляет детерминированный способ воспроизведения и исправления проблем.
Затем обсуждение переходит к идее событийного моделирования более подробно, с Верморелем, объясняющим, что это включает в себя рассмотрение каждой операции, которая происходит в цепочке поставок. Он предлагает, что можно задаться вопросом, почему событийное моделирование не является стандартным подходом, так как оно соответствует тому, как бухгалтеры использовали бухгалтерские книги веками. Бухгалтерские книги обычно являются неизменными, с добавлением новых транзакций для исправления предыдущих ошибок, а не перезаписью прошлых транзакций.
Верморель объясняет, что причина, по которой событийное моделирование не является стандартным подходом, заключается в высокой стоимости компьютерного хранения в конце 1970-х и начале 1980-х годов. Чтобы сэкономить на стоимости хранения, программные системы были разработаны для перезаписи прошлых данных с обновленными итогами. Однако он указывает на то, что стоимость хранения данных с тех пор значительно снизилась, что делает более реальным внедрение событийного моделирования как стандартной практики.
На вопрос о том, должны ли малые компании быть заинтересованы в событийном моделировании, Верморель отвечает, что это философская перспектива на прошлое, с идеей, что прошлое должно быть неизменным в компьютерных системах. В то время как большинство ERP-систем не используют событийное моделирование, Верморель считает, что принятие этого подхода может помочь предотвратить проблемы, связанные с изменяемым прошлым в программном обеспечении для управления цепочкой поставок.
В заключение, Жоанн Верморель выступает за использование событийного моделирования в оптимизации цепочки поставок, подчеркивая его преимущества при устранении ошибок и соответствие неизменной природе прошлого. Хотя событийное моделирование еще не получило широкого распространения, оно предоставляет более детерминированный способ решения проблем в системах программного обеспечения для управления цепочкой поставок и может быть интересным для компаний любого размера.
Они исследуют преимущества этого подхода, его принятие ведущими технологическими компаниями и его потенциальное будущее распространение на рынке.
Event sourcing - это метод проектирования программного обеспечения, который хранит состояние системы в виде последовательности событий, а не через более традиционную методологию Создание, Чтение, Обновление, Удаление (CRUD). Верморель отмечает, что ведущие технологические компании, такие как Amazon, Zalando и Alibaba, приняли event sourcing для своих систем управления цепочкой поставок, причем Amazon является основным стимулом его принятия на рынке.
Верморель утверждает, что event sourcing предлагает несколько преимуществ для управления цепочкой поставок. Во-первых, он обеспечивает большую прозрачность и эффективность, а также сокращение отходов и улучшение отзывчивости. Во-вторых, он подчеркивает ограничения CRUD, которые сильно повлияли на экономические ограничения, которые были актуальны только в 70-х и 80-х годах.
Взгляд в будущее. Верморель считает, что event sourcing станет более распространенным по мере удешевления хранения данных и продолжительного роста технологических компаний. Он подчеркивает, что принятие на рынке определяется процессом “великого фильтра”, в котором компании, использующие менее эффективные методы, выходят из бизнеса, оставляя тех, кто использует более успешные подходы, чтобы процветать.
Верморель также подчеркивает важность event sourcing для компаний с внутренними программными системами. Даже если они не принимают event sourcing полностью, понимание его принципов может помочь им смягчить проблемы изменяемости в их существующих системах CRUD. Он утверждает, что event sourcing должен рассматриваться как основополагающий принцип практики управления цепочкой поставок, подобно концепции нередактируемого регистра в бухгалтерии.
Поскольку практики управления цепочкой поставок основаны на данных по необходимости, Верморель утверждает, что для них важно иметь руководящие принципы сбора, организации и обработки данных. Он предлагает исследовать event sourcing, чтобы помочь практикам выявить и решить многие скрытые проблемы в своих организациях.
Верморель видит будущее, в котором event sourcing продолжит завоевывать рыночную долю, поддерживаемую ростом технологических компаний, таких как Amazon. Однако он признает, что экономия масштаба в конечном итоге может ограничить доминирование этих компаний, открывая возможности для более разнообразных подходов к управлению цепочкой поставок.
Полный текст
Кирен Чандлер: Итак, сегодня мы собираемся узнать немного больше о том, как это работает, и обсудить, как это может обеспечить более ясное представление о том, что произошло в прошлом. Итак, Жоанн, что такое event sourcing?
Жоанн Верморель: Event sourcing технически представляет собой идею, что состояние в вашей компьютерной системе является только отражением серии событий. Таким образом, все, что вы видите в компьютерной системе или все, что она делает, основано на событиях. У вас есть только события, и если у вас есть что-то вроде общего количества на дисплее или любой информации в системе, это только прямой результат серии событий. Чтобы сделать это очень конкретным, идея заключается, например, в том, что если у вас есть уровень запаса на дисплее в вашем программном обеспечении управления запасами, в программном обеспечении нет такого понятия, как уровень запаса. У вас есть только поток движений запасов, где количество было помещено или взято, и когда вы объединяете все эти события, вы получаете синтетическое число, которое является текущим уровнем запаса. Но идея event sourcing заключается в том, что система не имеет ничего, кроме событий, что касается прошлого.
Кирен Чандлер: Где используются эти техники event sourcing? Это что-то, что мы часто видим на рынке?
Жоанн Верморель: В 70-х годах были сделаны некоторые выборы относительно того, каким образом лучше всего представить данные компании в целом и ее прошлое в частности. Это может показаться очень философским, но на самом деле это очень широкий вопрос. Когда вы хотите цифровизировать свою компанию, вам нужно электронное представление вашей компании и ее прошлого. Даже если это очень недавнее прошлое, это все равно прошлое. Таким образом, вам нужно иметь отражение прошлого, и оказалось, что есть много способов сделать это. Несколько из этих способов стали чрезвычайно популярными в конце 70-х и поддерживали свою популярность в последние несколько десятилетий. Но это не единственный способ смотреть на это. Очень любопытно, что когда у вас есть определенный способ делать вещи, который становится чрезвычайно популярным, он может стать настолько большим, что в какой-то момент вы даже не осознаете, что на самом деле можно делать это очень разными способами.
Так что произошло, это победила реляционная модель, и на ее основе был создан определенный тип приложений. По сути, подавляющее большинство программного обеспечения для управления цепочками поставок, используемое в настоящее время, относится к категории, известной как CRUD-программное обеспечение. CRUD на самом деле является аббревиатурой, которая означает Create, Read, Update, Delete (Создание, Чтение, Обновление, Удаление). Идея заключается в том, что у вас есть таблицы, каждая таблица имеет поля, и ваше программное обеспечение позволяет добавлять строки (это Create), читать существующие строки, изменять (это Update) существующие строки и удалять существующие строки. Эта модель очень проста, и эти четыре переменные, CRUD, смогли завоевать мир цепочек поставок, так что вы можете отразить практически все с их помощью. Она оказалась очень успешной, очень популярной, но это не единственный подход. И интересно то, что существуют и другие альтернативные подходы, и одним из них является событийно-ориентированное программирование.
Кирен Чандлер: Давайте посмотрим на популярность этого подхода CRUD. Внес ли он какие-либо ограничения или предположения, с которыми мы сейчас привыкли работать?
Жоанн Верморел: Да, он внес что-то, что
Кирен Чандлер: Что-то, что очень загадочно, если подумать об этом с философской точки зрения, это то, что прошлое изменяемо. Я имею в виду, когда вы думаете о своем повседневном опыте, что-то произошло в прошлом, вы не можете изменить это, верно? Это просто так. И все же, в компьютерных системах, современных корпоративных системах, таких как ERP, MRP и т. д., все эти классы сложных программных систем, которые управляют компаниями и их цепочками поставок, подавляющее большинство этих программных систем построены на примитивном принципе, что прошлое полностью изменяемо. Если задуматься об этом, то можно столкнуться с самыми странными ситуациями, которые являются результатом того, что прошлое изменяемо, и это может привести к искаженному представлению о системах. Это создает много сложностей и в целом противоречит интуитивному представлению о системах.
Жоанн Верморел: Да, есть одно преимущество событийно-ориентированного программирования, которое на самом деле очень значительно и невероятно обыденно: исправление ошибок. В больших системах управления цепочками поставок полно ошибок, нежелательных функций повсюду, и, как правило, это продолжается буквально десятилетиями. Есть тысячи открытых тикетов, которые передаются в IT, и большинство из них никогда не исправляются. Это так раздражает. Событийно-ориентированное программирование на самом деле имеет много общего с исправлением ошибок. В Lokad мы используем событийно-ориентированное программирование внутренне уже десять лет, и это очень интересно. Когда вы сталкиваетесь с ошибкой в системе, основанной на событиях, вся информация в системе представлена в виде серии событий. Поэтому, когда вам нужно отладить что-то, вам нужно просто воспроизвести события одно за другим. Благодаря тому, что единственные данные, существующие в вашей системе, представляют собой этот поток событий, вы можете воспроизвести точно такую же ситуацию, которая вызвала проблему, и исправить ее.
Давайте сравним это с альтернативной ситуацией, когда все состояние вашей системы изменяемо. Проблема заключается в том, что к моменту возникновения проблемы, например, сбоя в уровне запасов, уровни запасов продолжают меняться. К моменту, когда команда IT обращается к проблеме, она исчезает. Вы не можете воспроизвести ее и исправить. Это чрезвычайно раздражает как программного инженера, когда вы имеете дело с системой, которая является высокоизменяемой. Большинство ошибок оказываются похожими на квантовые ошибки, где есть ошибка, но когда вы на нее смотрите, она исчезает. Затем вы перестаете на нее смотреть, и она снова появляется. Это так раздражает.
Событийно-ориентированное программирование очень интересно с этой точки зрения, потому что оно дает вам полностью детерминированный способ воспроизвести эти проблемы и исправить их навсегда. Если посмотреть на проблемы в цепочках поставок в целом, даже если программное обеспечение не решит все проблемы, оказывается, что…
Кирен Чандлер: Программное обеспечение часто создает свою долю проблем, с которыми сталкиваются современные цепочки поставок. Хорошо, давайте вернемся и рассмотрим более подробно событийно-ориентированное программирование, эту идею о том, чтобы рассмотреть каждую малозначительную операцию, которая произошла в цепочке поставок. Звучит немного скучно. Насколько легко будет вернуться назад и проверить, что произошло и найти корень проблемы?
Жоанн Верморель: Почему не сделать запись событий по мере их поступления и сказать, что это прошлое, вы знаете? Когда вы смотрите на то, что, я бы сказал, люди делали веками, например, бухгалтеры, у них были бухгалтерские книги. Бухгалтерские книги обычно имеют свойство быть неизменными. Вы только добавляете информацию в бухгалтерскую книгу. Если вы сделали ошибку в транзакции, вы не удаляете транзакцию в прошлом. Вы просто добавляете другую транзакцию, которая говорит, что предыдущая транзакция была неверной, и вот исправление, и так вы работаете. Таким образом, вы не переписываете прошлое, вы просто добавляете больше информации в конце.
Но в конце 70-х годов компьютерное хранилище было невероятно дорогим, и поэтому идея иммутабельности прошлого была своего рода хорошей особенностью, если у вас действительно тугая ситуация. Если ваша бухгалтерская книга, как у бухгалтера, состоит всего из 10 страниц, и если у вас заканчивается место, у вас есть только ластик. Итак, вы пытаетесь суммировать итоги по вашим книгам, добавить несколько транзакций, и когда у вас заканчивается место, вы просто стираете прошлую транзакцию, обновляете итоги, и все. Это буквально произошло в конце 70-х и начале 80-х годов. Весь мир программного обеспечения пошел по определенному пути, который имел смысл из-за того, что хранение данных было настолько невероятно дорогим в то время.
Быстро вперед, спустя 40 лет, хранение данных стало просто невероятно дешевым. Вы можете купить жесткий диск на один терабайт за пятьдесят долларов. Это невероятно дешево. Так что, если вы хотите иметь надежное хранилище данных, вам нужно несколько копий и система для управления этими копиями, но мы находимся ниже 1 доллара за гигабайт, и данные просто очень, очень дешевые.
Событийно-ориентированное программирование является основной архитектурой всей системы ERP. Это темы, которые действительно интересны крупным международным компаниям и крупным компаниям, таким как SAP. Должны ли меньшие компании действительно быть заинтересованы в чем-то подобном?
Кирен Чандлер: Это интересный вопрос. Должны ли меньшие компании быть заинтересованы в событийно-ориентированном программировании?
Жоанн Верморель: Я думаю, что событийно-ориентированное программирование - это философская перспектива на прошлое, которая, по сути, заключается в том, что прошлое неизменно, и компьютерные системы, которые у вас есть, должны отражать это, иначе вы получите неоптимальные решения. Большинство систем ERP не используют событийно-ориентированное программирование, вот первая проблема. Большинство систем ERP в основном не используют его. Когда вы смотрите, кто использует событийно-ориентированное программирование, это технологические лидеры, которые обычно не создают программное обеспечение для цепочек поставок, возможно, за исключением Amazon, Zalando и Alibaba, компаний, которые управляют своими собственными цепочками поставок с помощью собственного программного обеспечения.
В плане преимуществ многие компании пытаются обеспечить большую прозрачность в цепочке поставок. Они хотят быть более эффективными, меньше тратить, более гибкими и более реактивными, и они очень борются со своими ИТ-системами.
Кирен Чандлер: Хотя это проблемы, которые очень размыты, нет одного ответа на проблему. Но то, что я вижу, это то, что событийно-ориентированное программирование очень интересно, потому что оно указывает на конкретный недостаток, я бы сказал, чрезмерно доминирующего способа проектирования программного обеспечения, которое используется для проблем цепочки поставок. Обычно большинство практиков даже не осознают эту перспективу, что есть и другие точки зрения. Так что я думаю, что событийно-ориентированное программирование очень интересно не обязательно потому, что оно является окончательным ответом на эти проблемы, а просто потому, что сам факт его существования доказывает, что на самом деле этот метод CRUD, где CRUD означает Создание, Чтение, Обновление, Удаление, просто показывает, что этот метод CRUD, который является способом построения программных систем для решения проблем цепочки поставок, не является конечной целью. Это просто один из способов, и этот шаблон проектирования был сильно повлиян экономическими ограничениями, которые были актуальны только в 70-х и 80-х годах, и уже к концу 90-х годов это начало исчезать. Итак, если мы посмотрим в будущее, хранение данных невероятно дешево, и мы уже преодолели эти преграды. Можете ли вы представить, что событийно-ориентированное программирование станет более распространенным на рынке в ближайшие несколько десятилетий, и есть ли какие-либо преграды, которые нам все еще нужно преодолеть для этого?
Joannes Vermorel: Во-первых, использование событийного программирования становится все более распространенным из-за роста Amazon. Каждый раз, когда Amazon захватывает один процент рынка, использование событийного программирования становится на один процент более распространенным на рынке. И когда я говорю о Amazon, я имею в виду все другие компании, основанные на технологиях, которые просто поглощают рынок. Так что, безусловно, это становится все более распространенным. Рынок - это отличный фильтр, но не образовательное учреждение, поэтому вещи не становятся популярными только потому, что они принимаются; они становятся популярными просто потому, что компании, которые их не используют, просто обанкротятся и исчезнут, и, таким образом, останутся только компании, которые используют то, что работает лучше. Так что, может ли это стать более популярным? Я бы сказал, что безусловно. И когда я смотрю на клиентскую базу Lokad, у нас около четверти или пятой части клиентов, у которых есть специализированные внутренние программные системы для управления компанией. Поэтому, если у вас есть внутренние программные системы, я настоятельно рекомендую вам обратить внимание на событийное программирование. Даже если вы не применяете событийное программирование сразу, потому что это полное изменение парадигмы для проектирования вашего программного обеспечения, здесь все равно есть многое, что можно изучить. И если вы очень хорошо знакомы с событийным программированием, это позволяет вам фактически выполнять CRUD, знаете, обычный способ управления цепочкой поставок.
Kieran Chandler: Современное программное обеспечение может использоваться таким образом, чтобы уменьшить проблемы изменяемости прошлого. Если вы очень внимательно подходите к его проектированию, вы можете фактически изменять прошлое в своем коде и получать что-то, что гораздо ближе к событиям или вещам. Вам не обязательно переписывать все, чтобы приблизиться к этому. Я бы сказал, что это не только проблема для IT. Некоторые люди могут отмахнуться от этого как от супер-гиковской вещи, которая интересна только для архитекторов баз данных, но я думаю, что это больше, чем просто это.
Joannes Vermorel: Я согласен, такие высокоуровневые концепции должны быть основой практики в сфере цепочки поставок. Точно так же, как невозможно изменить бухгалтерский регистр, это является основой принципов бухгалтерии. В бухгалтерии вы знаете, что вы не должны возвращаться к записям предыдущих лет и изменять транзакции. Люди не будут говорить, что это только деталь программного обеспечения. Эти принципы были установлены до появления компьютеров.
Если учесть, что работа в сфере цепочки поставок связана с обработкой большого объема данных, трудно воспринимать реальность цепочек поставок, потому что они огромны, сложны и многоуровневы. По своей природе, как специалист по цепочке поставок, вы не можете сказать, что вы увидите все своими глазами. Вы можете увидеть магазин, склад, но вы не можете быть везде. Поэтому вы зависите от данных. Единственное, что вы видите о своей цепочке поставок, это в основном числа, полученные из множества систем.
Я считаю, что, подобно бухгалтеру, вам нужно иметь определенные руководящие принципы по сбору, организации и обработке этих данных. Вернувшись к событийному программированию, я думаю, что это то, на что специалисты по цепочке поставок должны обратить внимание, потому что это поможет им выявить множество скрытых проблем в их организации.
Kieran Chandler: Прекрасно. Ну, если мы будем ждать Amazon, они скоро захватят еще один процент и приблизятся к 100%. В какой-то момент крупные компании, такие как Amazon, могут рухнуть под собственным весом из-за сложности стать абсолютно гигантскими. Это помешает им захватить 100% рынка, но проблема в том, что остальную часть рынка просто займут другие конкуренты, похожие на Amazon.
Joannes Vermorel: Да, следите за этим.
Kieran Chandler: Это все на этой неделе. Большое спасибо за внимание, и до новых встреч. Пока!
