چند شرکت، یک نصب، بدون مشتریان مشترک

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

iKonekt همهٔ آن‌ها را از یک نصب اجرا می‌کند و جدایی میانشان را پایگاه داده حفظ می‌کند، نه کد. این تمایز تا روزی که موضوعیت پیدا نکند آکادمیک به نظر می‌رسد.

گروه در واقع چه چیزهایی را به اشتراک می‌گذارد

جدایی، انزوا به‌خاطر خودش نیست. چیزهایی که ارزش اشتراک در سطح گروه را دارند آگاهانه به اشتراک گذاشته می‌شوند و بیشترشان همان‌های خسته‌کننده‌اند — که دقیقاً درست است، چون هزینهٔ تکراری در همان‌هاست:

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

سؤالی که گروه همیشه دوم می‌پرسد

«آیا می‌توانیم روی همهٔ آن‌ها گزارش بگیریم؟» بله — از دیدگاه خودِ گروه، آگاهانه و صریح، نه به‌عنوان اثر جانبی مرزی نشتی‌دار. همین تمایز کل طراحی است: عبور از خط باید کاری باشد که کسی عمداً و با اختیار انجام داده باشد. هرگز نباید چیزی باشد که یک شناسهٔ سرگردان بتواند تصادفی انجامش دهد.

و سؤالی که سوم می‌پرسند: «اگر یکی از برندها را بفروشیم چه می‌شود؟» مرزی که پایگاه داده نگه می‌دارد، مرزی است هم که می‌توانید یک نسخهٔ تمیز از بیرونش بکشید. این تصادفی نیست — جدایی و قابلیت انتقال یک ویژگی‌اند که از دو جلسهٔ متفاوت دیده شده‌اند.