Від COBOL, Fortran, Clipper, dBase, «Delphi», «RAD Studio» та 1С/BAS до Python, TypeScript, хмарних платформ і штучного інтелекту. Чому технологічна еволюція неминуча, скільки вона коштує та як українська K2 ERP допомагає створювати нове покоління програмних продуктів, не починаючи все з нуля.

Програми можуть жити довше за своїх розробників

Десь у світі досі працює банківська система, окремі частини якої були написані на COBOL багато десятиліть тому. Десь промислове підприємство використовує програму на Fortran, яка продовжує виконувати складні інженерні розрахунки. А десь у невеликій компанії працює складський облік на FoxPro або dBase, створений ще тоді, коли комп’ютери були великими, монітори маленькими, а інтернет для більшості людей існував лише в науково-фантастичних фільмах.

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

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

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

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

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

І ця проблема абсолютно міжнародна. Вона однаково актуальна для американського розробника фінансової системи на COBOL, німецької компанії з виробничим програмним забезпеченням на «Delphi», французького інтегратора зі старою системою на Oracle Forms, японського підприємства з власними промисловими застосунками або українського бізнесу, який десятиліттями використовує 1С/BAS.

Світ накопичив величезний обсяг програмного забезпечення, яке створювалося в різні технологічні епохи. І далеко не всі ці продукти були своєчасно модернізовані.

Як чудові технології поступово перетворюються на обмеження

У 1980–1990-х роках поява персональних комп’ютерів і таких технологій, як dBase, Clipper, FoxPro та формат DBF, відкрила нову еру автоматизації. Підприємствам більше не потрібно було купувати дорогі великі обчислювальні системи для відносно простих облікових задач. Програміст міг створити бухгалтерію, склад, зарплату або систему управління замовленнями на звичайному комп’ютері.

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

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

Подібна історія відбувалася з величезною кількістю інших технологій. Visual Basic, Microsoft Access, старі клієнт-серверні програми на PowerBuilder, Oracle Forms та різноманітні власні середовища розробки дозволили створити серйозні корпоративні продукти. Частина з них працює й сьогодні, оскільки вирішує реальні бізнес-задачі.

Особливе місце в Східній Європі та країнах колишнього СРСР посіли 1С 7.7, а згодом 1С 8 і BAS. Перша була типовим представником своєї технологічної епохи, хоча мала й SQL-варіанти роботи. Новіші покоління отримали клієнт-серверну архітектуру, вебклієнт, кластеризацію й значно ширші можливості. Проте їхні розробники та користувачі залишилися залежними від спеціалізованої платформи, власної мови програмування, механізмів конфігурації й розвитку технологічного постачальника.

Це не означає, що на 1С 8 або BAS неможливо створити велику корпоративну систему. Можливо, і таких прикладів чимало. Але коли з’являється потреба в іншій архітектурі, незалежній моделі ліцензування, нових інструментах AI-розробки або радикальній зміні технологічної основи, накопичена залежність починає суттєво впливати на вартість розвитку.

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

Саме тут виникає парадокс. Чим успішнішим був продукт, чим більше клієнтів він отримав і чим більше функцій накопичив, тим складніше його повністю модернізувати.

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

Але є технологія, історію якої ми знаємо особливо добре.

«Delphi» та «RAD Studio»: прекрасна ідея, якій стало тісно у світі вебтехнологій

Для мене «Delphi» — особлива технологія. Після Clipper, DBF, DOS і текстових інтерфейсів поява повноцінного візуального середовища розробки виглядала майже фантастикою. Програміст міг розмістити на формі компоненти, підключити базу даних, написати декілька обробників подій — і отримати справжню Windows-програму.

Візуальне програмування, об’єктноорієнтована архітектура, бібліотека компонентів VCL, компіляція у машинний код і зручні засоби роботи з даними зробили «Delphi» одним із найцікавіших інструментів свого часу. В окремих задачах один досвідчений програміст міг створювати прикладні рішення швидше за цілу команду, яка працювала з менш зручними технологіями.

Ми самі пройшли цей шлях і багато років використовували «Delphi» для створення корпоративних систем. Причому ще на початку 2000-х років у нашій системі «Корпорація» ми реалізували власне IDE-середовище, яке дозволяло програмувати прикладні рішення «Корпорації 2».

Це була не просто можливість змінити розташування кнопок на формі. Ми створили вбудоване середовище програмування з Pascal-подібною скриптовою мовою, яке дозволяло розвивати прикладну логіку без необхідності щоразу перекомпілювати основний застосунок.

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

Цей досвід виявився надзвичайно цінним для подальшого розвитку K2 ERP.

Чому «Delphi» втратила колишнє лідерство

Історія самої «Delphi» склалася непросто. Компанія Borland, яка створила цей продукт, пережила фінансові та стратегічні труднощі. У 2006 році напрям інструментів розробки було виділено в CodeGear, а у 2008 році продано Embarcadero Technologies. У 2009 році сама Borland була придбана Micro Focus.

Поки компанії змінювали структуру, власників і стратегічні пріоритети, світ програмування розвивався шаленими темпами. Java, C#, PHP, JavaScript, Python, а згодом TypeScript, сучасні вебфреймворки, хмарні платформи та відкриті бібліотеки поступово змінювали уявлення про те, як потрібно створювати програмне забезпечення.

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

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

Звичайно, сучасна «RAD Studio» продовжує розвиватися. І варто уточнити: «RAD Studio» — це комплексне середовище, яке включає «Delphi» та «C++Builder», а не просто нова назва мови Delphi.

Сьогодні доступні підтримка різних операційних систем, FireMonkey, засоби серверної розробки, інтеграцій, вебтехнологій та AI-інструменти. Проте наявність цих можливостей у нових версіях не означає, що десятиліттями створювані VCL-системи автоматично стали сучасними веборієнтованими продуктами.

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

«Lazarus» і «Free Pascal»: Pascal виявився напрочуд живучим

Окремої уваги заслуговують незалежні відкриті проєкти «Free Pascal» та «Lazarus». Вони довели, що хороші технологічні ідеї можуть продовжувати життя поза межами однієї комерційної компанії.

«Free Pascal» — відкритий компілятор Pascal/Object Pascal, який підтримує різні операційні системи та процесорні архітектури. «Lazarus» — безкоштовне кросплатформне RAD-середовище з візуальним дизайнером форм і бібліотекою компонентів. За їх допомогою можна створювати застосунки для Windows, Linux, macOS та інших підтримуваних середовищ.

У певному сенсі ці проєкти підхопили й продовжили ідеї, які колись зробили «Delphi» популярною. Особливо цікаво, що «Lazarus» можна використовувати як середовище розробки безпосередньо під Linux або macOS, тоді як IDE «RAD Studio» залишається Windows-орієнтованим.

Можна пожартувати, що Pascal уже стільки разів проводжали на пенсію, що він, мабуть, навчився самостійно оформлювати документи на повторне працевлаштування. І, судячи з розвитку «Lazarus», зробив це цілком успішно.

Втім, кросплатформна компіляція не розв’язує автоматично всіх архітектурних проблем. Великий застосунок, написаний на VCL із численними Windows-залежностями, не завжди можна перенести до «Lazarus» простим натисканням кнопки. Потрібні адаптація компонентів, перегляд інтерфейсів, тестування та іноді значне переписування.

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

Кросплатформеність: світ давно перестав обмежуватися Windows

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

Сьогодні ситуація зовсім інша. Керівник може використовувати MacBook, бухгалтер працювати на Windows, серверна інфраструктура — під Linux, складські працівники — з Android-терміналами, менеджери — з iPhone, а виробниче обладнання — під спеціалізованими операційними системами.

