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