Модульность в цепочке поставок

00:00:03 Введение в модульность в ИТ и цепочках поставок.
00:00:26 Модульность физических цепочек поставок.
00:02:31 Монолитные архитектуры ранних ИТ-систем.
00:04:08 Контекст ИТ для монолитных систем.
00:05:31 Влияние интернета на модульный дизайн программного обеспечения.
00:08:02 Проблемы монолитных программных систем.
00:08:48 Неэффективность монолитных систем.
00:11:16 Переход на модульные системы: примеры.
00:13:34 Отказы систем в модульных приложениях.
00:14:34 Избыточность и время безотказной работы в модульных системах.
00:16:00 Надёжность крупных систем, неудачи программных проектов.
00:16:50 Пример неудачного перехода программного обеспечения на примере Lidl.
00:18:09 “Fail fast” концепция быстрого провала в проектах.
00:19:30 Управление пересечениями, важность “связующего” программного обеспечения.
00:22:46 Избежание программных катастроф.

Резюме

В выпуске Lokad TV Жоаннес Верморель, основатель Lokad, обсуждает значимость модульности в ИТ-инфраструктуре бизнеса, сравнивая её с адаптивностью цепочек поставок. Он ссылается на монолитные ИТ-системы 70-х и 80-х годов, характеризовавшиеся их негибкостью из-за технологических ограничений. Несмотря на переход к сетевым системам после появления интернета, он подчёркивает продолжающуюся проблему модульного построения ИТ-систем в бизнесе. Верморель предлагает архитектуру, ориентированную на обслуживание (SOA), как потенциальное решение, подчеркивая необходимость меньших, чётко определённых сервисов. Он предостерегает от реализации крупных проектов и выступает за подход “fail fast”, подчёркивая критическую важность управления рисками и быстрого восстановления в случае неудач.

Расширенное резюме

В текущем выпуске Lokad TV ведущий Кириан Чендлер ведёт беседу с Жоаннесом Верморелем, основателем Lokad, об модульности в ИТ-инфраструктуре бизнеса. Верморель излагает концепцию модульности, проводя параллели в первую очередь с физическими цепочками поставок, которые он считает самыми модульными изобретениями человечества.

Он приводит примеры грузовиков, поддонов и контейнеров, чтобы проиллюстрировать свою точку зрения на модульность. Верморель подчёркивает присущую физическим цепочкам поставок модульность, указывая на универсальность штрих-кодов, которые можно прикрепить практически к любому объекту.

Хотя физические цепочки поставок демонстрируют явную модульность, Верморель отмечает, что ИТ-инфраструктуры компаний часто лишены аналогичной гибкости. Он объясняет это отсутствием модульности тем, что первые этапы развития ИТ в компаниях в 1970-х и 1980-х годах, когда первые ИТ-решения и системы ERP проектировались как автономные, монолитные структуры из-за технологических ограничений того времени.

Верморель определяет “монолит” в ИТ-контексте как единое приложение, которое нельзя разбить на меньшие части. Он объясняет, как этот монолитный подход контрастирует с модульностью, наблюдаемой в физических цепочках поставок, где различные компоненты могут комбинироваться или разделяться по необходимости.

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

Верморель отмечает, что ситуация начала меняться с появлением интернета в конце 90-х годов, что привело к проектированию программного обеспечения из изолированных частей, соединённых сетью. Однако он отмечает, что многие компании до сих пор испытывают трудности с модульностью, несмотря на то, что ценность модульных ИТ-систем теоретически хорошо осознаётся.

Он объясняет, как многие поставщики адаптировали эти старые монолитные архитектуры к облачным и моделям программного обеспечения как услуги (SaaS), что привело к системам, предлагающим улучшенное обслуживание, но не повышающим модульность. Он говорит, что отсутствие модульности мешает компаниям изолировать и изменять отдельные функции.

Чтобы преодолеть эту проблему, Верморель предлагает архитектуру, ориентированную на обслуживание (SOA), подход, который разбивает возможности на меньшие, чётко определённые “блоки”. В качестве примера он приводит Amazon — компанию, которая успешно приняла этот модульный подход на раннем этапе.

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

Верморель оценивает, что от третьей до половины всех ИТ-проектов в цепочках поставок завершаются неудачей. Он ссылается на случай Lidl в Германии, который потерял полмиллиарда евро в результате неудачного перехода на SAP. Он утверждает, что переход от небольших поставщиков к крупным лишь немного снижает уровень неудач, но не устраняет их.

