Skip to main content

アーキテクチャ

OutSystems

エンタープライズアーキテクチャへの適合性

OutSystemsは、エンタープライズエコシステムに完全に適合します。組織はプラットフォームの能力を最大限に活用し、外部API、コアサービス、連携サービスという3つのレベルでのサービス配布を促進するサービス指向アーキテクチャ(SOA)を構築することができます。これにより、アーキテクチャを容易に更新し、恒久的にビジネス戦略に沿ったものにすることが可能です。

OutSystemsとエンタープライズエコシステム

エンタープライズエコシステムは、数年間発展を続けるうちにベンダーやテクノロジーが混在するレガシーシステムや企業データベースで構成されるようになりがちです。さらに、これらのコンポーネントは外部システム、サテライトアプリ、Webポータルと情報やAPIを交換します。その結果、多くの場合でアーキテクチャが複雑化し、組織のビジネス戦略をデジタルでサポートする仕組みを維持・進化させることが難しくなります。

Enterprise Ecosystem.png

主な問題は以下のとおりです。

  • サービスが適切に抽象化されていない: コアビジネスコンセプト向けのサービスが正しく分離、抽象化されていません。ビジネスルールが様々なシステムに分散され、コードの再利用がほとんど構造化されていません。

  • システムの依存関係が管理できていない:  システムが互いに正しく分離されていないため、システムを更新または交換すると他のシステムに大きな影響を与えてしまいます。共通のESB(エンタープライズサービスバス)を利用すると、異なるシステム間の通信を統一することができます。ただし、ビジネスコンセプトの表現が適切に正規化されていない場合は、システムの独立性を確保できません。

  • レガシーシステムが低速で柔軟性がない:  レガシーシステムをビジネスの変化に迅速に適応させることが困難です。システムが複雑で柔軟性がない場合、変更に時間がかかります。テクノロジーが時代遅れになることもあります。また、時間の経過とともにコア情報やシステムの依存関係が増加していくと、一切リプレースができなくなる可能性もあります。

OutSystemsはオープンプラットフォームであるため、複雑なエンタープライズアーキテクチャに最適です。OutSystemsを使用することで、アプリを構成可能にし、フロントエンドをバックエンドから切り離し、疎結合なサービスを抽象化するという企業のITトレンドに対応することができます。これは、 ビジュアルモデリングや、RESTおよびSOAPを利用するための迅速なバックエンドサービス作成をOutSystemsの内外で提供することで実現します。コモディティ機能のサポート役を進化の遅いレガシーシステムに委ねたままで、革新と差別化を図ることができるのです。

通常、エンタープライズシステムにおいてOutSystemsは下図のように位置付けられています。

OutSystems in Ecosystems.png

OutSystemsのサービスが提供するコア機能は、OutSystemsに完全に実装されているか、外部のシステムやレコードの機能を拡張して標準化したものです。後者の例としては、外部のプロデューサや企業のデータベースが挙げられます。

こうしたサービスは、OutSystemsアプリケーションやマイクロサイトでの再利用が可能です。マイクロサイトとは、他のWebサイトのインラインフレームで動作する小さなWebアプリケーションです。また、外部のコンシューマや外部ポータル、OutSystems以外で開発された他のアプリケーションでも使用が可能です。 

OutSystemsを使用したSOAの構築

先進的な企業の継続的なデジタル革命を支えるSOA(サービス指向アーキテクチャ)を構築するためには、健全なアーキテクチャ原理に従うことが重要です。こうした原理が、OutSystemsを周辺エコシステムに正しく実装し、付加価値サービスを適切に設計できるようにするからです。

ソリューションアーキテクチャを設計するためのフレームワーク 

OutSystemsのアーキテクチャ設計フレームワークにより、正しい実装と設計が可能になります。SOAの設計を簡素化するため、4つのレイヤーを使用しています。これにより、再利用可能なサービスの正確な抽象化と、別個の機能モジュールの適切な分離が促進されます。その結果、モジュールのライフサイクルの独立性が向上して依存関係を管理できるようになり、コスト効率が良く、維持と発展が容易なアーキテクチャ設計が実現します。

フレームワークのレイヤーごとに、モジュールに組み込まれる機能の性質が異なります。

4 layers canvas.png

 

このフレームワークは、アーキテクチャ設計における2つの段階で使用されます。

  1. 機能面、非機能面、連携面のニーズなどの概念の特定。このフレームワークは、アーキテクチャ要件を系統的かつ構造的に収集します。


Identifying concepts 2.png

2.特定された概念を実装するモジュールの定義は、推奨パターンに従って設計されます。

アーキテクチャの設計は、1回行ったら終わりという作業ではありません。継続的なプロセスです。ソリューションが進化してビジネスから新たな概念やニーズが生まれてくるのに伴い、この2つの段階を繰り返してアーキテクチャを反復開発する必要があるのです。

