Приложения для бизнеса CRUD

С начала 1980-х годов подавляющее большинство бизнес-приложений приняли похожую внутреннюю структуру, известную как CRUD, что означает Create / Read / Update / Delete (Создание / Чтение / Обновление / Удаление). Эта структура отражает применение реляционной базы данных для сохранения бизнес-данных. CRUD-дизайн выдержал несколько значительных технологических скачков, от консольных терминалов, подключенных к главным компьютерам, до мобильных приложений, подключенных к облачным платформам. Понимание CRUD-дизайна имеет значение в сложных областях, таких как цепочка поставок, которые обычно работают поверх всего прикладного ландшафта, состоящего из CRUD-приложений. Такое понимание является важным для правильной навигации в этом ландшафте, от ведения переговоров с поставщиками программного обеспечения до использования записей данных, собранных через все эти приложения.

Обзор

К началу 1980-х годов реляционные базы данных стали доминирующим подходом для хранения и доступа к бизнес-данным. К концу 1990-х годов новые открытые реляционные базы данных еще больше укрепили эту практику. В наши дни CRUD-дизайн отражает наиболее распространенный подход к разработке бизнес-приложения поверх реляционной базы данных.

База данных в реляционном смысле включает список таблиц. Каждая таблица содержит список столбцов (также называемых полями). Каждое поле имеет тип данных: число, текст, дата и т. д. Таблица содержит список строк (также называемых записями). Как правило, количество столбцов ожидается ограниченным, несколько сотен, а количество строк неограниченно, потенциально достигая миллиардов.

Рисунок 1: простая таблица, отражающая список продуктов и их запасов, иллюстрирующая то, что обычно находится в реляционной базе данных.

На практике реляционный подход требует нескольких таблиц для отражения чего-то, интересного с точки зрения бизнеса (например, заказы на покупку). Эти “группировки” таблиц называются сущностями. Сущность отражает высокоуровневое понимание бизнеса.

Рисунок 2: простая сущность "корзина для покупок", состоящая из двух таблиц. Эта сущность отражает состояние корзины для посетителя интернет-магазина.

Как уже упоминалось выше, CRUD означает Create (Создание), Read (Чтение), Update (Обновление) и Delete (Удаление) - 4 основные операции, которые выполняются с таблицами в реляционной базе данных.

• Create: добавление новых строк в таблицу.
• Read: извлечение существующих строк из таблицы.
• Update: изменение существующих строк в таблице.
• Delete: удаление существующих строк из таблицы.

Эти операции выполняются с помощью специализированного языка базы данных, почти всегда сейчас это SQL (Structured Query Language)¹.

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

Большинство “транзакционных” бизнес-приложений, от простого учета времени до очень сложных ERP или CRM, используют аналогичный дизайн CRUD под капотом - шаблон проектирования, установленный более 4 десятилетий назад. Простые приложения содержат только несколько сущностей, в то время как сложные могут содержать тысячи. Однако, от простого к сложному, с точки зрения внутреннего дизайна, это просто больше того же самого.

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

Приложения CRUD в цепочке поставок

Почти все приложения (доступные конечным пользователям), которые используются для работы компаний и их процессов, являются CRUD. Говоря в общем, если предприятийское программное обеспечение имеет преимущество в виде трехбуквенного акронима, такого как ERP, MRP, CRM, SRM, PLM, PIM, WMS, OMS, EDI (и т.д.), то оно почти наверняка реализовано как CRUD. Самое заметное исключение из этого правила - это редакторы документов (например, программное обеспечение для работы с электронными таблицами), которые представляют собой совершенно другой тип программного обеспечения.

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

Такие приложения CRUD содержат практически все актуальные исторические транзакционные данные, которые могут быть использованы для количественного улучшения цепочки поставок (например, оптимизация уровней запасов). В результате, многие приложения CRUD пытаются² в какой-то момент перейти к аналитическим возможностям (например, для планирования или оптимизации). К сожалению, хотя CRUD имеет множество преимуществ, он также имеет серьезные недостатки в отношении аналитических возможностей (см. “Ограничения CRUD” ниже).

Преимущества CRUD

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

С точки зрения штатного расписания, существует большой рынок программных инженеров, имеющих опыт работы с CRUD. Кроме того, CRUD является одной из наиболее доступных частей программной инженерии - в основном благодаря высококачественным инструментам разработки. В результате CRUD крайне доступен даже для младших программных инженеров (и менее талантливых старших). Поскольку основные принципы CRUD остаются стабильными на протяжении десятилетий, переход к новому технологическому стеку также может быть выполнен относительно легко - по крайней мере, по сравнению с другими, более технически продвинутыми подходами.

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

Ограничения CRUD

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

Ограничение выразительности отражает тот факт, что четыре действия (или “глаголы”) - создание, чтение, обновление и удаление - не могут правильно описать более детальный набор намерений. Например, рассмотрим ситуацию, когда сотрудник хочет объединить несколько записей поставщиков, созданных по ошибке в SRM (Система управления отношениями с поставщиками). Подходящим глаголом для этой операции было бы объединение. Однако в CRUD-дизайне нет такого глагола. Фактически, такая возможность обычно реализуется как двухэтапный процесс. Сначала обновите все строки, которые ранее указывали на скоро удаляемые записи поставщиков, чтобы они теперь указывали на ту, которую нужно сохранить. Затем удалите все, кроме одной из дополнительных записей поставщиков. При этом теряется исходное намерение (объединение), а также происходит разрушение данных. Как правило, когда CRUD-приложения предупреждают своих пользователей о том, что они собираются внести некоторые необратимые изменения в данные, это почти всегда ограничение CRUD³, которое вмешивается в пользовательский опыт.