Что касается управления множеством приложений, Верморель предлагает выбирать приложения с узкой специализацией, чтобы минимизировать пересечения, и советует не покупать крупные фреймворки у поставщиков. Для эффективного управления несколькими приложениями он говорит, что компаниям следует разрабатывать внутреннее “связующее” ПО, которое объединяет эти приложения, что поддерживается архитектурой, ориентированной на обслуживание.

Наконец, Верморель делится советами о том, как предотвратить катастрофы, подобные неудачному переходу на SAP в Lidl. Он подчеркивает необходимость мышления в терминах управления рисками и принятия подхода “fail fast”. Он предупреждает против мечтательного управления проектами и подчеркивает важность планирования возможных неудач и поиска способов быстрого восстановления.

Полная стенограмма

Kieran Chandler: Здравствуйте, и добро пожаловать в новый выпуск Lokad TV. На этой неделе мы будем обсуждать модульность — процесс разделения компьютерных процессов нашей компании от единой автономной системы на ряд субпрограмм или даже приложений. Как всегда, со мной Жоаннес Верморель. Итак, Жоаннес, какую часть бизнес-процессов мы сегодня собираемся сделать более модульной?

Joannes Vermorel: Сегодня мы особенно сосредоточимся на ИТ-инфраструктуре и приложенческом ландшафте вашей компании. Модульность — интересное явление. Если задуматься о физическом мире, очевидно, что цепочки поставок невероятно модульны. Возможно, они — самые модульные из всех изобретений человечества. Под модульностью я имею в виду, что если вы хотите транспортировать товары по дорогам, вы можете использовать грузовики. Грузовики невероятно модульны, потому что в них можно поместить практически всё, что не превышает их грузоподъемность, и грузовик может ехать по любой дороге, перемещаясь откуда угодно куда угодно. Если вам нужно больше грузовиков, вы можете практически использовать любой тип грузовика, и они могут добавить транспортную ёмкость вашей цепочке поставок.

То же самое относится к поддонам и контейнерам. Вы можете поместить практически всё на поддон или в контейнер, если это не превышает его вместимость. Контейнеры крайне модульны. Их можно перемещать с грузового корабля на грузовик. Все эти элементы невероятно модульны. Вы можете прикрепить штрих-код к практически любому объекту, если только он не слишком маленький. Это невероятно современное изобретение. Если у вас есть, скажем, алмаз, вы, вероятно, поместите его в коробку и наклеите штрих-код сверху на коробку. Все эти простые элементы можно комбинировать практически бесконечно. Это очень похоже на конструктора LEGO; простые детали, которые можно объединять самыми разнообразными способами. Вот такая физическая цепочка поставок, которая невероятно модульна.

Однако интересное заключается в том, что когда вы переходите в мир ИТ, вы оказываетесь в совершенно иной перспективе, где модульность часто теряется. Я думаю, что её истоки уходят в начало 70-х или 80-х годов, когда компании начали внедрять свои первые компьютерные системы и первые реализации ERP.

Kieran Chandler: То есть вы говорите, что те первоначальные реализации, те первые ИТ-системы, поскольку они были реализованы как единое целое, до сих пор используются в таком виде? Правильно?

Joannes Vermorel: Да, действительно. Если вспомнить ИТ или программное обеспечение 70-х, 80-х или даже начала 90-х годов, любое взаимодействие через сеть было чем-то вроде ракетостроения. Это было возможно, но представляло собой инженерный кошмар. Гораздо проще было взять один большой компьютер, идеальный мейнфрейм IBM того времени, и разместить всю вашу логику на этом компьютере. Затем все пользовались терминалом, подключённым к этому компьютеру, и вся логика работала в виде монолита на этом устройстве.

Kieran Chandler: Что вы подразумеваете под монолитом?

Joannes Vermorel: Под монолитом я подразумеваю приложение как единое целое. Его нельзя разбирать на части. Оно должно быть цельным, иначе это нечто иное.

Kieran Chandler: Боюсь, я представитель поколения миллениалов, так что такая идея может быть мне не совсем знакома. Но, по сути, вы говорите, что всё подключено к одному единственному компьютеру, верно? И мы все подключаемся и работаем оттуда?

Joannes Vermorel: Именно. Мейнфреймы были довольно сложными аппаратными устройствами, поэтому, даже если это был один компьютер…

