すべてのプログラマは、思考が自由に形や手段を発明できるとき、レガシーを振り返ることなく決定を下すことができるとき、ゼロからシステムを作ることを好む。 もちろん、完全に設計されたシステムは、専門家によって作成されたものである限り、常にモノリシックに見え、喜ばれます。 しかし、私たちの現実は流動的であり、時間の経過とともに、事業開発、プロセスの変更、企業の買収または合併、新しいシステムの導入、ハードウェアまたはソフトウェアプラットフォームの変更、さらには法律の制定の過程で、概念的な牧歌に違反します。
システムのサポートと実装を行い、さらに開発、リエンジニアリング、統合に取り組んだ人たちは、ITにおけるすべての努力（注意、時間、お金）の3分の2以上が、互換性のないモジュールを「接着」して「友達を作る」ことに費やされていることを知っています異なるプラットフォームで、異なる人々、異なる時点、異なる言語と技術で。
統合に影響する要因をリストして分析します。
- プロセスの高速化 。 組織の開発では、設計とユーザーインターフェイスはもちろんのこと、単に絶えず変化しているだけでなく、データ構造、ビジネスプロセスを変更することがますます頻繁に必要になっています。 ここでは、「変動性」がシステムの本質であり本質であるような動的な領域でのみ、統合のタスクが悪化し、深刻な問題に変わります。
- 配布 組織はますます大きくなり、取り組まれるタスクはますます複雑になり、論理的、組織的、および地理的な分散が生じています。
- 異質性 。 大規模なプロジェクトでは、あるメーカーのプラットフォームとツールに固執することはほとんど不可能であるため、いくつかのプラットフォームの機能を検討してサポートする必要があります。
- 遺伝 。 システムのレガシー、時代遅れのテクノロジー、古いハードウェアを完全に放棄できないことは、ちなみに、時には信頼性とパフォーマンスの非常に良い指標を提供しますが、決して統合には寄与しません。
- ランダムネス 。 データを完全に形式化、指定、構造化することは常に可能とは限らず、モデルの一部は「疎結合」のままであり、機械の処理、分析、インデックス付け、計算を受け入れられない、または受け入れにくい。
- 条件付け 。 残念ながら、情報システムは、技術的な枠組みだけでなく、人々の習慣（再訓練が困難）、法律の特性（このようなシステムの登場に単純に準備が整っていない）、および開発者に依存しない他の多くの要因によっても制限されています。
- 双方向性 情報の消費者は、システムの反応の速度、情報配信の速度および効率について常に期待を高めています。 ほとんどのプロセスはリアルタイムで実行される傾向があります。
- モビリティ 。 システムのユーザーはより速く動き始め、彼との相互作用は、交通機関、家庭、路上、公共の場所、そしてどこでも公共の通信チャネルを通じて行われます。
- 安全性 データはセキュアルーム内のメディアに保存されていましたが、暗号化について実際に心配する人はいませんでしたが、現在ではネットワークパケットが空中を飛んでおり、これは無視できません。
- 高負荷 。 統合の複雑さは、システム内のユーザー数、データ処理ストリームの強度、データ量、計算のリソース消費によって影響を受けます。
- 作業サイクルの継続 。 システムの統合とアップグレードは、ほとんど常に、機能を停止することなく、スムーズに、徐々に、そして目に見えないように、組織とその顧客に対して実行する必要があります。
- システム間統合 。 ドッキングタスクは組織に限定されず、パートナー、顧客、サプライヤー、請負業者、さらには政府機関との統合が必要になることが多くなります。
これらは現実です。ITにはシステム統合ほど複雑なタスクはない、と言うことさえできます。 次に、別の角度から問題を分析し、統合の複雑さの原因となるパラメーターを選択し、これらのパラメーターの悪影響を最小限に抑えるためのオプションを提案しましょう。
- 概念的な違い -さまざまなシステムの開発者が最初にさまざまな決定、仮定、および概念的には合わない仮定を行ったという事実に基づいています。 概念的には両方のアプローチに矛盾しない、抽象化の別のレイヤーの導入によって解決されます。 同時に、2つの実装オプションがあります：（a）結果のシステムが集中化され、2つ以上の統合可能なシステムがサブシステムに変わるとき、および（b）ブローカーのアーキテクチャ（中心ではない仲介者）を使用するとき、システムは独立したままであり、ブローカーはそれらの間にレイヤーを提供します。
- 技術的な違いは、互換性のないデータ交換フォーマット、相互作用プロトコル、およびインターフェースがある場合です。 封筒、レイヤー、ブローカー、その他のローションを書くことで解決します。きれいではありませんが、十分に信頼できます。
- ライセンスの非互換性。 私はこの問題の専門家ではないので、これについては詳しく説明しません。また、組織レベルでの決定はそれぞれの場合に個別である可能性があります。
共通のタスクは次のようになります。上記の要因によって特徴付けられるN個の情報システムを、レイヤー、コンバーター、ブローカー、およびそれらの間のインターフェースの数を最小限に抑えて統合する必要があります。 問題を真正面から解決すると、N個のシステム間にN（N-1）/ 2個の接続、つまりN（N-1）インターフェースの双方向の相互作用があります。 ここで、Webサービスから、たとえば1日に1回開始され、データベースを同期するための多くの複雑な操作（要求、処理、エクスポート、FTP経由のアップロード、信号伝送）を実行するオフラインプロセスまで、インターフェイスとして何でも理解できることを考慮すると、送信されたデータを受信して作業の一部を実行し、結果を通知し、必要なデータを返送するように、システムの別の部分。 一般的に、そのようなオプションは完全に排除することはできません。唯一の問題は、それらの有能な実装です。
しかし、私は他の人から学んだ問題のうち、問題を解決するためのすべてのツールを提供します。私はそれを自分で使い、実際に観察しました：
- 標準化 -できるだけ多くの国際標準、州標準、業界標準を使用することが必要かつ重要であり、一部が十分ではないが明確に要求されている場合は、企業標準を導入する必要があり、多くの場合、迅速な普及と普及のために関連組織でそれらを理解し促進します。
- ブローカーレベルでの統合 。 利点 ：汎用性-ほとんどの場合、異なる方法で両方のシステムにアクセスする追加のソフトウェアモジュールを作成できます（たとえば、一方はデータベースを介して、もう一方はRPCを介して）。 欠点 ：複雑さ、複雑さ、したがって開発、実装、所有のコストが高い。
- データレベルでの統合 -つまり、複数のアプリケーションが同じデータベースまたはレプリケーションで接続された複数のデータベースにアクセスできます。 利点 ：統合の低コスト。単一のDBMSを使用する場合、これは非常に魅力的なソリューションになります。 短所 ：データベースがストアドプロシージャによって保護されておらず、必要な整合性制約（カスケード操作とトリガーの形式）がない場合、異なるアプリケーションがデータを競合状態にする可能性があります。 データベースが保護され、整合性が確保されている場合、この場合、同じデータベースで実行されている並列アプリケーションでは、同じまたは同様の操作を実行するコードの重複部分があります。 さらに、データベースの構造を変更する場合、データベースで動作するすべてのアプリケーションのコードを個別に書き換えます。
- サービスレベルでの統合は、両側のインターフェイスとデータ形式の修正に基づく美しい統合であり、企業間ビジネスロジックの迅速な開発を可能にします。 欠点があります。それにもかかわらず、固定が存在し、構造またはプロセスが変更されると、問題と狭義のプライベートなソリューションが形成されます。
- ユーザーがコピー、貼り付け、ファイル、メール、その他の不名誉を介してシステム間でデータを移動する場合、 ユーザーレベルでの統合は極端なケースであり、自動統合ではありません。 このような方法は考慮していませんが、残念ながら、ソフトウェアシステムの準備が整うまでその時点で使用されていることが多く、会社の発展により待つことはできません。
- メタ情報の動的な解釈 -これについては別の記事で説明します。
これは古典的な方法のほぼ網羅的なレビューです。何か見落とした場合は補足してください。 しかし、非古典的な統合方法については、別の出版物を準備しています。 ご清聴ありがとうございました。