Banks में Enterprise Architecture: Layers, TOGAF और Modernisation (CAIIB ITDB)
अगर आप CAIIB ITDB इलेक्टिव की तैयारी कर रहे हैं, तो आपको banks में enterprise architecture की ठोस समझ होनी चाहिए — सिर्फ एक exam टॉपिक के तौर पर नहीं, बल्कि उस discipline के तौर पर जो bank के technology decisions को board-approved strategy के साथ align रखती है। Banks में enterprise architecture यह मैप करता है कि business processes, applications, data और technology infrastructure आपस में कैसे जुड़े हैं, और leadership को आज के उलझे हुए systems से target state तक बिना operations को बीच में तोड़े पहुंचने का एक documented तरीका देता है। यह article चार architecture layers, banks द्वारा change की planning के लिए इस्तेमाल होने वाली TOGAF Architecture Development Method, monolith-to-microservices modernisation path, और governance mechanisms — architecture review boards और technical debt registers — को कवर करता है जो इस पूरी कवायद को ईमानदार बनाए रखते हैं।
🏛️ Enterprise Architecture की चार Layers
Banks में हर enterprise architecture framework — TOGAF भी शामिल — चार layers में organised होता है, जिन्हें अक्सर BDAT stack कहा जाता है। business layer strategy, organisation structure, processes और bank द्वारा बेचे जाने वाले products को कैप्चर करता है: current accounts, trade finance, retail loans वगैरह। यह इस सवाल का जवाब देता है कि bank क्या करता है और क्यों।
data layer उन entities को define करता है जिन्हें bank को consistently manage करना होता है — customer, account, collateral, transaction — चाहे उन्हें कोई भी system store करे। एक दर्जन product systems चलाने वाले bank को भी "customer" की एक ही authoritative definition चाहिए, इसीलिए data architecture किसी भी एक database से ऊपर बैठता है। यहां Database Management Systems chapter दोबारा देखना उपयोगी रहेगा, क्योंकि data-layer के decisions उन्हीं normalisation और referential-integrity concepts पर टिके होते हैं।
application layer systems की inventory है — core banking, CRM, loan origination, payment gateways — और वे आपस में data कैसे exchange करते हैं। technology layer उस infrastructure को कवर करता है जिस पर ये applications चलते हैं: servers, storage, networks और cloud platforms। Networking Systems chapter सीधे इसी layer पर लागू होता है।
जो architecture review सिर्फ applications देखता है और data lineage को नज़रअंदाज़ करता है, या infrastructure को बिना किसी business process से जोड़े document करता है, वह internal audit में टिक नहीं पाएगा। ये layers इसीलिए हैं ताकि किसी एक में हुआ बदलाव — जैसे किसी legacy core banking module को retire करना — ऊपर उस business capability तक ट्रेस किया जा सके जिसे वह सर्व करता है, और नीचे उन servers तक जिन पर वह चलता है।
🧭 Banking में TOGAF Architecture Development Method
Formal EA function चलाने वाले ज्यादातर Indian banks इसे TOGAF के Architecture Development Method (ADM) से एंकर करते हैं, जो आठ-से-ज्यादा phases का एक cycle है। Preliminary Phase architecture capability और principles सेट करता है; Phase A किसी दिए गए initiative के लिए architecture vision और scope define करता है, मान लीजिए एक digital lending platform।
इसके बाद Phases B, C और D क्रमशः Business, Information Systems (data और application) और Technology architectures को develop करते हैं — हर phase एक baseline, एक target, और दोनों के बीच का gap document करता है। Phase E opportunities identify करता है और बदलावों को काम करने-लायक projects में group करता है; Phase F sequencing और dependencies के साथ migration plan तैयार करता है; Phase G implementation को govern करता है ताकि delivered systems वाकई target architecture से मैच करें; और Phase H नए state के live होने के बाद change requests को manage करता है।
ADM एक cycle है, one-time exercise नहीं — जब भी business strategy बदलती है, जैसे कोई नया digital-only vertical या कोई acquisition जो दूसरा core banking platform साथ लाए, bank Preliminary Phase को दोबारा देखता है।
💡 Exam Tip: ADM phase order याद रखें Preliminary → A → B → C → D → E → F → G → H; CAIIB के सवाल अक्सर यह टेस्ट करते हैं कि बताई गई activity किस phase में आती है।
ADM को किसी concrete चीज़ पर लागू करने से यह याद रह जाता है। Introduction to Computing chapter पढ़ने के बाद, अपने bank के हर बड़े system को एक mini gap analysis के candidate की तरह ट्रीट करें: यह आज क्या करता है, target state में इसे क्या करना चाहिए, और इस gap को बंद करने के लिए आप किस ADM phase का इस्तेमाल करेंगे।
🔄 Monolith से Microservices: Modernisation Roadmap
ज्यादातर Indian banks अभी भी एक monolithic core banking system चलाते हैं: एक बड़ा, tightly coupled application जो accounts, deposits और general ledger को साथ handle करता है। छोटे scale पर monolith चलाना आसान होता है, लेकिन जैसे-जैसे transaction volumes और digital channels की संख्या बढ़ती है, यह bottleneck बन जाता है — एक छोटे bug fix के लिए भी पूरे system को test और redeploy करना पड़ सकता है।
Microservices architecture उस monolith को छोटे, independently deployable services में तोड़ देता है — मान लीजिए account opening के लिए एक अलग service और interest calculation के लिए दूसरी — हर एक अपना data खुद रखती है और APIs के जरिए expose होती है। इससे bank अपने mobile-banking-facing services को हर हफ्ते update कर सकता है, बिना नीचे के general ledger engine को छुए।
यह transition शायद ही कभी एक झटके में होता है। Banks आमतौर पर strangler fig pattern इस्तेमाल करते हैं: नई functionality monolith के किनारों पर microservices के रूप में बनाई जाती है, traffic को धीरे-धीरे नए services की तरफ route किया जाता है, और legacy core को घोंटकर सिर्फ उन functions तक सीमित कर दिया जाता है जिन्हें decompose करना वाकई मुश्किल है, जैसे core ledger posting।
⚠️ Common Mistake: Modernisation को एक single big-bang cutover मान लेना। एक phased transition state — monolith और microservices को साथ-साथ चलाना, साफ data-ownership boundaries के साथ — यही वह चीज़ है जो target-state EA document में transition roadmap को दिखाना चाहिए।
यही transition state असल में target-state architecture और transition roadmap का मकसद है: सिर्फ अंतिम तस्वीर नहीं, बल्कि वे intermediate states भी जिनसे होकर bank गुजरेगा, हर एक का अपना risk profile और rollback plan होगा।
🛡️ Architecture Review Board और Technical Debt
Architecture Review Board (ARB) वह governance body है जो build में जाने से पहले यह approve करती है कि प्रस्तावित system design bank के target-state architecture और principles के अनुरूप है या नहीं। इसमें आमतौर पर Chief Technology Officer या Enterprise Architect शामिल होते हैं, साथ ही information security, data governance और sponsoring business unit के representatives भी। किसी भी बड़े system change को यह review bypass नहीं करना चाहिए, क्योंकि इसी तरह architectural drift — और technical debt — बिना पता चले जमा होती जाती है।
Technical debt shortcuts की accumulated cost है: standard integration layer इस्तेमाल करने के बजाय एक point-to-point integration बना देना, redesign करने के बजाय database schema को patch कर देना, कोई legacy language जिसे अब कोई maintain नहीं कर सकता। अगर track न किया जाए, तो technical debt हर आने वाले project को धीमा कर देता है, क्योंकि नए काम को उसके इर्द-गिर्द रास्ता निकालना पड़ता है। एक disciplined ARB architecture roadmap के साथ-साथ एक technical debt register भी रखता है ताकि debt को जानबूझकर चुकाया जाए, किसी outage के दौरान अचानक खोजा न जाए।
| Governance Element | उद्देश्य | Go-Live से पहले Review |
|---|---|---|
| Architecture Review Board | Target-state EA और principles के विरुद्ध design approve करता है | ✅ हां |
| Technical Debt Register | Shortcuts और उनकी remediation plan को track करता है | ✅ हां |
| Ad hoc point-to-point integration | Standard integration patterns के बाहर बनाया गया quick fix | ❌ कोई formal sign-off नहीं |
| Transition Roadmap | Baseline से target state तक जाने के move को sequence करता है | ✅ हां |
यहीं पर banks में enterprise architecture वापस board oversight से जुड़ता है। RBI के IT governance guidance के तहत, board और IT Strategy Committee से यह देखने की अपेक्षा की जाती है कि technology decisions किसी approved strategy तक ट्रेस हों — एक working technical debt register वाला ARB इस link का operational सबूत है।
🚀 आपके CAIIB Exam के लिए सब कुछ एक साथ
CAIIB ITDB के लिए, examiners उम्मीद करते हैं कि आप banks में enterprise architecture को असली governance से जोड़ें: चार BDAT layers, TOGAF ADM phase sequence, monolith-to-microservices modernisation के लिए transition roadmap, और एक Architecture Review Board जो technical debt को छुपाने के बजाय visible रखता है। हर concept को अलग-अलग definitions की तरह नहीं, बल्कि एक ही story के हिस्से की तरह ट्रीट करें — strategy से लेकर servers तक। नीचे दिए MCQs को attempt करने से पहले इसे हमारे CAIIB course में practice sets के साथ reinforce करें।
Introduction to Software chapter कवर करने के बाद, इसे हमारे related reads के साथ जोड़ें — banks में IT service management पर, यह समझने के लिए कि change requests असल में कैसे execute होते हैं, और banks में data governance पर, यह जानने के लिए कि data layer को trustworthy कैसे रखा जाता है। अगर आप banking IT infrastructure में network security भी कवर करते हैं, तो आपके पास technology-layer risk की तस्वीर भी होगी। और क्योंकि architecture decisions आखिरकार bank के risk profile को आकार देते हैं, यह देखना भी worth है कि banks में credit risk models कैसे उसी clean, well-governed data architecture पर depend करते हैं।
ITDB पर और coverage Information Technology and Digital Banking tag hub पर देखें, फिर नीचे खुद को टेस्ट करें।
🧠 Practice MCQs: Banks में Enterprise Architecture
Q1. TOGAF के ADM में, कौन-सा phase Information Systems और Technology Architectures define होने से पहले Business Architecture develop करता है? (a) Phase A - Architecture Vision (b) Phase B - Business Architecture (c) Phase E - Opportunities and Solutions (d) Phase H - Architecture Change Management
उत्तर: (b) — Phase B Business Architecture तैयार करता है, जो Phases C और D में होने वाले data, application और technology काम का baseline बनता है।
Q2. Banks में enterprise architecture में इस्तेमाल होने वाली BDAT (Business, Data, Application, Technology) layering में, "customer" और "account" जैसी entities की authoritative definition, किसी एक system से स्वतंत्र, कौन-सी layer में रहती है? (a) Business layer (b) Data layer (c) Application layer (d) Technology layer
उत्तर: (b) — data layer shared entities को उन सभी applications में consistently define करता है जो उन्हें इस्तेमाल करते हैं, बजाय इसके कि हर system अपना अलग version define करे।
Q3. एक bank deadline पूरा करने के लिए दो systems के बीच standard integration pattern इस्तेमाल करने के बजाय एक quick point-to-point interface बना देता है। EA की भाषा में, इस shortcut को सबसे अच्छी तरह क्या कहा जाएगा? (a) Target-state architecture (b) Technical debt (c) Architecture principle (d) Transition roadmap
उत्तर: (b) — approved architecture से short-term सुविधा के लिए लिया गया कोई भी deviation, अगर unresolved छोड़ दिया जाए, तो वह technical debt है।
Q4. किसी नए system design के bank के target-state architecture के अनुरूप होने को build से पहले approve करने की मुख्य जिम्मेदारी किस governance body की होती है? (a) Credit Committee (b) Architecture Review Board (c) Asset Liability Committee (d) Audit Committee
उत्तर: (b) — Architecture Review Board, build शुरू होने से पहले प्रस्तावित designs को approved architecture principles और target state के विरुद्ध review करता है।
Q5. Monolithic core banking system को microservices में modernise करते समय, "strangler fig pattern" का मतलब क्या है? (a) एक ही cutover में पूरे monolith को replace करना (b) Monolith के इर्द-गिर्द नई functionality को microservices के रूप में बनाना और धीरे-धीरे traffic को उससे दूर route करना (c) Disaster recovery के लिए twin data centres चलाना (d) Migration से पहले legacy databases को encrypt करना
उत्तर: (b) — नए microservices monolith के किनारों पर उगाए जाते हैं और traffic को क्रमिक रूप से shift किया जाता है, ताकि legacy system को रातों-रात replace करने के बजाय धीरे-धीरे घोंटा जाए।
100+ MCQs वाले chapter-wise mock tests चाहिए? मुफ्त practice शुरू करें →
Banks में enterprise architecture क्या है?
यह bank के business processes, applications, data और technology infrastructure को एक coherent, documented structure में मैप करने की discipline है, ताकि IT investments board-approved strategy तक ट्रेस हो सकें और operations तोड़े बिना modernise किए जा सकें।
Bank enterprise architecture frameworks में इस्तेमाल होने वाली चार layers कौन-सी हैं?
Business, Data, Application और Technology — जिन्हें अक्सर BDAT stack कहा जाता है। TOGAF अपने Architecture Development Method को इन्हीं layers को current baseline से एक defined target state तक develop करने के इर्द-गिर्द organise करता है।
Banks TOGAF का इस्तेमाल enterprise architecture के लिए क्यों करते हैं?
TOGAF का Architecture Development Method एक repeatable, phase-by-phase process देता है — vision से लेकर business, data, application और technology architecture होते हुए migration planning और governance तक — जिसे banks जैसे बड़े, regulated organisations कई projects में standardise कर सकते हैं।
Architecture Review Board की भूमिका क्या है?
यह build शुरू होने से पहले प्रस्तावित system designs को bank के target-state architecture और principles के विरुद्ध review और approve करता है, और technical debt को track करता है ताकि deadline के दबाव में लिए गए shortcuts भुलाए न जाएं बल्कि ठीक किए जाएं।
Quick quiz on this topic
5 exam-style questions from our free test bank — check yourself before you move on.
Practice this topic
मुफ़्त मॉक टेस्ट दें, चैप्टर PDF डाउनलोड करें या वीडियो क्लास देखें — सब iibf.store पर मुफ़्त है।
पढ़ना जारी रखें