І всі ці пристрої повинні працювати з одними бізнес-процесами та взаємодіяти між собою.

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

Іноді компанія витрачає декілька місяців, щоб перенести старий десктопний продукт на Linux або macOS. А клієнт, побачивши результат, ставить цілком природне запитання: «Чудово. А можна тепер просто відкрити це в браузері?»

Саме тому для багатьох корпоративних систем більш перспективною стала вебархітектура. Прикладна логіка виконується на сервері, а користувацький інтерфейс працює через браузер. Незалежно від того, чи використовує людина Windows, Linux, macOS, Android або iOS, вона отримує доступ до однієї інформаційної системи.

Звичайно, браузер не розв’язує абсолютно всіх проблем. Потрібно враховувати адаптивність інтерфейсів, мобільні сценарії, доступ до обладнання, офлайн-роботу та обмеження конкретних платформ. Але для величезної кількості бізнес-задач він дозволяє значно скоротити складність розробки та супроводу.

І тут виникає ще одна цікава особливість сучасного програмного забезпечення: далеко не кожному програмному компоненту взагалі потрібен графічний інтерфейс.

А якщо користувач вашої програми — робот?

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

ERP отримує замовлення клієнта, WMS визначає місце зберігання товару й формує завдання на переміщення. Робот отримує команду доставити контейнер до зони відвантаження, виконує операцію та передає результат: завдання завершено, вантаж доставлено, залишок заряду акумулятора — 65%.

Усе це відбувається без жодної Windows-форми, меню чи кнопки «Зберегти». Роботу не потрібно показувати таблицю з переліком товарів і просити його натиснути «ОК». Йому достатньо структурованого завдання, відповідного програмного інтерфейсу та можливості передати результат.

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

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

Наприклад, ROS 2 — відкрита екосистема для робототехніки — дозволяє створювати програмні компоненти на Python та C++, які обмінюються повідомленнями, отримують інформацію від сенсорів і взаємодіють з обладнанням.

При цьому для низькорівневого керування двигунами, критичних процесів реального часу та фізичної безпеки потрібні спеціалізовані контролери й відповідні технології. Python не повинен замінювати їх там, де це недоцільно. Але для логіки завдань, координації, обробки даних, AI, інтеграцій та автоматизації він є надзвичайно зручним інструментом.

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

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

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

Безпека, масштабування й самообслуговування: вимоги, про які раніше майже не думали

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

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

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

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

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

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

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

Окремою вимогою стало самообслуговування. Сучасний користувач не хоче звертатися до програміста щоразу, коли потрібно додати нове поле до картки товару, змінити друковану форму або побудувати управлінський звіт.

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

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

Python і TypeScript: технологічна основа нового покоління програм

Чому сьогодні для нових корпоративних платформ дедалі частіше обирають Python, TypeScript, сучасні вебфреймворки та відкриті бази даних?

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

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

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

Важливо, що ці технології не прив’язують програміста до однієї закритої мови конкретного ERP-виробника. Розробник може використовувати стандартні IDE, Git, інструменти тестування, CI/CD, бібліотеки, документацію та сучасних AI-асистентів.

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

Python як мова розширень: підхід, перевірений світовими розробниками

Ідея використання Python як скриптової мови всередині програмних продуктів далеко не нова. Багато відомих систем мають високопродуктивне ядро, створене на C, C++ або інших технологіях, але відкривають свої можливості через Python API.

Це дозволяє стороннім розробникам створювати доповнення, власні інструменти, сценарії автоматизації та спеціалізовані функції без необхідності змінювати або перекомпілювати основний продукт.

Ось приклади відомих систем, які використовують Python для розширення функціональності.

Програмний продукт	Призначення	Використання Python
Blender	3D-моделювання та анімація	Вбудовані скрипти, Python API, створення плагінів, генерація моделей, автоматизація
Autodesk Maya	3D-анімація, кіно, ігри	Python API, сценарії автоматизації, інструменти моделювання
Autodesk 3ds Max	Архітектурна візуалізація та 3D	Python-скрипти, керування сценами, автоматизація операцій
Autodesk Fusion	CAD/CAM та конструювання	Python API, сценарії та доповнення для автоматизації проєктування
FreeCAD	Інженерне 3D-проєктування	Python-консоль, макроси, додаткові модулі, параметричне моделювання
QGIS	Геоінформаційні системи	PyQGIS, Python-консоль, плагіни, географічні розрахунки
Houdini	Візуальні ефекти та процедурна графіка	Python API, створення інструментів, автоматизація сцен
Ansys Mechanical	Інженерні розрахунки	Python-скрипти для автоматизації моделей та аналізу
Abaqus	Моделювання фізичних процесів	Python Scripting Interface для автоматизації розрахунків
LibreOffice	Офісні документи	Python-макроси, автоматизація документів через UNO API
Scribus	Верстка та поліграфія	Python-сценарії для автоматизації підготовки документів
GIMP	Редагування зображень	Python-плагіни та автоматизація графічних операцій
Calibre	Управління електронними книгами	Python-компоненти, плагіни, робота з метаданими
Microsoft Power BI	Бізнес-аналітика	Запуск зовнішніх Python-скриптів для обробки й візуалізації даних

У цих продуктах застосовуються різні моделі інтеграції: вбудовані інтерпретатори, API, зовнішні сценарії, макроси або плагіни. Наприклад, Blender має вбудований Python-інтерпретатор, тоді як Power BI використовує окремо встановлене середовище Python. Calibre сама значною мірою побудована на Python. Проте спільний принцип однаковий: користувач може програмно розширювати можливості готової системи.

Особливо показовий приклад Blender. Розробникам не потрібно щоразу змінювати ядро графічного редактора, щоб створити новий інструмент, генератор об’єктів або спеціалізований імпортер. Значну частину такої функціональності можна реалізувати на Python через підтримувані програмні інтерфейси.

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

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

Але для створення ERP одного Python недостатньо. Потрібні інструменти роботи з даними, формами, звітами, користувачами, документами, бізнес-процесами, оновленнями й багатьма іншими типовими елементами.

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

K2 ERP (Україна): понад тридцять років технологічної еволюції

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

У 1990-х роках створювали програми для бухгалтерії, зарплати, складів та інших завдань на Clipper і DBF. Згодом перейшли на Pascal і «Delphi», розробляли Windows-застосунки, клієнт-серверні системи та власні інструменти швидкого програмування.

Уже на початку 2000-х років у системі «Корпорація» ми створили IDE-середовище з вбудованою скриптовою мовою, яке дозволяло розробляти прикладні рішення на технологічній основі нашого продукту.

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

Саме з цього розвитку виникла «Корпорація 2», скорочено K2. Надалі назва стала самостійним брендом, а система еволюціонувала від великих прикладних рішень до модульної ERP-платформи.

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

Згодом ми дійшли до необхідності нового архітектурного переходу — створення платформи на Python, TypeScript, Vue та PostgreSQL.

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

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

Причому головна цінність полягає не тільки у використанні Python і TypeScript, а в тому, що значна частина технологічної інфраструктури вже створена.

K2 ERP: як підняти можливості Python на новий рівень

Уявімо компанію, яка вирішила розробити власну ERP на Python. Вона наймає програмістів, обирає PostgreSQL, створює API, використовує Vue або інший frontend-фреймворк. На перший погляд усе виглядає цілком логічно.

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

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

Саме тут K2 ERP (Україна) дозволяє суттєво скоротити шлях.

ER-моделі та візуальне проєктування даних

