معماری پلتفرمی به‌ عنوان زیرساخت تاب‌آوری

علیرضا نمازی، مدیر واحد مدیریت پروژه‌های توسعه محصول داتین در یادداشتی در «مجله فناوری‌های مالی» نوشت: در معماری پلتفرمی، قابلیت‌های سازمان در قالب ماژول‌ها، سرویس‌ها و اجزای نسبتا مستقل، سازمان‌دهی می‌شوند که از طریق رابط‌های استاندارد با یکدیگر تعامل دارند. این ساختار باعث کاهش وابستگی‌های متقابل و محدودشدن دامنه اثر خرابی‌ها می‌شود.

به گزارش پایگاه خبری بانکداری الکترونیک ،در عصر دیجیتال و جهانی‌شدن، سازمان‌ها با محیطی پویا و پر از عدم قطعیت مواجه‌اند که تغییرات سریع بازار، فناوری‌های نوظهور و بحران‌های ناگهانی را به همراه دارد. در این شرایط، تاب‌آوری یا توانایی یک سیستم یا سازمان برای ادامه عملکرد موثر و بازگشت به حالت پایدار پس از اختلال، به یکی از معیارهای کلیدی موفقیت تبدیل شده است. معماری پلتفرمی با طراحی ماژولار، استانداردسازی رابط‌ها و ایجاد اکوسیستم‌های تعاملی، به‌ عنوان یک زیرساخت استراتژیک، فرصت‌های منحصربه‌فردی برای افزایش انعطاف‌پذیری و تاب‌آوری فراهم می‌کند.

این مقاله تلاش دارد تا نقش معماری پلتفرمی را در تقویت تاب‌آوری سازمان‌ها تحلیل کند، نمونه‌هایی از موفقیت‌های عملی ارائه دهد و چالش‌ها و محدودیت‌های این رویکرد را مورد بررسی قرار دهد. با توجه به اهمیت تاب‌آوری در بانک‌ها و صنعت بانکداری، در این مفاله کاوش عمیق‌تری در حوزه مزبور صورت گرفته و بر این حوزه تاکید بیشتری شده است.

مفهوم تاب‌آوری

تاب‌آوری سازمانی به معنای ظرفیت سازمان در پیش‌بینی بحران، کاهش اثرات و مقاومت در برابر آسیب‌های آن، پاسخ و واکنش مناسب و در نهایت بازیابی از شرایط بحرانی است. تاب‌آوری صرفا در مورد بحران‌ها نیست، بلکه تمام اختلالات و مواردی که کسب‌وکار را به طور جدی یا جزئی تحت تاثیر قرار می‌دهد را شامل می‌شود. به طور خلاصه می‌توان گفت که تاب‌آوری یعنی توانایی یک سیستم برای:

  • ادامه‌دادن عملکرد در شرایط اختلال
  • بازیابی سریع بعد از بحران
  • سازگاری با تغییرات محیط
  • یادگیری و تکامل بعد از شوک

این بحران یا اختلال می‌تواند از هر نوع باشد، از جمله:

  • اختلال ناشی از خرابی یا تغییرات فنی (عمدی، سهوی یا اجنتاب‌ناپذیر)
  • تغییر بازار و محیط
  • افزایش ناگهانی کاربران
  • تحریم، بحران مالی، حمله سایبری یا حتی تغییر رفتار مشتری

با این تعریف، یکی از مفاهیم مهمی که سازمان‌ها برای آن برنامه‌ریزی می‌کنند، بودجه اختصاص می‌دهند و ساختار و اقدام پیش‌بینی می‌کنند، «تاب‌آوری» است. تاب‌آوری نه صرفا در بعد ابزار و فناوری که در تمامی ابعاد انسانی، سازمانی و فناوری مطرح می‌شود.

مفهوم معماری پلتفرمی

تعاریف متفاوتی برای پلتفرم در حوزه‌های مختلف ارائه شده است. به صورت عمومی معماری پلتفرمی یک ساختار ماژولار از سیستم‌های پیچیده است که در آن اجزای هسته (پلتفرم) ثابت می‌مانند، در حالی که به اجزای جانبی (مکمل‌ها) اجازه داده می‌شود تا در طول زمان توسعه و تغییر یابند. این ساختار وظایف نوآوری را تقسیم کرده و بستر مشارکت را فراهم می‌سازد.

