Сегодня немного философии про архитектуру программных систем — монолитной или модульной. Когда и какая модульность полезна, всегда ли она благо или нет. Ну и более предметно про ERP системы как близкая нам тема.
Определения.
Прежде чем раздувать пламя споров, необходимо договориться о дефинициях.
Монолитная система — программный комплекс, который работоспособен только в своей единственной конфигурации и объеме программного кода. Модульная система — программный комплекс состоящий из независимых самодостаточных программных систем.
Определение немного отдает тавтологией, но и провести предельно четкую границу между модульными и монолитными системами невозможно. Хотя бы потому, что и понятие программного комплекса не имеет четкого определения. Если говорить терминами нечеткой логики, то вероятность, что система монолитна, растет с уменьшением числа внешних интерфейсов модулей и обращений к любым внешним системам. В свою очередь, система более модульная чем большее число интерфейсов присутствует в системе.
Монолитные системы так же отличаются изолированностью — данные модулей доступны только модулям-владельцам, остальные модули получают информацию через внешние интерфейсы. В случае с ERP системами это означает разделение данных модулей вплоть до различных СУБД для каждого модуля.
Разобравшись с определениями переходим к тезисам.
В реалиях ERP систем имеем как раз такой образчик — меняется функционал существующих, интенсивно взаимодействующих подсистем. Стоимость нарушения взаимодействия крайне высока.
ERP системы, одни из самых сложных программных систем, созданных человечеством (еще операционки, игры, гугл и фейсбук) имеют потребность меняться вместе с изменением бизнес-процессов, что заставляет их меняться быстрее чем прочие программные системы. Именно поэтому, модульные системы начинают сильно страдать от накапливающихся изменений в протоколах обмена из-за отсутствия формальных механизмов контроля качества.
Подводя итог, имеем — модульные системы отличное архитектурное решение для стабилизированного приложения, в стабильном окружении, где требуется только увеличение функционала системы, в виде создания НОВЫХ функций.
Более-менее современные, реально используемые системы (созданные после 1995-го года) имеют монолитную архитектуру, или тяготеют к монолитной архитектуре.
Модульную архитектуру имеют либо системы, носящие экспериментальный характер, либо системы, которые получили модульную архитектуру в итоге череды поглощений и преобразовании купленных программных систем в “модули” системы. Такие системы, в итоге, имеют весьма изощренный функционал обмена сообщения, преобразования интерфейсов и прочих механизмов реализации взаимодействия между модулями. По нашему опыту сложность растет очень быстро с ростом числа модулей.
Не так давно один из коллег в статье сетовал на отсутствие модульности в 1С. Не думаю что разработчики 1С порадовались бы обилию всевозможных проверок о наличии того или иного модуля. Порадовались бы только компании, поддерживающие 1С что теперь надо настраивать не одну программу, а сразу несколько модулей, да еще и некий middle-ware их интеграции.
Перейдем к особенностям модульных ERP-систем где модулями являются бухгалтерия, склад, управление финансами, сотрудниками и т.п.
Как минимум, ERP система должна отражать реальное положение дел в компании. Например — сколько товара лежит на складе. Или сколько денег на расчетном счете. Модульная система ввиду слабо-связанности и изолированности модулей быстро скатывается к дублированию информации. И далее к расхождению показателей.
Например — складской модуль списывает 10 штук товара со склада. Финансовый модуль должен списать их стоимость своей отдельной операцией. Однако, в процессе работы, возникают вроде незначительные события — отказ канала, изменение в протоколе обмена. По прошествии некоторого времени оказывается, что товара на складе нет — ноль штук, а в данных финансового модуля этого товара на складе лежит на сто рублей. В итоге, появляется специальная коррекция в финансовом модуле, и далее, такие ошибки распространяются по системе. В монолитных системах списание со склада — единая операция (в нашем случае — единая запись) о движении денег и единиц товара, что значительно повышает достоверность данных.
Данные монолитных систем лежат в единой базе данных, для них выполняются все правила ссылочной целостности, а изменение структуры данных едино для всей системы. Поэтому вероятность искажения данных значительно снижается, не говоря уже появлении нескольких вариантов реальности.
В заключение.
Среди разработчиков (как впрочем и среди любых людей и даже у птиц существует много иррациональных предубеждений. Среди них — об архитектуре программных систем, что модульность и слабо-связанность лучше монолитности. Как сущность.
P.S. Если кому интересно, критический взгляд на проблематику модульности с точки зрения эксплуатанта.
Определения.
Прежде чем раздувать пламя споров, необходимо договориться о дефинициях.
Монолитная система — программный комплекс, который работоспособен только в своей единственной конфигурации и объеме программного кода. Модульная система — программный комплекс состоящий из независимых самодостаточных программных систем.
Определение немного отдает тавтологией, но и провести предельно четкую границу между модульными и монолитными системами невозможно. Хотя бы потому, что и понятие программного комплекса не имеет четкого определения. Если говорить терминами нечеткой логики, то вероятность, что система монолитна, растет с уменьшением числа внешних интерфейсов модулей и обращений к любым внешним системам. В свою очередь, система более модульная чем большее число интерфейсов присутствует в системе.
Монолитные системы так же отличаются изолированностью — данные модулей доступны только модулям-владельцам, остальные модули получают информацию через внешние интерфейсы. В случае с ERP системами это означает разделение данных модулей вплоть до различных СУБД для каждого модуля.
Разобравшись с определениями переходим к тезисам.
- Плюсом модульной системы считается возможность наращивать функционал системы добавлением новых модулей.
Что это означает на самом деле? Что получатель системы получает систему частями.
Возможно, в начале истории компьютерной техники и были проблемы с размещением всей программы на оборудовании, но такие проблемы исчезли как класс. И сейчас нет никакой проблемы разместить весь программный комплекс на оборудовании. Преимущества поставки системы модулями очевидны для продавца, и совершенно не очевидны для покупателя. Впрочем это несколько отдельная тема, за ней отсылаю к нашей статье.
- •Модульные системы легко поддерживать. На самом деле в модульной системе легко создавать новые модули. Однако модульные системы пасуют, когда требуется значительное изменение функционала двух или более взаимодействующих модулей. Слабая связность становится проблемой не позволяющей тестировать на этапе компиляции.
В реалиях ERP систем имеем как раз такой образчик — меняется функционал существующих, интенсивно взаимодействующих подсистем. Стоимость нарушения взаимодействия крайне высока.
ERP системы, одни из самых сложных программных систем, созданных человечеством (еще операционки, игры, гугл и фейсбук) имеют потребность меняться вместе с изменением бизнес-процессов, что заставляет их меняться быстрее чем прочие программные системы. Именно поэтому, модульные системы начинают сильно страдать от накапливающихся изменений в протоколах обмена из-за отсутствия формальных механизмов контроля качества.
Подводя итог, имеем — модульные системы отличное архитектурное решение для стабилизированного приложения, в стабильном окружении, где требуется только увеличение функционала системы, в виде создания НОВЫХ функций.
Более-менее современные, реально используемые системы (созданные после 1995-го года) имеют монолитную архитектуру, или тяготеют к монолитной архитектуре.
Модульную архитектуру имеют либо системы, носящие экспериментальный характер, либо системы, которые получили модульную архитектуру в итоге череды поглощений и преобразовании купленных программных систем в “модули” системы. Такие системы, в итоге, имеют весьма изощренный функционал обмена сообщения, преобразования интерфейсов и прочих механизмов реализации взаимодействия между модулями. По нашему опыту сложность растет очень быстро с ростом числа модулей.
Не так давно один из коллег в статье сетовал на отсутствие модульности в 1С. Не думаю что разработчики 1С порадовались бы обилию всевозможных проверок о наличии того или иного модуля. Порадовались бы только компании, поддерживающие 1С что теперь надо настраивать не одну программу, а сразу несколько модулей, да еще и некий middle-ware их интеграции.
Перейдем к особенностям модульных ERP-систем где модулями являются бухгалтерия, склад, управление финансами, сотрудниками и т.п.
Как минимум, ERP система должна отражать реальное положение дел в компании. Например — сколько товара лежит на складе. Или сколько денег на расчетном счете. Модульная система ввиду слабо-связанности и изолированности модулей быстро скатывается к дублированию информации. И далее к расхождению показателей.
Например — складской модуль списывает 10 штук товара со склада. Финансовый модуль должен списать их стоимость своей отдельной операцией. Однако, в процессе работы, возникают вроде незначительные события — отказ канала, изменение в протоколе обмена. По прошествии некоторого времени оказывается, что товара на складе нет — ноль штук, а в данных финансового модуля этого товара на складе лежит на сто рублей. В итоге, появляется специальная коррекция в финансовом модуле, и далее, такие ошибки распространяются по системе. В монолитных системах списание со склада — единая операция (в нашем случае — единая запись) о движении денег и единиц товара, что значительно повышает достоверность данных.
Данные монолитных систем лежат в единой базе данных, для них выполняются все правила ссылочной целостности, а изменение структуры данных едино для всей системы. Поэтому вероятность искажения данных значительно снижается, не говоря уже появлении нескольких вариантов реальности.
В заключение.
Среди разработчиков (как впрочем и среди любых людей и даже у птиц существует много иррациональных предубеждений. Среди них — об архитектуре программных систем, что модульность и слабо-связанность лучше монолитности. Как сущность.
P.S. Если кому интересно, критический взгляд на проблематику модульности с точки зрения эксплуатанта.