У K2 розвиваються засоби опису структури даних за допомогою ER-моделей. Розробник може працювати із сутностями, їхніми полями, характеристиками, зв’язками та іншими елементами бізнес-моделі.

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

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

У K2 для цього застосовуються декларативні описи, зокрема YML, а також ORM-моделі та механізми міграцій. Візуальні інструменти ER-моделювання продовжують розвиватися, щоб ще більше скоротити обсяг ручного програмування.

BP-моделі: бізнес-процеси повинні бути зрозумілими

Інша важлива частина ERP — бізнес-процеси. Замовлення, закупівля, погодження договору, виробнича операція або сервісна заявка можуть проходити десятки етапів, взаємодіяти з різними підрозділами та залежати від великої кількості умов.

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

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

Ми розвиваємо такі засоби в K2, використовуючи сучасні вебтехнології та TypeScript. Ідея полягає в тому, щоб поступово переходити від ручного програмування кожної типової операції до керованих моделей та повторно використовуваних компонентів.

Компоненти, форми, таблиці та звіти

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

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

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

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

Метадані та незалежність від конкретного IDE

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

Це відкриває можливість використовувати Git, сучасні IDE, інструменти перевірки коду та AI-асистентів. При цьому розробник не зобов’язаний працювати лише в одному спеціалізованому редакторі.

Він може використовувати Visual Studio Code, PyCharm, WebStorm, Cursor, інші редактори та засоби розробки, які відповідають його потребам. Такий підхід принципово відрізняється від платформ, де прикладний код можна змінювати тільки через власний закритий конфігуратор.

Хмари, компоненти та система оновлення

K2 ERP розвивається як гібридна платформа. Вона може використовуватися в хмарному середовищі, на власних серверах підприємства, у партнерських інсталяціях та в інших підтримуваних інфраструктурних сценаріях.

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

Окремим напрямом є обмін метаданими, звітами, налаштуваннями та компонентами між інсталяціями. Якщо програміст створив корисний модуль для одного підприємства, немає сенсу повторно розробляти його для кожного наступного клієнта.

Система K2 Update дозволяє організовувати постачання оновлень, виправлень і компонентів. У перспективі вона може стати основою повноцінного маркетплейсу прикладних модулів, створених не тільки командою K2, а й незалежними розробниками та партнерами.

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

Штучний інтелект: наступна технологічна революція вже почалася

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

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

І саме тут популярність Python та TypeScript створює додаткову перевагу. Ці мови широко представлені в сучасних інструментах розробки, навчальних матеріалах, бібліотеках і програмних репозиторіях. AI може працювати зі стандартними структурами коду, форматами даних та відомими інструментами.

У K2 розвиток метаданих, ER- і BP-моделей, програмних компонентів та декларативних описів створює можливість використовувати AI не лише для написання окремих функцій, а й для автоматизації створення цілих частин прикладних рішень.

Наприклад, розробник описує новий модуль сервісного обслуговування. AI допомагає підготувати структуру сутностей, YML-описи, програмні моделі, заготовки форм, SQL-запити та інші компоненти. Після цього програміст перевіряє логіку, доповнює алгоритми та інтегрує модуль у систему.

Це зовсім інший рівень автоматизації порівняно з традиційним ручним створенням усіх програмних елементів.

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

І саме тому сучасна технологічна платформа повинна бути придатною до таких змін.

Від ERP до єдиної платформи управління підприємством

Ще одна тенденція полягає в тому, що традиційні межі між різними категоріями корпоративних систем поступово стираються.

ERP, CRM, WMS, HR, LMS, документообіг, управління проєктами, технічне обслуговування обладнання та бізнес-аналітика часто обслуговують взаємопов’язані процеси.

Наприклад, клієнт створює замовлення. CRM зберігає інформацію про взаємодію з клієнтом, ERP перевіряє комерційні умови, WMS організовує складську операцію, виробнича система планує виготовлення, а бухгалтерія відображає фінансовий результат. Якщо обладнання виходить із ладу, система ТОІР створює завдання на його обслуговування.

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

Саме тому K2 розвивається як екосистема взаємопов’язаних компонентів і модулів. Бухгалтерія, зарплата та HR, CRM, WMS, виробництво, управління проєктами, документообіг, LMS, ТОІР, CMS, електронна комерція, комунікації й аналітика можуть використовувати спільні механізми платформи.

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

І таким чином виникає можливість створювати нові галузеві продукти значно швидше, ніж якби кожен розробник починав із побудови власної платформи.

Найдорожче в переході на нові технології — не програмний код

Коли компанія вирішує переписати ERP на новій технологічній основі, перша думка зазвичай стосується вартості програмістів.

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

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

За десятиліття розробки в ERP з’являються тисячі особливостей: алгоритми собівартості, розрахунки зарплати, виробничі норми, логістичні правила, галузеві стандарти, інтеграції, специфічні документи й численні нестандартні сценарії.

Частина цих правил добре документована. Частина існує лише в програмному коді. А частина — тільки в пам’яті людей, які колись створювали систему.

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

Не можна просто вимкнути всі системи, переселити мешканців на декілька років і пообіцяти, що потім усе стане краще. Підприємство має продовжувати працювати, виконувати замовлення, виплачувати зарплату та формувати звітність.

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

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

K2 ERP як інструмент модернізації існуючих програмних продуктів

Уявімо європейську компанію, яка понад двадцять років створює ERP на «Delphi». Вона має великий досвід, сильну команду, стабільних клієнтів та складну прикладну систему, яка добре працює у своїй галузі.

Але ринок змінюється. Клієнти очікують браузерного доступу, мобільних застосунків, хмарних сервісів, інтеграцій, AI, простішого оновлення й нових моделей ліцензування.

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

Інший варіант — використати вже створену технологічну платформу K2 ERP (Україна), переносячи на неї найціннішу частину власного продукту: галузеву бізнес-логіку, алгоритми, моделі даних та прикладні рішення.

У такому випадку не потрібно з нуля створювати всі типові компоненти корпоративної системи. Значна частина інструментів уже існує в K2: форми, таблиці, довідники, документи, звіти, користувачі, права, моделі, API, механізми оновлень та інші компоненти.

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

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

Особливо цікавим такий підхід може бути для розробників великих enterprise-рішень, які хочуть виходити на нові ринки, пропонувати доступніші продукти середньому бізнесу або переходити до хмарної моделі постачання.

Зрозуміло, що перехід не буде автоматичним. Неможливо просто натиснути кнопку й перетворити мільйон рядків Delphi-коду на сучасну Python-систему зі збереженням усіх бізнес-правил. Потрібні аналіз, проєктування, конвертація, тестування та адаптація.

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

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

Реплікатор K2: перехід без необхідності вимикати стару систему

Один із найбільших ризиків модернізації — перенесення накопичених даних і необхідність забезпечити безперервність роботи підприємства.

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

Саме тому в екосистемі K2 створено Реплікатор — інструмент перенесення та синхронізації інформації. Зокрема, він використовується для поступового переходу з 1С/BAS на K2 ERP.

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

Для інших технологій, зокрема власних рішень на «Delphi», DBF, SQL-системах та інших платформах, можуть створюватися відповідні конектори, правила перетворення й сценарії міграції.

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

Але поетапний підхід дозволяє уникнути одного з найнеприємніших сценаріїв: коли в п’ятницю стару ERP урочисто вимикають, а в понеділок уся компанія починає згадувати, як працювати в Excel.

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

Саме так складна технологічна еволюція перетворюється на керований процес модернізації.

Економіка технологічної еволюції: що дорожче — переписати програму чи продовжувати її не переписувати?

Для власника програмного продукту питання модернізації насамперед економічне.

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

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