Ограничение производительности отражает тот факт, что любая длительная операция - то есть любая операция, которая читает больше, чем крошечную долю базы данных - ставит CRUD-приложение под угрозу отказа отклика. Действительно, для CRUD-приложения пользователи ожидают, что задержка будет едва заметной для практически всех обычных операций. Например, обновление уровня запасов в WMS (Система управления складом) должно происходить в миллисекундах (чтобы обеспечить плавность операций). Поскольку все операции, передаваемые CRUD-приложению, потребляют вычислительные ресурсы из одной и той же базы данных, практически любая нетривиальная операция ставит эту базу данных под угрозу нехватки вычислительных ресурсов. Как правило, в крупных компаниях CRUD-приложения часто становятся нереагирующими на несколько секунд (или даже минут). Эти ситуации почти всегда вызваны несколькими “тяжелыми” операциями, которые монополизируют вычислительные ресурсы на короткое время, тем самым задерживая все остальные операции, включая “легкие”. Эта проблема объясняет, почему нетривиальные операции обычно разделяются на пакетные задания, которые выполняются ночью. Это также объясняет, почему CRUD-приложения обычно плохо подходят для аналитики, поскольку аналитические нагрузки практически невозможно выполнять только в нерабочее время.

Современные варианты CRUD

За последние несколько десятилетий предприятийное программное обеспечение претерпело существенные изменения. В 1990-х годах большинство приложений перешло с консольных терминалов на пользовательские интерфейсы на рабочем столе. В 2000-х годах большинство приложений перешло с пользовательских интерфейсов на рабочем столе на веб-интерфейсы. За последнее десятилетие большинство приложений перешло на SaaS (программное обеспечение как услуга) и в процессе мигрировало к облачным вычислениям. Однако дизайн CRUD остался практически неизменным в этих изменениях.

Переход от одноарендной модели к многорендной⁴ заставил поставщиков программного обеспечения ограничивать доступ к данным сущностей через API (интерфейсы программирования приложений). Действительно, прямой доступ к базе данных, даже только для чтения, создает возможность истощения вычислительных ресурсов транзакционного ядра всего несколькими тяжелыми запросами. API смягчает такие проблемы. Ограничение доступа к данным приложения через API также устраняет некоторые преимущества CRUD, по крайней мере, с точки зрения клиентской компании. Надежное извлечение большого объема данных из API обычно требует больше усилий, чем составление сравнимой серии SQL-запросов. Более того, API может быть неполным - не раскрывая данные, которые существуют в приложении, хотя прямой доступ к базе данных должен был предоставить полный доступ к данным по конструкции.

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

Динамика поставщика

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

Добавление сущностей открывает новые возможности и дает поставщику возможность повысить цены, отражая дополнительную созданную для клиентской компании ценность. Также часто вводятся модули⁵, то есть группировки бизнес-связанных сущностей, как механизм ценообразования для взимания большей платы (в зависимости от степени использования программного продукта).

В результате CRUD-приложения обычно становятся все более сложными со временем, но также становятся менее актуальными. Действительно, по мере добавления новых сущностей для удовлетворения интересов всей клиентской базы, многие (если не большинство) вновь введенных сущностей не являются актуальными для каждой отдельной клиентской компании. Эти “мертвые” сущности - с точки зрения клиентской компании - представляют собой растущую случайную сложность, которая загрязняет CRUD.

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

Взгляд Lokad

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

В настоящее время очень мало причин платить большие суммы за CRUD-приложения. Как правило, любое CRUD-приложение, стоимость которого превышает 250 тыс. долларов США в год, является серьезным кандидатом на замену внутренним программным обеспечением. Любое CRUD-приложение, стоимость которого превышает 2,5 млн долларов США в год, должно практически без исключения быть заменено внутренним программным обеспечением (возможно, начиная с предварительно существующей базовой версии с открытым исходным кодом и настройкой оттуда).

Поставщики корпоративного программного обеспечения, которые продают CRUD-приложения, хорошо осознают эту проблему (и давно это знают). Поэтому поставщику искусственно добавлять в решение функциональность/приложения/элементы⁷, не относящиеся к CRUD, и пытаться убедить клиентов (a) в том, что эти элементы имеют значение, и (b) что эти элементы представляют собой некую “секретную приправу”, которую клиент не сможет повторить, кажется очень соблазнительным. Однако такой подход практически никогда не приводит к успеху, главным образом потому, что у поставщика нет правильного инженерного ДНК⁸. Как свидетельство на основе анекдотических данных, почти все известные и установленные системы планирования ресурсов предприятия (ERP) имеют обширные возможности прогнозирования и планирования, большая часть которых остается неиспользованной из-за плохой производительности при выполнении этих задач.

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

Примечания