Модуляризация в цепи поставок

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 Концепция “быстрого сбоя” в программных проектах.
00:19:30 Управление перекрытиями, важность “склейки” программного обеспечения.
00:22:46 Избегание программных катастроф.

Резюме

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Полный текст

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

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

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

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

Кирен Чандлер: Итак, вы хотите сказать, что эти первоначальные реализации, эти первоначальные IT-системы, поскольку они были в значительной степени единственным подходом, все еще используются сегодня. Это то, что вы хотите сказать?

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

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

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

Кирен Чандлер: Боюсь, я немного миллениал, поэтому эта идея может быть немного старше меня. Но в основном мы говорим о том, что все подключено к одной единственной машине, верно? И затем мы все подключаемся и работаем оттуда?

Жоанн Верморел: Именно. Мейнфреймы были относительно сложными аппаратными устройствами, поэтому даже если это была одна машина.

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

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

Кирен Чандлер: Интернет существует уже давно, почему мы все еще говорим о модульности? Почему эти программы все еще действуют в таком единственном режиме?

Жоанн Верморел: Сейчас мое диагноз состоит в том, что когда вы берете среднюю компанию, которая управляет сложной цепочкой поставок или многонациональной компанией с множеством местоположений, все физическое является чрезвычайно модульным. Однако, когда мы начинаем смотреть на IT, оно полностью монолитное. Я считаю, что компании и рынок в целом все еще испытывают трудности в оценке ценности наличия чего-то чрезвычайно модульного в плане IT. Физически это довольно очевидно, и цепочки поставок все еще улучшают свою модульность. Однако в плане ландшафта приложений это более абстрактно, более сложно воспринимать модульность как таковую.

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

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

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

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

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

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

Жоанн Верморель: Я думаю, мы вернемся к одной из компаний, о которой мы упоминали практически в каждом эпизоде, как, например, Amazon. Они не единственные, кто принял крайне модульный подход. В Германии Zalando, вы можете следить в блогах, также полностью адаптировали очень модульный подход, и ключевое слово в IT для этого, когда вы хотите иметь эту модульность, вероятно, Service Oriented Architecture, SOA.

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

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

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

Жоанн Верморель: Это правда, и в некотором смысле это одно из вызовов распределенной системы. Если ваше оборудование выходит из строя 1% времени, то это означает, что если у вас есть главный компьютер.

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

Жоанн Верморель: Резервирование - это первое, что приходит на ум, но я хотел бы обсудить последствия с точки зрения распределенных вычислений, и, возможно, затем мы можем поговорить о маленьких против больших компаний и неравенстве среди поставщиков. С точки зрения распределенных вычислений, цель состоит в том, чтобы обеспечить высокую надежность каждого отдельного блока. Это суть облачных вычислений. Вы хотите иметь сильно резервируемое программное обеспечение, чтобы ваше время работы было очень высоким.

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

Киран Чандлер: Что насчет перехода от одного большого поставщика к множеству маленьких поставщиков?

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Кирен Чандлер: Отлично, мне нравится. Совет дня от Lokad: если вы собираетесь потерпеть неудачу, делайте это быстро. Великолепно. Это все на этой неделе. Мы вернемся в следующей неделе с еще одной серией. До тех пор, спасибо за просмотр.