構造化データ設計戦略が重要な理由: 例
背景
これまでの 2 つの記事では、データ駆動型設計の考慮事項、特にビジネス データが潜在的なビジネス価値をどのように表すかに焦点を当ててきました。 重要なメッセージは、構造化データ アーキテクチャが、その固有の価値を引き出すことを可能にする技術的基盤であるということです。 しかし、それらの記事は、関連するトピックを概念レベルで紹介することに重点を置いていました。 今日は、より具体的でわかりやすい例、つまりデータファーストの考え方に沿ったアプリケーションの設計についてどのように考えるかについてのストーリーで、概念を説明したいと思います。
しかし、まず、なぜ気にする必要があるのでしょうか?
話に入る前に、データが過去よりも今日重要である理由を振り返ってみましょう。 データの収集と保存は、これまで多くの企業で、監査やコンプライアンスなどのガバナンス上の理由から、主にそれ自体の目的で行われてきました。 そのため、データの収集と保存は歴史的に、ビジネス運営に対する一種の「税金」と見なされており、直接的な運用上のビジネス価値はほとんど認識されていません。
現在変わったのは、収集されたデータをマイニングすることでビジネス プロセスを最適化し、顧客体験を向上できるという認識が深まったことです。 例えば、デジタル小売業に関する最近の調査によると、ビジネスプロセスと顧客体験の向上という2つの目標は、調査対象企業の57%にとってデジタル変革の主な推進力となっている。企業。 重要な観察、つまり「なぜそれが重要なのか」の本質は、データ駆動型ワークフローが、外部向けの領域（顧客体験など）と内部向けの領域（コアビジネスプロセス）の両方でビジネスに影響を与えるという点です。 そのため、最も重要なビジネス ワークフローの品質とコスト効率を実現するには、思慮深く計画的なデータ戦略が不可欠です。 さらに、ワークフローが計測されたデータ排出をデータ収集および分析インフラストラクチャに送信するように設定されている場合、ワークフロー自体を継続的に分析および改善できるため、常に適応し最適化されたビジネス ワークフローが実現します。
ちなみに、これらの企業がデジタル変革に関して最も懸念していたのは、これらのデジタル プロセスのサイバー セキュリティを確保することでした。実は、これもデータ テレメトリと分析のアプローチが重要な役割を果たす別の領域ですが、これについては別の記事で取り上げることにします。
アプリケーション: レストランの注文と配達
思考実験に移りますが、私は、今日のコロナウイルスに適応したライフスタイルにおいて、おそらく多くの人が共感できるであろうストーリー、つまり、レストランの食事の注文と配達をオンラインで提供するアプリケーションを選びました。 食事は顧客が指定したレストランからオンラインで注文され、ユーザーは注文品を顧客が直接受け取るか、サービスに配達を依頼するかを選択できます。
このストーリーでは、アプリケーション所有者の役割を演じます。 その役割において、私たちはさまざまな懸念に対処する必要がありますが、それらを 2 つのカテゴリに分けます。1 つ目は必要な運用活動、2 つ目は将来を見据えた戦略的な懸念です。
最初のセット（必要な運用活動）には、次のような懸念事項が含まれます。
- 場所や営業時間など、レストランの検索と特徴付け
- メニュー項目と価格に関するデータの収集
- レストランへの注文の通知
- 支払いの処理
- 注文の集荷と配送を行う人員の空き状況に関するデータを保持する
- 注文の準備状況と配送状況の追跡
2 番目の懸念事項は、日常業務とはそれほど関係ありませんが、同様に重要です。 これらの問題について事前に検討しておけば、ビジネスは俊敏かつ適応的になり、継続的に改善できるようになります。 こうした懸念の例は次のとおりです。
- 需要を予測するにはどうすればよいでしょうか? これは単純に時間帯別/週別の需要の総計である場合もあれば、レストランごとなどより細かい粒度である場合もあります。
- どのようなツール、プロセス、ワークフローがサプライヤー (レストラン) にビジネス上の洞察を提供しますか?
- 食品または配達の価格を動的に調整するにはどうすればよいでしょうか?
- アプリケーションがパブリック クラウドでホストされていると仮定した場合、運用インフラストラクチャ コストを最適化するにはどうすればよいでしょうか?
もちろん、これは私たちが抱える懸念事項の完全な一部に過ぎませんが、この小さなセットでも、拡張可能なデータ処理パイプラインをサポートする構造化データ アーキテクチャの重要性を強調する適切な議論を行うには十分です。
データ アーキテクチャまたはデータ パイプライン/鶏が先か卵が先か
アプリケーション所有者の想定される役割では、全体的なデータ戦略を検討する際に、ビジネス ワークフローを列挙し、それぞれのデータ処理のニーズを特定することから始めることができます。 一例として、営業中の近くのレストランを検索し、それぞれのメニューの選択肢と価格を提示するワークフローが挙げられます。レストランを場所と営業時間でフィルタリングし、次に、選択した特定のレストランのメニューの選択肢を検索し、おそらく配達ドライバーの空き状況によってもフィルタリングする必要があります。 そして、支払い処理、ドライバーと配送のマッチングなど、ワークフローごとにこれを実行できます。
あるいは、同様に合理的に、代わりに、基本的なデータ「原子」、つまり必要なデータ構成要素から検討を始めることもできます。 私たちは、重要なデータ アトムを識別して列挙し、それらのデータ アトムの統一された表現と一貫したセマンティクス、およびビジネス ワークフローのサポートに必要なメタデータ語彙を持つことに特に注意を払います。 サンプル アプリケーションのデータ アトムの例には、レストラン、顧客、ドライバーの位置データ、メニューや請求書に必要な食品、配送品質のフィルタリングと追跡に使用される時間、顧客とドライバーの支払いワークフローに関連する支払い情報などがあります。
ワークフローのデータ処理パイプライン、あるいはデータ「アトム」という 2 つの潜在的な出発点のどちらをデータ戦略に使用するかは、鶏が先か卵が先かという問題です。 どちらの視点も有用であり、さらに重要なことに、相互に依存しています。 基礎となるデータ アトムについて考えずにデータ処理パイプラインについて推論することはできません。また、処理パイプラインのニーズを考慮せずにデータ アーキテクチャを開発することもできません。 ただし、一般的には、ワークフロー全体を最初に通過してデータ アトムを列挙し、その後、データ パイプラインの詳細設計を行う前に、データ アーキテクチャの構造化設計に取り組むというアプローチをお勧めします。 これは、ワークフローがより動的であるためです。ワークフローはビジネスの進化に合わせて追加および変更されますが、基礎となるデータにはより多くの履歴と慣性があるため、データ アーキテクチャは事前の検討からより多くのメリットを得られます。
具体的な例に総合的なデータアーキテクチャとパイプラインアプローチを適用する
例に戻って、アプリケーション所有者として、主要なビジネスクリティカルなワークフローと、それらをサポートするために必要なデータアトムについて、かなり発展した見解を持っていると仮定しましょう。 このディスカッションの前半で、ワークフローに必要な基本的なデータ要素として、場所、時間、食品、支払い情報をいくつか特定しました。 また、以前の記事を要約すると、データ アーキテクチャは、構文の統一性、セマンティクスの一貫性、およびデータの推論と管理のためのメタデータ語彙という 3 つの主要な目標を実現する必要があります。 したがって、これらの原則を適用して、今日の例で列挙した特定のデータ アトムのデータ アーキテクチャの考慮事項について議論することができます。
位置データ アトムに焦点を当てて、3 つの主要なデータ アーキテクチャの目標をそれぞれ検討します。
- まず、統一されたデータ表現構文とは何でしょうか?
最初に思いつくのは、レストランや顧客が自分の場所を表すのに一般的に使っている住所で場所を表すことです。 ただし、配達を行うドライバーを追跡するための位置情報のニーズを考慮してください。ドライバーは多くの場合、移動中であり、おそらく主要高速道路上や、住所ではうまく説明できない場所にいるでしょう。 代わりに、緯度と経度の指定は、そのワークフローの場所を表すよりよい方法である可能性があり、この形式はレストランと顧客の場所には依然として機能します。 しかし、ドライバーは通常、レストランや顧客の場所まで移動する必要があるため、ドライバーの位置 (緯度/経度) と顧客の位置 (住所) を関連付ける方法が必要です。 したがって、より考慮された選択肢としては、すべての位置データを緯度と経度（必要な「正規の」表現）で正規化し、住所が最初に提供されたときに住所を緯度/経度に変換する機能（「取り込み」ワークフロー）を備えることが考えられます。 - 2 番目の考慮事項は、一貫したセマンティクスです。
位置が緯度/経度として正規化されていると仮定すると、これは明確な解釈を備えた確立された標準であるため、比較的簡単です。 ただし、一貫したセマンティクスのもう 1 つの側面は、精度、つまりデータの暗黙の正確さに関するものです。 GPS とマッピング データの精度は暗黙的に制限されるため、データ ソースの品質に応じて、一定の精度 (たとえば、最も近い弧秒、およそ 100 フィートなど) または可変精度で場所を指定することを選択できます。 柔軟性のために後者を選択する場合は、次に説明するメタデータを使用して、各位置データ インスタンスの精度を注釈付けする必要があります。 - データ アーキテクチャの 3 番目の目標は、収集されたデータ要素に注釈を付けて拡充する機能を備えることです。
位置情報の場合、前述したように、データの精度も含まれる場合があります。 ただし、さらに、人間にとってわかりやすくするために、特に取り込んだ住所データを保存できるように、場所に住所を注釈として付けることもできます。 これは、アパートの複合施設など、複数の住所が同じ緯度/経度にマッピングされる可能性がある場合に特に重要です。 さらに別の強化として、位置データ フィールドが収集されたときのタイムスタンプが考えられます。これは、位置データがすぐに古くなる移動中のドライバーにとって重要な場合があります。
これまでは場所の要件についてのみ説明しましたが、今度は他の各データ フィールドについても同様の演習を実施してみましょう。 ただし、各データ アトムの懸念事項をすべて列挙するのではなく、代わりに注目すべきいくつかの観察事項を強調します。
- 時間データアトムについて: 時間値の表現は非常に難しいことで知られています。 構文的にも (例: 24 時間形式と 12 時間形式) 異なる場合があります。 12 時間制と AM/PM の組み合わせ) と意味論的 (例: タイムゾーンの概念と夏時間の観測による変化) に使用されます。 したがって、時間の表現は正規化する必要があると考えられます (たとえば、GMT に正規化したり、Unix/Linux ユーザーの場合は「エポック以降の」秒数に正規化したりします)。
- 食品アイテムのデータ インスタンスは、独自のニーズにより、非常に多様化する可能性があります。 データ アトムは自由形式であることが多いため、統一された構文を試みるよりも、標準的なメタデータ語彙の方が便利です。 一部のメタデータ フィールドは、「冷蔵保存が必要」や「ナッツを含む」など、アイテムごとの静的プロパティ用ですが、その他のメタデータ フィールドは、「辛さレベル」や「好みの調味料」など、インスタンスごと (注文ごと) の食品アイテム情報に必要になります。 どちらの場合でも、設計目標には、メタデータ フィールドの統一された構文と一貫したセマンティクスが必要であり、それによって、メニュー項目の全インベントリでメタデータ フィールドを共有できるようになります。
- その他の重要な考慮事項は、データのコンプライアンスとガバナンスです。 1 つの側面はデータ保持ポリシーであり、顧客の IP アドレスやドライバーの位置履歴などの一部のフィールドは短期間のみ保持できます。 もう 1 つの一般的な考慮事項は、一部のフィールドにセキュリティまたはプライバシーの制約がある可能性があることです。例としては、支払い情報があります。 メタデータの拡張は、どちらの場合も解決策となります。 メタデータは、データ保持のためのデータ有効期限を IP アドレスまたは場所の値に注釈付けるために使用する必要があります。 支払い情報の場合、メタデータを使用して、保存データの暗号化の必要性などのセキュリティ要件を伝えたり、永続データ ストアの地理的位置の制約を指定したりできます。
この例はまだ表面をなぞっただけですが、現実世界のシナリオに関連する多くの懸念事項を浮き彫りにしました。 しかし、現実の世界では、データ戦略を検討するプロセスはここで終わるのではなく、反復的かつ継続的に行われます。 データ要素がビジネス ワークフローを具体化するデータ処理パイプラインに取り込まれると、データ アーキテクチャに対して反復的な調整と機能強化が行われます。 既存のワークフローが強化され、新しいワークフローが追加されると、新しいデータ アトムとともに既存のデータ アトムに対する追加のデータ アーキテクチャ要件が見つかります。
終わりに
この例は簡潔にするために合理化されていますが、ワークフローをデータ アーキテクチャへの影響にマッピングする際の重要な原則を示しています。 このプロセスは常に、ビジネス ニーズ、つまり顧客エクスペリエンスとそれらのニーズを満たすために必要なビジネス プロセスを考慮することから始まります。 ビジネス プロセスは、ビジネス用語の要素を定義します。 次のレベルの特異性では、プロセスはデータ ボキャブラリを活用するデータ パイプラインにマッピングされます。
重要な原則は、構文、セマンティクス、注釈を定義する堅牢なデータ アーキテクチャによって、データ パイプラインを効率的に強化し、新しいワークフローを簡単に追加できる基盤が構築されることです。 ビジネス レイヤーの抽象化では、既存のビジネス プロセスを簡単に変更でき、新しいビジネス プロセスを迅速にオンラインにすることができます。 逆に、データ語彙、データ アーキテクチャ フレームワーク、またはこれらをビジネス ニーズに結び付けるといった領域のいずれかで慎重な決定を下さなければ、最終的には脆弱で壊れやすいシステムとなり、新しいビジネス要件に柔軟に対応できなくなります。