今回は、テクノロジーアーキテクチャをどう設計するのか説明します。
テクノロジーアーキテクチャは、エンタープライズアーキテクチャの一要素で、データやアプリケーションを支えるIT基盤やコミュニケーション基盤のテクノロジーの仕組を表します。
ITマネジメントの導入プロセスにおけるテクノロジーアーキテクチャの設計の位置づけは次の図のようになります。
次の図は、テクノロジーアーキテクチャを設計するプロセスを示しています。
※実践は、順番、点線は参照を示す線です。
今回は、このテクノロジーアーキテクチャ設計プロセスに従って、次の順で、ビジネスアーキテクチャの具体的な設計方法について説明します。
- IT基盤（方針レベル）の設計
- コミュニケーション基盤（方針レベル）の設計
- BPM基盤（方針レベル）の設計
- データ管理基盤（方針レベル）の設計
- IT戦略の策定
- IT基盤（製品レベル）の設計
- コミュニケーション基盤（製品レベル）の設計
- BPM基盤（製品レベル）の設計
- データ管理基盤（製品レベル）の設計
IT基盤（方針レベル）の設計
IT基盤導入基準の定義
IT基盤をクラウドコンピューティングで構築するかオンプレミスにするか判断する基準を定義します。
クラウドコンピューティングを採用する場合、IT基盤の仮想化により、可用性やキャパシティを高めるための設計や構築に対する初期コストは削減されますが、運用コストはかかります。
※
オンプレミス
オンプレミスとは、サーバやソフトウェアなどの情報システムを、使用者が管理している施設の構内に機器を設置して運用することです。プレミスは「構内」「店内」の意味です。
IT基盤導入方針の設定
IT基盤導入基準に従って、アプリケーションアーキテクトと共同でIT基盤導入方針を設定します。
コミュニケーション基盤（方針レベル）の設計
コミュニケーション基盤導入基準の定義
電子メール、チャット、電子会議システムなどコミュニケーション基盤を導入するかどうか判断する基準を定義します。
コミュニケーション基盤導入方針の設定
コミュニケーション基盤導入基準に従って、コミュニケーション基盤導入方針を設定します。
BPM基盤（方針レベル）の設計
BPM基盤導入基準の定義
どのような場合にBPM基盤を導入するかなど、BPM基盤を導入する場合の基準を定義します。
BPM基盤導入方針の設定
BPM基盤導入基準に従って、具体的なBPM基盤の導入方針を設定します。
データ管理基盤（方針レベル）の設計
データウェアハウスの導入基準の定義
データウェアハウスを導入するかどうか判断する基準を定義します。
例
多次元分析など記述的分析が必要な場合は、表形式で構造化されたデータの履歴を保持し、高速にクエリすることができるデータウェアハウスを導入します。
データ分析環境の導入基準の定義
データ分析環境を導入するかどうか判断する基準を定義します。
例
データウェアハウスが企業全体のデータを保持いる場合で、特定の領域や部門にデータを分けることでセキュリティを確保するとともに、クエリのパフォーマンスを上げる必要がある場合、データマートを導入します。
データレイクの導入基準の定義
データレイクを導入するかどうか判断する基準を定義します。
例
AIがデータをマイニングして予測的分析や処方的分析を行うなど、動画や音声など非構造化データも含めて、多様で大量のデータを高速にマイニングする必要がある場合、データレイクを導入します。
NoSQLの導入基準の定義
NoSQLを導入するかどうか基準する基準を定義します。
例
リレーショナルデータベースの表形式のように厳密に構造化できないが、IoTからのデータなど、様々な種類の値に対応できるデータ項目の関係を構造化したい場合、NoSQLデータベースを導入します。
マスターデータ管理の基準の定義
マスターデータをどう管理するのか（トランザクションハブや統合アプローチなど）判断する基準を定義します。
例
マスターデータを管理する主管システムで保持するマスターデータの構造が特殊でない場合、その主管システムをトランザクションハブにし、特殊である場合、マスターデータを管理する特別なシステムを導入します。
データ統合の基準の定義
データをどう統合するのか（リアルタイム統合やイベント駆動統合など）判断する基準を定義します。
例
データを統合する場合、データの適時性、トランザクション整合性などリアルタイム性を求められる（レイテンシの許容度が非常に低い）場合は、APIなどによるリアルタイム統合、そうでない場合は、システム間を疎結合にするために、非同期メッセージングなどによるイベント駆動による統合を考えます。
データ連携の基準の定義
データをどう連携するのか（ESBなどのデータ連携基盤を使って統合するかなど）判断する基準を定義します。
例
データ連携を考える場合、業務パッケージ（ブラックボックスでモノリシックなシステム）間の連携が多く、連携方法も多様な場合、連携機能をカプセル化するために、ESBなどのデータ連携基盤を導入することを考えます。
データウェアハウスの導入方針の設定
データウェアハウス導入基準に従って、データウェアハウスの導入方針を設定します。
例
売上分析システムなど多次元分析が必要なので、表形式で構造化されたデータの履歴を保持し、高速にクエリすることができるデータウェアハウスを導入します。
データ分析環境の導入方針の設定
データ分析環境の導入基準に従って、データ分析環境の導入方針を設定します。
例
企業全体にセントラルなデータウェアハウスを設けるのではなく、売上分析システムやLTV分析システムなど、分析の主題ごとに軽量なデータマートを設けるごとでデータ分析の要求ごとにアジャイルに対応できるようにします。
データレイクの導入方針の設定
データレイクの導入基準に従って、データレイクの導入方針を設定します。
例
戦略目標「製品品質の維持向上」を実現するために、過去の製品の障害データ（画像含む）をマイニングして予測的分析や処方的分析を行いたいため、動画や音声など非構造化データも含めて、多様で大量のデータを高速にマイニングできるデータレイクを導入します。
NoSQLの導入方針の設定
NoSQLの導入基準に従って、NoSQLの導入方針を設定します。
例
戦略目標「製品品質の維持向上」を実現するために、納入先の納入機から状態データを定期的に取得し予防保全を実現したいため、IoTからのデータなど、様々な種類の値に対応できるデータ項目の関係を構造化できるNoSQLデータベースを導入します。
マスターデータ管理の方針の設定
マスターデータ管理の基準に従って、マスターデータ管理の方針を設定します。
例
顧客管理システムを顧客マスターデータのトランザクションハブにします。
マスターデータ管理の方針に従って、改めて業務概念データフローを見直します。
上図は、顧客管理システムがトランザクションハブになって、Topicを介して、顧客データを要するすべてのアプリケーションに、顧客データをブロードキャストしています。
データ統合方針の設定
データ統合の基準に従って、データ統合方針を設定します。
例
データを統合する場合、データの適時性、トランザクション整合性などリアルタイム性を求められる（レイテンシの許容度が非常に低い）場合は、APIなどによるリアルタイム統合、そうでない場合は、システム間を疎結合にするために、非同期メッセージングなどによるイベント駆動による統合を考えます。
データ連携方針の設定
データ連携の基準に従って、データ連携方針を設定します。
例
業務パッケージはERPしかなく、業務パッケージ間の連携機能をカプセル化する必要がないため、ESBなどのデータ連携基盤は導入しません。
IT戦略の策定
IT戦略では、中長期的に、どのITサービスにリソース（要員やコンピュータ資源）をどの程度配分するか決定します。
ITサービスはビジネスの目的を実現するための手段なので、それが所属する事業単位の戦略に連動します。
例えば、市場の占有率×成長率で事業単位の組み合わせを考える事業ポートフォリオに基づいて全社戦略を考える場合、投資対象となる事業単位に所属するITサービスが投資対象となり、投資レベルによってリソースの配分の程度が決まります。
この例の場合、新規事業の成長を促す戦略（探索）と、次の花形をつくる戦略（深化）があり、それぞれに所属するITサービスが投資対象になります。
IT基盤（製品レベル）の設計
システムの構成におけるITマネジメントの管理対象は次のようになります。
ここでは、アプリケーションアーキテクトと共同でIT基盤部分の製品を選定します。
コミュニケーション基盤（製品レベル）の設計
上図の共通アプリケーションのうち、コミュニケーション基盤の製品を選定します。
BPM基盤（製品レベル）の設計
データ管理基盤（製品レベル）の設計
データウェアハウスの製品選択基準の定義
データウェアハウスの製品を選択する際の判断基準を定義します。
判断基準は、データウェアハウスの導入方針、製品に求められる機能要件、非機能要件、開発ベンダーの特性、価格などの観点で定義します。
データレイクの製品選択基準の定義
データレイクの製品を選択する際の判断基準を定義します。
判断基準は、データレイクの導入方針、製品に求められる機能要件、非機能要件、開発ベンダーの特性、価格などの観点で定義します。
データ分析環境の製品選択基準の定義
データ分析環境（データマートやBIツールなど）の製品を選択する際の判断基準を定義します。
判断基準は、データ分析環境の導入方針、製品に求められる機能要件、非機能要件、開発ベンダーの特性、価格などの観点で定義します。
NoSQLの製品選択基準の定義
NoSQLデータベースの製品を選択する際の判断基準を定義します。
判断基準は、NoSQLの導入方針、製品に求められる機能要件、非機能要件、開発ベンダーの特性、価格などの観点で定義します。
マスターデータ管理の製品選択基準の定義
マスターデータ管理の製品を選択する際の判断基準を定義します。
判断基準は、マスターデータ管理の方針、製品に求められる機能要件、非機能要件、開発ベンダーの特性、価格などの観点で定義します。
データ統合の製品選択基準の定義
データ統合の製品を選択する際の判断基準を定義します。
判断基準は、データ統合方針、製品に求められる機能要件、非機能要件、開発ベンダーの特性、価格などの観点で定義します。
データ連携の製品選択基準の定義
データ連携の製品を選択する際の判断基準を定義します。
判断基準は、データ連携方針、製品に求められる機能要件、非機能要件、開発ベンダーの特性、価格などの観点で定義します。
データウェアハウスの設計（製品レベル）
データウェアハウスの製品選択基準に従って製品を決定します。
データ分析環境の設計（製品レベル）
データ分析環境の製品選択基準に従って製品を決定します。
データレイクの設計（製品レベル）
データレイクの製品選択基準に従って製品を決定します。
NoSQLの設計（製品レベル）
NoSQLの製品選択基準に従って製品を決定します。
マスターデータ管理の設計（製品レベル）
マスターデータ管理の製品選択基準に従って製品を決定します。
データ統合の設計（製品レベル）
データ統合の製品選択基準に従って製品を決定します。
データ連携の設計（製品レベル）
データ連携の製品選択基準に従って製品を決定します。