Ще важливішими можуть бути втрачені можливості. Компанія могла б вийти на новий ринок, але її продукт занадто дорогий у впровадженні. Могла б залучити тисячі нових користувачів, але архітектура погано масштабується. Могла б створити мобільний застосунок або AI-модуль, але спочатку доводиться витрачати місяці на розробку додаткових технологічних компонентів.

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

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

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

Тоді технологічна модернізація перестає бути просто побажанням програмістів. Вона стає частиною бізнес-стратегії.

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

Майбутнє не належить одній мові програмування

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

Цілком можливо, що через десять або двадцять років нинішні Python, TypeScript та Vue також поступляться місцем новим технологіям. У цьому немає нічого страшного. Навпаки, було б дивно, якби розвиток програмування раптом зупинився.

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

Саме так ми розглядаємо розвиток K2 ERP (Україна).

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

Ми створювали власне IDE на «Delphi», розвивали клієнт-серверні системи, переходили до вебтехнологій, змінювали мови програмування та поступово будували компонентну архітектуру.

Сьогодні цей досвід втілюється в технологічній платформі K2 ERP на Python, TypeScript, Vue та PostgreSQL, яка продовжує розвиватися разом із сучасною програмною індустрією.

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

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

Ці знання не потрібно втрачати лише тому, що змінюються мови програмування й операційні системи.

Навпаки, їх потрібно переносити на сучасну технологічну основу, яка дозволить створювати нові покоління програмних продуктів.

І тут K2 ERP (Україна) може стати технологічним партнером для розробників у будь-якій країні — від невеликої компанії з власною галузевою програмою до великого виробника корпоративного програмного забезпечення.

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

Зрештою, старі програми можуть жити дуже довго. Можливо, десь і через тридцять років працюватиме система на COBOL, Fortran або «Delphi», яка безпомилково виконуватиме свої задачі. І це нормально.

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

Технологічна еволюція неминуча для тих, хто хоче розвиватися. Але вона зовсім не обов’язково повинна починатися з нуля.

Ми пройшли шлях від Clipper, DBF та «Delphi» до Python, TypeScript, вебархітектури й сучасної модульної платформи. Це були десятиліття роботи, експериментів та інвестицій.

Тепер цей досвід може допомогти іншим компаніям пройти аналогічний шлях значно швидше.

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

---

K2 ERP (Україна) — сучасна технологічна платформа для розробки, розвитку та модернізації корпоративних інформаційних систем.

Офіційний сайт: https://erp.kyiv.ua/

Документація та інструменти розробника: https://wiki.erp.kyiv.ua/

Безкоштовна хмара для ознайомлення: https://cloud.corp2.eu/

---

Old Code Never Dies. But Can Businesses Afford to Live Forever on Old Technologies?

From COBOL, Fortran, Clipper, dBase, “Delphi”, “RAD Studio”, and 1C/BAS to Python, TypeScript, cloud platforms, and artificial intelligence. Why technological evolution is inevitable, how much it costs, and how Ukraine’s K2 ERP helps build the next generation of software without starting from scratch.

Software Can Outlive Its Developers

Somewhere in the world, a banking system is still running code written in COBOL several decades ago. Somewhere else, an industrial enterprise relies on a Fortran application that continues to perform complex engineering calculations. And somewhere in a small company, an inventory management system built with FoxPro or dBase is still running — developed back when computers were bulky, monitors were tiny, and the internet was something most people had only heard about in science fiction movies.

And the most interesting part? All these programs may still work perfectly well. They perform their tasks, users know how to operate them, and businesses see no reason to spend money replacing them. Why change something that works?

A perfectly reasonable position. At least until someone needs to connect a new warehouse, open a branch in another country, develop a mobile application, integrate artificial intelligence, or allow customers to work independently over the internet.

Suddenly, it turns out that the software which has performed flawlessly for twenty years is not particularly enthusiastic about its new life. It requires a specific version of Windows, outdated libraries, certain network configurations, and sometimes a programmer nobody has seen for the past decade.

Sometimes the situation is even worse: the source code lives on a server everyone is afraid to reboot because the last restart took three days to recover from. The system administrator may even develop a special tradition — mentally saying goodbye to colleagues before every major update.

But the problem is not that old technologies are inherently bad. Quite the opposite: many of them were revolutionary in their time. The real problem is that business requirements change, while software architecture designed twenty or thirty years ago cannot always accommodate those changes without enormous investments.

Software does not become technologically obsolete when it stops working. It becomes obsolete when it can no longer keep up with the needs of the business.

And this is a global issue. It affects an American developer maintaining a financial system written in COBOL, a German company running manufacturing software on “Delphi”, a French integrator supporting an old Oracle Forms application, a Japanese manufacturer operating proprietary industrial systems, or a Ukrainian business that has relied on 1C/BAS for decades.

The world has accumulated an enormous amount of software developed during different technological eras. Much of it has never been fully modernized.

How Great Technologies Gradually Become Limitations

In the 1980s and 1990s, the emergence of personal computers and technologies such as dBase, Clipper, FoxPro, and the DBF file format opened a new era of business automation.

Companies no longer needed expensive mainframes to handle relatively simple accounting and management tasks. A programmer could develop an accounting system, inventory management application, payroll module, or order processing solution on an ordinary personal computer.

For its time, this was extraordinary progress. The simplicity of development, accessibility of hardware, and ability to customize applications quickly allowed thousands of businesses to automate processes that had previously been handled manually.

However, many of these systems were architected for relatively small numbers of users, local networks, and file-based data storage. As workloads increased, problems emerged involving record locking, concurrent access, indexes, network performance, and data integrity.

Of course, well-designed systems could handle substantial workloads. But scaling them further often required increasingly complicated technical workarounds.

A similar story unfolded with many other technologies. Visual Basic, Microsoft Access, legacy client-server applications developed with PowerBuilder, Oracle Forms, and various proprietary development environments made it possible to create sophisticated enterprise software.

Some of these products remain operational today because they continue to solve real business problems.

In Eastern Europe and the countries of the former Soviet Union, 1C 7.7 — followed by 1C 8 and BAS — occupied a particularly important position.

The earlier generation reflected the architectural assumptions of its era, although SQL-based configurations were also available. Later versions introduced client-server architecture, web clients, clustering, and significantly broader capabilities.

Nevertheless, developers and customers remained dependent on a specialized platform, its proprietary programming language, configuration mechanisms, and the decisions of the technology vendor.

This does not mean large enterprise systems cannot be built on 1C 8 or BAS. They certainly can, and many such implementations exist.

But when a company needs a different architecture, an independent licensing model, new AI development tools, or a fundamental change in its technology stack, accumulated platform dependencies begin to have a serious impact on development costs.

The software industry has a term for this situation: legacy software.

Importantly, legacy software is not necessarily bad software. Quite often, it is exactly the opposite. The product has been so successful that it has survived far beyond its originally expected lifespan and continues to perform business-critical functions.

This creates a paradox: the more successful a product becomes, the more customers it acquires, and the more functionality it accumulates, the harder it becomes to modernize.

Such software may contain millions of lines of code, tens of thousands of business rules, enormous databases, and hundreds of custom integrations.

Replacing all of this is not the same as rewriting a small website with a newer framework.

And there is one technology whose history we know particularly well.

“Delphi” and “RAD Studio”: A Brilliant Idea That Found Itself Constrained by the Web Era

For me, “Delphi” is a special technology.

After Clipper, DBF, DOS, and text-based interfaces, the arrival of a fully visual development environment seemed almost magical. A programmer could place components on a form, connect a database, write a few event handlers, and produce a real Windows application.

