मैं तुरंत कहूंगा - मैं एक नौसिखिया वास्तुकार हूं जो सिस्टम प्रशासन से इस शिल्प के लिए पीछे हट रहा है।
इस लेख में निम्नलिखित विषयों पर चर्चा नहीं की जाएगी:
- मैं उद्योग में कैसे आया और सिस्टम प्रशासन की परेशानी;
- साने साहित्य और लेखों की उपस्थिति / अनुपस्थिति, सिस्टम आर्किटेक्ट्स के स्कूल;
- मैं एक नई स्थिति में कैसे महसूस करता हूं और भविष्य के लिए योजनाएं आदि।
परिचयात्मक भाग एक बड़ी कंपनी में एक वास्तुकार के स्थान की मेरी सीमित समझ के साथ शुरू होगा।
आईटी विभाग के रखरखाव और सॉफ्टवेयर विकास प्रक्रिया में कई प्रतिभागी हैं: विभिन्न दिशाओं के प्रोग्रामर, विश्लेषक, परीक्षक, सिस्टम प्रशासक, विभिन्न स्तरों पर तकनीकी सहायता आदि। उनमें से प्रत्येक या तो सिस्टम या पूरे सिस्टम का हिस्सा देखता है, लेकिन अपने दृष्टिकोण से (उदाहरण के लिए, एक प्रथम-स्तरीय तकनीकी सहायता विशेषज्ञ "सिस्टम को एक उन्नत उपयोगकर्ता के रूप में देखता है")।
थोड़ा दर्शन। एंटरप्राइज़ (एप्लिकेशन, डेटाबेस और रिपॉजिटरी, डेटा स्रोत, एकीकरण सेवाएं) की सभी जानकारी परिसंपत्तियाँ एक एकल इकाई हैं। एक आधुनिक उद्यम में पूरी तरह से स्वायत्त सेवाएं नहीं होती हैं। उन परिसंपत्तियों से जो उद्यम की सेवाओं के साथ बातचीत नहीं करते हैं, भविष्य में एकीकरण की आवश्यकता होगी।
तो, तर्क और डेटा के इस सभी बॉयलर में वास्तुकार से, एक विशेष चीज की आवश्यकता होती है - सूचना प्रणाली की वास्तु दृष्टि। एक वास्तुकार एक ऐसा व्यक्ति है जो लगभग सब कुछ और लगभग सब कुछ जानता है। नहीं, मेरा मतलब यह नहीं है कि वह कोड में आने और बग को ठीक करने में सक्षम है। मेरा मतलब है कि डेटा के मामले में "दृष्टि" और उनके बीच के रिश्ते। सूचना प्रणालियों का एकीकरण अब वास्तुकला का सबसे जटिल और महत्वपूर्ण कार्य है। सभी घर पहले से ही बनाए गए हैं - उद्यम अक्सर स्व-लिखित वाले खरीदे गए सिस्टम को पसंद करते हैं। हां, वे इमारतों में कॉस्मेटिक मरम्मत करते हैं, लेकिन यह सबसे महत्वपूर्ण बात नहीं है। (यदि आप किसी सॉफ्टवेयर कंपनी में काम नहीं करते हैं)। वास्तुकार का मुख्य कार्य संचार का निर्माण करना और बुनियादी ढांचे का निर्माण करना है।
लेकिन कंपनी, ज्यादातर मामलों में, एक अलग वातावरण में नहीं रहती है। क्या यह अच्छे बुनियादी ढांचे वाले शहर में समझ में आता है, जिसके लिए एक भी राजमार्ग नहीं है? कंपनी विभिन्न संगठनों और व्यक्तियों के आईटी सिस्टम के साथ सीधे या बिचौलियों के माध्यम से बातचीत करती है। इस तरह की बातचीत को व्यवस्थित करना कई बार अधिक कठिन होता है, क्योंकि आपको सिस्टम के सभी प्रतिभागियों के साथ एक्सचेंज के विषय और प्रारूपों के बारे में सहमत होना होगा। मामला इस तथ्य से सरल हो सकता है कि ये समझौते पहले ही पहुंच चुके हैं और अंतरराष्ट्रीय मानकों में निर्धारित हैं, लेकिन व्यवहार में, कुछ उन्हें पालन करते हैं।
अब थोड़ा "redecorating" के बारे में। हमारे शहर में पहले से ही आंतरिक और बाहरी बुनियादी ढाँचा है - और क्या लगता है अगर शहर में केवल लोग नहीं रहेंगे। और लोगों के पास लगातार नई ज़रूरतें हैं, अपार्टमेंट नवीकरण से लेकर नई इमारत के निर्माण तक। तो यह आईटी में है, जहां नई आवश्यकताओं की एक सतत धारा काफी सामान्य है। आर्किटेक्ट का कार्य आवश्यकताओं और उनके कार्यान्वयन का पता लगाना है, साथ ही उनके कार्यान्वयन पर निर्णय को प्रभावित करना है। हमें पूरी इमारत को नष्ट करने के लिए अपार्टमेंट में से एक में एक दीवार को ध्वस्त करने की अनुमति नहीं देनी चाहिए या हमने ऐसा घर बनाया है जिसकी किसी को जरूरत नहीं है।
ऐसे समय होते हैं जब डेवलपर्स एक उत्पाद जारी करते हैं जो उपयोगकर्ता की आवश्यकताओं को पूरा नहीं करता है। और यहां एक अप्रिय, लेकिन वास्तुकार के प्राथमिक कार्य सामने आते हैं - प्रोग्राम कोड में उपयोगकर्ता की आवश्यकताओं को लागू करने की प्रक्रिया को ट्रैक करने के लिए। वास्तुकार को न केवल निर्णयों को समझना चाहिए और दस्तावेज करना चाहिए, बल्कि इन निर्णयों को बनाने का कारण भी होना चाहिए।
पिछले पैराग्राफ से शिल्प प्रणाली वास्तुकार और शहरी योजनाकार के बीच मुख्य अंतर का पालन करता है। क्या आप तैयार हैं? मैं आपको एक सरल सत्य बताऊंगा - भौतिकी के नियम सॉफ्टवेयर की वास्तुकला को प्रभावित नहीं करते हैं! नहीं, निश्चित रूप से प्रणालीगत सीमाएं, सर्वोत्तम प्रथाएं, पैटर्न और सिद्धांत हैं। लेकिन इस सब को आसानी से दरकिनार किया जा सकता है, हम पत्थर और रेत दोनों से घर बना सकते हैं, और दोनों सैकड़ों साल तक चलेंगे। हम पृथ्वी के कोर के माध्यम से पाइपलाइन चला सकते हैं या घर को उल्टा रख सकते हैं - और यह सब पूरी तरह से काम करेगा यदि निर्णय संतुलित किया जाता है। सूचना संपत्ति, एक मायने में, वास्तविक नहीं हैं और डेवलपर की फंतासी उड़ान की कोई सीमा नहीं है (उचित सीमा के भीतर, निश्चित रूप से)।
डेवलपर्स की कल्पना को सीमित करने के तरीकों में से एक वास्तुशिल्प सिद्धांत और प्रतिबंध हैं। वे प्रणाली और व्यापार स्तर के नियमों का एक समूह हैं। उदाहरण के लिए, सिद्धांतों में से एक निम्नानुसार पढ़ा जा सकता है: "परियोजना के लिए हम ASP.Net तकनीक का उपयोग करते हैं"। इन सिद्धांतों के कारणों को तुरंत लिखना बुरा नहीं है।
स्वाभाविक रूप से, उपरोक्त सभी को दो स्थानों पर संग्रहीत किया जाना चाहिए: संक्षेप में वास्तुकार के सिर में और प्रलेखन में विस्तार से। दस्तावेज़ीकरण उपरोक्त सभी की तुलना में कम महत्वपूर्ण और जटिल कार्य नहीं है। विस्तार के संदर्भ में आर्किटेक्चर दस्तावेज़ स्वयं, आवश्यकताओं और स्रोत कोड के बीच कहीं होना चाहिए। यह दस्तावेज़ इस बात की एक कहानी है कि उपयोगकर्ता की आवश्यकताओं को एक सबसिस्टम में कैसे बदला जाता है।
दस्तावेज़ वास्तुकला की कठिनाइयों में से एक लगातार परिवर्तन है। और इन परिवर्तनों के इतिहास की निगरानी और रखरखाव के लिए कोई भी अस्पष्ट पद्धति नहीं है। मुझे इस दस्तावेज़ को बनाए रखने के सिद्धांतों की समझ नहीं है, लेकिन मैं अपने चक्र के तीसरे या चौथे लेख में उन्हें प्रकट करने का प्रयास करूंगा।
आज के लिए बस इतना ही। मैंने बहुत बड़े लेख नहीं लिखने का फैसला किया, लेकिन सब कुछ छोटे भागों में विभाजित करने के लिए (यह, वैसे, आर्किटेक्ट के कार्यों में से एक है)। अगले लेख में, हम वास्तुकारों की भाषा - यूएमएल और अमूर्त के बारे में बात करेंगे।
अद्यतन। मैं आपसे इस विषय पर टिप्पणी करने का अनुरोध करता हूं। मेरी क्षमता के स्तर का आकलन करने की आवश्यकता नहीं है।