グループ・複数ブランド向け

複数の会社、1つのインストール、顧客は共有しない

グループは通常、これを2通りに悪く解決します。5つの別々のインストールと5つの別々のすべてを持つか、1つのインストールでアプリケーションが常に正しくフィルタリングすると厳かに約束するかです。前者は高くつきます。後者は約束であり、約束はセキュリティモデルではありません。

複数の会社を運営されているなら——子会社を持つ持株会社、フランチャイズ、異なる市場を狙う2つのブランド、代理店とその代理店から生まれた事業——問題の形はすでにご存じでしょう。ブランド同士は人材、ツール、財務部門を共有します。しかし顧客は共有せず、共有しているように見えてもならないのです。

iKonektは1つのインストールですべてを稼働させ、その間の分離はコードではなくデータベースによって保たれます。この違いは学術的に聞こえますが、そうでなくなる日が来るまでのことです。

このレイヤーが重要である理由

アプリケーションレベルのフィルタは、クエリの中の1文です。それが機能するのは、これから書かれるすべてのクエリにその文が含まれる限りです——急いで書かれたクエリ、新しい開発者が書いたクエリ、一度しか使わないはずのレポートのために書かれたクエリも含めて。

境界をデータベースに押し込めば、計算は逆転します。ポリシーはすべての読み取りと書き込みで、すべての下で実行されます。会社を忘れたクエリは誤った行を返すのではなく、何も返しません。障害モードは空の画面と困惑した開発者になります。それが正しい障害モードです。

空の画面は機能です。私たちは、予期せず顔を合わせることになった2人のクライアントに顧客リストを見せるより、自社のエンジニア1人に空の画面を説明する方がましです。

1つのインストール会社ごと

1顧客・スレッドスコープ制限。ブランドAの営業担当者は、設定ではなく構造によって、ブランドBの顧客にはアクセスできません。
2顧客への権利主張「このアカウントはすでに保有しています」は会社ごとに保持されるロックです。そのため、2つのブランドが同じ市場で衝突せずに活動できます。
3プロンプト・設定各会社が自分のものを編集します。これが共有された唯一の場所はバグであり、このシステムが発見できたことを最も誇りに思うバグです。
4パートナープログラム会社ごとのモジュールであり、全員が継承するグローバルなものではありません。

アプリケーションの下層で強制される境界

グループが実際に共有できるもの

分離はそれ自体のための孤立ではありません。グループ全体で共有する価値のあるものは意図的に共有され、そのほとんどは地味なものです。それがまさに正しいのです。重複したコストが潜んでいるのは地味なものだからです:

1つのインストールの実行と更新。1つのデプロイ、管理すべき1組の認証情報、パッチを当て続けるべき1つの対象。
異なる帽子をかぶる1つのチーム。1人が複数の会社で働くことはできます。できないのは、尋ねるのを忘れたクエリを通じて両方を同時に見ることです。
1つの習慣のセット。リードの割り当て方、メモの書き方、ジョブが請求書に至るまでの流れ——一度学べばどこでも適用でき、オンボーディングは1日の午前中ほどに短縮されます。
ファミリーの他の部分との1つの関係。基盤にはcastomAPI、同じアカウント、同じコネクタ——重要な箇所では会社ごとに設定されます。

グループが必ず2番目に尋ねる質問

「そのすべてにわたってレポートできますか?」はい — できます。ただし、漏れやすい境界の副産物としてではなく、グループ自身の視点から、意図的かつ明示的に行う場合です。この区別こそが設計の核心です。境界を越える行為は、それを行う権限を持つ誰かが意図的に実行したものでなければなりません。迷子になった識別子が偶然に達成できるものであってはなりません。

そして3つ目に尋ねる質問は:「ブランドの一つを売却したらどうなりますか?」データベースが維持している境界は、きれいなコピーを取り出せる境界でもあります。これは偶然ではありません — 分離と移植性は、別々の会議から見た同じ性質なのです。

床の下