Буриданов осел и композиция конфигурации

в 18:37, , рубрики: ERP-системы, Анализ и проектирование систем, Блог компании Ultima, концепция, Программирование, проектирование, Проектирование и рефакторинг

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

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

Традиционно, сначала договоримся о значении слов.
Все известные автору ERP системы логически состоят из некоей “платформы” и реализованного на ней прикладного кода — он называется “конфигурацией” (в 1С и у нас) или “решением”.

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

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

Как у Лексуса когда-то: комплектация одна, она же максимальная

И первое время это было хорошо весьма — мы очень быстро разворачивали решения. Однако с каждым новым клиентом возникали новые проблемы.

Для понимания — объем именно прикладного кода (то есть кода конфигурациирешения) составлял порядка 15Мб.

При этом объем кода конфигурации не был проблемой сам по себе.

Проблемой было постепенное устаревание базовой конфигурации.

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

Как естественное следствие, базовая конфигурация не обогащалась и не актуализировалась и постепенно теряла в потребительских свойствах.

С другой стороны, в процессе внедрения разветвленный обширнейший функционал базового решения as is становился проблемой — бОльшая его часть очередному внедряемому клиенту была совершенно избыточна, при этом создание востребованных новых или актуализация старых функций в силу сложных взаимодействий была неоправданно (с точки зрения отдельного эксплуатанта) сложной.

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

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

Аналогичные проблемы с внедрениями — вытекают естественно и неизбежно. Проблема, собственно, хорошо описаны в той самой статье про 1С.

Марк Твен призывал: “Если ты оказался в большинстве — хорошенько задумайся”.
Буриданов осел и композиция конфигурации - 1

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

И — семь бед один ответ — решили изменить подход с «максимум» функционала на обратный: minimum minimorum, дорогие читатели. Голь на выдумки хитра.

Минимум — это самый лаконичный функционал, который будет в неизменном или близко к тому виде востребован всем множеством будущих эксплуатантов. Вне зависимости от вида бизнеса.

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

Такой функционал если и устаревает, то крайне неторопливо (по нашей практике, существенных изменений с 2004 года не обнаружено).

Он и был включен в базовую конфигурацию.

И только.

Для сравнения — для второго поколения платформы Ultima Businessware объем кода базовой конфигурации — 2 Мб.

Плюсы такого подхода для внедрений и поддержки — неоценимы и очевидны.

Однако исчезает преимущество богатейшего функционала (реальное или вымышленное — предмет отдельного текста, но с точки зрения маркетинга “богатый функционал” — несомненно плюс).

Проблему наличия “богатейшего функционала” мы решаем через аппарат бизнес-кейсов: результатов внедрения и эксплуатации логически выделенного блока функционала у отдельного клиента.

Их совокупность, в некотором роде, являет собой открытую базу знаний — в том числе с точки зрения управленческих решений.

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

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

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

Некоторые усилия от разработчика, безусловно, требуются — но несравненно меньше, чем в случае реализации конфликтующего функционала.

В итоге:

  • Решения Ultima легко поддерживать.
    В базовой конфигурации присутствует исключительно используемый функционал.
    Нет «прикрытого» функционала.
    Нет простыней настроек и проверок.
  • Функциональность внедряемого решения — всегда актуальна.
    “Инфрастуктурный” функционал не стареет.

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

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

    Никакой вендор никогда не сможет даже приблизиться к этому — по очевидным причинам принципиального характера.

P.S. Возвращаясь к началу — сетованиям автора статьи про 1С на, по его мнению, принципиальные пороки монолитности архитектуры.
Если кошек уметь готовить, монолитная архитектура — огого!

Автор: Rupper

Источник

* - обязательные к заполнению поля


https://ajax.googleapis.com/ajax/libs/jquery/3.4.1/jquery.min.js