آشنایی با معماری مداوم
طاهره مصطفویدر۱۴۰۳/۲/۱۸
ندائي به ما مي گويد معماران آينده باشید نه قربانيان آینده "آر. باكمينستر فولر"
هر دوي ما خودمان را معمار صدا مي زنيم چرا كه معتقديم براي كارهايي كه هر روز سرِ كار انجام مي دهيم عنوان بهتر ديگري وجود ندارد. در کل مسير کاریمان كه فروشندگان سخت افزار و نرم افزار، شركت هاي مشاوره اي مديريتي و موسسات مالي بزرگ بوده ايم، كاري را انجام داده ايم كه مي توان آن را كار نرم افزاري، ارائه راه حل و معماري سازماني ناميد. با همه اين اوصاف، وقتي مي گوئيم «ما معماريم»، می طلبد که هميشه آن را با بيان كيفي تري ابراز كنيم. به باور ما به توضيحي نياز داريم تا بتوانيم خودمان را از لفظ كليشه اي «معمار فناوري اطلاعات (IT)»، كه عملا چيزي به ارزش هاي ما نمي افزايد، متمايز سازيم. به احتمال زياد، بيشتر خوانندگان با اين توضيح عمومي كه «من معمار هستم اما، كار من تحويل/نوشتن كد/سروكار داشتن با مشتري است» آشنا هستند .
سوال اين است كه چگونه تصور معماری برج عاج (گوشه خلوت) تا اين حد به تصوری غالب تبديل شده است؟
اطمينان قلبی مان این است كه در اين طرز فكر تنها نيستيم. به باور ما، معماراني كه كيفيت كارشان به مثابه كيفيت افتضاح كارهاي ساده دانشمندان ديوانه، سرهم بندكنندگان فناوري و يا معتادان ارائه آمار و اطلاعات است، در اقليت فعالان معماري هستند و اكثريت معماران در قالب بخشي از تيم تحويل نرم افزار به شكلي اثربخش كار مي كنند و شايد بيشتر وقت ها خودشان را معمار هم ننامند. جانِ كلام اينكه، همه نرم افزارها داراي معماري هستند و اكثر محصولات نرم افزاري مجموعه كوچكي از توسعه دهندگان ارشد را در خود دارند كه صرف نظر از اين كه كارشان مستندسازي بشود يا خير، معماري پايداري را ايجاد مي كنند.
در مسير حرفه اي خودمان، متوجه سرعت فزاينده زمان تحويل مورد انتظار از فعالان IT در سازمان ها شده ايم. همزمان، شاهد اين بوده ايم كه كاربران نهايي انتظار سهل الاستفاده بودن محصولات و استفاده همه روزه و همه ساعته از آن ها را در زندگي روزانه دارند و اين نبوده است جز در سايه توسعه پرقدرت فناوري. ما از كامپيوترهاي خانگي به تبلت و به گوشي هاي هوشمند، و در حال حاضر به فناوري هاي قابل پوشيدن ترقي كرده ايم. امروزه، از تيم هاي تحويل نرم افزار انتظار مي رود تا در زمان و مقياس اينترنتي كار كنند. اين امر موجب افزايش معنادار تقاضا، و نهايتا، منجر به گسترش استفاده از روش های تحويل چابك و مداوم شده است.
نتيجه کار اين بوده است كه اين مفهوم جديد کوکی جدا از ساز معماري نرم افزار سنتي، و بويژه معماري سازماني، دارد و اعتقادي هم نداريم كه بنا دارد به نوای همان ساز روش های سنتي برگردد. با اينحال، هنوز به رويكرد معماري نياز داريم كه بتواند تحويل مداوم را در سيطره خود داشته باشد و دورنماي معماري وسيعتري براي آن فراهم آورد. اين همان موضوعي است كه در اين كتاب به آن مي پردازيم. پيش از تعريف معماري مداوم، اجازه دهيد تا تعريفي را از معماري نرم افزار ارائه دهيم و سپس چشم انداز تاريخي آن را مطالعه كنيم.
منظورمان از معماري چيست؟
وقتي درباره معماري حرف مي زنيم منظورمان معماري نرم افزار است. خب، خود اين معماري نرم افزار را چگونه تعريف مي كنيم؟ با هم نگاهی به بعضي از تعاريف رايج می اندازيم.
تعريفي كه در ويكيپديا توسط IFIP WG 2.10 براي معماري نرم افزار ارائه شده است به اين شرح است:
معماري نرم افزار به ساختارهاي سطح بالاي سيستم نرم افزاري، نظام حاكم بر ايجاد اين ساختارها و مستندسازي اين ساختارها اطلاق مي شود. معماري نرم افزار مجموعه اي از ساختارهاست كه براي ارائه ادله درباره سيستم نرم افزاري به آن ها نياز داريم. هر ساختار متشكل است از عناصر نرم افزاري، ارتباط بين آن ها و ويژگي هاي هم عناصر و هم ارتباطات. معماري سيستم نرم افزاري استعاره اي از معماري ساختمان است.
سازمان بين المللي استانداردها و انجمن مهندسان برق و الكترونيك (IEEE) تعريف زير را بكار مي برند:
معماري عبارت است از مفاهيم بنيادي يا ويژگي هاي يك سيستم در محيط خود كه در عناصر، روابط بين عناصر و اصول طراحي و تكوين آن نهفته است.
در اين مقاله بطور خاص با دغدغه هاي IT در فرآيند توسعه محصول در يك واحد تجاري سروكار داريم. 4 ركن معمول توسعه معماري نرم افزار عبارتند از:
1- تعريف اصول و استانداردهاي راهنما:
معماري ديدي از آينده است و از ابزارهايي كه براي رسيدن به آن نقطه به شما كمك مي كنند پشتيباني مي كند.
2- توسعه مدل هاي معماري:
در اين حالت، معماري با ساده سازي كار تا سطحي مناسب سروكار دارد تا تصميمات كاري و فني اتخاذ شود.
3- ايجاد خدمات مشترك:
اين خدمات ممكن است سيستم يا سازمان باشند. مي توان معماري را تمركز روي اينترفيس هاي تعیین کننده تعريف كرد.
4- تهيه نقشه راه وضعيت آتي IT:
معماري با فعاليت هاي برنامه ريزي گذرائي سروكار دارد كه به پياده سازي موفقيت آميز طرح اوليه IT منجر مي شود.
وفق اهداف فوق الاشاره، ايجاد سيستم نرم افزاري بزرگ و كاملا اثربخش و كارآمد به طرح اوليه اي كه معمولا به آن «معماري نرم افزار» اطلاق مي شود نياز دارد. اين معماري شامل هم مدل هاي توصيفي است (كه در هر دو وجهه كسب و كار و فناوري تعريف مي شوند) تا به تصميم سازان در فهم اين نكته كمك كند كه امروزه يك نهاد به چه شكل كار مي كند و مي خواهد در آينده به چه شكل كار كند، و هم شامل مدل هاي تجويزي است كه به تيم پروژه كمك مي كند تا با موفقيت به وضعيت مطلوب IT خود گذر كند.
دورنماي تاريخي
بيائيد تا به تاريخچه تكامل كامپيوتر و صنعت نرم افزار نگاهي گذرا بيندازيم. در اينجا هدف ما شرح كامل تاريخچه اين موضوع نيست و تنها به برخي از توسعه هاي كليدي در اين مسير اشاره مي كنيم تا معماري مداوم را در بستر دورنماي تاريخي ورانداز كنيم.
با نگاه به تاريخچه فناوري كامپيوتر، بررسي دو جنبه جالب توجه خواهد بود: نقاط عطف اصلي فناوري و مفاهيمي كه حول توسعه نرم افزار و معماري نرم افزار در حركتند.
مي توانيم نقاط عطف عمده صنعت كامپيوتر را به شكل زير بازگو كنيم:
1- عصر كامپيوترهاي mainframe (دهه 1950 و به بعد): اين عصر اساسا در دهه 1950 آغاز شد. در اين عصر كامپيوترهاي mainframe پاراديم اصلي محاسبات به شمار مي رفتند. اين كامپيوترها ماشين هاي گران و قدرتمندي بودن كه شركت هاي بزرگ را قادر مي ساختند تا جنبه هاي خاصي از كسب و كار خود را مكانيزه، و از توسعه علمي پشتيباني كنند.
2- خانگي شدن كامپيوتر (دهه 1970 و به بعد): اين عصر زماني آغاز شد كه كامپيوترهاي شخصي (PC) به شكلي كه امروزه آن ها را مي شناسيم وارد عرصه شدند. اين عصر گام رو به جلوي بزرگي از اين نظر بود كه مي شد قدرت محاسباتي را در ماشيني قرار داد كه مي توان آن را روي ميزي قرار داد. اين امر افراد را قادر می ساخت تا تعامل خصوصی تری با كامپيوتر داشته باشند. با اينحال، هنوز هم اكثر كاربران اين فناوري در شركت هاي بزرگ و موسسات تحقيقاتي بودند.
3 - توزيع بار (دهه 1980 و به بعد): با رشد ظرفيت كامپيوترها و شروع شبكه اي شدن آن ها، مفهوم معماري سرور مشتري (Client server) رشد خود را آغاز كرد. اين امر به بينشي منتج شد كه بر اساس آن ضرورتي نداشت تا همه نرم افزارها در يك كامپيوتر اجرا شوند و مي شد حجم محاسبات را به اشتراك گذاشت. در آن زمان، ، موضوعات اصلي معماري عبارت بودند از معماري سرور مشتري و نحوه توزيع مسئوليت ها و كارها بين كامپيوترها به بهترين شكل ممكن. با رشد و تكوين پارادايم سرور مشتري، مفهوم كامپيوترهاي تحت شبكه نيز رشد و توسعه يافت.
4- عصر اتصال (دهه 1990 و به بعد): اصطلاح «شبكه كامپيوتر» در سال 1984 عرضه شد (اين اصطلاح به جورج گيج، پژوهشگر مسئول و پنجمين كارمند شركت سان ميكروسيستم نسبت داده مي شود)، اما 10 سال طول كشيد تا اولين جستجوگر تجاري معرفي شود (جستجوگر موزائيك، Mosaic، در نوامبر سال 1993 معرفي شد). وب جهاني و انقلاب اينترنت اثرات شگرفي روي نه تنها صنعت نرم افزار كه كل جهان داشت. در اينجا مجال كافي براي توضيح مفصل اين اثرات نداريم اما، ناگفته پيداست كه همه چيز از نحوه خريد كردن ما تا نحوه ارتباطات ما و حتي نحوه تعاملات ابزارهاي مكانيكي ما تغيير كرده است.
5 - بازگشت به آينده (دهه 2000 به بعد): با بودن اينترنت در همه جا، اين فرصت ايجاد شد تا خودمان را از وابستگي به ابزارهاي فيزيكي رها كنيم. توانائي ذخير ه سازي و بازيابي اطلاعات از سيستم ابري (cloud) حتي باعث پيدايش فرصت ها، و البته چالش هاي، بيشتري هم مي شود. براي نمونه، هميشه صاحب فيزيكي كتابي كه آن را از e readers مي خريم نيستيم. شركتي كه اين كتاب ها را به ما مي فروشد صاحب محتواي آن هاست و حق حذف آن ها را دارد، چيزي كه در كتاب هاي فيزيكي قديمي امكان آن وجود نداشت. بحث درباره اخلاق اينترنتي و محاسبات ابري را به ديگر نويسندگان وا مي نهيم و به بحث معماري خودمان بازمي گرديم.
عصر محاسبات ابري واحدهاي تجاري را قادر ساخته است تا فقط نرم افزارهاي مورد نياز را بدست آورند و نسبت به محاسبه ظرفيت اقدام كنند. ما اين عصر را عصر «بازگشت به آينده» مي ناميم چرا كه در حال برگشت به مدل ظرفيت ليزينگ هستيم كه دقيقا مدل موجود در روزگار mainframe بود و تنها تفاوت در آن است كه اين مدل را در دنياي به شدت در هم تنيده، استاندارد شده و زمان واقعي پياده مي كنيم.
دنياي كامپيوتر و نرم افزار به رشد خود ادامه خواهند داد و هم اينك فاز بعدي كه دستگاه هاي قابل حمل و كامپيوترهاي قابل پوشيدن است در حال ظهور است. تنها چيزي كه در طول اين سفر تقريبا نيم قرني دست نخورده باقي مانده است اين است كه توسعه دهندگان نرم افزار هنوز هم كد مي نويسند. چيزي كه هنوز هم جالب است اين است كه بهره وري توسعه دهندگان نرم افزار هنوز هم كاملا متغير است و نوآوري هنوز هم به نقش توسعه دهنده نرم افزار مربوط است. اساسا، در مورد نرم افزار هنوز هم در مرحله حرفه و مهارت هستيم و هنوز نتوانسته ايم انقلاب صنعتي و اتوماسيوني را كه در هر مرحله از اين سفر طولاني مدت وعده آن داده شده بود، در اين حوزه به انجام برسانيم. با همه این اوصاف، آنچه كه تغيير كرده است سرعت مورد انتظار ما از اجرا و نيز مقياس مورد نياز ما براي كار است. چرخه هاي ارائه سه ماهه ديگر موضوعيت ندارند و راه حل هاي تجاري بايد خوراك تقاضاي فزاينده از جانب كاربران نهايي را از نظر عملكرد، قابليت استفاده و مقياس پذيري فراهم آورند.
حال بيائيد ببينيم رويكرد توسعه نرم افزار و معماري در طول اين سفر به چه شكل تكامل يافته است. همانطور كه قبلا گفتيم، بعضي چيزها دست نخورده باقي مانده اند. در بخش زيادي از اين سفر، برنامه نويسي ساختاريافته با ما همراه بوده است. برنامه ريزي ساختار يافته عناصر كليدي را كه توسط معمار و توسعه دهنده در آن زمان شناسائي مي شدند برجسته مي سازد و در نتيجه ساختاري منطقي را بر اساس مدولاريته بودن بنا مي نهد.
دهه 1980 شاهد شروع پيدايش برخي از الگوهاي كليدي معماري بود. مدل ارتباط سيستم باز (Open System Interconnection, OSI) در حوزه شبكه نمونه اي عالي از ايجاد معماري لايه اي است. مي توان چنين در نظر گرفت كه مفاهيم معماري سازماني با معرفي چهارچوب زاچمن (Zachman)، كه تيره اي از فناوري را ايجاد كرد كه امروزه هنوز هم معتبر است، ظهوري جهشي داشته اند.
از اوايل تا اواسط دهه 1990شاهد انفجار ايده ها بوده ايم از موارد استفاده گرفته تا UML و برنامه نويسي مفرط (Extreme Programming, XP). اين اتفاق زماني رخ داد كه برنامه نويسيِ هدف محور در اوج بود و خودِ اين امر به تلاش هايي براي ايجاد روش ها و فنوني درخورِ اين دنياي جديد انجاميد. همچنين ، اين رخداد همگام با شروع انفجار اينترنت بود حتي اگر واقعا هم آنجا نبوده ايم.
اثرات عصر اينترنت و نيز تقاضا براي تحويل سريع تر نرم افزار منجر به ارائه مفهوم بيانيه توسعه چابك يا agile manifesto گرديد. نکته جالب آن است كه اين مفهوم درست پس از انفجار حباب دات كام ارائه شد. به مرور زمان، شاهد پذيرش تدريجي رويكرد چابك و تكامل آن به تحويل مستمر و مفاهيم DevOps بوده ايم. به موازات، مفهوم معماري سازماني در لابلاي امواج محبوبيت و سرخوردگي پس و پيش شده است. اين كه استاندارد The Open Group Architecture Forum (TOGAF) هنوز فعال است گواه اين است كه هنوز هم تقاضا برای رسیدگی به دغدغه هاي معماري سطح سازماني وجود دارد. با اينحال، معتقديم كه مفهوم معماري نرم افزار، و بويژه ارتباط معماري سازماني با توسعه دهندگان نرم افزار، در شركت هاي بزرگ در حال كم شدن است. حتي اگر گروه هاي معماري سازماني هم وجود داشته باشند، اثرات اين گروه ها روي توسعه روز به روز محدود شده است.
فعاليت هاي گروه هاي معماري سازماني محكوم به شكست است چيزي كه ما آن را آزمايش تورنسل «توسعه دهنده اصلي» مي ناميم. اين آزمايش تورنسل تاييد مي كند كه بسياري از تصميمات معماري توسط توسعه دهندگان در خلال كار اتخاذ مي شوند، جايي كه چالش ها و فرصت ها شناسايي مي شوند. اگر توسعه دهنده اصلي تيم تصميات خود را بر اساس راهنمايي هاي معماران اتخاذ كند، آزمايش تورنسل اين نكته را تاييد خواهد کرد. معتقديم كه فاصله بين تحويل چابك و اقدامات معماري در داخل شركت تجاري بيشتر از قبل است. اين همان جائي است كه معماري مداوم وارد صحنه مي شود. معماري مداوم مجموعه اي از اصول و ابزارهاست كه هدف آن رسیدگی به اين فاصله است.
روش ديگر توضيح معماري مداوم، قياس آن با معماري در زندگي واقعي است. اگر بخواهيم كليساي جامعي بسازيم، توسعه دهنده چابك كار حفاري را سريعا شروع خواهد كرد اما، معمار سازماني نگاهي به برنامه 5 ساله خواهد داشت. هدف معماري مداوم پل زدن روي اين فاصله است . (سیارک)