معماری پلتفرمی به جای تمرکز بر تولید یک محصول واحد، بر طراحی یک زیرساخت باز و انعطاف‌پذیر تمرکز دارد. این ساختار با تدوین مقررات و بستر فنی، امکان اتصال، تعامل و مشارکت میان توسعه‌دهندگان جانبی و کاربران را برای خلق ارزش، سازمان‌دهی می‌کند. این مفهوم کلی در حوزه‌های خاص، تعاریف دقیق و عینی‌تری پیدا می‌کند که در ادامه به چند مورد از آنها اشاره می‌شود.

اقتصاد پلتفرمی به سیستمی اشاره دارد که در آن بسترهای دیجیتال (پلتفرم‌ها) به عنوان واسطه، تعامل بین دو یا چند گروه (مانند تولیدکنندگان، مصرف‌کنندگان و توسعه‌دهندگان) را تسهیل می‌کنند. ارزش این پلتفرم‌ها نه از تولید مستقیم کالا، بلکه از ایجاد شبکه‌ها و تسهیل مبادلات ناشی می‌شود.

در حوزه بانکداری به طور خاص، بانکداری به مثابه پلتفرم، به عنوان روشی برای استفاده بهينه از ظرفيت فراوان توسعه‌دهندگان خارجی مطرح می‌شود. بانکداری به عنوان يک پلتفرم، نوعی نظام بانکداری باز تلقی می‌شود که در آن شرکت‌های فناوری نرم‌افزار، ابزارهای توسعه، ميان‌افزار، سيستم‌عامل‌ها، مجازی‌سازی، سرورها، ذخيره‌سازی و شبکه را به بانک‌ها و ساير ارائه‌دهندگان خدمات مالی ارائه می‌دهند. سپس می‌توان از اين بستر برای ارائه راه‌حل‌ها، خدمات و تجربيات سفارشی به مشتريان استفاده کرد. بانک‌های سنتی همواره به عنوان نهادهای متمرکز در مدیریت مالی شناخته شده‌اند، اما در رویکرد پلتفرمی، نقش آنها نیازمند بازتعریف است.

در حوزه نرم‌افزار هم معماری پلتفرمی به طراحی سیستم‌هایی اشاره دارد که به جای یک محصول واحد، زیرساختی پایدار و انعطاف‌پذیر ارائه می‌دهند. این ساختار امکان ساخت، توسعه و یکپارچه‌سازی ابزارها و برنامه‌های کاربردی جانبی را فراهم کرده و بستر مشارکت توسعه‌دهندگان و کاربران را ایجاد می‌کند.

معماری پلتفرمی به طور معمول شامل اجزای اصلی زیر است:

۱- لایه زیرساخت: منابع سخت‌افزاری و نرم‌افزاری پایه‌ای که سیستم روی آن سوار است.

۲- هسته اصلی: بخش ثابتی از پلتفرم که سرویس‌های مرکزی و پایه را ارائه می‌دهد.

۳- واسط‌های برنامه‌نویسی: ماژول‌های ارتباطی که اجازه می‌دهند اجزای داخلی و خارجی با یکدیگر ارتباط برقرار کنند.

۴- لایه داده: ساختار ذخیره‌سازی و مدیریت اطلاعات که برای کارایی بهتر به صورت متمرکز یا غیرمتمرکز (مانند ساختارهای نوین دیتامش) طراحی می‌شود.

