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