Kieran Chandler: Мы в основном говорим об ERP, то есть системах управления ресурсами предприятия. Эти системы, как правило, разрабатываются с возможностью расширения, позволяя добавлять дополнительные возможности и функции. Однако они не являются модульными, то есть вы не можете отделить эти возможности, чтобы сохранить их полную изоляцию.

Joannes Vermorel: Интересно то, что, вероятно, изменилось именно с появлением интернета. Я не говорю об изобретении интернета, а о том, что в конце 90-х, когда интернет стал очень популярным, люди начали задумываться о том, как спроектировать программное обеспечение так, чтобы его части были изолированы, соединённые сетью. Таким образом, рабочий процесс перестаёт быть инженерным кошмаром. Раньше, если вы не знали, как построить сложную систему из множества частей, наличие сети в качестве посредника представляло собой инженерный кошмар. Эти знания, культура и инструменты в основном возникли как побочный продукт массового распространения интернета.

Kieran Chandler: Интернет существует уже давно, так почему же мы всё ещё говорим о модульности? Почему это программное обеспечение до сих пор функционирует как единое целое?

Joannes Vermorel: На данный момент я считаю, что если взять среднюю компанию, управляющую сложной цепочкой поставок или транснациональную организацию с множеством филиалов, всё физическое чрезвычайно модульно. Однако, когда мы начинаем смотреть на ИТ, всё оказывается совершенно монолитным. Я считаю, что как компании, так и рынок в целом всё ещё испытывают трудности с оценкой ценности высокомодульной ИТ-системы. В физическом плане это достаточно очевидно, и цепочки поставок продолжают улучшать свою модульность. Однако в сфере приложений это более абстрактно, и модульность не так легко воспринимается.

Многие поставщики взяли старые монолитные архитектуры, немного модернизировали их до моделей SaaS и облачных технологий, но просто скопировали и вставили их. Это по сути та же архитектура, что была в мейнфрейме IBM в 90-х, где вы просто решали, что вместо того, чтобы иметь компьютер в штаб-квартире, на котором всё работает, вы делегируете это поставщику программного обеспечения, работающему по модели SaaS. Но если у поставщика SaaS есть только монолит, который работает на компьютере, расположенном далеко от вашей штаб-квартиры, с небольшой сетью и веб-интерфейсом посредине, это не добавляет ничего с точки зрения модернизации. Это просто облегчает обслуживание. Но когда вы хотите изолировать функции, вы всё ещё сталкиваетесь с монолитом, где такого рода возможности невозможны.

Kieran Chandler: В чем проблема этого монолитного подхода? Как это сказывается на компаниях в реальном мире?

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

Боль, понимаете, сравнима с ситуацией в программном обеспечении. Когда вам не хватает модернизации, это как если заменить одну деталь, то придётся менять их все. Если вы заменяете один грузовик, вам нужно заменить весь парк. Представьте, что вы меняете стеллажи в одном складе, а потом вам нужно менять все стеллажи во всех других складах, иначе они не будут совместимы. Затем вы понимаете: хорошо, может быть, я решусь обновить свой парк грузовиков на электромобили, но это будет грандиозный стратегический шаг и очень сложно. Вы всё равно предпочли бы иметь относительно модульную систему, где электромобили и грузовики с двигателями внутреннего сгорания могут сосуществовать вместе длительное время. Когда не хватает модернизации, это означает, что вы не можете изменить отдельные части вашей цепочки поставок, не изменяя всю систему.

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

Kieran Chandler: Это интересно. Как крупные компании делают это, если они функционируют на такой монолитной системе? Как они переходят на более модульную систему?

Joannes Vermorel: Думаю, мы вернемся к одной из компаний, о которой упоминали практически в каждом эпизоде, например, Amazon. Они не единственные, кто применил крайне модульный подход. В Германии Zalando, как можно узнать из блогов, также полностью адаптировали очень модульный подход, и ключевое слово в IT для этого, когда вы хотите добиться модульности, — это, вероятно, Сервис-ориентированная архитектура, SOA.

