AI केस स्टडी
एउटा बिक्री-व्यवस्थापनको मूल प्रणाली। करिब २० वर्ष चलिरहेको, र काम हरेक दिन सञ्चालन भइरहेको। OS को सपोर्ट धेरै अघि नै सकिएको, एप्लिकेसन सर्भर र स्क्रिन प्रविधि दुवै पुरानो पुस्ताको। यति हुँदाहुँदै पनि “पूर्ण नवीकरण” मा हात हाल्न नसक्नु, परिमाण र व्यावसायिक प्रभाव विचार गर्दा स्वाभाविक निर्णय हो।वास्तविक अभिलेख①मा “पुनः बनाउने” रोजियो, तर सबै प्रणालीका लागि पुनर्निर्माण नै उत्तम हुँदैन। यसपटक अपनाइएको रणनीति हो —विद्यमान प्रणालीलाई कत्ति पनि नछोई, बाहिरपट्टि नयाँ प्रवेशद्वार खडा गर्ने— अर्थात् स्ट्र्याङलर प्याटर्न हो।
विद्यमान कोडको परिवर्तन, ० लाइन।
प्रयोगकर्ता → नयाँ गेटवे (नयाँ बनाइएको) → विद्यमान प्रणाली (सुधार बिनाको) → विद्यमान DB (जस्ताको तस्तै)
- विद्यमान प्रणालीतर्फ, भित्री व्यावसायिक लजिकलाई बाहिरबाट बोलाउन मिल्ने बनाउनेREST को पातलो तहमात्र थपियो। विद्यमान क्लासमा एउटै लाइन पनि फेरिएको छैन। नछोएकाले, बिग्रिँदैन
- अगाडिको भागमानयाँ गेटवे(Java 21 / Spring Boot) नयाँ बनाइयो। आन्तरिक बिजनेस च्याट आधारको खाताबाट SSO लगइन गरी, प्रमाणित भइसकेका अनुरोध मात्र विद्यमान प्रणालीमा पठाइन्छ
- स्क्रिनलाई नयाँ गेटवेतर्फ आधुनिक रूपमा पुनर्निर्माण गरियो। बल्क दर्ता होस् वा फारम दर्ता,विद्यमान प्रणालीको दर्ता लजिकलाई १००% पुनःप्रयोगगरेर चल्छ
जोखिमलाई “नयाँ बनाइएको तह” भित्रै थुनेर, प्रमाणित व्यावसायिक लजिकलाई जस्ताको तस्तै उपयोग गर्ने। यही यस रणनीतिको मर्म हो।
काम सुरु गरेको केही दिनमै, उत्पादन पूर्वाधारमा E2E सफल भयो।
AI एजेन्ट (Claude Code) ले विद्यमान प्रणालीको कोड पढ्यो, पुरानो फ्रेमवर्कको विशिष्ट भित्री संरचनाका बानीहरू एक-एक गरी हटायो, र गेटवेको कार्यान्वयन, सर्भर निर्माण, रिभर्स प्रोक्सी सेटिङसम्म अघि बढायो। परिणामस्वरूप,काम सुरु गरेको केही दिनमै, सार्वजनिक URL बाट प्रमाणीकरण पार गरेर, विद्यमान इन्जिनमा वास्तविक डेटा दर्ता हुनेसम्मको प्रक्रिया एकैसाथ सफल भयो। त्यसपछि खोज र नयाँ दर्ता गरी, स्क्रिन-अनुसार सुविधा थप्दै गएका छौं।
चरणबद्ध स्थानान्तरणको राम्रो पक्ष हो —प्रयोग हुने स्क्रिनदेखि क्रमशः नयाँतिर सार्दै जान सकिनेकुरा। पूर्ण नवीकरणजस्तो ठूलो पुँजी, संरचना र स्थिरीकरण अवधि नचाहिने गरी, काम नरोकी “नयाँ प्रणाली” को क्षेत्रफल फराकिलो पार्दै जान सकिन्छ। स्ट्र्याङलर प्याटर्न आफैंमा पुरानो विधि हो, तर विश्लेषण र कार्यान्वयनमा उल्लेख्य श्रम लाग्ने भएकाले स्वीकृति पाउन कठिन विकल्प थियो। AI ले ती दुवैलाई अत्यधिक छिटो बनाइदिएपछि,“पूर्ण नवीकरण वा थन्क्याउने” भन्ने दुई विकल्पमा, व्यावहारिक तेस्रो बाटो थपियो।
के तपाईं पनि यस्तै अवस्थामा अल्झिनुभएको छ?
“रोक्न नमिल्ने मूल प्रणाली छ,” “नवीकरणको स्वीकृति पास हुँदैन,” “कम्तीमा नयाँ स्क्रिन र नयाँ प्रमाणीकरण मात्र भए पनि” — त्यो प्रणाली, नबिगारी प्रवेशद्वार मात्र नयाँ बनाउने बाटो छ।
हाम्रो कम्पनीले लिगेसी नवीकरणलाई “AI Re: Platform” (छोटकरीमा: AIR Platform) का रूपमा प्रदान गर्छ।
विद्यमान स्रोतको विश्लेषणसम्म निःशुल्क।परिणाम प्राविधिक ऋणको सूची र “पुनः बनाउने / बेर्ने” प्रारम्भिक रणनीति समेटिएकोसरल संस्करणको “AIR रिपोर्ट”का रूपमा हस्तान्तरण गर्छौं (NDA मा हस्ताक्षर गरेर सञ्चालन)।अहिले नै सम्पर्क गर्नुहोस्।
सम्पर्क फारम(“निःशुल्क विश्लेषण (AIR रिपोर्ट) चाहिन्छ” भनी लेखिदिनुहोस्) / info@flagship-ai.jp
निःशुल्क अनलाइन सेमिनार“लिगेसी to AI ― IT उद्योगको औद्योगिक क्रान्ति, र २० वर्ष पुरानो Java प्रणालीलाई पुनर्जीवित गरेको वास्तविक अभिलेख”आयोजना हुने योजना (मिति मिलाइँदै)।पूर्व-दर्ता चाँडै सुरु हुनेछ ― यही ब्लगमा सूचना दिनेछौं।
शृंखला “लिगेसी to AI वास्तविक अभिलेख”
- समग्र संस्करण: एउटै PC मा २२ प्रणाली र 246,000 लाइन ― AI विकासको ३.५ महिनाको मापन-अभिलेख
- वास्तविक अभिलेख①: २० वर्ष पुरानो Java लाई, करिब एक हप्तामा पूर्ण नवीकरण
- वास्तविक अभिलेख②: विद्यमान कोडमा ० लाइन परिवर्तनसहित, मूल प्रणालीमा नयाँ प्रवेशद्वार बनाउने (यही लेख)
- वास्तविक अभिलेख③: एक महिना स्तरको संरचना अध्ययनलाई, दुई दिनमा प्रोटोटाइप + वास्तविक मापनले
※ यस लेखका अंकहरू २०२६ जुलाई अन्त्यको वास्तविक मापन हुन्। विकास परिणाम प्रणालीको अवस्था र आवश्यकताअनुसार फरक हुन्छ।