Visual programming, object-oriented architecture, the VCL component library, native code compilation, and convenient database tools made “Delphi” one of the most impressive development environments of its time.

For certain tasks, a single experienced programmer could create applications faster than an entire team working with less convenient technologies.

We followed this path ourselves and used “Delphi” extensively for developing enterprise systems.

In fact, in the early 2000s, we went beyond simply using existing “Delphi” components. In our “Corporation 1” system, we developed our own integrated development environment (IDE).

It was not merely a tool for changing button positions or configuring form properties. We created an embedded development environment with a Pascal-like scripting language, allowing developers to implement and extend application logic without recompiling the entire application every time.

Essentially, more than twenty years ago, we were already exploring what is now commonly called platform-based development: a technological core, application development tools, and the ability to extend functionality without rewriting the underlying platform.

That experience became extremely valuable for the subsequent evolution of our products, including “Corporation 2” and today’s K2 ERP.

Why “Delphi” Lost Its Former Leadership

The history of “Delphi” itself was far from straightforward.

Borland, the company behind the product, experienced financial difficulties and strategic challenges. In 2006, its development tools division was separated into CodeGear, which was sold to Embarcadero Technologies in 2008. In 2009, Borland itself was acquired by Micro Focus.

While companies were restructuring, changing ownership, and redefining their strategic priorities, the software industry was advancing at tremendous speed.

Java, C#, PHP, JavaScript, Python, and later TypeScript, modern web frameworks, cloud platforms, and open-source libraries gradually transformed the way software was developed.

In my opinion, “Delphi” lost an entire historical period during which it could have remained one of the leading rapid application development technologies.

And the problem was not limited to Borland’s corporate difficulties. The industry changed its fundamental approach to software development, while the “Delphi” ecosystem remained largely oriented toward traditional desktop applications for a considerable period.

It is somewhat like the story of a manufacturer of the world’s finest horse-drawn carriages, which became so focused on improving wheels and suspension systems that it failed to notice the arrival of automobiles.

The carriage remained excellent, and experienced coachmen were still highly skilled professionals. But customers were increasingly asking where they could turn on the air conditioning and connect the GPS.

Of course, modern “RAD Studio” continues to evolve.

And to be precise, “RAD Studio” is an integrated development environment that includes “Delphi” and “C++Builder”; it is not simply a new name for the Delphi programming language.

Today, the platform offers support for multiple operating systems, FireMonkey, server-side development tools, integration capabilities, web technologies, and AI-assisted development.

However, the existence of these capabilities in modern versions does not mean that decades of VCL-based applications have automatically become modern web-oriented products.

Millions of lines of legacy code, hundreds of forms, specialized libraries, database components, and Windows-specific dependencies can require enormous effort to migrate to a new architecture.

“Lazarus” and “Free Pascal”: Pascal Turned Out to Be Remarkably Resilient

The independent open-source projects “Free Pascal” and “Lazarus” deserve special attention.

They demonstrated that good technological ideas can continue developing beyond the boundaries of a single commercial vendor.

“Free Pascal” is an open-source Pascal/Object Pascal compiler supporting multiple operating systems and processor architectures.

“Lazarus” is a free, cross-platform rapid application development environment with a visual form designer and component library. Together, they enable developers to create applications for Windows, Linux, macOS, and other supported environments.

In a sense, these projects preserved and extended the ideas that once made “Delphi” so popular.

It is particularly interesting that “Lazarus” can be used as a development environment directly on Linux or macOS, while the “RAD Studio” IDE remains Windows-based.

One could joke that Pascal has been escorted into retirement so many times that it has probably learned to complete its own re-employment paperwork.

And judging by the continued development of “Lazarus”, it has been rather successful.

However, cross-platform compilation does not automatically resolve every architectural problem.

A large VCL application with numerous Windows dependencies cannot necessarily be migrated to “Lazarus” by simply pressing a button. Components may need to be adapted, interfaces redesigned, and substantial portions of the software rewritten and tested.

More importantly, even if an application compiles successfully for Windows, Linux, and macOS, that does not automatically mean it meets all the requirements of modern enterprise systems.

Cross-Platform Development: The World Has Long Moved Beyond Windows

There was a time when almost every corporate user worked on Windows.

Accounting, inventory management, sales, manufacturing — most business applications were designed for a single operating system.

This simplified development, deployment, and maintenance. Programmers rarely needed to think about other platforms.

Today, the situation is completely different.

A company director may use a MacBook, accountants may work on Windows, servers may run Linux, warehouse employees may use Android terminals, managers may carry iPhones, and industrial equipment may operate under specialized operating systems.

All these devices must interact with the same business processes and exchange information.

One approach is to develop separate native applications for every platform.

Sometimes this is entirely justified, especially for sophisticated graphical applications or specialized hardware.

But for a large enterprise system, this approach can become extremely expensive. Developers must maintain multiple builds, SDKs, platform-specific libraries, deployment mechanisms, and compatibility across different versions.

Sometimes a company spends several months porting its old desktop application to Linux or macOS.

Then the customer looks at the finished product and asks a perfectly reasonable question:

“Wonderful. But can I just open it in a browser?”

This is why web architecture has become such an attractive option for many enterprise systems.

Business logic runs on the server, while users interact with the application through a browser. Whether someone uses Windows, Linux, macOS, Android, or iOS, they access the same information system.

Naturally, browsers do not solve every problem. Developers still need to consider responsive interfaces, mobile workflows, hardware integration, offline functionality, and platform-specific limitations.

Nevertheless, for a vast range of business applications, web architecture can significantly reduce development and maintenance complexity.

And this brings us to another important characteristic of modern software: not every component needs a graphical interface at all.

What If the User of Your Software Is a Robot?

Imagine a modern logistics center where employees work alongside automated conveyors, sorting systems, and autonomous warehouse robots.

The ERP system receives a customer order. The WMS identifies where the goods are stored and creates a transport task.

A robot receives an instruction to move a container to the shipping area. It completes the operation and returns a status message: task completed, cargo delivered, battery level 65%.

All of this happens without a Windows form, a menu, or a Save button.

The robot does not need to see a table listing the products, and nobody has to ask it to click OK. It needs structured instructions, an appropriate programming interface, and a way to report the result.

And if a robot must first install Windows, register forty libraries, configure drivers, and accept a licensing agreement before starting work, it may genuinely begin questioning humanity’s intelligence.

Robotics, automated equipment, and the Internet of Things often require a completely different approach: APIs, message exchange, text-based or binary protocols, autonomous processes, telemetry processing, and communication between software components without graphical interfaces.

ROS 2, for example, is an open robotics ecosystem that enables developers to create software components in Python and C++ that exchange messages, receive sensor data, and interact with hardware.

Of course, low-level motor control, safety-critical real-time operations, and physical safety systems require specialized controllers and appropriate technologies.

Python should not replace them where doing so would be inappropriate.

But for task logic, coordination, data processing, AI, integrations, and automation, Python is an extremely useful tool.

This is why a modern enterprise platform should separate business logic, user interfaces, and the mechanisms used to communicate with equipment.

Today, a system user may be an accountant working on a laptop. Tomorrow, it may be a software agent. The day after tomorrow, an autonomous warehouse robot.

And if the information system is designed properly, it should not fundamentally matter whether an authorized business operation is initiated by a person through a browser or by an external service through an API.

Naturally, integrating robots requires appropriate security mechanisms, state control, testing, and consideration of the equipment’s specific characteristics.

But the ability to evolve in this direction should be part of the architecture from the beginning.

Security, Scalability, and Self-Service: Requirements That Barely Existed Before

