الگوهای یکپارچهسازی سیستمها
هیچ سامانهای در سازمان تنها نیست. فروشگاه به انبار وصل است، انبار به مالی، مالی به سامانهٔ مؤدیان، و همه به یک سامانهٔ حضور و غیاب که ده سال پیش نوشته شده.
بیشتر پیچیدگی نرمافزار سازمانی در همین اتصالهاست، نه در خودِ سامانهها.
سه سؤال قبل از انتخاب هر الگو
برای هر جریان داده، اینها را جواب بدهید. جوابها الگو را تعیین میکنند، نه برعکس.
چقدر تازگی لازم است؟ موجودی با پنج دقیقه تأخیر معمولاً مشکلی ندارد. ماندهٔ اعتبار مشتری شاید داشته باشد.
اگر طرف مقابل در دسترس نبود چه؟ این سؤال بیشتر از بقیه نادیده گرفته میشود و بیشتر از بقیه به دردسر میخورد.
صاحب این داده کیست؟ اگر دو سامانه بتوانند یک چیز را عوض کنند، تعارض حتمی است.
الگوها
تماس مستقیم. یکی از دیگری میپرسد و منتظر جواب میماند. ساده و دقیق، و شکنندگیاش این است که در دسترس نبودن یک طرف، طرف دیگر را هم میخواباند.
جایش: وقتی جواب همین حالا لازم است و بدون آن نمیشود ادامه داد — استعلام ماندهٔ اعتبار در لحظهٔ ثبت سفارش.
شرطش: مهلت، تلاش مجدد، و یک رفتار جایگزین که از قبل تصمیم گرفته شده باشد. اگر سرویس جواب نداد، سفارش رد میشود یا با آخرین دادهٔ شناختهشده ثبت و علامتدار میشود؟ در عمل تقریباً همیشه دومی بهتر است.
صف پیام. فرستنده پیام را میگذارد و میرود؛ گیرنده هر وقت توانست برمیدارد. دو طرف از هم جدا میشوند.
جایش: هر کاری که میتواند چند ثانیه دیرتر انجام شود. ارسال سفارش به انبار، ثبت سند در مالی، ارسال پیامک.
مزیت اصلیاش این است که خرابی موقت طرف مقابل، پیام را از بین نمیبرد. تفصیلش در صف پیام.
رویداد. سامانه اعلام میکند چه اتفاقی افتاده و هر کس علاقهمند بود واکنش نشان میدهد. تفاوتش با صف در این است که فرستنده نمیداند چه کسی گوش میدهد.
جایش: وقتی چند سامانه باید به یک اتفاق واکنش نشان دهند و فهرستشان با زمان عوض میشود.
همگامسازی دورهای. هر چند دقیقه یا هر شب، تغییرات منتقل میشود.
جایش: حجم زیاد و تازگی کماهمیت — کاتالوگ، لیست قیمت، دادهٔ گزارشی. و تنها گزینه وقتی طرف مقابل API ندارد.
فایل واسط. یکی فایل میسازد، دیگری میخواند. قدیمی و هنوز رایج، چون نرمافزارهای مالی قدیمی همین را میدهند.
جایش: وقتی چارهای نیست. کار میکند، به شرطی که بپذیرید همگامسازیتان تقریبی است و بدانید فایل ناقص یا تکراری را چطور تشخیص میدهید.
دو مسئله که در هر الگوی ناهمگام پیش میآید
پیام تکراری. ممکن است یک پیام دو بار برسد. اگر گیرنده هر بار سفارش جدیدی بسازد، مشتری دو بار کالا میگیرد.
راهش این است که هر پیام شناسهٔ یکتا داشته باشد و گیرنده شناسههای پردازششده را نگه دارد. کار سختی نیست و اگر از ابتدا نباشد، بعداً پیدا کردنش سخت است چون فقط گاهی اتفاق میافتد.
ترتیب. پیامها ممکن است نامرتب برسند. «سفارش لغو شد» نباید قبل از «سفارش ثبت شد» پردازش شود. شمارهٔ ترتیب در پیام، سادهترین راه است.
قاعدهای که جلوی آشفتگی را میگیرد
وقتی تعداد سامانهها زیاد شود، اگر هر کدام مستقیم به بقیه وصل شود، به شبکهای میرسید که هیچکس نمیفهمدش. پنج سامانه یعنی تا بیست اتصال ممکن.
دو راه برای مهارش:
یک نقطهٔ مرکزی که همه به آن وصل میشوند بهجای به هم. اتصالها خطی میشود نه نمایی. هزینهاش این است که آن نقطه اگر بخوابد همهچیز میخوابد.
صاحب مشخص برای هر داده. حتی بدون نقطهٔ مرکزی، اگر برای هر موجودیت دقیقاً یک سامانه صاحب باشد و بقیه فقط بخوانند، بیشتر آشفتگی از بین میرود. این ارزانترین قاعده در کل این مقاله است و بیشترین اثر را دارد. جدول صاحبها را در اتصال فروشگاه به ERP نمونهوار آوردهایم.
چیزی که همیشه لازم است و همیشه فراموش میشود
گزارش تطبیق. باید بشود پرسید «کدام سفارشهای امروز به سامانهٔ مالی نرفتهاند؟»
بدون این گزارش، شکافها را وقتی میفهمید که مشتری تماس بگیرد. با آن، هر روز صبح میبینید چند مورد جا مانده و چرا.
این را برای هر جریان داده بسازید، نه فقط برای مهمترینشان. کل هزینهاش یک کوئری و یک صفحه است.
اگر طرف مقابل API ندارد
در بازار ایران این حالت رایج است و سه راه دارد:
خواندن مستقیم از پایگاه دادهٔ آن سامانه. برای خواندن گاهی قابل قبول است، برای نوشتن تقریباً هرگز — چون منطق کسبوکارش را دور میزنید و به دادهٔ ناسازگار میرسید که کسی نمیفهمد از کجا آمده.
فایل واسط، با محدودیتهایش.
یا یک لایهٔ واسط: سرویس کوچکی که کنار سامانهٔ قدیمی مینشیند و آن را به API تبدیل میکند. تمیزترین در بلندمدت، و یک پروژهٔ مستقل با برآورد جدا — نه یک قلم زیر «اتصالات».
پیش از شروع
برای هر جریان، یک جدول کوچک بکشید: چه دادهای، از کجا به کجا، صاحبش کیست، چه تأخیری قابل قبول است، و اگر طرف مقابل نبود چه میشود.
معمولاً همین جدول نشان میدهد کدام اتصالها سادهاند و کدام یکیدوتا کل ریسک پروژهاند — و آنها همانهایی هستند که باید اول ساخته شوند، نه آخر.