エンタープライズアーキテクチャへの適合性
目次
OutSysOutSystemsは、エンタープライズエコシステムに完全に適合します。組織は、外部API、コアサービス、連携サービスという 3つのレベルでのサービス配布を促進するSOA（サービス指向アーキテクチャ）を構築することができます。サービスは、OutSystemsのアプリケーションと密結合させてプラットフォームの機能を最大限に利用することも、マイクロサービス戦略のもとに完全に分離させてCD/CIを促進することも可能です。これにより、アーキテクチャを容易に更新し、恒久的にビジネス戦略に沿ったものにすることが可能です。
OutSystemsとエンタープライズエコシステム
エンタープライズエコシステムは、数年間発展を続けるうちにベンダーやテクノロジーが混在するレガシーシステムや企業データベースで構成されるようになりがちです。さらに、これらのコンポーネントは外部システム、サテライトアプリ、Webポータルと情報やAPIを交換します。その結果、多くの場合でアーキテクチャが複雑化し、組織のビジネス戦略をデジタルでサポートする仕組みを維持・進化させることが難しくなります。
主な問題は以下のとおりです。
- サービスが適切に抽象化されていない: コアビジネスコンセプト向けのサービスが正しく分離、抽象化されていません。ビジネスルールが様々なシステムに分散され、コードの再利用がほとんど構造化されていません。
- システムの依存関係が管理できていない: システムが互いに正しく分離されていないため、システムを更新または交換すると他のシステムに大きな影響を与えてしまいます。共通のESB（エンタープライズサービスバス）を利用すると、異なるシステム間の通信を統一することができます。ただし、ビジネスコンセプトの表現が適切に標準化されていない場合や、大量のビジネスロジックがESB内に配置されている場合、システムの独立性を保証することはできません。
- レガシーシステムが低速で柔軟性がない: レガシーシステムをビジネスの変化に迅速に適応させることが困難です。システムが複雑で柔軟性がない場合、変更に時間がかかります。テクノロジーが時代遅れになることもあります。また、時間の経過とともにコア情報やシステムの依存関係が増加していくと、一切リプレースができなくなる可能性もあります。
OutSystemsはその性質上、複雑なエンタープライズアーキテクチャに最適です。OutSystemsを使用することで、アプリを構成可能にし、フロントエンドをバックエンドから切り離し、再利用可能なサービスやライブラリを抽象化するという企業のITトレンドに対応することができます。ライブラリは、アプリケーション間の標準化および高い再利用性を促進します。サービスは、マイクロサービスアーキテクチャで疎結合できます。たとえば、利用する側のアプリケーションがすべて同一のCD/CIパイプライン内にあるようなシナリオで、モノリスのほうが好ましい場合は、密結合させることもできます。これにより、データベーストランザクションが一本化され、分散ソリューションを管理する手間を省くことができます。
では、どのようにサービスをサポートするのでしょう。OutSytemsでは、視覚的なモデリングによって、非OutSystemsコンシューマ（RESTまたはSOAP APIの公開）向けと、他のOutSystemsコンシューマ（密結合アクションや疎結合マイクロサービスの公開）向けのバックエンドサービスを迅速に作成できます。コモディティ機能のサポート役を進化の遅いレガシーシステムに委ねたままで、革新と差別化を図ることができるのです。
ライブラリは、外部のシステムやUIパターンのほか、共通のレイアウトやアプリケーションテーマとのコネクタとして使用できます。また、Google Mapsコンポーネントのようなより大きなUI要素とも連携が可能です。
通常、エンタープライズシステムにおいてOutSystemsは下図のように位置付けられています。
OutSystemsのサービスが提供するコア機能は、OutSystemsに完全に実装されているか、外部のシステムやレコードの機能を拡張して標準化したものです。後者の例としては、外部のプロデューサや企業のデータベースが挙げられます。
こうしたサービスは、OutSystemsアプリケーションやマイクロサイトでの再利用が可能です。マイクロサイトとは、他のWebサイトのインラインフレームで動作する小さなWebアプリケーションです。また、外部のコンシューマや外部ポータル、OutSystems以外で開発された他のアプリケーションでも使用が可能です。
OutSystemsを使用したサービスの構築
先進的な企業の継続的なデジタル革命を支えるSOA（サービス指向アーキテクチャ）を構築するためには、健全なアーキテクチャ原理に従うことが重要です。こうした原理が、OutSystemsを周辺エコシステムに正しく実装し、付加価値サービスを適切に設計できるようにするからです。
ソリューションアーキテクチャを設計するためのフレームワーク
OutSystemsのアーキテクチャ設計フレームワークにより、正しい実装と設計が可能になります。SOAの設計を簡素化するため、4つのレイヤーを使用しています。これにより、再利用可能なサービスの正確な抽象化と、別個の機能モジュールの適切な分離が促進されます。その結果、モジュールのライフサイクルの独立性が向上して依存関係を管理できるようになり、コスト効率が良く、維持と発展が容易なアーキテクチャ設計が実現します。
フレームワークの各レイヤーは、モジュール内の機能の様々な側面に対応します。
このフレームワークは、アーキテクチャ設計における2つの段階で使用されます。
-
機能面、非機能面、連携面のニーズなどの概念の特定。このフレームワークは、アーキテクチャ要件を系統的かつ構造的に収集します。
-
推奨パターンに従って特定の概念を実装するモジュールの定義 。
アーキテクチャの設計は、1回行ったら終わりという作業ではありません。継続的なプロセスです。ソリューションが進化してビジネスから新たな概念やニーズが生まれてくるのに伴い、この2つの段階を繰り返してアーキテクチャを反復開発する必要があるのです。
OutSystems Forgeで入手可能なElectronic Canvasツールlは、デジタルフレームワーク内での概念の配置と移動を可能にすることで、新しいプロジェクトの実装に必要なアーキテクチャ要素をすべて特定し、整理します。
優れたアーキテクチャを作成するための3つのルール
再利用可能なサービスを適切に抽象化し、エンドユーザーのプロセスを分離し、管理できない参照を避けるアーキテクチャにするために、組織は以下のルールに従う必要があります。
- 上方参照をしない: 上方参照を行っているということは、サービスが正しいレイヤーで分離されていないということです。上方参照は、直接的または間接的なサイクルで巨大なモジュールのクラスタに発展しうる、複雑で管理不能な依存関係を生む主な原因となります。
- オーケストレーションまたはエンドユーザーではサイドリファレンスをしない: オーケストレーションおよびエンドユーザーモジュールが、再利用可能なサービスを提供しないようにします。こうすることで2つを正しく分離し、互いのライフサイクルへの干渉を避けることができます。
- サービス間での循環を避ける: 概念上、サービスは通常別のサービスに依存するか、別のサービスを拡張したものです。循環が生じている場合、一般的には概念が正しく分離されていないことを示しています。たとえば、要素の誤配置などです。場合によっては、他の何かに依存する第3の、より一般的な概念を分離する必要があります。
複雑なシステムでこうしたルールを検証し、急速な進化を続けるシステムでこれらのチェックを実行することは時に困難です。そこで役立つのが、自動化されたメカニズムです。
OutSystemsのアーキテクチャ設計フレームワークにより、ルール違反に対処することができます。Discoveryツールは、ルールに対する準拠状況を自動的に検証します。モジュール間の依存関係を分析し、修正が必要なアクションや画面、エンティティ、その他の要素を特定します。このように煩雑な作業を抑制することで、付加価値のあるタスクに時間を充てられるようになります。
エンタープライズアーキテクチャの中核としてのサービス
OutSystemsソリューションの設計の指針となり、ソリューションを企業のエコシステムに正しく統合するための鍵となるのが、アーキテクチャ設計フレームワークの原理です。これらの原理を適用することで、サービスやアプリケーションを明確に分離できます。OutSystemsのアプリケーションとマイクロサイトは、主にエンドユーザーモジュールとオーケストレーションモジュールで構成されています。OutSystemsと他のアプリケーションをサポートするサービスは、コアモジュールと基本モジュールで構成されています。
OutSystemsサービスは、SOAP WebサービスまたはREST APIによって公開することができます。これらはいずれも言語に依存せず、他のテクノロジーによって容易に利用できます。組織内で利用するサービスについては、疎結合と密結合の両方をサポートしています。疎結合サービスのサポートにより、CD/CIパイプラインを独立させてマイクロサービス戦略を実装することができます。 また、密結合サービスのサポートにより、アプリケーションとサービスを完全に独立させる必要がなくなるため、OutSystemsプラットフォーム最大限活用することができます。
どちらのシナリオにおいても、影響分析の実行、IDE内のサービス検索、セキュリティ管理といったOutSystemsの機能を提供します。
3つのレベルにわたるサービス配布
このサービスアーキテクチャの例は、OutSystemsが外部API、コアサービス、および連携サービスという3つのレベルでサービス配布を行う様子を示したものです。
OutSystemsではこうした原理を容易に適用できるため、コアサービスは外部システムから適切に分離されており、エコシステム変化の影響を最小限にとどめることができます。外部のコンシューマが変更、追加、削除された場合、外部APIのみが影響を受け、外部プロデューサが変更、追加、削除された場合は連携サービスのみが影響を受けるというのが理想的な状態です。
外部APIレベル
外部のコンシューマにサービスを公開するAPIの構成は、このレベルでRESTやSOAPなどを用いて行われます。ビジネスロジックは追加されません。このレベルは、コアサービスレイヤーに実装されている実際のサービスの技術的なラッパーであり、サービスを外部システムと合意されたAPIに変換し、連携のロギングを適宜追加します。
コアサービスレベル
サービス本体は、あらゆるビジネスルールやコアエンティティとともにこのレベルに実装されます。コアサービスはシステムに依存しないものでなければなりません。
連携サービス
コアサービスがレコードの外部システムを拡張する場合、連携は連携サービスレイヤーによって抽象化されます。このレイヤーは、単にデータ構造を正規化し、エラーからの復旧や外部システムでの認証など、複雑な連携を抽象化するための技術的なラッパーです。