ソリューションデザイン

機能要件の定義により、ユースケースで実装する必要のあるコンポーネントを抽出することができます。これにより、それらの要件を満たすために何を提供する必要があるか、そして評価実装オプションに進むためのより小さなピースが得られます。

機能要件からコンポーネントの抽出

ソリューションデザインプロセスの次のステップは、機能要件を取り、それらを Foundry で実装できるコンポーネントにマッピングし、その構成の選択肢を検討することです。このステップはユースケースによって異なるかもしれませんが、以下のコンポーネントは広く有用です。

• オブジェクトモデル：コア、派生、およびユースケースオブジェクトタイプとそのリンクタイプを識別するオブジェクトモデルのスケッチ。
• ライフサイクル図：オブジェクトを変更するためにユーザーが実行するアクションの状態遷移図。
• エンリッチメント：意思決定の入力を知るために必要なデータエンリッチメントのリスト。
• インターフェースの期待値：異なるインターフェースとその目的の分解。

これらのコンポーネントを機能要件から抽出することができます。例えば：

ルート運用アナリスト（ユーザータイプ）は、責任のあるルートのためのアラート受信トレイ（インターフェース）を確認し、優先度、フライトおよびルートの詳細、および組織への影響（意思決定の入力）に基づいてアラートをトリアージ（意思決定）し、各アラートを再割り当て、解決、またはエスカレーション（アクション）します。

• アラート受信トレイ - 新しいアラートを確認するためのスタンドアロンインターフェースが必要です
• 彼らの責任ルート - ルート、ユーザー、およびそれらの関係を反映するデータの概念が必要です
• アラートのトリアージ - 現在の担当者を反映する異なる状態を持つオブジェクトが必要です。また、アラートを何らかの方法で生成する必要があります。
• 優先度、フライトおよびルートの詳細、および組織への影響 - フライト、航空会社、航空機などに基づくルートに関連する追加のデータが必要です。アラートの優先度と組織への影響を反映するエンリッチメントが必要です。
• 再割り当て、解決、またはエスカレーション - アラートオブジェクトタイプの完全な状態遷移を定義するアクションが必要です

他の機能要件に対してもこのプロセスを繰り返すことで、以下のコンポーネントが得られます。

• オブジェクトモデル
• ライフサイクル図
• エンリッチメント
• インターフェースの期待値

オブジェクトモデル

この図は、機能要件に埋め込まれた概念を含むオブジェクトモデルを表しています。円はオブジェクトタイプを表し、それらの間の線はリンクタイプです。詳細レベルに応じて、各オブジェクトタイプの主キープロパティと各リンクタイプのカーディナリティ（1:1、1:N、またはN:N）を識別することを検討してください。

色は、オントロジーのコアであるオブジェクトタイプを識別するのに役立ちます。これらは、データの粒度に直接マップされ、真実のソースからきます。また、派生し、エンリッチメントとして作成する必要があるオブジェクトタイプも識別します。色はまた、ユースケース内のオペレーションワークフローを通じてアクティブに編集されるユースケースオブジェクトタイプを識別します。

例えば、ソースシステムに遡ると、フライト、航空機、航空会社、空港に関するデータの記録システムを特定できます。その後、パイプラインは、これらの概念を反映したコアオントロジーを生成できます。

ただし、「ルート」に関するデータを持つソースシステムはありません。変換セグメントでは、ルートの概念をオントロジーに反映させるために、1行ごとのルートデータセットを派生させます。

ユースケースのオペレーショナルな側面には、組織を反映するデータモデルが必要です。これが、チームと従業員のオブジェクトタイプです。また、アラートや関連するオブジェクトタイプをキャプチャするための標準的なビルディングブロックオブジェクトタイプも必要です。

ライフサイクル図

この簡略化された図は、アラートチケットオブジェクトの可能な状態と、状態間の遷移を行うアクションを追跡します。ユースケースが進むにつれて、各アクションでキャプチャされるメタデータや、特定のアクションが利用可能であるかどうかを定義する検証、およびそれを実行できるユーザーを含めて追跡がさらに洗練されます。

エンリッチメント

