Сегодня немного лирики: как мы решаем, что попадает в базовый функционал решения, а что нет.
Тему настоящего текста дала известная (на хабре) статья про 1С, освещавшая помимо прочего, подход уважаемой корпорации к развитию функционала коробочных конфигураций.
Нашу платформу объединяет с 1С концепция монолита (в противовес модульной схеме некоторых коллег, что на слуху), а вот подход к композиции базовой конфигурации у нас по сравнению с 1С совершенно противоположный.
Традиционно, сначала договоримся о значении слов.
Все известные автору ERP системы логически состоят из некоей “платформы” и реализованного на ней прикладного кода — он называется “конфигурацией” (в 1С и у нас) или “решением”.
Все известные автору вендоры (и мы том числе) самостоятельно поддерживают функционал платформы и базовой конфигурациирешения.
В силу исторических причин в момент выхода на рынок в нашей базовой конфигурации функционал, разработанный когда-либо с самого начала, присутствовал полностью. Чуть более, чем.
Как у Лексуса когда-то: комплектация одна, она же максимальная
И первое время это было хорошо весьма — мы очень быстро разворачивали решения. Однако с каждым новым клиентом возникали новые проблемы.
Для понимания — объем именно прикладного кода (то есть кода конфигурациирешения) составлял порядка 15Мб.
При этом объем кода конфигурации не был проблемой сам по себе.
Проблемой было постепенное устаревание базовой конфигурации.
В каждом новом внедрении возникал новый функционал. Переносить его в базовую конфигурацию не представлялось возможным ввиду конфликта с ранее реализованным функционалом.
Как естественное следствие, базовая конфигурация не обогащалась и не актуализировалась и постепенно теряла в потребительских свойствах.
С другой стороны, в процессе внедрения разветвленный обширнейший функционал базового решения as is становился проблемой — бОльшая его часть очередному внедряемому клиенту была совершенно избыточна, при этом создание востребованных новых или актуализация старых функций в силу сложных взаимодействий была неоправданно (с точки зрения отдельного эксплуатанта) сложной.
А так же рискованной в плане багогенерации — собственно, “кто служил, тот знает”, а для менее погруженных в тему читателей параллель: если вы просто положите камень на ровную землю — в мире нет ничего стабильнее. А если “просто” положить его на склон горы, состоящей из таких же камней, — вы с большой вероятностью получите катастрофу лавинного характера.
Имея на руках вышеописанным образом сконструированную базовую конфигурацию, мы стояли в длинном ряду коллег: стремление иметь максимально насыщенный функционал базового решения объединяет практически всех ERP-вендоров.
Аналогичные проблемы с внедрениями — вытекают естественно и неизбежно. Проблема, собственно, хорошо описаны в той самой статье про 1С.
Марк Твен призывал: “Если ты оказался в большинстве — хорошенько задумайся”.
При разработке второго поколения платформы мы отказались от обратной совместимости, так что прикладной код в любом случае надо было писать с нуля.
И — семь бед один ответ — решили изменить подход с «максимум» функционала на обратный: minimum minimorum, дорогие читатели. Голь на выдумки хитра.
Минимум — это самый лаконичный функционал, который будет в неизменном или близко к тому виде востребован всем множеством будущих эксплуатантов. Вне зависимости от вида бизнеса.
Для себя внутри мы его называем “инфраструктурный функционал”: справочники товаров, клиентов, сотрудников, финансовые документы, учет затрат, бюджетов, безналичных платежей и т.п.
Такой функционал если и устаревает, то крайне неторопливо (по нашей практике, существенных изменений с 2004 года не обнаружено).
Он и был включен в базовую конфигурацию.
И только.
Для сравнения — для второго поколения платформы Ultima Businessware объем кода базовой конфигурации — 2 Мб.
Плюсы такого подхода для внедрений и поддержки — неоценимы и очевидны.
Однако исчезает преимущество богатейшего функционала (реальное или вымышленное — предмет отдельного текста, но с точки зрения маркетинга “богатый функционал” — несомненно плюс).
Проблему наличия “богатейшего функционала” мы решаем через аппарат бизнес-кейсов: результатов внедрения и эксплуатации логически выделенного блока функционала у отдельного клиента.
Их совокупность, в некотором роде, являет собой открытую базу знаний — в том числе с точки зрения управленческих решений.
Функционал каждого бизнес-кейса работает и — что особенно важно — развивается в условиях реального живого бизнеса.
Каждый раз, когда новому клиенту требуется функционал отдельного бизнес-кейса или его группы, не входящий в инфраструктурный, актуальный код переносится из одного проекта в другой. Всякие сопутствующие ништяки типа естественного код-ревью подразумеваются, но не описываются в силу тривиальности.
В случае, если проекты находятся в ведении разных партнеров, коммуникация может быть поддержана Партнерским центром Ultima — но, как правило, его вмешательство не требуется.
Вследствие молотковой простоты базовой конфигурации (ну, и средств разработки платформы, конечно) внешний функционал относительно легко интегрируется.
Некоторые усилия от разработчика, безусловно, требуются — но несравненно меньше, чем в случае реализации конфликтующего функционала.
В итоге:
- Решения Ultima легко поддерживать.
В базовой конфигурации присутствует исключительно используемый функционал.
Нет «прикрытого» функционала.
Нет простыней настроек и проверок. - Функциональность внедряемого решения — всегда актуальна.
“Инфрастуктурный” функционал не стареет.Внешний функционал из бизнес-кейсов актуален в силу условий его существования — в противоположность “богатым базовым решениям”, в которые отдельно взятые участки кода могли попасть дремучее количество лет назад и окуклиться.
В работающем бизнесе функционал эволюционирует. В хорошо работающем — эволюционирует быстро, причем под влиянием огромного количества независимых акторов — сотрудников, а иногда и клиентов. Когда изначально одинаковый функционал эволюционирует у разных клиентов различным образом — на выходе получается богатейшая палитра решений различной эффективности для различных условий.
Никакой вендор никогда не сможет даже приблизиться к этому — по очевидным причинам принципиального характера.
P.S. Возвращаясь к началу — сетованиям автора статьи про 1С на, по его мнению, принципиальные пороки монолитности архитектуры.
Если кошек уметь готовить, монолитная архитектура — огого!
Автор: Rupper
