Буріданов осел і композиція конфігурації

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

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

Традиційно, спочатку домовимося про значення слів.
Всі відомі автору ERP системи логічно складаються з якоїсь «платформи» та реалізованого на ній прикладного коду — він називається «конфігурацією» (в 1С і у нас) або «рішенням».

Всі відомі автору вендори (і ми в тому числі) самостійно підтримують функціонал платформи і базової конфігурації\рішення.

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

Як у Лексуса коли-то: комплектація одна, вона ж максимальна

І перший час це було дуже добре — ми дуже швидко розгортали рішення. Однак з кожним новим клієнтом виникали нові проблеми.

Для розуміння — обсяг саме прикладного коду (тобто коду конфігурації\рішення) становив близько 15Мб.

При цьому обсяг коду конфігурації не був проблемою сам по собі.

Проблемою було поступове старіння базовій конфігурації.

У кожному новому впровадженні виникав новий функціонал. Переносити його в базову конфігурацію не представлялося можливим через конфлікт з раніше реалізованих функціоналом.

Як природний наслідок, базова конфігурація не збагачувалася і не актуалізувалася і поступово втрачала в споживчих властивостях.

З іншого боку, у процесі впровадження розгалужений широкий функціонал базового рішення as is ставав проблемою — більша його частина чергового внедряемому клієнту була абсолютно надлишкова, при цьому створення нових затребуваних або актуалізація старих функцій в силу складних взаємодій була невиправдано (з точки зору окремого експлуатанта) складною.

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

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

Аналогічні проблеми з впровадженнями — випливають природно і неминуче. Проблема, власне, добре описані у тій самій статті про 1С.

Марк Твен закликав: «Якщо ти опинився в більшості — гарненько задумайся».


При розробці другого покоління платформи ми відмовилися від зворотної сумісності, так що прикладної код в будь-якому випадку треба було писати з нуля.

І — сім бід-один відповідь — вирішили змінити підхід з «максимум» функціоналу на зворотний: minimum minimorum, дорогі читачі. Голота на вигадки хитра.

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

Для себе всередині ми його називаємо "інфраструктурний функціонал": довідники товарів, клієнтів, співробітників, фінансові документи, облік витрат, бюджетів, безготівкових платежів і т. п.

Такий функціонал якщо і застаріває, то вкрай неквапливо (у нашій практиці, істотних змін з 2004 року не виявлено).

Він і був включений в базову конфігурацію.

І тільки.

Для порівняння — для другого покоління платформи Ultima Businessware обсяг коду базової конфігурації — 2 Мб.

Плюси такого підходу для впроваджень та підтримки — неоціненні й очевидні.

Проте зникає перевага багатого функціоналу (реальне або вигадане — предмет окремого тексту, але з точки зору маркетингу «багатий функціонал» — безсумнівно плюс).

Проблему наявності «багатого функціоналу» ми вирішуємо через апарат бізнес-кейсів: результатів впровадження та експлуатації логічно виділеного блоку функціоналу у окремого клієнта.

Їх сукупність, в деякому роді, являє собою відкриту базу знань — в тому числі з точки зору управлінських рішень.

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

У випадку, якщо проекти перебувають у віданні різних партнерів, комунікація може бути підтримана Партнерським центром Ultima — але, як правило, його втручання не потрібна.

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

Деякі зусилля від розробника, безумовно, потрібні — але незрівнянно менше, ніж у разі реалізації конфліктує функціоналу.

У результаті:

  • Рішення Ultima легко підтримувати.
    У базовій конфігурації присутній виключно використовується функціонал.
    Немає «прикритого» функціоналу.
    Немає простирадлом налаштувань і перевірок.
  • Функціональність впроваджуваного рішення — завжди актуальна.
    «Инфрастуктурный» функціонал не старіє.

    Зовнішній функціонал з бізнес-кейсів актуальне в силу умов його існування — в протилежність до «багатим базовим рішень», які окремо взяті ділянки коду могли потрапити дрімуче кількість років тому і окуклиться.

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

    Ніякої вендор ніколи не зможе навіть наблизитися до цього — з очевидних причин принципового характеру.
P. S. Повертаючись до початку — нарікань автора статті про 1С, на його думку, принципові вади монолітності архітектури.
Якщо кішок вміти готувати, монолітна архітектура — огого!

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

0 коментарів

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