これはエンジニアリング上の懸念事項のように聞こえますが、ビジネスを運営している人なら誰でも簡単に委任でき、安全に無視できます。 データモデル — ソフトウェアが顧客、注文、プロジェクトをどのように表し、それらがどのように関連しているか。ただし、データ モデルは技術的な詳細ではありません。どのような質問に答えられるか、何を自動化できるか、さらには何を確認できるかを静かに決定します。 データモデルは戦略です、それを意図的に選んだのか、それとも偶然受け継いだのか。
何が可能かはモデルによって決まります。
簡単な質問を考えてみましょう。「製品 A を購入し、サポート チケットを開いて、更新していないすべての顧客を見せてください。」それに簡単に答えられるかどうかは、完全にデータ モデルによって決まります。購入、チケット、更新が「顧客」が 1 つのエンティティである 1 つのモデル内にある場合、それはクエリです。彼らが 3 つの顧客概念を備えた 3 つのツールを使用している場合、それは数日かかるプロジェクトになる可能性があり、それはおそらく間違っています。 「リスクのある顧客に再度関与する」という戦略は、最初の企業には利用可能ですが、2 番目の企業には事実上閉じられています。これは野心のためではなく、アーキテクチャのためです。
戦略とは、実行しようとする一連のことです。データ モデルは、実際に実行できることのセットです。両者が異なる場合は、データ モデルが優先されます。
断片化されたモデルは断片化された戦略です。
データが 12 個のツールに存在する場合、データ モデルは 1 つではありません。12 個あり、それぞれにコア エンティティの独自の定義があり、完全に一致するものはありません。その断片化は中立的ではありません。パーソナライゼーション、ライフサイクルの自動化、真の収益性分析、顧客全体を 1 つのビューで把握する必要があるものなど、断片全体を把握する必要があるあらゆる戦略を黙って排除します。分散したデータがサポートできる範囲に合わせて戦略が静かに縮小され、削除されたオプションに気付かない可能性があります。
意図的にモデルを選択します。
戦略的な動きは、データ モデルを戦略的決定として扱い、意図的に選択することです。統合モデルでは、コア エンティティを一度定義すれば、すべてがそれらに関連するため、利用可能な戦略の最大数が維持されます。これは、アーキテクチャ上、選択肢を開いたままにしておくのと同じです。2 年後に必要となる横断的な機能を今知る必要はありませんが、一貫したデータ モデルにより、必要になったときにそれが可能になることが保証されます。
結果は技術的なものではなく、戦略的なものであるため、これを気にするためにデータベースを気にする必要はありません。ビジネスがその世界をどのように表現するかによって、ビジネスで何ができるかが決まります。統合モデルを選択すれば、戦略的なオプションを常にオープンに保つことができます。断片化したものを継承すると、誰も選ばなかった建築によって建てられた、見えない壁にぶつかりながら何年も過ごすことになる。