システム統合は、工学においては、構成要素となるサブシステムを1つのシステム(システムが包括的な機能を提供できるように連携するサブシステムの集合体)に統合し、サブシステムがシステムとして連携して機能することを保証するプロセスとして定義され[ 1 ] 、情報技術においては[ 2 ] 、異なるコンピューティングシステムやソフトウェアアプリケーションを物理的または機能的にリンクして、協調した全体として機能させるプロセスとして定義される[ 3 ] 。
システムインテグレーターは、コンピュータネットワーク、エンタープライズアプリケーション統合、ビジネスプロセス管理、手動プログラミングなど、さまざまな技術を使用して個別のシステムを統合します。[ 4 ]
システム統合とは、既存の、多くの場合異なるシステムを、「顧客への価値を高める」[ 5 ](例えば、製品の品質と性能の向上)に重点を置きながら、同時に企業にも価値を提供する(例えば、運用コストの削減と応答時間の短縮)方法で統合することです。[ 5 ]インターネットでつながった現代社会では、システム統合エンジニアの役割は重要です。構築中のシステム内だけでなく、既に展開されているシステムとも接続するように設計されたシステムがますます増えています。[ 6 ]
垂直統合(「水平統合」とは対照的に)は、機能エンティティ(サイロとも呼ばれる)を作成することによって、サブシステムをその機能に応じて統合するプロセスです。 [ 7 ]この方法の利点は、統合が迅速に実行され、必要なベンダーのみが関与するため、短期的にはコストが安くなることです。一方、新しい機能や機能の強化の場合、実装(システムの拡張)する唯一の方法は別のサイロを実装することになるため、所有コストは他の方法よりも大幅に高くなる可能性があります。サブシステムを再利用して別の機能を作成することはできません。 [ 8 ]
スター統合(スパゲッティ統合とも呼ばれる)は、各システムが残りのサブシステムと相互接続されるシステム統合プロセスです。統合されるサブシステムの視点から見ると、接続は星を連想させますが、システム全体の図で示すと、接続はスパゲッティのように見えるため、この方法の名前が付けられました。コストは、サブシステムがエクスポートするインターフェースによって異なります。サブシステムが異種または独自のインターフェースをエクスポートする場合、統合コストが大幅に上昇する可能性があります。追加のサブシステムを追加すると、システムを統合するために必要な時間とコストが指数関数的に増加します。機能の観点からは、機能の再利用の柔軟性が非常に高いため、この方法が好ましい場合が多いようです。[ 8 ]
水平統合またはエンタープライズ サービス バス(ESB) は、専用のサブシステムが他のサブシステム間の通信に特化している統合方法です。これにより、接続 (インターフェース) の数をサブシステムごとに 1 つだけに減らすことができ、その接続は ESB に直接接続されます。ESB はインターフェースを別のインターフェースに変換できます。これにより、統合コストを削減し、極めて高い柔軟性を実現できます。この方法で統合されたシステムでは、同様の機能を提供するがインターフェースが異なる別のサブシステムで 1 つのサブシステムを完全に置き換えることが可能です。これは他のサブシステムに対して完全に透過的です。必要な唯一の作業は、ESB と新しいサブシステムの間に新しいインターフェースを実装することです。[ 8 ]
しかし、中間データ変換のコストやビジネスロジックの責任の移転コストを回避できると考えると、水平的なスキームは誤解を招く可能性がある。[ 8 ]
産業ライフサイクル統合は、システムの初期実装、エンジニアリングと設計、プロジェクトサービス、運用という4つのカテゴリまたは統合段階を考慮したシステム統合プロセスです。[ 9 ]このアプローチでは、システムとサブシステムを統合する際に、産業資産の各ライフサイクル段階の要件を組み込みます。主な成果物は、資産のライフサイクル全体を通して機能する標準化されたデータアーキテクチャです。
共通データ形式は、各アダプタが他のすべてのアプリケーションの形式との間でデータを変換する必要をなくすための統合方法です。エンタープライズアプリケーション統合(EAI) システムは通常、アプリケーションに依存しない (または共通の) データ形式を規定します。[ 10 ] EAI システムは通常、アプリケーション固有の形式と共通形式の間で変換するのに役立つデータ変換サービスも提供します。これは 2 つのステップで行われます。アダプタは、アプリケーションの形式からバスの共通形式に情報を変換します。次に、これに意味変換が適用されます (郵便番号を都市名に変換したり、あるアプリケーションのオブジェクトを他のアプリケーションのオブジェクトに分割/マージしたり、など)。
システム統合は組織にとって困難な場合があり、これらの課題は新しいソフトウェアソリューションを導入した後の投資収益率を低下させる可能性があります。これらの課題には、信頼の欠如と他社とのデータ共有への意欲の欠如、さまざまな業務を第三者にアウトソーシングすることへの意欲の欠如、明確なコミュニケーションと責任の欠如、機能の所在に関するパートナー間の意見の相違、統合の高コスト、優秀な人材の確保の難しさ、データサイロ、および共通のAPI標準などが含まれます。[ 11 ]これらの課題は、「企業内および企業間のビジネスシステム統合を妨げたり遅らせたりする」障害を生み出します。[ 12 ]明確なコミュニケーションと簡素化された情報交換は、ビジネス要件をサポートできる長期的なシステム統合を構築する上で重要な要素です。
一方で、システム統合プロジェクトは非常に大きな成果をもたらす可能性があります。旧式のレガシーシステムの場合、さまざまな統合手法によってリアルタイムのデータ共有が可能になります。これにより、例えば、パブリッシャー/サブスクライバー型のデータ配信モデル、統合データベース、イベント駆動型アーキテクチャを実現したり、ユーザーによる手動データ入力を削減したり(エラーの削減にもつながります)、アプリケーションのフロントエンドを刷新または最新化したり、クエリやレポート処理を高価な運用システムから安価な汎用システムにオフロードしたり(コスト削減、拡張性の向上、メイン運用システムの処理能力の解放につながります)することができます。通常、統合プロジェクトを実施する価値があるかどうかを判断するために、包括的な費用対効果分析が行われます。
{{cite journal}}: CS1 maint: 複数の名前: 著者リスト (リンク)