Pull to refresh
0
Rating

Монолит или кирпич?

Ultima corporate blog ERP-systems *
Сегодня немного философии про архитектуру программных систем — монолитной или модульной. Когда и какая модульность полезна, всегда ли она благо или нет. Ну и более предметно про ERP системы как близкая нам тема.


Определения.

Прежде чем раздувать пламя споров, необходимо договориться о дефинициях.

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

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

Монолитные системы так же отличаются изолированностью — данные модулей доступны только модулям-владельцам, остальные модули получают информацию через внешние интерфейсы. В случае с ERP системами это означает разделение данных модулей вплоть до различных СУБД для каждого модуля.

Разобравшись с определениями переходим к тезисам.
  • Плюсом модульной системы считается возможность наращивать функционал системы добавлением новых модулей.
    Что это означает на самом деле? Что получатель системы получает систему частями.

    Возможно, в начале истории компьютерной техники и были проблемы с размещением всей программы на оборудовании, но такие проблемы исчезли как класс. И сейчас нет никакой проблемы разместить весь программный комплекс на оборудовании. Преимущества поставки системы модулями очевидны для продавца, и совершенно не очевидны для покупателя. Впрочем это несколько отдельная тема, за ней отсылаю к нашей статье.
  • •Модульные системы легко поддерживать. На самом деле в модульной системе легко создавать новые модули. Однако модульные системы пасуют, когда требуется значительное изменение функционала двух или более взаимодействующих модулей. Слабая связность становится проблемой не позволяющей тестировать на этапе компиляции.

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

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

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

Более-менее современные, реально используемые системы (созданные после 1995-го года) имеют монолитную архитектуру, или тяготеют к монолитной архитектуре.

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

Не так давно один из коллег в статье сетовал на отсутствие модульности в 1С. Не думаю что разработчики 1С порадовались бы обилию всевозможных проверок о наличии того или иного модуля. Порадовались бы только компании, поддерживающие 1С что теперь надо настраивать не одну программу, а сразу несколько модулей, да еще и некий middle-ware их интеграции.

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

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

Например — складской модуль списывает 10 штук товара со склада. Финансовый модуль должен списать их стоимость своей отдельной операцией. Однако, в процессе работы, возникают вроде незначительные события — отказ канала, изменение в протоколе обмена. По прошествии некоторого времени оказывается, что товара на складе нет — ноль штук, а в данных финансового модуля этого товара на складе лежит на сто рублей. В итоге, появляется специальная коррекция в финансовом модуле, и далее, такие ошибки распространяются по системе. В монолитных системах списание со склада — единая операция (в нашем случае — единая запись) о движении денег и единиц товара, что значительно повышает достоверность данных.

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

В заключение.

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

P.S. Если кому интересно, критический взгляд на проблематику модульности с точки зрения эксплуатанта.
Tags:
Hubs:
Total votes 6: ↑5 and ↓1 +4
Views 6.7K
Comments Comments 8

Information

Founded
Location
Россия
Website
www.ultimaerp.com
Employees
51–100 employees
Registered