رویکرد پلتفرمی، مزایا و ویژگی‌های متمایزی را برای کسب‌وکارها به همراه دارد. از جمله ویژگی‌های کلیدی زیر:

  • توسعه‌پذیری و مقیاس‌پذیری: امکان اضافه‌کردن ماژول‌ها و ویژگی‌های جدید بدون نیاز به تغییر در ساختار اصلی سیستم وجود دارد.
  • یکپارچه‌سازی: قابلیت اتصال آسان به سایر نرم‌افزارها، سرویس‌ها و منابع داده از طریق APIها فراهم می‌شود.
  • پشتیبانی از اکوسیستم: فراهم‌کردن محیطی که توسعه‌دهندگان ثالث می‌توانند روی آن پلاگین یا برنامه‌های مکمل بسازند.
  • کاهش هزینه‌های توسعه: به جای نوشتن همه بخش‌ها از صفر، تیم‌ها می‌توانند از امکانات هسته مرکزی پلتفرم استفاده کنند.
  • تسریع در ورود به بازار: به دلیل وجود زیرساخت آماده ارائه محصولات و خدمات جدید، با سرعت جدیدی همراه است.
  • سفارشی‌سازی برای کاربر نهایی: امکان بالای شخصی‌سازی سیستم بر اساس نیازهای خاص هر مشتری یا کسب‌وکار فراهم می‌شود.

این مزایا محدود به موارد فوق نبوده و گستره بیشتری دارد. در ادامه این نوشتار به طور مشخص به تاثیر رویکرد و معماری پلتفرمی بر تاب‌آوری سیستم‌ها با تمرکز بیشتر بر مباحث فنی و به‌ویژه نرم‌افزاری می‌پردازیم.

رابطه تاب‌آوری و معماری پلتفرمی

رابطه‌ «تاب‌آوری» و «معماری پلتفرمی» عمیق‌تر از صرفا پایداری فنی سیستم‌هاست. در واقع معماری پلتفرمی یکی از الگوهایی است که می‌تواند تاب‌آوری را در سطح فنی، سازمانی و حتی اقتصادی افزایش دهد. از نگاه سیستمی، پلتفرم‌ها تاب‌آوری را از طریق مکانیزم‌های مختلفی ایجاد می‌کنند که در ادامه مهم‌ترین آنها تشریح می‌شود:

  • ماژولارسازی و محدودسازی خرابی

معماری پلتفرمی مبتنی بر ماژولارسازی است و سیستم‌های ماژولار نسبت به سیستم‌های یکپارچه پایدارتر هستند، چراکه در معماری پلتفرمی:

  • اجزا تا حدی مستقل‌اند.
  • وابستگی‌های مستقیم کاهش می‌یابد.
  • خرابی در یک بخش به کل سیستم سرایت نمی‌کند.

در نتیجه انتشار خطا محدود می‌شود و در موارد بروز خطا سیستم قادر به حفظ عملکرد جزئی خواهد بود.

  • کاهش وابستگی و افزایش ظرفیت تطبیق

در سیستم‌های  متمرکز یا یکپارچه شدید، تغییر یا اختلال در یک جز می‌تواند موجب اختلال زنجیره‌ای شود. اما معماری پلتفرمی با استفاده از APIها، قراردادهای استاندارد و جداسازی لایه‌ها، انعطاف ساختاری ایجاد می‌کند. این امر توان سیستم در مواجهه با ابهام و بحران را بالا می‌برد. همچنین سبب می‌شود تغییرات موضعی، آسان‌تر مدیریت شوند و سیستم ظرفیت سازگاری بالاتری پیدا کند.

  • توزیع‌پذیری و حذف نقاط شکست واحد

یکی از ویژگی‌های رایج پلتفرم‌ها، ساختار توزیع‌شده آنهاست. معماری توزیع‌شده ویژگی‌های زیر را داراست:

  • منابع در چند گره توزیع می‌شوند.
  • افزونگی (Redundancy) ایجاد می‌شود.
  • وابستگی به یک نقطه مرکزی کاهش می‌یابد.

این ویژگی باعث کاهش گلوگاه‌های یکتای خرابی سیستم و خرابی‌های دومینووار می‌شود. در نتیجه سیستم حتی در شرایط خرابی بخشی از زیرساخت، قادر به تاب‌آوری و ادامه عملکرد خواهد بود.

  • استانداردسازی رابط‌ها و بازآرایی سریع

پلتفرم‌ها معمولا مبتنی بر پروتکل‌های استاندارد و قراردادهای مشخص تعامل بین ماژول‌ها و با بیرون از خود هستند. استانداردسازی امکان جایگزینی اجزا، توسعه مستقل و بازپیکربندی سریع سیستم را فراهم می‌کند. این ویژگی سبب می‌شود بتوان با کمترین اختلال، فرایند توسعه را پیش برد و در زمان مواجهه با اختلال، بازیابی پس از بحران را سریع‌تر انجام داد.

  • هماهنگی سازمانی و تاب‌آوری اجتماعی- فنی