Сервис-ориентированная архитектура по сути означает, что вы хотите изолировать возможности в виде блоков, которые сами по себе представляют собой маленькие монолиты, но гораздо меньшие, и которые очень хорошо ограничены для выполнения одной задачи и делают её качественно. И вы соединяете все эти компоненты посредством вашей Сервис-ориентированной архитектуры, что означает, что каждая отдельная служба, то есть приложение, которое выполняет одну задачу и делает её хорошо, предоставляет API, чтобы его можно было легко интегрировать в вашу архитектуру приложений. Она разработана так, чтобы быть легко программно подключаемой к любой произвольной архитектуре приложений, не делая почти никаких предположений о том, какие ещё части включает эта архитектура.

Джефф Безос из Amazon опубликовал очень известное меморандум, я полагаю, в 2002 году, в котором всем его командам было сказано, что каждое подразделение должно иметь сервис-ориентированную архитектуру с API, чтобы данные, находящиеся в вашем silo, могли экспортироваться для использования в любом другом подразделении компании, и мы могли программно взаимодействовать с тем, что вы создаёте.

Kieran Chandler: Проблема, которую я вижу в этом, заключается в том, что вы становитесь зависимыми от множества мелких приложений, меньших программ, в конечном итоге меньших компаний. Разве это не приводит к большему количеству единичных точек отказа? В то время как при монолитном подходе у вас есть одна надежная крупная компания, одна крупная ERP-система, которая всегда будет работать, и в ней можно быть уверенным.

Joannes Vermorel: Это правда, и в определённой степени это одна из проблем распределённой системы. Если ваше оборудование выходит из строя в 1% случаев, то это значит, что если у вас есть мейнфрейм.

Kieran Chandler: Вы упоминали, что программное обеспечение может давать сбои три раза в год. Если у вас есть 10 приложений, каждое из которых имеет 1%-ный шанс быть недоступным в любой день, это означает, что примерно каждые 10 дней что-то выходит из строя в вашей сети. Это действительно проблема. Какие решения вы бы предложили для этой ситуации?

Joannes Vermorel: Первое, что приходит в голову — это избыточность, но я хотел бы обсудить последствия с точки зрения распределённых вычислений, а затем, возможно, поговорим о больших и малых компаниях и различиях между поставщиками. С точки зрения распределённых вычислений, цель состоит в том, чтобы каждый отдельный блок был высоко избыточным. Это и есть суть облачных вычислений. Вы хотите иметь сильно избыточное программное обеспечение, чтобы обеспечить очень высокий уровень доступности.

Хорошая новость заключается в том, что поскольку ваши приложения меньше и проще, гораздо легче обеспечить очень высокую доступность с помощью небольшого, простого приложения, чем с помощью очень сложного. В интернете существует множество компонентных сервисов, которые буквально работают круглосуточно. Например, Google Mail действительно работает всегда. Сайт Yahoo практически всегда доступен. Facebook тоже всегда в сети. Таким образом, можно спроектировать такие свойства «всегда вкл.» для ваших приложений, что повышает надёжность всей системы.

Kieran Chandler: А как насчёт перехода от одного крупного поставщика к множеству мелких?

Joannes Vermorel: Реальность такова, что уровень отказов в программном обеспечении высок. Люди не осознают, что, возможно, половина программных инициатив терпит неудачу. По моим оценкам, от трети до половины всех IT-проектов в цепочке поставок терпят неудачу у компаний практически любого размера. Несколько недель назад Lidl в Германии фактически потерял полмиллиарда евро на неудачном переходе SAP. Это был семилетний проект, закончившийся провалом, и в конце концов они сдались. Но это не единственный пример; такое случается довольно часто.

Крупные поставщики, вероятно, имеют более высокий уровень успеха, но если говорить приблизительно, то речь идёт о переходе от мелкого поставщика с 50%-ным уровнем неудач, что довольно плохо, к крупному поставщику с 30%-ным уровнем неудач. Таким образом, при переходе от небольшой компании к большой риск немного снижается, но всего лишь незначительно.

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

Особенность подхода Lidl заключается в том, что я уверен, они изначально не планировали семилетнюю миграцию. Это, вероятно, был двухлетний переход, который превратился в трёхлетний, затем четырёхлетний и так далее, потому что они терпели неудачи, переосмысливали и снова терпели неудачи. Спустя семь лет они, наконец, решили сдаться, вероятно, потому что все утратили надежду на успех проекта.

Kieran Chandler: Итак, если мы согласны, что эти приложения, как только вы найдёте подходящее и, возможно, проведёте несколько итераций, могут быть надёжными… Они, кажется, работают и выполняют те же функции, что и более крупная система. А как насчёт взаимодействия между этими приложениями? Потому что часто приложение может хорошо выполнять что-то ещё, и может возникнуть некоторое пересечение и конфликт в системе. Как с этим справиться?

