Корпоративні автоматизовані системи зазвичай будуються за класичною трирівневою архітектурою, яка розділяє шари клієнта (вистави), логіки та зберігання даних. Такий підхід перевірено часом, але його головною проблемою є складність внесення змін, пов'язаних з модифікацією структури даних. У таких випадках доводиться вносити зміни в усі три шари, що на практиці найчастіше означає редагування структури бази даних, модифікацію коду серверної частини, сервісів для взаємодії з клієнтською частиною і самого клієнта. Актуально це і для систем, побудованих за мікросервісною архітектурою, де зміна структури даних може торкнутися відразу кількох сервісів.
Існує безліч інструментів і технік для внесення скоординованих змін у всі шари програми, але це в будь-якому випадку вимагає значних трудовитрат і сильно впливає на структуру процесів розробки і розгортання. Чи можна побудувати таку архітектуру автоматизованої системи, яка спростить і прискорить реалізацію змін, пов'язаних зі структурою даних?
Наш досвід створення подібних систем дозволяє говорити про те, що побудова автоматизованої системи навколо даних, а не логіки їх обробки, дозволяє досягти цієї мети. Пропонований підхід є втіленням ідеї дата-центричної архітектури на рівні конкретного додатку. Коротко описати наш підхід можна наступними тезами:
- дані існують самі по собі і не повинні залежати від автоматизованих систем, які з ними працюють, «» належати «» якійсь конкретній системі;
- структура даних так само мінлива, як і самі дані, і не повинна бути жорстко пов'язана з програмним кодом - код повинен бути готовий до зміни структури даних;
- логіку обробки даних бажано, наскільки можливо, відокремити від програмного коду і зробити налаштовуваною.
Уявімо, що в центрі архітектури автоматизованої системи знаходиться шар зберігання даних, який забезпечує такі функції:
- мульти-модельне зберігання структурованих даних у різних фізичних сховищах та абстрагування коду програми від деталей зберігання (віртуалізацію даних) шляхом надання універсального API для роботи з ними. Підкреслимо, що це протилежно технології ORM, яка, навпаки, пов'язує внутрішню структуру коду програми зі структурою даних у сховищі;
- програмний інтерфейс для зчитування та зміни структури даних;
- механізм повідомлень програмних компонентів про зміни в даних та їх структуру під час виконання програми (наприклад, підписка через менеджери черг);
- зберігання та надання через API історії зміни даних та їх структури (версійність), планування майбутніх змін у даних;
- вбудовані механізми контролю логічної цілісності даних та їх збагачення.
Програмний код, що реалізує логіку програми, при роботі з таким сховищем даних набуває важливих властивостей. Він не повинен містити класів ОВП, структура яких повторює структуру даних, тому що структура даних може змінитися по ходу роботи програми, і тим більше не повинен використовувати ORM, яка «» відливає в бетоні «» зв'язок між кодом і структурою даних. Замість цього код і сервіси обміну даними між компонентами повинні бути гранично абстрактними, готовими до зміни структури даних в певних межах. Це означає, що і логіка обробки конкретних типів об'єктів або їх властивостей повинна бути формалізована поза кодом і доступна для зміни під час виконання програми.
Для реалізації подібної архітектури необхідний механізм машинно-читаного подання структури даних і логіки їх обробки. На наш погляд, одним з найбільш відповідних для цього засобів є специфікації онтологічного моделювання RDF/RDFS/OWL. З точки зору цих специфікацій структура даних, самі дані та елементи логіки їх обробки технологічно однорідні, тобто можуть зберігатися і редагуватися одними і тими ж засобами.
Значна частина формального опису логіки виконання програми може бути перенесена з коду на рівень онтологічної моделі, виразних засобів якої достатньо для опису алгоритмів обчислень і збагачення даних (див., наприклад, специфікацію SHACL Advanced Features), правил перетворення даних, правил надання доступу, відображення візуального інтерфейсу та багато іншого. Явних обмежень тут немає, в онтологічній моделі можна уявити будь-яку частину логіки програми, зробивши усвідомлений вибір на користь гнучкості програми в обмін на підвищену складність розробки програмного коду, що інтерпретує таку модель.
Розгляньмо на прикладі, як може бути побудована робота програми з такою архітектурою. Нехай необхідно створити додаток для автоматизації звичайного бізнес-процесу, такого як відкриття магазину торгової мережі. Процес включає кілька стадій, на яких співробітники різних ролей виконують завдання підбору приміщення, узгодження та виконання його ремонту та оформлення, підбору персоналу та ін. Всі вони працюють з різними поданнями інформації про об'єкти одних і тих же типів, таких як приміщення, співробітник, підрядник, документ та ін. Під час виконання процесу інформація про конкретні об'єкти цих типів створюється, збагачується і трансформується. Потрібно побудувати додаток, який дозволить користувачам різної кваліфікації бачити тільки необхідні їм дані в списках і картках кожного об'єкта, відображати в системі результати виконання своїх завдань і передавати процес на наступні стадії.
Ядром створюваної системи буде онтологічна модель предметної області, в якій насамперед потрібно описати типи бізнес-об'єктів та їх властивості. Також вона буде включати модель самого бізнес-процесу, що описує його стадії, правила переходу між ними, властивості бізнес-об'єктів, значення яких заповнюються на кожній стадії процесу, набори типів прикріплюваних документів. Програмний код повинен інтерпретувати модель під час виконання і негайно реагувати на зміну складу даних, логіки їх обробки, правил візуального подання.
Всі ці елементи будуть редагуватися аналітиками через редактор онтології, і в машинно-читаному вигляді будуть доступні програмному коду через API платформи віртуалізації даних. В якості API для взаємодії компонентів програми з платформою віртуалізації даних і між собою може використовуватися, наприклад, GraphQL - з урахуванням того, що структура типів сутностей, зв'язків і властивостей описана в онтології і може змінюватися.
Тепер уявімо, що бізнес-процес змінився через появу нових нормативних вимог - наприклад, необхідно проходити ще один вид погоджень, що супроводжується оформленням документів нових типів. Для внесення змін до автоматизованої системи достатньо створити в онтологічній моделі опис нового кроку процесу, правила переходу до нього, нові типи документів, їх можливі зв'язки з об'єктами інших типів, правила відображення в користувацькому інтерфейсі. Всі ці зміни можна запланувати до набуття чинності в певний момент за допомогою функцій платформи віртуалізації даних. У призначений час програмні компоненти отримають від платформи повідомлення про зміну структури даних і правил їх обробки, і повинні будуть негайно змінити логіку своєї роботи. Це не потребує ні оновлення коду компонентів, ні навіть перезапуску програми. Зміни в модель будуть вносити не програмісти, а аналітики - майже як в Low code платформах, тільки в більш загальному/стандартному вигляді і без прив'язки до пропріетарного рішення. В результаті реалізація, налагодження і доставка змін потребують менше часу і ресурсів, ніж при класичному підході.
Ми не наполягаємо на тому, щоб повністю виключити з коду програми будь-яку прив'язку до предметної області. Якщо якісь типи об'єктів можна вважати «» константами «» для даного бізнес-процесу, як, наприклад, сутність «» магазин «» для процесу відкриття магазину - згадка цих сутностей в коді не порушить стрункості підходу. Однак додаток повинен бути готовий до появи нових підкласів цих сутностей, що мають різні властивості (наприклад, у магазинів різних форматів набір властивостей може відрізнятися), нових властивостей і зв'язків, зміни логіки їх обробки.
Які переваги забезпечить пропонована архітектура та інструментарій?
- Можна змінювати поведінку системи, структуру даних та логіку їх обробки без оновлення програмного коду та перезапуску програми.
- Більшу частину змін в роботу системи будуть вносити аналітики, а не програмісти.
- Можливість включення об'єкта одночасно в декілька класів (віднесення об'єкта до декількох типів) і можливість виділення підкласів об'єктів, які забезпечує онтологічне моделювання, забезпечують гнучкість формування наборів властивостей об'єктів. Так, одна і та ж фізична особа на різних стадіях процесу може розглядатися як кандидат, контактна особа з боку зовнішнього контрагента, співробітник, керівник, власник та ін., причому кожному з цих статусів відповідає особливий набір застосовних властивостей і відносин з об'єктами інших типів.
- Сервіси в мікросервісній архітектурі зможуть скоротити витрати ресурсів на обробку і передачу даних, оскільки будуть працювати з даними в загальному сховищі.
Все це в цілому знизить витрати на розробку і вартість володіння системою, підвищить швидкість надання корисних функцій бізнес-користувачам, незважаючи на те, що витрати на початкове створення універсального коду зростуть, а проектуванню онтологічної моделі доведеться приділити істотну увагу.
Найбільш яскраво переваги підходу проявляться при створенні аналітичних систем, а також додатків, що працюють з даними дуже складної і мінливої структури, таких як ПО ситуаційних центрів. Тим не менш, зрозуміло, запропонована архітектура - лише один з можливих варіантів вирішення подібних завдань. У кожному конкретному випадку необхідно вибирати найбільш відповідний варіант виходячи з прогнозу частоти і масштабу передбачуваних змін вимог до системи, які вимагатимуть зміни структури даних і логіки їх обробки.
Створивши додаток за описаними принципами, ми виявимо, що відкрили шлях до реалізації повноцінної дата-центричної архітектури підприємства, в якій безліч додатків одночасно працюють з одним і тим же набором інформації, що знаходиться під управлінням платформи віртуалізації даних. Це дозволить забути про проблеми з інтеграцією і зосередитися на реалізації корисних функцій додатків. Зокрема, відкриється можливість створення мікро-фронт-ендів для швидкого вирішення завдань користувачів без ускладнення ІТ-архітектури підприємства, створення зайвих копій наборів даних та інтеграційних процедур.