تاب‌آوری صرفا ویژگی فنی نیست، بلکه ماهیتی اجتماعی- فنی (Socio-Technical) دارد. معماری پلتفرمی با ایجاد خدمات مشترک، ابزارهای استاندارد و سازوکارهای هماهنگی بین اجزا، توان واکنش سازمانی را افزایش می‌دهد. نتیجه آن، کاهش گلوگاه تصمیم‌گیری، توزیع مسئولیت و تسریع پاسخ به بحران است.

معماری پلتفرمی و تاب‌آوری در صنعت بانکی

صنعت بانکداری به دلیل نقش حیاتی خود در گردش مالی، حفظ اعتماد عمومی و پشتیبانی از فعالیت‌های اقتصادی، بیش از بسیاری از صنایع دیگر به تاب‌آوری وابسته است. تاب‌آوری در این صنعت به توانایی بانک برای حفظ یا بازیابی سریع عملکردهای حیاتی در مواجهه با اختلالات فناوری، حملات سایبری، خطاهای عملیاتی، نوسانات بازار یا تغییرات مقرراتی اشاره دارد. در این چارچوب، معماری فناوری اطلاعات بانک‌ها نقش تعیین‌کننده‌ای در میزان تاب‌آوری آنها ایفا می‌کند.

در معماری‌های سنتی، سامانه‌های بانکی عمدتا به ‌صورت یکپارچه و متمرکز طراحی می‌شدند. در چنین ساختاری، اجزای مختلف کسب‌وکار مانند مدیریت حساب‌ها، پردازش تراکنش‌ها، مدیریت مشتریان و خدمات پرداخت به‌شدت به یکدیگر وابسته هستند. این وابستگی موجب می‌شود که بروز اختلال در یک بخش بتواند به سایر بخش‌ها سرایت کرده و عملکرد کل سامانه را تحت تاثیر قرار دهد. علاوه بر این، اعمال تغییرات یا توسعه قابلیت‌های جدید در این نوع معماری‌ها معمولا مستلزم تغییر در بخش‌های متعددی از سیستم است که ریسک بروز خطا و توقف خدمات را افزایش می‌دهد.

معماری پلتفرمی رویکرد متفاوتی را ارائه می‌کند. در این رویکرد، قابلیت‌های سازمان در قالب ماژول‌ها، سرویس‌ها و اجزای نسبتا مستقل، سازمان‌دهی می‌شوند که از طریق رابط‌های استاندارد با یکدیگر تعامل دارند. این ساختار باعث کاهش وابستگی‌های متقابل و محدودشدن دامنه اثر خرابی‌ها می‌شود. به بیان دیگر، اگر یک سرویس یا ماژول دچار مشکل شود، سایر بخش‌های سامانه می‌توانند بدون اختلال جدی به فعالیت خود ادامه دهند.

از منظر عملیاتی، معماری پلتفرمی امکان واکنش سریع‌تر به تغییرات محیطی را نیز فراهم می‌کند. بانک‌ها در محیطی فعالیت می‌کنند که به طور مداوم تحت تاثیر تغییرات مقرراتی، فناوری‌های نوظهور، الزامات امنیتی و انتظارات مشتریان قرار دارد. در ساختارهای پلتفرمی، افزودن، حذف یا اصلاح خدمات معمولا بدون نیاز به بازطراحی کل سامانه امکان‌پذیر است. در نتیجه، سازمان می‌تواند با هزینه و ریسک کمتر خود را با شرایط جدید تطبیق دهد. این قابلیت انطباق‌پذیری، یکی از ابعاد مهم تاب‌آوری سازمانی محسوب می‌شود.

یکی از جلوه‌های مهم این رویکرد در بانکداری باز مشاهده می‌شود. در این مدل، بانک‌ها از طریق APIهای استاندارد، خدمات خود را در اختیار بازیگران مختلف اکوسیستم مالی قرار می‌دهند. این ساختار پلتفرمی موجب می‌شود که توسعه یا تغییر یک خدمت جدید بدون ایجاد اختلال گسترده در کل سامانه انجام شود و در نتیجه تاب‌آوری عملیاتی افزایش یابد.