The world of information systems has changed for reasons beyond new operating systems and devices.

Requirements for security, scalability, performance, and ease of administration have changed dramatically.

Twenty years ago, a program might operate entirely inside a local network, with user access controlled by a simple password.

Today, ERP systems interact with banks, government services, marketplaces, mobile applications, partners, and external software platforms.

As a result, requirements for authentication, access control, encryption, audit trails, API protection, update management, and secure data storage have increased substantially.

International businesses must also consider various regulatory requirements related to personal data, financial information, and infrastructure location.

Resilience has become equally important.

Data center failures, cyberattacks, natural disasters, power outages, and major network incidents can happen in any country.

In Ukraine, these risks have been intensified by military attacks on infrastructure. However, the need for geographically distributed systems is global.

A modern ERP should allow businesses to implement backups, recover information, move server components between infrastructures, and, when necessary, operate across multiple data centers.

At the same time, no programming language automatically guarantees security or resilience. These capabilities depend on architecture, implementation quality, and professional operations.

The scale of business systems has also changed significantly.

Where five or ten concurrent users once represented a typical corporate workload, large systems today may serve hundreds or thousands of users, process tens of thousands of documents every day, and support enormous warehouses and geographically distributed enterprises.

What matters here is not simply the programming language, but database architecture, transaction handling, caching, asynchronous processing, background tasks, load distribution, and integration efficiency.

Another major requirement is self-service.

Modern users do not want to contact a programmer every time they need to add a field to a product card, modify a printed document, or create a management report.

And who can blame them?

If moving a company logo three millimeters to the right on an invoice requires creating a Jira ticket, assigning it to a sprint, and waiting two weeks for a release, the logo is no longer the problem.

That is why modern platforms increasingly use visual tools, designers, metadata, business process models, and configurable components.

Administrators and trained business users can handle many routine changes, allowing developers to concentrate on complex business logic and product evolution.

Python and TypeScript: A Foundation for the Next Generation of Software

Why are Python, TypeScript, modern web frameworks, and open databases increasingly attractive for new enterprise platforms?

Not because these technologies are magical.

And certainly not because it is impossible to write bad software with them. Trust me, bad software can be written in absolutely any programming language, and some developers demonstrate truly remarkable talent in this field.

The real advantage lies in the global ecosystem.

Python is widely used for server-side development, scientific computing, automation, data analysis, machine learning, computer vision, and robotics.

It benefits from enormous international developer communities and a vast ecosystem of libraries.

TypeScript makes it possible to build complex web applications with typed client-side logic, while Vue provides a component-based approach to creating reactive interfaces.

PostgreSQL offers a powerful foundation for transactional systems, complex queries, large data volumes, and enterprise information processing.

Crucially, these technologies do not lock developers into a proprietary language belonging to a single ERP vendor.

Developers can use standard IDEs, Git, testing tools, CI/CD systems, libraries, documentation, and modern AI coding assistants.

But Python has another particularly interesting characteristic: it has long been used not only to create standalone applications, but also to extend the functionality of large software products.

Python as an Extension Language: An Approach Proven by Global Software Vendors

Using Python as a scripting language inside software products is far from a new idea.

Many well-known applications have high-performance cores written in C, C++, or other technologies, but expose their capabilities through Python APIs.

This allows third-party developers to create extensions, custom tools, automation scripts, and specialized functions without changing or recompiling the core product.

Below are examples of well-known applications that use Python to extend their functionality.

Software product	Application area	How Python is used
Blender	3D modeling and animation	Embedded scripts, Python API, plugins, model generation, automation
Autodesk Maya	3D animation, film, and games	Python API, automation scripts, modeling tools
Autodesk 3ds Max	Architectural visualization and 3D	Python scripting, scene management, automation
Autodesk Fusion	CAD/CAM and engineering design	Python API, scripts, and add-ins for design automation
FreeCAD	Engineering and parametric 3D design	Python console, macros, additional modules, parametric modeling
QGIS	Geographic information systems	PyQGIS, Python console, plugins, geospatial analysis
Houdini	Visual effects and procedural graphics	Python API, custom tools, scene automation
Ansys Mechanical	Engineering simulations	Python scripts for model automation and analysis
Abaqus	Physical process simulation	Python Scripting Interface for simulation automation
LibreOffice	Office productivity	Python macros, document automation through the UNO API
Scribus	Desktop publishing	Python scripts for automating document production
GIMP	Image editing	Python plugins and graphics automation
Calibre	E-book management	Python components, plugins, metadata processing
Microsoft Power BI	Business intelligence	External Python scripts for data transformation and visualization

These products use different integration models: embedded interpreters, APIs, external scripts, macros, or plugins.

For example, Blender provides an embedded Python interpreter, while Power BI relies on a separately installed Python environment. Calibre itself is developed largely in Python.

Nevertheless, the underlying principle is the same: users can extend the functionality of an existing software product through programming.

Blender provides a particularly illustrative example.

Developers do not need to modify the graphics editor’s core whenever they want to create a new tool, object generator, or specialized importer. Much of this functionality can be implemented in Python through supported APIs.

QGIS follows a similar approach, enabling developers to create geospatial plugins, algorithms, custom interfaces, and automated processes using Python.

This principle is extremely important for enterprise software.

Instead of inventing a proprietary specialized programming language, developers can use a standard language supported by an enormous ecosystem of libraries and professionals.

However, Python alone is not enough to build an ERP.

An enterprise platform also needs tools for managing data, forms, reports, users, documents, business processes, updates, and numerous other standard elements.

And this leads us to the next stage of technological evolution: combining Python with a full-featured rapid application development platform for enterprise software.

K2 ERP (Ukraine): More Than Thirty Years of Technological Evolution

The story of Ukraine’s K2 ERP is interesting because we did not begin with a ready-made technology stack selected from the latest programming language popularity rankings.

We experienced practically every major stage of business software evolution over the past several decades.

In the 1990s, we developed applications for accounting, payroll, inventory management, and other business functions using Clipper and DBF.

Later, we moved to Pascal and “Delphi”, developing Windows applications, client-server systems, and our own rapid development tools.

As early as the beginning of the 2000s, we created an IDE with an embedded scripting language in “Corporation 1”, allowing developers to extend application functionality within our own software environment.

Over time, the scale of our projects increased.

We developed multi-branch systems, sophisticated integrations, and solutions for transport, logistics, warehousing, manufacturing, retail, and many other industries.

Internet technologies became increasingly important, as did the ability to unite geographically distributed enterprises into a common information environment.

This evolution eventually led to “Corporation 2”, abbreviated as K2.

Over time, the name became an independent brand, and the system evolved from large application solutions into a modular ERP platform.

The next technological stage involved PHP-based web applications, enabling us to create document management systems, corporate portals, e-commerce applications, management modules, and other browser-accessible solutions.

Eventually, we recognized the need for another architectural transition: building a platform around Python, TypeScript, Vue, and PostgreSQL.

This decision was not driven by a desire to replace one programming language with another simply because it was fashionable.

It was the result of decades of practical experience, during which we encountered both the strengths and limitations of different technologies.

Today, K2 ERP (Ukraine) is more than a collection of ready-made enterprise automation modules.

It is a technological platform for developing custom enterprise information systems, industry-specific solutions, integrations, and reusable software components.

And its greatest value is not merely the use of Python and TypeScript, but the substantial development infrastructure that has already been created.

K2 ERP: Taking Python Development to Another Level

Imagine a software company deciding to build its own ERP using Python.

It hires developers, chooses PostgreSQL, develops APIs, and uses Vue or another frontend framework.

At first glance, everything looks perfectly reasonable.

