Моноліт чи цеглина?

Сьогодні трохи філософії про архітектуру програмних систем — монолітної або модульної. Коли і яка модульність корисна, завжди вона благо чи ні. Ну і більш предметно про ERP системи як близька нам тема.


Визначення.

Перш ніж роздмухувати полум'я спорів, необхідно домовитися про дефініції.

Монолітна система — програмний комплекс, який працездатний тільки в своїй єдиній конфігурації та обсяг програмного коду. Модульна система — програмний комплекс складається з незалежних самодостатніх програмних систем.

Визначення трохи віддає тавтологією, але і провести гранично чітку межу між модульними і монолітними системами неможливо. Хоча б тому, що і поняття програмного комплексу не має чіткого визначення. Якщо говорити термінами нечіткої логіки, то ймовірність, що система монолітна, зростає зі зменшенням числа зовнішніх інтерфейсів модулів і звернень до будь-яких зовнішніх систем. У свою чергу, система модульна чим більше число інтерфейсів присутні в системі.

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

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

    Можливо, на початку історії комп'ютерної техніки і були проблеми з розміщенням всієї програми на обладнанні, але такі проблеми зникли як клас. І зараз немає жодної проблеми розмістити весь програмний комплекс на обладнанні. Переваги поставки системи модулями очевидні для продавця, і зовсім не очевидні для покупця. Втім це кілька окрема тема, за нею відсилаю до нашої статті.
  • •Модульні системи легко підтримувати. Насправді в модульній системі легко створювати нові модулі. Однак модульні системи пасують, коли потрібна значна зміна функціоналу двох або більше взаємодіючих модулів. Слабка зв'язність стає проблемою не дозволяє тестувати на етапі компіляції.
У реаліях ERP систем маємо саме такий зразок — змінюється функціонал існуючих, інтенсивно взаємодіючих підсистем. Вартість порушення взаємодії вкрай висока.

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

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

Більш-менш сучасні, реально використовувані системи (створені після 1995-го року) мають монолітну архітектуру, або тяжіють до монолітної архітектурі.

Модульну архітектуру мають або системи, що носять експериментальний характер, або системи, які отримали модульну архітектуру в результаті низки поглинання і перетворення придбаних програмних систем в «модулі» системи. Такі системи, в підсумку, мають вельми витончений функціонал обміну повідомлення, перетворення інтерфейсів та інших механізмів реалізації взаємодії між модулями. З нашого досвіду складність зростає дуже швидко із зростанням числа модулів.

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

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

Як мінімум, ERP система повинна відображати реальний стан справ в компанії. Наприклад — скільки товару лежить на складі. Або скільки грошей на розрахунковому рахунку. Модульна система через слабо-зв'язності та ізольованості модулів швидко скочується до дублювання інформації. І далі до розбіжності показників.

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

Дані монолітних систем лежать в єдиній базі даних, для них виконуються всі правила посилальної цілісності, а зміна структури даних єдине для всієї системи. Тому ймовірність спотворення даних значно знижується, не кажучи вже появу декількох варіантів реальності.

Висновок.

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

P. S. Якщо кому цікаво, критичний погляд на проблематику модульності з точки зору експлуатанта.

Джерело: Хабрахабр

0 коментарів

Тільки зареєстровані та авторизовані користувачі можуть залишати коментарі.