نمونه دیگر، استفاده از معماری میکروسرویس در سامانه‌های بانکی است. در این معماری، به جای ساخت یک نرم‌افزار بزرگ و یکپارچه، سیستم به چندین جزء سرویس‌های کوچک، مستقل و متمرکز بر یک قابلیت کسب‌وکاری مشخص تقسیم می‌شود. هر سرویس به‌ صورت مستقل، توسعه، استقرار، مقیاس‌گذاری و نگه‌داری می‌شود و از طریق رابط‌های استاندارد (معمولا APIها) با سایر سرویس‌ها ارتباط برقرار می‌کند. بنابراین، بروز مشکل در یکی از سرویس‌ها لزوما منجر به توقف کامل خدمات بانکی نمی‌شود و سایر بخش‌ها می‌توانند به فعالیت خود ادامه دهند.

یکی از رویکردهای رایج در معماری‌های پلتفرمی، استقرار سرویس‌ها در مراکز داده متعدد یا محیط‌های ابری توزیع‌شده است. برای مثال، اگر یک مرکز داده به دلیل قطعی برق، حمله سایبری یا بروز حادثه طبیعی از دسترس خارج شود، بار کاری به صورت خودکار به مرکز داده دیگری منتقل می‌شود. کاربران بدون وقفه محسوس به استفاده از خدمات ادامه می‌دهند و فعالیت‌های حیاتی بانک متوقف نمی‌شود. در این حالت، معماری پلتفرمی از طریق افزونگی، توزیع منابع و بازیابی خودکار، توان بانک در مقابله با اختلالات شدید را افزایش می‌دهد.

مرور چند تجربه واقعی

نتفلیکس، مهاجرت به معماری پلتفرمی و میکروسرویس‌ها

در سال‌های اولیه، نتفلیکس یک سیستم متمرکز داشت. خرابی یک بخش می‌توانست کل سرویس را مختل کند. با بازنگری در این مدل، نتفلیکس اقدامات زیر را انجام داد:

  • زیرساخت داخلی توسعه‌دهندگان را تولید کرد.
  • سرویس‌ها را مستقل کرد.
  • مهندسی پلتفرم ایجاد کرد.
  • ابزارهای مشترک برای استقرار، مانیتورینگ و بازیابی ساخت.

با این تغییرات، در حال حاضر وقتی بخشی از سیستم خراب می‌شود:

  • کل پلتفرم از کار نمی‌افتد.
  • خرابی سرویس‌ها مستقل شده است.
  • بازیابی خودکار انجام می‌شود.
  • استقرار محصولات مختلف در تیم‌ها بدون وابستگی شدید انجام می‌شود.

آمازون و تولد Amazon Web Services

آمازون در مقیاس بزرگ با رشد سریع و ترافیک شدید همراه می‌شد. در این شرایط، با دو رویکرد متفاوت مواجه بود و در نهایت به ‌جای اینکه هر تیم زیرساخت خودش را بسازد، سرویس‌های مشترک ساخته شدند، پلتفرم در سطوح پردازش‌ها، ذخیره‌سازی و پیام‌رسانی را ایجاد کردند و معماری مبتنی بر API توسعه داده شد. در نتیجه این رویکرد، آمازون در مواجهه با بحران‌ها از توانایی‌های زیر برخوردار است:

  • سرویس‌ها به صورت جداگانه قابلیت مقیاس‌شدن دارند.
  • قطع‌شدن سرویس به صورت منطقه‌ای است و نه سراسری.
  • تیم‌ها مستقل‌ترند.
  • بازیابی سریع‌تر است.

با این رویکرد، به عنوان مثال اگر یک منطقه مشکل پیدا کند، ترافیک به منطقه دیگر منتقل می‌شود و کاربر کمترین اختلال را حس می‌کند.

مدل Platform+ Squad در اسپاتیفای

