CRUD бизнес-приложения

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

Обзор

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

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

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

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

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

Как упоминалось выше, CRUD обозначает Create, Read, Update и Delete — четыре фундаментальные операции, которые выполняются над таблицами реляционной базы данных.

• 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 на протяжении десятилетий был основным подходом для бизнес-приложений. С технологической точки зрения, этот подход выигрывает благодаря комплексным open-source фреймворкам и инструментам во всех основных программных стэках. В результате технологический путь предельно ясен. Кроме того, CRUD также выигрывает от наличия высококачественных инструментов разработки, благодаря чему производительность программистов, участвующих в создании CRUD-приложений, как правило, высока.

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

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

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

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

Ограничение в выразительности отражает тот факт, что четыре действия (или «глагола») — create, read, update и delete — не могут адекватно передать более детализированный спектр намерений. Например, рассмотрим ситуацию, когда сотрудник пытается устранить дублирование нескольких записей поставщиков, созданных по ошибке в системе SRM (Supplier Relationship Manager). Подходящим глаголом для этой операции было бы «слияние». Однако в дизайне CRUD этого глагола нет. Фактически такая возможность неизменно реализуется в виде двухэтапного процесса. Сначала обновляются все записи, которые раньше указывали на собирающиеся к удалению записи поставщиков, так, чтобы они указывали на ту, которая должна быть сохранена. Затем удаляются все, кроме одной из лишних записей поставщиков. Таким образом, не только теряется исходное намерение (слияние), но и само преобразование оказывается разрушительным с точки зрения данных. По опыту, когда CRUD-приложения предупреждают пользователей о предстоящем необратимом изменении данных, это почти всегда проявление ограничения CRUD², негативно сказывающееся на пользовательском опыте.

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

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

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

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

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

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

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

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

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

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

Точка зрения Lokad

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

В наше время почти нет причин платить баснословные суммы за CRUD-приложения. Как правило, любое CRUD-приложение, стоимость которого превышает 250k USD в год, является серьёзным кандидатом на замену собственным программным обеспечением. Любое CRUD-приложение, стоимость которого превышает 2.5M USD в год, почти без исключения должно быть заменено собственным программным обеспечением (возможно, с использованием уже существующей открытой базы и дальнейшей кастомизацией).

Поставщики корпоративного программного обеспечения, продающие CRUD-приложения, прекрасно осведомлены об этой проблеме (и давно ею интересуются). Таким образом, поставщикам часто заманчиво добавить в решение функциональность/приложения/элементы, не относящиеся к CRUD⁶, и попытаться убедить клиентов в том, что (а) эти элементы имеют значение и (б) они представляют собой некий «секретный соус», который клиент не сможет воспроизвести. Однако такой подход почти никогда не увенчивается успехом, в основном потому, что у поставщика отсутствует подходящая инженерная база⁷. По наглядным примерам почти все известные и устоявшиеся ERP-системы обладают обширными возможностями прогнозирования и планирования, из которых почти все остаются неиспользованными, учитывая, насколько плохо они фактически выполняют эти задачи.

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

Заметки