機能要件とオブジェクトモデリング演習を通じて、オブジェクトレベルおよびプロパティレベルのエンリッチメントを特定できます。オブジェクトレベルのエンリッチメントは、ソースデータに本質的に反映されていない新しい、派生した概念です。これらは、ルートオブジェクトタイプのような外部の概念に一致することがありますし、アラートチケットのようなオペレーショナルまたはユースケース固有の概念に一致することがあります。

プロパティレベルのエンリッチメントは、組織のルールを適用したり、より低い粒度のデータを集約したり、モデルを実行したりして、新しいデータを既存のオブジェクトタイプに追加します。例えば、各アラートチケットの優先度と組織への影響の推定値を反映する必要があります。

インターフェースの期待値と意図

機能要件全体で、ユーザーが持つであろう異なる意図とそれに対応するインタラクションの期待を特定できます。意図と期待を特定することで、実際の実装と対応するツールのリストが得られます。

例えば、次のようなことがあります。

• オペレーショナルユーザーは、必要なアラートのみを確認し、すぐに利用できるすべての重要なコンテキストを持つガイド付きのスタンドアロンエクスペリエンスを期待しています。意図は直接アクションを起こすことです。
• 分析者は、assignedおよびunder investigationのアラートをすべて表示する素早い場所を期待し、簡単にアドホックなデータ探索と分析に移行し、調査の物語を書き上げることができます。意図は分析および文書化です。
• エグゼクティブユーザーは、オペレーショナルプロセスの有効性を提示し、時間の経過とともに変化していることを強調するダッシュボードビューを期待しています。意図は理解です。

実装オプション

ユースケースのコンポーネントをカタログ化した後、各部分を実装することが次の決定です。上記の図は、一般的なコンポーネントのデフォルトオプションをマッチさせるのに役立ちます。

例えば、上記のインターフェースの期待値は以下のようになります。

スタンドアローンの受信トレイアプリケーションは Workshop プロジェクトです。多くのインタラクションが単一のチケットに関連しているため、特定のチケットの Object View は、関連する意思決定のコンテキストと適切なアクションへの簡単なアクセスの両方を提示する統一されたビューを提供する必要があります。エグゼクティブダッシュボードは、Quiver テンプレートから始めることができます。レビューと監督プロセスが洗練されるにつれて、テンプレートは別の Workshop モジュールや、定期的に追跡および承認するための追加のユースケースオブジェクトタイプセットに進化するかもしれません。ほとんどの場合、Carbon ワークスペースは、検索および探査のための関連するオブジェクトタイプのサブセットとカスタムインターフェースを、洗練された、統一された、そしてアクセシブルなエクスペリエンスにまとめます。

これらのオプション内の考慮事項についての詳細は、Pipeline、Ontology、およびApp Buildingのドキュメントにあります。以下では、実装決定がこれらのセクション全体にわたって行われる領域に焦点を当てます。

最も重要な例は、特定のエンリッチメントをどこで実装するかです。

エンリッチメントの実装

ルートオブジェクトタイプのエンリッチメントと、各ルートに関する知りたい一連のメトリックの例を考えてみましょう。平均フライト時間、30分以上の到着遅延があるフライトの数、およびフライト時間の変動性の指標です。

1つのアプローチは、アプリケーション内でこれらを導出することです。例えば、出発地と目的地の空港でグループ化されたフライトオブジェクトタイプのピボットテーブルを作成し、平均フライト時間を計算できます。まず、遅延が30分以上のフライトのセットにフィルターをかけた場合、同様にピボットテーブルをプロットして、遅延フライトの数があるルートを表示できます。

このアプローチにはいくつかの欠点があります。メトリックは特定のインターフェース内で計算されるため、再利用することができません。また、ページの読み込み時に評価する必要があるため、パフォーマンスが比較的低下することがあります。また、メトリックが一時的なものであるため、それらをさらなるフィルタリングや分析の一部として使用することはできません。このアプローチの利点は、計算が動的に行われるため、アクションによる新しい値や更新された値の変更をすぐに反映できることです。

過度に単純化されたヒューリスティックは次のようになります。エンリッチメントが、アクションを通じてユーザーが変更できるデータに依存しない場合、データレイヤーでエンリッチメントを作成してください。