در اسپاتیفای رشد تیم‌ها باعث کندی توسعه و وابستگی زیاد شده بود. برای غلبه بر این موضوع، اسپاتیفای یک پلتفرم توسعه‌دهندگان محصول ساخت، جوخه‌‌های محصول را مستقل کرد و در ازای آن، ابزار  یکپارچه‌سازی و استقرار مستمر و قابلیت مشاهده مشترک ایجاد کرد. در نتیجه در زمان اختلال، فقط جوخه مرتبط مداخله می‌کند، همه تیم‌ها درگیر بحران نمی‌شوند و بقیه سیستم پایدار می‌ماند. این نوع طراحی علاوه بر تاب‌آوری فنی، تاب‌آوری سازمانی را هم بالا برد.

شاپیفای در دوران کرونا

در دوران کووید ۱۹ و به دلیل شرایط آن زمان، حجم فروش آنلاین در دنیا ناگهان جهش کرد. این موضوع اگرچه از نظر کسب‌وکاری برای شاپیفای مطلوب بود، اما سیستم را با بار ناگهانی بالایی روبه‌رو کرد. از آنجا که شاپیفای از قبل تدابیر زیر را اتخاذ و پیاده‌سازی کرده بود:

  • معماری پلتفرمی چندمستاجره
  • زیرساخت مقیاس‌پذیر
  • اکوسیستم API
  • پلتفرم اپلیکیشن

توانست در شرایط جدید تاب‌آور بماند. در نتیجه توانست میلیون‌ها فروشنده جدید را جذب و افزایش ترافیک ناشی از آن را تحمل کند. همچنین بدون نیاز به بازطراحی اساسی بزرگ شود.

JPMorgan Chase و گذار از سامانه‌های یکپارچه به میکروسرویس‌ها

JPMorgan Chase در سال‌های اخیر، بخش قابل توجهی از سامانه‌های خود را بر مبنای معماری ابری، رویدادمحور و میکروسرویسی بازطراحی کرده است. در مستندات فنی این بانک توضیح داده شده که برنامه‌های یکپارچه قدیمی به سرویس‌های مستقل شکسته شده‌اند و برای آنها قابلیت‌های مشترک تاب‌آوری توسعه یافته است. همچنین معماری جدید بر استقرار چندمنطقه‌ای و مقیاس‌پذیری خودکار مبتنی بر ابر استوار است تا در صورت بروز مشکل در یک منطقه یا مرکز داده، خدمات از مناطق دیگر ادامه پیدا کنند.

تحول دیجیتال بانک ING و گذار به معماری چابک و مبتنی بر سرویس

بانک هلندی ING یکی از شناخته‌شده‌ترین نمونه‌های تحول معماری در صنعت بانکداری است. این بانک از سال ۲۰۱۵ فرایند بازطراحی ساختار فناوری و عملیاتی خود را با الهام از شرکت‌های دیجیتال آغاز کرد. در این تحول، بسیاری از قابلیت‌های بانکی در قالب تیم‌های مستقل و سرویس‌های مجزا سازمان‌دهی شدند و مدل توسعه نرم‌افزار به سمت DevOps و معماری‌های ماژولار حرکت کرد. هدف اصلی این تغییر، تنها افزایش سرعت توسعه نبود؛ بلکه کاهش وابستگی میان بخش‌های مختلف سیستم و افزایش توان واکنش بانک در برابر تغییرات و اختلالات نیز مد نظر قرار داشت.

در این ساختار، تیم‌های مستقل می‌توانستند خدمات خود را بدون ایجاد اختلال در سایر بخش‌ها توسعه یا اصلاح کنند. همچنین کاهش تعداد وابستگی‌های فنی و سازمانی موجب شد زمان ارائه خدمات جدید کاهش یافته و بازیابی سامانه‌ها در زمان بروز مشکل ساده‌تر شود.

مهاجرت Capital One به رایانش ابری و معماری تاب‌آور

بانک آمریکایی Capital One یکی از نخستین موسسات مالی بزرگ بود که بخش عمده زیرساخت فناوری خود را به محیط ابری منتقل کرد. این مهاجرت صرفا جابه‌جایی سامانه‌ها به فضای ابری نبود، بلکه همراه با بازطراحی معماری سامانه‌ها و حرکت به سمت سرویس‌های توزیع‌شده انجام شد. معماری جدید، قابلیت ارائه خدمات در چند منطقه جغرافیایی را داراست و در صورت ازکارافتادن یک مرکز داده یا منطقه ابری، ترافیک به صورت خودکار به زیرساخت جایگزین منتقل می‌شود. این رویکرد، مانع از ایجاد «نقطه شکست واحد» شده و تداوم خدمات را در شرایط بحرانی تضمین می‌کند.