But the team soon discovers that before it can focus on the actual business logic, it must solve an enormous number of standard problems.

User management, access rights, forms, tables, directories, documents, file handling, printable forms, reports, metadata, updates, data import, and export — the list goes on.

Essentially, the company must first build its own software platform and only then start developing the actual product.

This is where K2 ERP (Ukraine) can significantly shorten the journey.

ER Models and Visual Data Modeling

K2 provides and continues to develop tools for describing data structures using entity-relationship models.

Developers can work with entities, fields, attributes, relationships, and other elements of the business data model.

For example, consider an equipment maintenance management system.

It needs to describe equipment, technical specifications, installation locations, responsible employees, service requests, maintenance history, and materials used.

In traditional development, programmers must manually create database tables, software models, forms, relationships, APIs, and other structures.

With a platform-based approach, the same structured data descriptions can be reused to create different software components.

K2 uses declarative descriptions, including YAML, as well as ORM models and migration mechanisms.

Visual ER modeling tools continue to evolve, reducing the amount of repetitive manual programming.

BP Models: Making Business Processes Understandable

Another essential part of an ERP is business process management.

A customer order, purchase request, contract approval, manufacturing operation, or service ticket may pass through dozens of stages, involve multiple departments, and depend on numerous conditions.

When all these processes exist only as scattered programming functions, even their original developers may struggle to explain why a document follows a particular route several years later.

Business process models make it possible to describe workflows visually: stages, transitions, performers, events, conditions, and results.

This simplifies design, discussions with customers, documentation, and future system evolution.

We are developing these capabilities in K2 using modern web technologies and TypeScript.

The goal is to move gradually from manually programming every standard operation toward managed models and reusable components.

Components, Forms, Tables, and Reports

One of K2’s major strengths is its extensive collection of reusable software components.

Tables, forms, directories, documents, search tools, filtering, sorting, import and export functions, charts, and configurable columns can be reused across different applications.

This may sound like a minor advantage — until you actually try to build a large ERP from scratch.

A typical enterprise data table may need to support dozens of operations. If every developer implements them independently, development costs quickly become enormous.

K2 also includes tools for designing printable forms, report designers, BI analytics, dashboards, pivot tables, and additional entity attributes that allow applications to be adapted to specific business requirements without constantly modifying source code.

For developers, this means spending more time on business-specific functionality.

If they are creating manufacturing software, they should focus on manufacturing algorithms rather than implementing table sorting for the hundredth time.

Metadata and Independence from a Specific IDE

K2 makes extensive use of YAML, JSON, XML, and other structured formats.

Their value lies in the fact that software component descriptions can be stored as ordinary text files, suitable for analysis, comparison, version control, and automated generation.

This enables the use of Git, modern IDEs, code quality tools, and AI coding assistants.

Importantly, developers are not forced to use a single specialized editor.

They can work with Visual Studio Code, PyCharm, WebStorm, Cursor, or other development environments that meet their needs.

This approach differs fundamentally from platforms where application code can only be modified using a proprietary configuration tool.

Clouds, Components, and Updates

K2 ERP is developing as a hybrid platform.

It can be deployed in cloud environments, on enterprise-owned servers, in partner installations, and in other supported infrastructure configurations.

For corporate customers, this matters because they need control over data location, access policies, backups, and software operations.

Another important development area is the transfer of metadata, reports, settings, and components between installations.

If a developer creates a useful module for one company, there is little reason to build the same functionality again for every subsequent customer.

K2 Update provides mechanisms for delivering software updates, fixes, and components.

In the future, this infrastructure could also support a full marketplace of application modules created not only by the K2 team but also by independent developers and technology partners.

For a software company planning to sell its product to hundreds or thousands of customers, this infrastructure is more than a convenience.

It directly affects the economics of development, maintenance, and software distribution.

Artificial Intelligence: The Next Technological Revolution Has Already Begun

Not long ago, generating complex source code from a natural-language description sounded like science fiction.

Today, AI coding assistants help create functions, write tests, explain unfamiliar code, identify errors, generate documentation, and design software components.

Of course, this does not mean artificial intelligence can already independently develop and deploy any ERP without mistakes.

Complex financial, manufacturing, and logistics logic still requires professional verification.

Nevertheless, the speed at which standard development tasks can be completed is changing.

And this is another area where the popularity of Python and TypeScript provides an advantage.

These languages are widely represented in modern development tools, educational materials, libraries, and code repositories.

AI assistants can work with standard code structures, data formats, and established development tools.

Within K2, the evolution of metadata, ER and BP models, software components, and declarative descriptions creates opportunities to use AI not only for writing individual functions but also for automating the creation of entire application components.

For example, a developer describes a new maintenance management module.

AI helps prepare entity structures, YAML descriptions, software models, form templates, SQL queries, and other elements.

The developer then verifies the logic, adds specialized algorithms, and integrates the module into the system.

This represents a fundamentally different level of automation compared with manually creating every software element.

In the future, programming will increasingly involve designing models, processes, rules, and interactions between components.

Writing code will remain important, but automated tools will generate a growing proportion of standard structures.

This is precisely why modern technology platforms must be capable of evolving in this direction.

From ERP to a Unified Enterprise Management Platform

Another important trend is the gradual disappearance of traditional boundaries between different categories of enterprise software.

ERP, CRM, WMS, HR, LMS, document management, project management, equipment maintenance, and business intelligence often support interconnected business processes.

For example, a customer places an order.

CRM stores the customer relationship history. ERP checks commercial conditions. WMS manages warehouse operations. Manufacturing software schedules production. Accounting records the financial results.

If a machine breaks down, the maintenance management system creates a service task.

Why should every one of these modules have separate user management, directories, notifications, files, tasks, and reporting mechanisms if much of this functionality can be implemented on a common technology foundation?

This is why K2 is evolving as an ecosystem of interconnected components and modules.

Accounting, payroll and HR, CRM, WMS, manufacturing, project management, document management, LMS, maintenance management, CMS, e-commerce, communications, and analytics can share the platform’s common mechanisms.

This matters not only to enterprises but also to independent software developers.

A company that has spent years developing its own logistics product can use the K2 technology foundation for users, documents, reports, integrations, and interfaces while preserving its unique transportation management logic.

As a result, new industry-specific products can be created much faster than if every developer had to build an entire platform independently.

The Most Expensive Part of Modernization Is Not the Source Code

When a company decides to rewrite an ERP using modern technologies, the first concern is usually the cost of developers.

A new architecture must be designed, algorithms rewritten, interfaces rebuilt, databases migrated, calculations verified, and testing organized.

But the most valuable part of an established software product is not its source code.

It is the accumulated business logic.

Over decades of development, an ERP acquires thousands of specialized rules: cost calculation algorithms, payroll formulas, manufacturing standards, logistics procedures, industry-specific accounting requirements, integrations, document formats, and countless custom workflows.

Some of these rules are well documented.

Others exist only in the source code.

And some survive exclusively in the memories of the people who originally developed the system.

Rewriting a large ERP is therefore rather like rebuilding a city while its residents must continue living there.

You cannot simply shut everything down, relocate the population for several years, and promise that life will be better afterward.

The enterprise must continue receiving orders, paying salaries, managing inventory, and preparing financial reports.

That is why modernization of large software products often takes years and requires substantial investment.

This is particularly true when the software vendor has hundreds or thousands of customers who continue using existing versions.

But there is an alternative approach: instead of building the entire new foundation independently, use an existing technology platform.

K2 ERP as a Modernization Platform for Existing Software Products

Imagine a European software company that has been developing an ERP system in “Delphi” for more than twenty years.