Architecture Iteration.png

OutSystems Forgeで入手可能なElectronic Canvasツールは、新しいアーキテクチャの設計を支援します。デジタルフレームワーク内での概念の配置と移動を可能にすることで、新しいプロジェクトの実装に必要なアーキテクチャ要素をすべて特定し、整理します。

優れたアーキテクチャを作成するための3つのルール

再利用可能なサービスを適切に抽象化し、エンドユーザーのプロセスを分離し、管理不能な参照を避けるアーキテクチャにするには、以下の3つのルールに従う必要があります。

  1. 上方参照をしない: 上方参照を行っているということは、サービスが正しいレイヤーで分離されていないということです。上方参照は、直接的または間接的なサイクルで巨大なモジュールのクラスタに発展しうる、複雑で管理不能な依存関係を生む主な原因となります。

  2. オーケストレーションまたはエンドユーザーではサイドリファレンスをしない: オーケストレーションおよびエンドユーザーモジュールが、再利用可能なサービスを提供しないようにします。こうすることで2つを正しく分離し、互いのライフサイクルへの干渉を避けることができます。

  3. サービス間での循環を避ける:概念上、サービスは通常別のサービスに依存するか、別のサービスを拡張したものです。循環が生じている場合、一般的には概念が正しく分離されていないことを示しています。たとえば、要素の誤配置などです。場合によっては、他の何かに依存する第3の、より一般的な概念を分離する必要があります。

複雑なシステムでこうしたルールを検証し、急速な進化を続けるシステムでこれらのチェックを実行することは時に困難です。そこで役立つのが、自動化されたメカニズムです。 

OutSystemsのアーキテクチャ設計フレームワークの大きな利点は、アーキテクチャの規則違反を容易に特定し、修正することができるという点です。OutSystems環境においてアーキテクチャのルールが厳守されているかどうかは、Discoveryツールで自動的に検証できます。このツールは、モジュール間の実際の依存関係を分析します。そしてルール違反や、組み立てに問題のあるアクション、画面、エンティティ、その他の要素を簡単に特定します。これにより複雑さに対処できるようになるため、時間を節減し、付加価値の高い作業に集中することができます。

エンタープライズアーキテクチャの中核としてのサービス

OutSystemsソリューションの設計の指針となり、ソリューションを企業のエコシステムに正しく統合するための鍵となるのが、アーキテクチャ設計フレームワークの原理です。これらの原理を適用することで、サービスやアプリケーションを明確に分離できます。OutSystemsのアプリケーションとマイクロサイトは、主にエンドユーザーモジュールとオーケストレーションモジュールで構成されています。OutSystemsと他のアプリケーションの両方をサポートするサービスは、コアモジュールとライブラリモジュールで構成されています。

OutSystemsサービスは、SOAP WebサービスまたはREST APIで公開することができます。これらはいずれも言語に依存せず、また社内で利用可能できる疎結合なサービスを促進します。OutSystemsアプリケーションは、これらのサービスを直接使用して、OutSystemsプラットフォームの可能性を最大限に引き出します。その結果、以下の点を実現します。

  • エンティティと再利用可能なUIウィジェットが使用される。

  • OutSystemsのメカニズムの潜在能力が最大限に活用される。

  • Webサービスをマーシャリング/アンマーシャリングする必要がないため、呼び出しの効率が向上する。

3つのレベルにわたるサービス配布

このサービスアーキテクチャの例は、OutSystemsが外部APIコアサービス、および連携サービスという3つのレベルでサービス配布を行う様子を示したものです。

SOA.png

OutSystemsが原理の適用を容易にするため、コアサービスは外部システムから適切に分離されており、エコシステム変化の影響を最小限にとどめることができます。外部のコンシューマが変更、追加、削除された場合、外部APIのみが影響を受け、外部プロデューサが変更、追加、削除された場合は連携サービスのみが影響を受けるというのが理想的な状態です。

外部APIレベル

外部のコンシューマにサービスを公開するAPIの構成は、このレベルでRESTやSOAPなどを用いて行われます。ビジネスロジックは追加されません。このレベルは、コアサービスレイヤーに実装されている実際のサービスの技術的なラッパーであり、サービスを外部システムと合意されたAPIに変換します。

コアサービスレベル

サービス本体は、あらゆるビジネスルールやコアエンティティとともにこのレベルに実装されます。コアサービスはシステムに依存しないものでなければなりません。

連携サービス

コアサービスがレコードの外部システムを拡張する場合、連携は連携サービスレイヤーによって抽象化されます。このレイヤーは、単にデータ構造を正規化し、エラーからの復旧や外部システムでの認証など、複雑な連携を抽象化するための技術的なラッパーです。