استاندارد معماری چابک باز (O-AA[1]) : یک استاندارد از گروه باز[2] است که مفهوم و کاربرد معماری چابک برای تحول دیجیتال را به صورت زیر تبیین می‌نماید:
- برای رهبران کسب‌وکار، بینش و نقشه‌راهی فراهم می‌کند تا بتوانند هدایت سازمان در مسیر تحقق سازمان دیجیتال و چابک‌سازی عملیات را رهبری کنند.
- به معماران سازمان کمک می‌کند در مقیاس بزرگتر و برای موضوعات راهبردی در تحول دیجیتال نقش‌آفرینی کنند.
- به مدیران محصول، ابزارها و متدهایی ارایه میدهد تا هرچه موثرتر بتوانند محصولات نواورانه تولید کنند، تجربه مشتری را بهبود بخشند و نتایج مورد هدف را محقق سازند.
- برای مدیران عملیاتی، اصول و رهنمودهایی برای بکارگیری رویکردهای چابک در عملیات و مدیریت منابع ارایه میدهد.
لازم به ذکر است در استاندارد O-AA، هدف معماری و چابکی در مقیاس کل سازمان (سیستم) است و نه تنها در سطح همراستایی میان فناوری اطلاعات با کسب‌وکار. همچنین موضوع معماری چابک مستقیما ماموریت مدیران ارشد اجرایی سازمان است که برای مدیریت و تغییر مدل کسب‌وکار، عملیات و تشکیلات سازمان با رویکرد چابک می‌توانند از مشاوران مدیریت و معماران سازمانی نیز کمک بگیرند ولی در نهایت مسوول تحول در سازمان این مدیران ارشد هستند.
براساس اعلام گروه باز، این استاندارد (رهنمود) تکمیل‌کننده استاندارد کلاسیک توگف است و نه جایگزین آن؛ همانطور که خود چارچوب توگف نیز در طی سال‌های گذشته تغییر و به‌روزرسانی داشته است. البته باید توجه داشت خط‌مشی گروه باز حفظ قالب و ساختار کلاسیک چارچوب توگف طی بیش از دو دهه بوده است، لذا اسناد مکمل/راهنمای جانبی برای کاربردهای به‌روز و متناسب با ترندهای بازار ارایه شده است و قالب اصلی توگف طی بیش دو دهه تغییر بنیادینی نداشته است.
در این ادامه، اصول موضوعه (بدیهیات) معماری چابک که در استاندارد O-AA تعریف شده است، به اجمال معرفی می‌شوند:
- تمرکز بر تجربه مشتری(Customer Experience Focus): در دنیای دیجیتال امروز، کیفیت تجربه مشتریان یکی از فاکتورهای کلیدی موفقیت کسب‌وکار شده است. معماران با تحلیل تعاملات میان مشتریان و سازمان می‌بایست تجربه‌ای لذت‌بخش، متمایز و دیجیتال برای مشتریان خلق کنند.
- تفکر برون به درون(Outside-In Thinking): برای طراحی محصول تنها پرسش از کاربران و نیازمندی‌های آن‌ها کافی نیست، بلکه تفکر معماران باید مبتنی بر نگاه از بیرون به محصول/سرویس باشد. روش‌هایی مانند تفکر طراحی، نقشه تجربه مشتری و تحقیقات بازار باید در معماری چابک مورد نظر قرار گیرد تا تحقق بخش این تفکر باشد. برای مثال یک کارخانه خودروسازی باید تمرکز خود را بر اینکه خودرو چگونه توسط مشتریان استفاده می‌شود و چه ارزشی خلق می‌کند قرار دهد بجای نگاه درون‌سازمانی برای تولید خوردو با تعداد بیشتر و هزینه کمتر.
- چرخه‌های فیدبک سریع(Rapid Feedback Loops): روش‌های مختلفی برای شناسایی نیازمندی مشتریان و انتظارات از محصولات و خدمات وجود دارد، اما رویکردهایی مانند نمونه‌سازی[3] و چرخه‌های توسعه تکاملی به معماران کمک می‌کنند مفروضات جمع‌اوری شده از نیازها و انتظارات را پیش از انتشار محصول نهایی، ارزیابی و بازبینی نمایند.
- ارکستریشن نقاط تماس(Touch point Orchestration): مرزهای میان بیرون (مشتریان و اکوسیستم) و درون‌سازمان هر روز محوتر می‌شود. اصل ارکستریشن نقاط تماس برای مشتریان و ذینفعان سازمان در هر زمان و مکان، ابزار و دسترسی مناسب را فراهم می‌سازد.
- همراستایی جریان ارزش(Value Stream Alignment): معماری چابک بر جریان‌های ارزش در سازمان و همراستایی آن‌ها متکی است. برای هر گروه از محصولات و خدمات سازمان باید جریان ارزش از “ایده” تا “خلق محصول/سرویس” و از “درخواست” محصول/سرویس تا “تحویل” به مشتریان تحلیل و معماری شود. همچنین شناسایی مراحل مشترک (تکراری) میان چندین جریان ارزش، ورودی مهمی برای طراحی “مدل عملیاتی” است.
- تیم‌های بین-کارکردی خودمختار(Autonomous Cross-Functional Teams): معماری چابک باید توجه ویژه‌ای به بخش‌بندی سازمان به تیم‌های بین-کارکردی خودمختار داشته باشد. ساختار تیم‌ها در سازمان تاثیر مستقیمی بر بهره‌وری سازمانی، رضایت کارمندان و چابکی دارد. هرچه وابستگی میان تیم‌ها با یکدگیر کمتر باشد، بروکراسی و هدررفت زمان کمتر خواهد شد و این یعنی چابکی.
- توزیع اختیارات، مسوولیت و پاسخ‌گویی(Authority, Responsibility, and Accountability Distribution): با توجه به ضرورت هماهنگی و همکاری میان تیم‌های خودمختار در سازمان چابک نیاز است تا اختیارات و مسوولیت و پاسخ‌گویی نیز در سطوح مختلف سازمان توزیع شود و بدین وسیله از بی‌نظمی احتمالی حاصل از خودمختاری تیم‌ها محافظت شود.
- اتصل سست میان سیستم‌ها (Loosely-Coupled Systems): معماری چابک با تیم‌های خودمختار بیش از هر چیز وابسته به سیستم‌های دارای اتصال سست و مولفه‌های ماژولار است. اتصال سست میان سیستم‌ها به تیم‌های مختلف امکان کار موازی با حداقل وابستگی میدهد و همچنین تغییر یک مولفه کمترین تاثیرات جانبی بر سایر مولفه‌ها می‌گذارد.
- پلتفرم داده ماژولار(Modular Data Platform): پلتفرم‌های مجتمع و یک-تکه داده به عنوان یک ضدالگو در معماری شناخته می‌شوند و مشخصا در معماری چابک باید بجای مجتمع‌سازی همه داده‌های سازمانی در یک منبع و پلتفرم مجتمع و یک-تکه، به دنبال ماژولاریتی داده‌ها بر اساس دامنه کاربردی و فنی باشیم.
- اصول عملیاتی مشترک ساده(Simple Common Operating Principles): در معماری چابک برای استانداردسازی و ساده‌سازی عملیات باید مجموعه‌ای از قواعد مشترک تعریف و الزام نمود. برای مثال هر سیستم اطلاعاتی باید خروجی خود را در قالب استاندارد API ارایه نماید و هر فراخوانی (سرویس) میان سیستم‌ها باید طبق API انجام شود.
- ترجیح قسمت‌بندی بر لایه‌بندی(Partitioning Over Layering): قسمت‌بندی سازمان در معماری چابک باید در کل کسب‌وکار سازمان و سیستم‌ها اعمال شود. قسمت‌بندی در سطح کسب‌وکار باید ” بازار-محور” باشد، در سطح مدل عملیاتی ” قابلیت-محور” باشد و در سطح نرم‌افزار “دامنه-محور”.
- معماری بازتاب تشکیلات (Organization Mirroring Architecture): معماری چابک باید تشکیلات سازمان و تیم‌ها را به‌گونه‌ای سازماندهی کند که بازتاب‌دهنده معماری محصول/عملیات باشند. برای توضیح بیشتر باید به قانون کانوی اشاره کرد: “تشکیلات(تیم‌ها) سیستم‌هایی را طراحی می‌کنند که بازتاب دهنده ساختار ارتباطی خودشان است”. معکوس این قانون یعنی تشکیلات سازمان را بگونه‌ای طراحی کنیم که بازتاب‌دهنده معماری عملیات و محصولات باشد. نکته مهم اینکه نه محصولات و معماری سیستم‌های سازمان ثابت خواهد بود و نه تشکیلات و ساختار آن و شرط موفقیت تکامل همزمان این دو است.
- سطح‌بندی تشکیلاتی (Organizational Leveling): در معماری چابک باید معماری مبتنی بر سطوح تشکیلاتی و سازمانی تعریف و مدیریت شود. این سطوح که معمولا سلسله مراتبی هستند عبارتند از: 1. تیم‌های چابک با اندازه که از 10 نفر بیشتر نیستند 2. تیمی از تیم‌های چابک 3. سطح نهاد/شرکت که معادل یک شرکت خصوصی، دستگاه دولتی یا یک بخش کسب‌وکاری است و نهایتا 4. سطح اکوسیستم/هلدینگ که تشکیل شده از مجموعه‌ای از نهادها، سازمان‌ها و تشکیلات مرتبط هستند.
- تعصب بر تغییر (Bias for Change): تنها تعصبی که در معماری چابک ارزشمند است، تعصب بر تغییر و آمادگی برای تغییرات است! همچنان که نیازمندی مشتریان، ترندهای فناوری و شرایط محیطی هرلحظه تغییر می‌کنند، معماری و فراورده‌های معماری نیز تغییر و تکامل خواند یافت. از طرف دیگر باید میان دو رویکرد “Intentional” و “Emerging” در معماری توازن ایجاد نمود.
- تغییرنگرش از پروژه به محصول(Project to Product Shift): تیم‌های چابک مسوول تحویل پروژه نیستند بلکه باید یک محصول را ارایه و در طول چرخه عمر آن پشتیبانی نمایند. تفکر محصول-محور منجر به ایجاد تشکیلات (تیم‌های) دایم با هدفی بلندمدت و ماموریتی از ابتدا تا انتها می‌شود. نمونه این اصل در رویکرد DevOps وجود دارد که تاکید می‌کند آنچه می‌سازید را باید اجرا (پشتیبانی) کنید.
- امن‌سازی در هنگام طراحی(Secure by Design): امنیت در سیستم‌ها و محصولات، حاصل رعایت کنترل‌‌ها و الزامات ریسک-امنیت در هنگام طراحی هستند و نه اینکه پس از تولید محصول تازه به فکر امنیت سیستم باشیم. مشابه این اصل در “یکپارچگی در هنگام طراحی” است که آن هم از بدیهیات معماری است. معماری چابک نیازمند تفکر DevSecOps است که امنیت در تمامی گام‌ها تولید و ارایه نرم‌افزار نهادینه شده باشد.
[1] Open Agile Architecture
[2] Open Group
[3] Prototyping