Joannes Vermorel: Во-первых, когда вы формируете состав вашей системы приложений, вам действительно стоит выбирать приложения с узкой специализацией. Такой подход полностью противоречит тому, что делают большинство запросов предложений (RFP). Когда компании стремятся приобрести какое-либо программное обеспечение, они часто запускают RFP и требуют всё — все функции, все навороты и дополнительные возможности. Но это противоположно тому, чего стоит стремиться. Вам нужно выбрать нечто исключительно узкое, чтобы по замыслу минимизировать пересечения.

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

Платформа — это хорошо, но две платформы могут стать кошмаром. Как только у вас окажется несколько поставщиков, продающих платформы, вы столкнётесь с морем пересечений. Решение заключается в тщательном выборе состава ваших компонентов.

Что касается «связующего звена», обычно его лучше разрабатывать внутри компании. Это может идти вразрез с интуицией о том, зачем вообще разрабатывать программное обеспечение собственными силами. Ответ таков: если вы компания определённого размера, ваша система приложений абсолютно уникальна для вас.

Даже если вы используете все стандартные приложения, вам понадобится несколько приложений. Сегодня невозможно, чтобы одна ERP-система умела обрабатывать электронную почту, видеоконференции и так далее. Вы не можете внедрить каждую необходимую функцию в одно приложение. Вероятно, вы будете использовать Microsoft Excel, как и все остальные, так что вам потребуется место для хранения файлов и прочее.

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

Kieran Chandler: Это абсолютно уникально, это ваша ДНК. Вы можете использовать это связующее звено, которое разрабатываете внутри компании. В этом и заключается суть сервис-ориентированной архитектуры — сделать это связующее звено максимально простым и лёгким в реализации, чтобы у вас была очень компактная IT-команда, которой требуются минимальные усилия для создания этого кастомного программного обеспечения, которое просто всё склеивает вместе. Итак, подводя итоги, если я CEO, как мне избежать ещё одной катастрофы типа Lidl?

Joannes Vermorel: Во-первых, я считаю, что важно думать о риске, а не просто минимизировать его. Катастрофа типа Lidl возникла из-за того, что люди говорили: “Мы не хотим ни малейшего риска”, и поэтому выбирали самого крупного поставщика, пытаясь получить продукт, который делает всё. По сути, это подход, когда мы считаем, что хотим получить решение, которое изначально правильно, и сразу внедрить то, что обновит всю компанию. Это худший тип подхода с точки зрения управления рисками.

Вам нужно думать совершенно наоборот: “Как я могу создать что-то, что быстро потерпит неудачу, если должно потерпеть?” Видите ли, проблема с риском заключается в том, что когда у вас есть огромный проект, вы долго не узнаёте, потерпели ли вы неудачу или нет. Вам нужно иметь что-то, что соответствует принципу «быстрого провала», когда вы сразу понимаете, что произошёл провал, и он носит маломасштабный характер. И если потребуется замена, область применения будет управляемой, и это можно сделать с помощью множества небольших блоков.

Так что думайте об этом не как о предотвращении риска. Я говорю, что при переходе от крупного поставщика к мелкому, вы можете увеличить риск с 50%-ной вероятностью неудачи до 50%. В конечном итоге, если 30%-ная вероятность неудачи означает, что ваша компания обанкротится или цепочка поставок остановится, это не тот риск, который можно принять. Поэтому вам всё равно нужно планировать на случай неудачи.

Я считаю, что поскольку высокая степень риска неизбежна, следует сразу перейти к плану на случай провала. Старайтесь допускать небольшие, быстрые и чётко ограниченные провалы, чтобы иметь возможность проводить итерации, вместо того чтобы думать, что всё сработает с первой попытки, что является мечтательным подходом. Иначе вы отправитесь в путь, который, вероятно, продлится семь лет, чтобы в итоге потерять полмиллиарда евро. Вот такое мечтательное отношение к управлению проектами.

Kieran Chandler: Отлично, мне нравится. Совет дня от Lokad: если вы собираетесь потерпеть неудачу, делайте это быстро. Блестяще. Так что это всё на этой неделе. Мы вернёмся на следующей неделе с ещё одним эпизодом. До тех пор, спасибо за просмотр.