It has extensive expertise, a strong development team, loyal customers, and a sophisticated industry-specific product that works well.

But market requirements are changing.

Customers increasingly expect browser access, mobile applications, cloud services, integrations, AI capabilities, simpler updates, and more flexible licensing models.

The company could develop an entirely new platform internally.

Doing so would require years of work, substantial investment, and the simultaneous maintenance of two generations of software.

Another option is to use the existing K2 ERP (Ukraine) technology platform, transferring the most valuable parts of the original product onto it: industry-specific business logic, algorithms, data models, and application functionality.

In this case, the company does not need to recreate every standard enterprise software component from scratch.

K2 already provides a substantial range of platform capabilities: forms, tables, directories, documents, reports, user and access management, models, APIs, update mechanisms, and other reusable components.

Developers can concentrate on what genuinely distinguishes their product from competitors.

For example, complex manufacturing algorithms, logistics optimization, specialized industry accounting, or financial calculations.

This enables a shift from a model in which every software company builds its own technology foundation toward one based on reusing an established platform.

The approach may be particularly attractive to developers of large enterprise products seeking to enter new markets, offer more affordable solutions to medium-sized businesses, or transition toward cloud-based delivery.

Naturally, migration will not be automatic.

You cannot simply press a button and transform a million lines of Delphi code into a modern Python system while preserving every business rule.

Analysis, design, conversion, testing, and adaptation will still be necessary.

But if a substantial portion of the technology platform is already available, the scale of the remaining work changes considerably.

For companies planning to modernize large software products, this can mean significantly reducing development time and investment compared with building a completely new platform internally.

K2 Replicator: Modernization Without Switching Off the Old System

One of the greatest risks in software modernization is migrating accumulated data while maintaining uninterrupted business operations.

Large information systems may contain decades of transaction history, complex settlements, inventory balances, documents, master data, and integrations.

Even a small migration error can create serious operational problems.

That is why the K2 ecosystem includes K2 Replicator, a tool for transferring and synchronizing information.

It is used, among other scenarios, for gradual migration from 1C/BAS to K2 ERP.

Its principal advantage is the ability to organize parallel operation of the old and new systems.

Data can be transferred gradually, users can be trained, and developers can verify the correctness of new modules without shutting down the enterprise.

For other technologies, including proprietary applications developed with “Delphi”, DBF-based systems, SQL applications, and other platforms, appropriate connectors, data transformation rules, and migration scenarios can be developed.

Importantly, data replication does not mean automatic conversion of all application logic.

Some algorithms must be migrated separately, compatibility must be verified, and the correctness of results must be tested.

Nevertheless, a gradual migration strategy helps avoid one of the most unpleasant scenarios: the old ERP is ceremonially switched off on Friday, and by Monday the entire company is trying to remember how to run its business in Excel.

A much more practical approach is to transfer functionality step by step, validate the results, train users, and move to the new architecture when the business is genuinely ready.

In this way, a complicated technological transformation becomes a manageable modernization process.

The Economics of Technological Evolution: What Costs More — Rewriting Software or Continuing Not to Rewrite It?

For software owners, modernization is primarily an economic decision.

Developing a new system involves obvious expenses: programmers, architects, testers, infrastructure, training, and implementation.

The costs of maintaining an outdated architecture are often less visible.

They are distributed across support for obsolete libraries, complicated integrations, individual modifications, recruitment of specialized developers, manual updates, and constant compatibility problems.

But lost opportunities can be even more expensive.

A company might be able to enter a new market, but its product is too costly to implement.

It might attract thousands of additional users, but its architecture does not scale efficiently.

It might develop a mobile application or AI module, but first needs to spend months building the underlying technical infrastructure.

At some point, even an excellent legacy product begins losing to competitors not because of its functionality, but because of the speed and cost of delivering new capabilities.

Naturally, not every old program needs to be rewritten immediately.

If a system is stable, sufficiently secure in its operating environment, serves a limited number of users, and fully meets business requirements, continuing to use it may be entirely rational.

But the situation changes when a software company wants to expand internationally, support thousands of users, and compete with a new generation of applications.

At that point, technological modernization stops being merely a request from the development team.

It becomes part of the business strategy.

And this is where a ready-made rapid development platform can significantly change the economics of the project.

The Future Does Not Belong to Any Single Programming Language

Over more than thirty years of software development, we have witnessed technologies that once seemed almost perfect gradually give way to new approaches.

Clipper and DBF revolutionized business automation in their time.

“Delphi” taught an entire generation of programmers how to create sophisticated applications quickly.

Web technologies changed how users accessed software.

Cloud platforms transformed deployment and scalability.

And artificial intelligence is already beginning to change the process of software development itself.

It is entirely possible that in ten or twenty years, today’s Python, TypeScript, and Vue will also give way to new technologies.

There is nothing frightening about that.

On the contrary, it would be rather strange if the evolution of programming suddenly stopped.

This is why the most important characteristic of a modern software platform is not the popularity of a particular programming language, but its ability to evolve.

It should allow developers to improve individual components, replace technological layers, adopt new tools, support different operating systems, integrate with external services, and preserve what matters most: accumulated business logic.

This is exactly how we see the future of K2 ERP (Ukraine).

We did not create our platform from scratch in a single year, and we do not claim to have found a universal answer to every challenge facing the software industry.

Behind K2 ERP are more than thirty years of practical experience, several generations of technologies, complex implementations, architectural mistakes, experiments, and years of work on rapid application development tools.

We developed our own IDE using “Delphi”, built client-server systems, transitioned to web technologies, changed programming languages, and gradually developed a component-based architecture.

Today, this experience is embodied in the K2 ERP technology platform built around Python, TypeScript, Vue, and PostgreSQL — a platform that continues evolving alongside the global software industry.

And our goal is not limited to developing our own ERP modules.

We want other companies to be able to use this technological foundation to develop and modernize their own software products.

After all, the world contains an enormous number of excellent enterprise systems developed twenty or thirty years ago.

They have rich histories, extensive functionality, experienced teams, and loyal customers.

Their greatest value lies in decades of accumulated business expertise.

That knowledge should not be lost simply because programming languages and operating systems change.

Quite the opposite: it should be transferred to a modern technology foundation that makes it possible to create the next generation of software products.

And this is where K2 ERP (Ukraine) can become a technology partner for developers in any country — from a small company with its own industry-specific application to a major enterprise software vendor.

There is no need to repeat the entire multi-year modernization journey independently.

Companies can use existing tools, components, architectural approaches, and accumulated experience, reducing the effort required to rebuild standard technology infrastructure.

Ultimately, old software can live for a very long time.

Perhaps thirty years from now, somewhere in the world, a system written in COBOL, Fortran, or “Delphi” will still be performing its tasks flawlessly.

And that is perfectly fine.

But if a company wants to develop new products, expand into new markets, support thousands of users, automate manufacturing, interact with robots, and integrate artificial intelligence, its technology platform must be ready for those challenges.

Technological evolution is inevitable for companies that want to grow. But it certainly does not have to start from scratch.

We have traveled the long road from Clipper, DBF, and “Delphi” to Python, TypeScript, web architecture, and a modern modular development platform.

That journey required decades of work, experimentation, and investment.

Today, this experience can help other companies complete a similar transformation much faster.

And perhaps the best technology is not one that never grows old.

It is one that allows you to keep evolving without having to start all over again.

---

K2 ERP (Ukraine) — a modern technology platform for developing, extending, and modernizing enterprise information systems.

Official website: https://erp.kyiv.ua/

Documentation and developer tools: https://wiki.erp.kyiv.ua/

Free cloud environment: https://cloud.corp2.eu/