- PVSM.RU - https://www.pvsm.ru -
Сегодня немного лирики: как мы решаем, что попадает в базовый функционал решения, а что нет.
Тему настоящего текста дала известная (на хабре) статья про 1С [1], освещавшая помимо прочего, подход уважаемой корпорации к развитию функционала коробочных конфигураций.
Нашу платформу объединяет с 1С концепция монолита (в противовес модульной схеме некоторых коллег, что на слуху [2]), а вот подход к композиции базовой конфигурации у нас по сравнению с 1С совершенно противоположный.
Традиционно, сначала договоримся о значении слов.
Все известные автору ERP системы логически состоят из некоей “платформы” и реализованного на ней прикладного кода — он называется “конфигурацией” (в 1С и у нас) или “решением”.
Все известные автору вендоры (и мы том числе) самостоятельно поддерживают функционал платформы и базовой конфигурациирешения.
В силу исторических причин [3]в момент выхода на рынок в нашей базовой конфигурации функционал, разработанный когда-либо с самого начала, присутствовал полностью. Чуть более, чем.
Как у Лексуса когда-то: комплектация одна, она же максимальная
И первое время это было хорошо весьма — мы очень быстро разворачивали решения. Однако с каждым новым клиентом возникали новые проблемы.
Для понимания — объем именно прикладного кода (то есть кода конфигурациирешения) составлял порядка 15Мб.
При этом объем кода конфигурации не был проблемой сам по себе.
Проблемой было постепенное устаревание базовой конфигурации.
В каждом новом внедрении возникал новый функционал. Переносить его в базовую конфигурацию не представлялось возможным ввиду конфликта с ранее реализованным функционалом.
Как естественное следствие, базовая конфигурация не обогащалась и не актуализировалась и постепенно теряла в потребительских свойствах.
С другой стороны, в процессе внедрения разветвленный обширнейший функционал базового решения as is становился проблемой — бОльшая его часть очередному внедряемому клиенту была совершенно избыточна, при этом создание востребованных новых или актуализация старых функций в силу сложных взаимодействий была неоправданно (с точки зрения отдельного эксплуатанта) сложной.
А так же рискованной в плане багогенерации — собственно, “кто служил, тот знает”, а для менее погруженных в тему читателей параллель: если вы просто положите камень на ровную землю — в мире нет ничего стабильнее. А если “просто” положить его на склон горы, состоящей из таких же камней, — вы с большой вероятностью получите катастрофу лавинного характера.
Имея на руках вышеописанным образом сконструированную базовую конфигурацию, мы стояли в длинном ряду коллег: стремление иметь максимально насыщенный функционал базового решения объединяет практически всех ERP-вендоров.
Аналогичные проблемы с внедрениями — вытекают естественно и неизбежно. Проблема, собственно, хорошо описаны в той самой статье про 1С.
Марк Твен призывал: “Если ты оказался в большинстве — хорошенько задумайся”.
При разработке второго поколения платформы мы отказались от обратной совместимости, так что прикладной код в любом случае надо было писать с нуля.
И — семь бед один ответ — решили изменить подход с «максимум» функционала на обратный: minimum minimorum, дорогие читатели. Голь на выдумки хитра.
Минимум — это самый лаконичный функционал, который будет в неизменном или близко к тому виде востребован всем множеством будущих эксплуатантов. Вне зависимости от вида бизнеса.
Для себя внутри мы его называем “инфраструктурный функционал”: справочники товаров, клиентов, сотрудников, финансовые документы, учет затрат, бюджетов, безналичных платежей и т.п.
Такой функционал если и устаревает, то крайне неторопливо (по нашей практике, существенных изменений с 2004 года не обнаружено).
Он и был включен в базовую конфигурацию.
И только.
Для сравнения — для второго поколения платформы Ultima Businessware [4]объем кода базовой конфигурации — 2 Мб.
Плюсы такого подхода для внедрений и поддержки — неоценимы и очевидны.
Однако исчезает преимущество богатейшего функционала (реальное или вымышленное — предмет отдельного текста, но с точки зрения маркетинга “богатый функционал” — несомненно плюс).
Проблему наличия “богатейшего функционала” мы решаем через аппарат бизнес-кейсов: результатов внедрения и эксплуатации логически выделенного блока функционала у отдельного клиента [5].
Их совокупность, в некотором роде, являет собой открытую базу знаний — в том числе с точки зрения управленческих решений.
Функционал каждого бизнес-кейса работает и — что особенно важно — развивается в условиях реального живого бизнеса.
Каждый раз, когда новому клиенту требуется функционал отдельного бизнес-кейса или его группы, не входящий в инфраструктурный, актуальный код переносится из одного проекта в другой. Всякие сопутствующие ништяки типа естественного код-ревью подразумеваются, но не описываются в силу тривиальности.
В случае, если проекты находятся в ведении разных партнеров, коммуникация может быть поддержана Партнерским центром Ultima [6] — но, как правило, его вмешательство не требуется.
Вследствие молотковой простоты базовой конфигурации (ну, и средств разработки платформы [7], конечно) внешний функционал относительно легко интегрируется.
Некоторые усилия от разработчика, безусловно, требуются — но несравненно меньше, чем в случае реализации конфликтующего функционала.
В итоге:
Внешний функционал из бизнес-кейсов актуален в силу условий его существования — в противоположность “богатым базовым решениям”, в которые отдельно взятые участки кода могли попасть дремучее количество лет назад и окуклиться.
В работающем бизнесе функционал эволюционирует. В хорошо работающем — эволюционирует быстро, причем под влиянием огромного количества независимых акторов — сотрудников, а иногда и клиентов [9]. Когда изначально одинаковый функционал эволюционирует у разных клиентов различным образом [10] — на выходе получается богатейшая палитра решений различной эффективности для различных условий.
Никакой вендор никогда не сможет даже приблизиться к этому — по очевидным причинам принципиального характера.
P.S. Возвращаясь к началу — сетованиям автора статьи про 1С на, по его мнению, принципиальные пороки монолитности архитектуры.
Если кошек уметь готовить, монолитная архитектура — огого!
Автор: Rupper
Источник [11]
Сайт-источник PVSM.RU: https://www.pvsm.ru
Путь до страницы источника: https://www.pvsm.ru/programmirovanie/83530
Ссылки в тексте:
[1] статья про 1С: http://habrahabr.ru/post/244727/
[2] модульной схеме некоторых коллег, что на слуху: http://www.ultimaerp.com/library/modules_erp/
[3] В силу исторических причин : http://www.ultimabusinessware.com/history/
[4] платформы Ultima Businessware : http://www.ultimabusinessware.com
[5] бизнес-кейсов: результатов внедрения и эксплуатации логически выделенного блока функционала у отдельного клиента: http://www.ultimaerp.com/results/
[6] Партнерским центром Ultima: http://www.ultimapartnerscenter.com/
[7] средств разработки платформы: http://www.ultimabusinessware.com/why-devs/
[8] Решения Ultima: http://www.ultimaerp.com/
[9] а иногда и клиентов: http://www.ultimaerp.com/results/optimization/
[10] одинаковый функционал эволюционирует у разных клиентов различным образом: http://www.ultimaerp.com/results/strongly_personal/
[11] Источник: http://habrahabr.ru/post/250685/
Нажмите здесь для печати.