چابکی به زبان ساده، توانایی سازمان برای واکنش کارآمد و مؤثر در برابر انواع تغییرات است (Hanschke) و با توجه به اینکه بر اساس نتایج برخی تحقیقات، بیش از نیمی از سازمان‌ها از روش‌های چابک در معماری سازمانی استفاده می‌کنند، در این بخش به معرفی این متد می‌پردازیم.
مفهوم چابکی در توسعه نرم‌افزار
در رویکردهای سنتی (قدیمی) مهندسی نرم‌افزار، فرایند توسعه و راه‌اندازی مبتنی بر مدل آبشاری[1] بود که در آن با تکمیل هر مرحله، پرونده آن بسته شده و مرحله جدید آغاز می‌شد و این رویکرد برای هر نوع نرم‌افزار (با هر پیچیدگی، ابعاد و نیازمندی) مراحل ثابت و مشخصی را دارا بود. یکی از مهم‌ترین چالش‌های این رویکرد، موضوع نیازمندی‌های وظیفه‌مندی و غیروظیفه‌مندی ذینفعان (کاربران) بود که ماهیتاً در یک مرحله به‌صورت کامل قابل جمع‌آوری و نهاییسازی نبود. چالش دیگر موضوع خطاهای نرم‌افزاری بود که بسیار از آن در مراحل پایانی خود را نشان می‌داد و درنتیجه برای اصلاح برنامه، نیاز به‌صرف زمان و هزینه بالایی بود. طولانی شدن زمان انتشار اولین خروجی قابل‌اجرا از سیستم از دیگر ریسک‌های این رویکرد سنتی بود و دَه‌ها مورد دیگر که برای برنامه‌نویسان کاملاً شناخته شده است و نیازی به تکرار آن در این نوشته نیست.
رویکرد چابک در توسعه نرم‌افزار برای رفع مشکلات گفته‌شده به وجود آمد، اگرچه نشانه‌های اولیه از ظهور مفاهیم توسعه تکرارشونده و افزایشی[2] به دهه 1950 در آمریکا برمی‌گردد، در دهه 1970 تجاربی از اجرای این رویکرد در پروژه‌های نرم‌افزاری گزارش شد و نهایتاً در دهه 1990 به‌صورت رسمی رویکرد چابک در توسعه نرم‌افزار فراگیر شد و مورد استقبال بسیاری از برنامه‌نویسان ناامید از روش‌های آبشاری قرار گرفت.
بر اساس مانیفست چابک، چهار ارزش اصلی مدنظر در توسعه نرم‌افزار عبارت‌اند از:
- ارزش بیشتر به اشخاص و تعاملات نسبت به فرایندها و ابزارها
- ارزش بیشتر به نرم‌افزار قابل‌اجرا نسبت به حجم وسیع مستندسازی
- ارزش بیشتر به همکاری با مشتری نسبت به پافشاری بر شروط قرارداد
- ارزش بیشتر به استقبال از تغییرات نسبت به تبعیت از برنامه تعریف‌شده
مانیفست چابکی که توسط گروهی از صاحب‌نظران تهیه شد و شامل چهار ارزش کلیدی فوق و دوازده اصل برای تبیین چگونگی پیاده‌سازی این ارزش‌هاست، به‌عنوان چتری دربرگیرنده تعدادی از روش‌های توسعه نرم‌افزار ازجمله Scrum، [3]XP، FDD[4] و… محسوب می‌شود، همچنین این رویکرد نیز موافقان و مخالفانی دارد و نقدها و تحسین‌های مختلفی را به همراه داشته که قصد ورود به جزییات این مباحث را نداریم و خوانندگان می‌توانند به مراجع تخصصی روش‌های توسعه چابک نرم‌افزار مراجعه نمایند؛ مقدمات گفته‌شده صرفاً پیش‌نیازی برای بررسی نحوه تلفیق چابکی با مفاهیم معماری سازمانی در ادامه است.
متد چابک در معماری سازمانی
طرز فکر چابکی بر چهار ارزش کلیدی و تعدادی اصول استوار است که تحقق و تجسم آن‌ها در قالب روش‌شناسی‌های توسعه نرم‌افزار منجر به خلق روش Scrum، XP و موارد مشابه شده است. به همین روال، متد معماری سازمانی چابک نیز در قالب تعدادی رکن کلیدی تبیین می‌شود که تحقق این اصول به خلق چارچوب‌ها و روش‌شناسی‌های چابک یا تطبیق روش‌شناسی‌های موجود خواهد انجامید. بر اساس منابع و دیدگاه صاحب‌نظران می‌توان سه رکن کلیدی در متد معماری سازمانی چابک را به‌صورت زیر تبیین نمود:
- چرخه‌های تکرار متعدد و موازی در معماری
- عدم تبعیت مطلق از یک چارچوب یا روش‌شناسی
- مشارکت فعالانه و پیوسته ذینفعان
در ادامه هرکدام از سه ارزش فوق، به‌تفصیل بررسی شده‌اند.
الف) چرخه‌های متعدد و موازی تکرار در معماری
یکی از ارکان اصلی متد معماری سازمانی چابک، شکستن یک پروژه (طرح) معماری به تعدادی چرخه تکرار کوچک‌تر و قابل مدیریت‌تر است. هر چرخه می‌تواند متناظر با یک حوزه (بخش) از دامنه سازمان، یک سطح از جزییات معماری، یا یک صورت‌مسئله (گروهی از نیازمندی‌های مرتبط) باشد که در قالب یک چرخه انجام می‌شود؛ چرخه‌های تکرار می‌توانند به‌صورت موازی انجام شوند یا حتی یک چرخه به زیرچرخه‌های کوچک‌تر نیز شکسته شود. به‌هرحال هدف نهایی عبارت است از تسریع آماده شدن خروجی‌ها با کمک تصحیح مسیر برای تیم معماری و افزایش حمایت از ذینفعان و تحویل‌گیرندگان.
چارچوب‌های (روش‌شناسی) موجود معماری به‌خوبی از چرخه‌های تکرار حمایت می‌کنند. برای مثال ADM چارچوب توگف یا روش‌شناسی چارچوب ملی معماری سازمانی ایران نه‌تنها از چرخه تکرار حمایت می‌کند بلکه آن را توصیه می‌کند. این چرخه‌های تکرار حتی می‌تواند شامل زیرچرخه‌های تکرارشونده و بازگشتی نیز باشد که در شکل زیر نشان داده شده است.
چارچوب‌های دیگر نیز مانند فدرال با تقسیم کل پروژه معماری به «قطعات معماری» و تأکید بر روش توسعه معماری همکارانه از مفهوم چرخه‌های تکرار و توسعه تکاملی حمایت می‌کنند. آنچه باید به آن تأکید داشت این است که صرف ذکر مفهوم چرخه در روش‌شناسی معماری (بعضاً اضافه کردن یک پیکان بازخورد) منجر به چابکی و تحقق ارزش‌های آن نمی‌شود، بلکه تفکر توسعه تکرارشونده و افزایشی باید در تاروپود روش‌شناسی و تکنیک‌های معماری تجسم یابد.
ب) عدم تبعیت مطلق از یک چارچوب یا روش‌شناسی
تبعیت مطلق و همیشگی از یک چارچوب، فرایند یا ابزار برای معماری منجر به فراموش‌شدن نیاز خاص هر مشتری و شرایط ویژه هر صورت‌مسئله می‌شود. با توجه به اینکه در قلمرو دانش معماری مکاتب فکری مختلف، چارچوب‌ها و روش‌شناسی‌های متنوع و مجموعه‌ای از تکنیک‌ها و استانداردها وجود دارد؛ از طرف دیگر در هر سازمان (پروژه) نوع صورت‌مسئله، ابعاد کار، پیچیدگی موضوع، نوع نیازمندی‌ها، فرصت‌ها و تهدیدهای پیرامونی، بلوغ و مقاومت سازمانی و بسیاری فاکتورهای دیگر، متفاوت است؛ بنابراین تبعیت صرف از یک چارچوب یا ابزار در تمامی پروژه‌ها یکی از مهم‌ترین عوامل شکست معماری سازمانی خواهد بود.
لازم به تأکید است که اهمیت مهارت و خبرگی معمار در تشخیص صحیح موقعیت و شرایط هر پروژه (سازمان) و تعیین مسیر و رویکرد خاص برای آن است. محدود شدن معمار (معماری) به یک چارچوب، روش‌شناسی یا یک روال (دستورالعمل) ثابت و اصرار بر تبعیت از همه جزییات آن بدون توجه به منظور و نتیجه کار، برخلاف اصول چابکی است، لذا برای موفقیت در معماری سازمانی باید از حصار مدل‌ها و چارچوب‌ها خارج شد و با خلاقیت و نوآوری آنچه را کار درست بر اساس شرایط و موقعیت است، انجام داد. البته برخی نویسندگان به غلو این رویکرد را بی‌چارچوبی[5] می‌نامند که باید در اینجا تأکید نمود معماری سازمانی چابک به معنای کنار گذاشتن همه چارچوب‌ها و روش‌شناسی‌های موجود نیست، بلکه استفاده هدفمند و به میزان کافی از آن‌ها مدنظر است.
ج) مشارکت فعالانه و پیوسته ذینفعان
بنا بر ماهیت نیازمندی‌های معماری سازمان (و سیستم) که در یک مرحله (فاز) قابل نهاییسازی نیست و اصل تغییرات، ذینفعان معماری در تمامی چرخه معماری باید حضوری فعالانه داشته باشند. پیش از شروع پروژه توجه به ترسیم چشم‌انداز کلان معماری مبتنی بر شناسایی ذینفعان کلیدی (نه همه ذینفعان) و استخراج صورت‌مسئله و اولویت‌های این ذینفعان تضمین‌کننده تعریف صحیح پروژه معماری است. در طول اجرای پروژه معماری نیز باید تعادلی بین دوره‌های زمانی جمع‌آوری نیازمندی‌های تفصیلی و اطلاعات تکمیلی از ذینفعان معماری با دوره‌های زمانی ارائه خروجی و اخذ بازخورد از آن‌ها تعیین شود، به‌طوری‌که ذینفعان مشارکت مستمری را در طول پروژه داشته باشند و بتوانند در زودترین زمان ممکن خروجی‌های پروژه را دریافت نموده و بازخورد مناسب برای اصلاح این خروجی‌ها ارائه نمایند.
معماران باید توجه داشته باشند که منوط کردن مشارکت ذینفعان به دو دوره کوتاه ابتدای پروژه جهت دریافت نیازمندی و انتهای پروژه برای ارائه خروجی یک‌مرتبه‌ای، تبعات منفی متعددی به‌همراه خواهد داشت.
لازم به ذکر است معماری چابک با متد چابک در معماری سازمانی تفاوت دارد!
[1] Waterfall Model
[2] Iterative and Incremental Development
[3] Extreme Programming
[4] Feature-Driven Development
[5] Framework Free