علاوه بر این، بازطراحی معماری موبایل‌بانک و سامانه‌های پشتیبان در بستر ابری با هدف افزایش تاب‌آوری انجام شد؛ به گونه‌ای که سامانه بتواند در برابر اختلالات فنی یا افزایش ناگهانی بار کاری، بدون توقف خدمت به فعالیت ادامه دهد.

بانک Commonwealth Bank of Australia (CBA) و انتقال هسته بانکداری به ابر

یکی از بزرگترین پروژه‌های تحول معماری در صنعت بانکی متعلق به بانک استرالیایی Commonwealth  است. این بانک زیرساخت اصلی بانکداری متمرکز خود را که از حدود ۱۶ میلیون حساب فعال و بخش بزرگی از پرداخت‌های اقتصاد استرالیا پشتیبانی می‌کند، به معماری ابری منتقل کرد. هدف صرفا نوسازی فناوری نبود؛ بلکه افزایش قابلیت اطمینان و تاب‌آوری نیز به‌ طور رسمی از اهداف پروژه اعلام شد. پس از این تحول، بانک توانست یک لایه «همیشه در دسترس» ایجاد کند تا حتی در زمان برخی تغییرات و قطعی‌های برنامه‌ریزی‌شده، خدمات دیجیتال برای مشتریان همچنان فعال باقی بماند. همچنین ساختار جدید، امکان توزیع بار و بازیابی ساده‌تر خدمات را فراهم کرد.

معماری پلتفرمی همیشه تاب‌آوری ایجاد نمی‌کند

اگرچه معماری پلتفرمی می‌تواند تاب‌آوری را افزایش دهد، اما تمرکز بیش از حد پلتفرمی ممکن است به آسیب‌پذیرترشدن سیستم بینجامد. هر یک یا مجموعی از شرایط زیر می‌تواند منجر به این وضعیت شود:

  • یک پلتفرم یا بخشی از آن به زیرساخت بحرانی انحصاری تبدیل شود.
  • وابستگی اکوسیستم، بیش از حد متمرکز شود.
  • تنوع معماری از بین برود.
  • معماری، بیش ‌از حد متمرکز شود.
  • وابستگی شدید به فضای ابری یا تامین‌کننده خاص ایجاد کند.
  • امنیت ضعیف باشد.
  • APIها و پروتکل‌های ارتباطی کنترل نشوند.

در به‌کارگیری معماری پلتفرمی، توجه و پرهیز از موارد فوق می‌تواند علاوه بر اینکه مزایای این معماری در افزایش تاب‌آوری را حاصل کند، از تهدیدها و چالش‌های بالقوه پیش‌گیری به عمل آورد.

به طور کلی و در حالی که تاب‌آوری برای همه سیستم‌ها و سازمان‌ها مقوله مهمی است، معماری پلتفرمی از طریق ماژولارسازی، کاهش وابستگی، استانداردسازی تعاملات، توزیع‌پذیری و قابلیت بازآرایی باعث می‌شود سیستم راحت‌تر تغییر کند، در برابر اختلال مقاوم‌تر باشد، سریع‌تر بازیابی شود، وابستگی کمتری داشته باشد و بتواند در بحران هم رشد کند. در نتیجه، بتواند سطح تاب‌آوری خود را بالاتر ببرد. به همین دلیل امروز در تحول دیجیتال، شهر هوشمند، فین‌تک، لجستیک، دولت دیجیتال و نظایر آنها تاب‌آوری بدون معماری پلتفرمی تقریبا غیرممکن شده است.

با این حال، تمرکز بیش از حد و انباشت وابستگی‌ها می‌تواند خود منشا شکنندگی و آسیب‌پذیری باشد. بنابراین، اثربخشی معماری پلتفرمی در افزایش تاب‌آوری، وابسته به طراحی متوازن میان استقلال اجزا، هماهنگی سیستمی و توزیع ریسک است.

نظر شما چیست؟