Composable Commerce – یا: MACH Architectures in E-Commerce

روزهایی که فروشگاه های آنلاین با یک برنامه عظیم ساخته می شدند، گذشته است. اکنون، میتوان برای هر بخش نرمافزار یک ارائهدهنده مجزا انتخاب کرد، بنابراین دنیای تجارت الکترونیکی منحصربهفردی ایجاد کرد. یا می توانند؟ یک روند جدید روی لبان همه است: MACH! در آلمانی این به معنای “آن را انجام دهید!” … اما دقیقاً چه کاری باید انجام دهیم؟ و چه ربطی به Composable Commerce دارد؟
در پست خود، ما به آنچه MACH مستلزم آن است، مزایای بالقوه آن در تجارت الکترونیک، و همچنین معایبی که در حال حاضر دارد، می پردازیم.
تجارت قابل ترکیب
تا به حال، یک پروژه معمولی “فروشگاه آنلاین” شامل همکاری با یک ارائه دهنده خدمات برای توسعه یک برنامه کاربردی گسترده (فروشگاه آنلاین) بود که تمام جنبه های مهم را پوشش می داد: کاتالوگ محصول، جستجو، فرآیند سفارش و پرداخت، و مدیریت اطلاعات سفارش و مشتری.
نقطه ضعف این راه حل های یکپارچه وابستگی به یک سازنده است که به روز رسانی های آن بر کل برنامه تأثیر می گذارد.
Composable Commerce قصد دارد این ساختار یکپارچه را مدولار کند و قطعات جداگانه را قابل تعویض کند.
از لحاظ فنی، این در مورد جدا کردن اجزای یک سیستم تجارت الکترونیک (مانند سبد خرید، فرآیندهای پرداخت، مدیریت دادههای محصول و جستجو) از یکدیگر و اتصال آنها از طریق APIها است تا هر بخش به طور مستقل گسترش یابد، جایگزین شود یا بهینه شود، بدون اینکه بر بقیه سیستم تأثیر بگذارد.
مزیت آشکار برای خرده فروش این است که بتواند برای هر جنبه به دنبال یک ارائه دهنده تخصصی بگردد و در نهایت راه حل خود را بدون وابستگی به یک ارائه دهنده واحد جمع آوری کند.
بنیاد: معماری MACH
معماری MACH (Microservices، API-first، Cloud-native، Headless) پایه و اساس تجارت Composable Commerce است.
مفهوم بسیار ساده است: هر بخش از سیستم (“Microservice”) به طور مستقل عمل می کند و منحصراً از طریق رابط های تعریف شده (“API”) با سایر اجزا ارتباط برقرار می کند. این اجزا برای استقرار در سیستمهای توزیع شده طراحی شدهاند و از مزایای آنها مانند مقیاسپذیری، قابلیت اطمینان و کارایی هزینه استفاده میکنند (“Cloud-native”).
جداسازی frontend (واسط کاربری که مشتری می بیند) و backend (مانند مدیریت داده و منطق تجاری) امکان توسعه مستقل بیشتر هر جزء (“Headless”) را فراهم می کند.
هدف معماری MACH در درجه اول سرمایه گذاری، آینده ای مطمئن و حداکثر انعطاف پذیری است.
اتحاد MACH
با این حال، یکی از چالش های این رویکرد، همکاری تولیدکنندگان مختلف و ارائه دهندگان خدمات است. برای هماهنگی این همکاری در سطح بین المللی، اتحادی تشکیل شده است که کار آموزشی را ارائه می دهد و ارائه دهندگان خدمات را تأیید می کند. هدف از این کار، آسانتر کردن سفارشدهی به ارائهدهندگانی است که استانداردهای MACH را درک کرده و میتوانند پیادهسازی کنند.
پروژه های تجاری قابل ترکیب
بسیاری از ارائه دهندگان خدمات پیشنهاد می کنند که با Composable Commerce، همه اجزا آماده هستند و فقط باید “در کنار هم قرار گیرند”. با این حال، اجرای چنین پلتفرمی هم از نظر صنعت و هم از نظر فناوری به تخصص داخلی و خارجی نیاز دارد. بنابراین، خود برنامه باید برنامه ریزی شود – و کار واقعی در اینجا نهفته است: کد برنامه، که همه این میکروسرویس ها را از طریق API هایشان به هم متصل می کند، باید دقیقاً برنامه ریزی و توسعه داده شود.
این جایی است که جنبه “Composable” به طور کامل وارد عمل می شود، زیرا ما می توانیم تصمیم بگیریم که کدام مؤلفه ها را از کدام ارائه دهنده می خواهیم وصل کنیم. جستجو کردن؟ الگولیا! – کاتالوگ محصولات؟ مجنتو! – سبد خرید و فرآیند پرداخت؟ ابزارهای تجارت! … و فهرست احتمالات و تصمیماتی که باید گرفته شود به اینجا ختم نمی شود.
حتی پس از این تصمیم، در صورت یافتن راهحل مناسبتر، امکان تبادل قطعات در چند سال آینده باز است.
Dependency Hell – طلای احمق!
حتی اگر همه اینها مانند طلای درخشان به نظر می رسد، بررسی دقیق تر نشان می دهد: این فقط طلای احمق است. زیرا قابلیت تعویض اجزایی که اغلب در تبلیغات مورد ستایش قرار می گیرند در حال حاضر در دسترس نیست.
بسیاری از ارائه دهندگان در حال حاضر اجزای خود را شامل می شوند و یک سیستم بسته را تبلیغ می کنند. بله، قابل ترکیب است. اما نه: من نمی توانم به راحتی هیچ سازنده ای را به دلخواه ترکیب کنم.
یک پیش نیاز فنی حیاتی برای این قابلیت همکاری، اغلب موارد زیر است: استانداردسازی. و این دقیقاً در حال حاضر در دسترس نیست. هیچ “کاتالوگ محصول” DIN وجود ندارد که فرمت های داده را برای تبادل بین اجزا تعریف کند. حتی استاندارد نشده است که کدام دستورات API (به اصطلاح نقاط پایانی) باید منتقل شوند.
بنابراین، در حال حاضر، هر سازنده API خود را با فرمت های خاص خود دارد.
و در این مرحله، مزیت بزرگ تجارت ترکیبی در حال حاضر از بین رفته است. یکی در وابستگیهای ارائهدهنده گرفتار شده است و نمیتواند به سادگی قطعات را بدون سفارش مجدد کار توسعه برای ادغام جایگزین کند.
هزینه های تجارت قابل ترکیب
اغلب گفته می شود که هزینه های معماری مدرن باید در دراز مدت کمتر از یکپارچه های کلاسیک باشد. این تأثیر امروزه – اگر اصلاً وجود داشته باشد – فقط در موارد استثنایی نادر ظاهر می شود.
در بسیاری از موارد، معماری MACH به معنای تقاضای قابل توجهی بالاتر برای شرکت ها و افراد است. علاوه بر این، ادغام توابع جدید اغلب به معنای کار بر روی چندین مورد از این مؤلفه ها است. معمولا تیم های مختلف باید با هم هماهنگ شوند.
بنابراین، هنگامی که کل سیستم دارای یک اشکال باشد، جستجو در سیستم های توزیع شده آغاز می شود. آیا این خود برنامه است؟ یا یکی از اجزا؟ اگر بله، کدام یک؟ آیا این تنها دلیل مشکل است، یا آیا چندین مشکل در اجزای مختلف باید کنار هم قرار گیرند تا خطا ایجاد شود؟ بنابراین جستجوی خطا در این سیستم های توزیع شده بسیار دشوارتر است.
تمام این چالش ها بودجه مورد نیاز پروژه را نیز افزایش می دهد. صرفه جویی در هزینه تنها زمانی رخ می دهد که همه چیز به آرامی کار کند – یک حالت نادر.
بنابراین، این سوال دشوار باقی می ماند که چگونه پروژه خود را با نگاهی به آینده محقق کنید و چه بودجه ای را می خواهید برای آن اختصاص دهید.
کجا میری؟
تا زمانی که بازیگران اصلی اتحاد MACH همه پشت میز ننشینند و تصمیم نگیرند که رفاه خرده فروشان باید بالاتر از منافع مالی خودشان قرار گیرد، باید با طعم ترش مونولیت های مبتنی بر میکروسرویس زندگی کرد. تنها با رابطها و فرمتهای دادهای تایید شده و تایید شده میتوان از پتانسیل کامل Composable Commerce در آینده استفاده کرد.
یک فرصت – اما با ملاحظه
حتی امروزه، یکپارچههای موجود به اجزای اضافی مجهز شدهاند و قابلیتهای جدیدی را به سیستمهای موجود میآورند. Algolia یک مثال عالی از این است که چگونه یک ارائه دهنده خارجی می تواند جستجوی فروشگاه را جایگزین و به شدت بهبود بخشد. چنین راه حل هایی قابل اعتماد و مقرون به صرفه عمل می کنند.
با این حال، ادغام ها همیشه به سیستم مربوطه، گاهی اوقات حتی برای موارد استفاده فردی، تنظیم می شوند. اما آنها به زیبایی نشان می دهند که ایده “Composable Commerce” در مسیر درستی قرار دارد.
بنابراین هنوز هیجانانگیز است و در نهایت زمان نشان خواهد داد که آیا اتحادیه MACH استانداردهای مشترکی را ایجاد خواهد کرد که پشتیبانی بینصنعتی را پیدا کند یا خیر. در حال حاضر، شرکت ها باید برای درک احتمالات، تأثیرات و هزینه ها وقت بگذارند تا تصمیمی آگاهانه بگیرند. هر تبلیغاتی باید به طور انتقادی مورد سوال قرار گیرد و همیشه به یاد داشته باشید که فناوری همیشه باید ابزاری برای شرکت باشد. نه برعکس
ریکو نیتزل یکی از بنیانگذاران run_as_root GmbH در آلمان است. ما در اتوماسیون کیفیت نرم افزار و توسعه نرم افزار با کیفیت بالا تخصص داریم. ما در درجه اول بر تجارت الکترونیک تمرکز می کنیم.