再利用を検討するとき、多くの人は対象となる API の数やインテグレーションサービスの利用者の人数だけを考慮しがちです。しかし、インテグレーションアセットの再利用性を高めるためには、他にも考慮すべきことが数多くあります。
再利用性とは？
再利用性とは、インテグレーションのために作成されたオブジェクトやプロセスが、当初の用途で使用された後、それを開発者本人だけでなく他部門や組織により複数回利用されることです。現在、あらゆる開発チームが再利用性の獲得のために取り組んでいます。
MuleSoftがAPI管理とiPaaSの
業界リーダーであり続ける理由とは？
再利用が可能になると開発にかかる時間や労力を削減でき、効率が上がるため、コストも抑えられます。再利用すればするほどインテグレーションアセットの ROI が高まります。
以下は、インテグレーションの再利用の一般的な例となります。
- Java ライブラリ
- 関数やクラスのコード
- 仮想マシンをホストするサーバー
IT 部門で再利用を推進しているのは誰か？
ユーザーがいなければ、再利用もできません。API とインテグレーションの分野では、さまざまな使用者や関係者が組織で再利用できるコンポーネントを推進したり構築したりします。以下の関係者グループは、何を再利用するのか、そしてどの程度再利用するのかを協力して定義する必要があります。
- (APIを作成する) 開発者：API やインテグレーションのためのテクノロジーアセットを自部門や他部門が利用するために作成する開発者。IT 統括部門や事業部門所属の IT 担当チームが一般的です。
- (作成されたAPIを利用する) 開発者：API やインテグレーションのテクノロジーアセットを使用して、アプリケーションやサービスを構築する開発者。事業部門所属の IT チームや外部組織の開発チームが一般的です。
- API およびインテグレーションアーキテクト：API やインテグレーションの全体的なアーキテクチャやソリューションの方向性を決定するソートリーダー
- エンタープライズアーキテクト：ビジネス機能、データモデル、アーキテクチャ全体の原則や標準などの詳細を把握・確認できる立場にあるエンタープライズレベルのアーキテクト
インテグレーションの再利用のためのコンポーネント
再利用の促進のために、複数の要素やインテグレーションのビルディングブロックが存在しています。以下、再利用性を促進するために MuleSoft のプラットフォームが提供するさまざまな要素を紹介します。主に『Anypoint Platform』を中心に話を進めますが、そのコンセプトはインテグレーションに関連するあらゆる事柄に汎用可能です。
API
API は特定のアプリケーションやシステムから有益なビジネス機能を呼び出し、それを必要としているアプリケーションやシステム、従業員、顧客などに提供するサービスです。
- 再利用の対象：複数のサービスやアプリケーションで呼び出し可能なサービスやコード
- 対象者：開発者 (API の利用者) のコミュニティ
API 利用者は作成者本人だけでなく、組織内外のユーザーの場合もあります - 用途：API はアプリケーションとのやり取り (情報の送受信) に使用されます。やり取りの一般的な目的は、CRUD 操作の実行やアプリケーション内での操作のトリガーです。
- MuleSoft 製品/機能：Anypoint Designer、Runtime Manager、Anypoint Studio、API Manager など
- 例：Rest API: “請求 API GET”、”発注 POST” など
- 考慮事項：
- 組織のビジネスモデルに合った API を構築し、有意義なユーザビリティを実現するようにします。
- API を API Manager からデプロイしてユーザビリティを追跡・管理します。
- 明確かつ分かりやすく記述されたドキュメントを作成し周知を徹底。ユーザビリティを向上します。
コネクター
コネクターは (事前に) パッケージ化されたコードです。コネクターが存在するアプリケーションの接続性や運用の詳細を簡素化 / 抽象化することで、外部から確認できないようにします。MuleSoft には、商用アプリケーション用のプレビルドのコネクターが数多く用意されています。
- 再利用の対象：複数のプロジェクトで使用される呼び出し可能なコードやライブラリ
- 対象者：API やインテグレーションサービスを開発する作成側開発者のコミュニティ
- 用途：Exchange に利用可能な既存コネクターがある商用アプリケーションを使用する場合
既存のコネクターがない場合、開発者は商用アプリケーションの詳しい内容の理解が必要 - MuleSoft 製品/機能：Anypoint Exchange で提供されるプレビルドのコネクター各種
- 例：Salesforce コネクター、SAP コネクター、JIRA コネクターなど
- 考慮事項：
- Exchange で提供されているコネクターを活用します。
- コネクターに付属するアクセラレーターを利用するか、開発サイクルをすぐに開始できます。
コードテンプレート
コードテンプレートとは、使用中のアプリケーションにそのままインポートして、当該機能の再利用やカスタマイズが可能なプレビルドのアプリケーションやその一部です。テンプレートを使用することで、開発者はすぐに開発に着手でき、アプリケーション開発を高速化できます。
- 再利用の対象：複数のプロジェクトで使用できる、呼び出し不可能なコード
- 対象者：API やインテグレーションサービスを開発する開発者コミュニティや API およびインテグレーションアーキテクト
- 用途：複数のプロジェクトで一貫的な使われ方をする複雑なコード
- MuleSoft 製品/機能：Anypoint Studio、Anypoint Designer、Anypoint Exchange
- 例：エラー処理コード、検索コード、メッセージパーサー
- 考慮事項：
- コードテンプレートを Exchange 内に正式なアセットとして公開し、他の開発者が見つけ出せるようにします。
- コードテンプレートを (検証することなく) コピー＆ペーストだけで使用することを避けます。
- 複数のプロジェクトで利用可能な共通機能を決定します。
- 適切なオーナーシップとガバナンスを割り当ててテンプレートを継続的に管理します。
API フラグメント
API フラグメントは、RAML 仕様の再利用可能なコンポーネントであり、API を設計するためのコンポーネントを抽象化して構築します。これらのフラグメントは設計段階で構築かつ使用できます。
- 再利用の対象：複数のプロジェクトで使用される呼び出し不可能なコード
- 対象者：API やインテグレーションサービスを開発する開発者コミュニティ、API およびインテグレーションアーキテクト、エンタープライズアーキテクト
- 用途：再利用可能な複雑なデータオブジェクトや動作、ドキュメント
- MuleSoft 製品/機能：Anypoint Designer、Anypoint Exchange
- 例：データオブジェクト、ドキュメント、ライブラリ
- 考慮事項：
- データオブジェクトを API フラグメントとして抽象化するときは、ビジネス重視データモデルとの整合性を確保します。エンタープライズアーキテクチャを参照し、エンタープライズデータモデルの存在を把握するプロセスを踏襲することは必須です。
- フラグメントを Exchange の正式なアセットとして公開し、検出できるようにします。
- フラグメントを使用するプロジェクトは、フラグメントをコピー＆ペーストではなくインポートする必要があります。
- フラグメントの文書化と周知を徹底します。
メッセージ
メッセージは、データオブジェクト (属性と値の集合) の公式な形式です。複数のアプリケーション間で共有されます。Anypoint MQ など、JMS 準拠のメッセージングインフラストラクチャのコンテキスト内で使用されます。
- 再利用の対象：複数のプロジェクトやアプリケーションで使用される呼び出し不可能なコード
- 対象者：API やインテグレーションサービスの開発者コミュニティ、アプリケーションなどの開発者コミュニティ、API およびインテグレーションアーキテクト、エンタープライズアーキテクト
- 用途： メッセージシステム内で使用される複雑なデータオブジェクト
- MuleSoft 製品/機能：Anypoint MQ、Anypoint Exchange
- 例： データオブジェクト (請求データ、顧客データ、要求データなど)
- 考慮事項：
- 適切なスキーマやストラクチャが構築されるようにします。スキーマやストラクチャ、エンタープライズアーキテクチャによって維持されるエンタープライズデータガバナンスおよびモデルに整合性があることを確認することは必須です (可能な場合)。
- メッセージ管理者およびオーナーシップの定義を特定します。
- 耐久性やデリバリー保証を検討します。堅牢な最新のメッセージングシステムには、これらの機能が備わっています。
- 使用するメッセージングシステムに応じてメッセージのサイズ調整を検討します。たとえば、 Anypoint MQ は最大 10MB のメッセージに対応しています。
キュー、エクスチェンジ、トピック
これらは、アプリケーション間のメッセージ送信をサポートするメッセージングインフラストラクチャ内のパイプ役です。
- 再利用の対象：複数のプロジェクトやアプリケーションで使用されるインフラストラクチャ
- 対象者：API やインテグレーションサービスの開発者コミュニティ、アプリケーションなどの開発者コミュニティ
- 用途：メッセージシステム内で使用される複雑なデータオブジェクト
- MuleSoft 製品/機能：Anypoint MQ、Anypoint Exchange
- 例：出荷状況の更新情報やトピック、請求キュー、発注キューなど
- 考慮事項：
- トピックと更新情報は本質的に複数のアプリケーションで再利用可能です。
- インフラストラクチャを設計する際は、十分な再試行、耐久性、デリバリー保証を備えるようにします。
- 適切なレイテンシーを実現するため、インフラストラクチャを適切なリージョンにデプロイすること (クラウドの場合) を検討します。
Mule ランタイム
Mule ランタイムは、ひとつまたは複数のアプリケーションを実行用にホストする JVM と同等の MuleSoft の実行エンジンです。Mule ランタイムは、メモリ、スレッド作成、スケジューラなど必要なリソースを提供します。
- 再利用の対象：複数のプロジェクトで使用されるインフラストラクチャ
- 対象者：プラットフォーム管理者
- 用途：関連する Mule アプリケーションをまとめてデプロイ
- MuleSoft 製品/機能： Anypoint Runtime Manager、Anypoint Monitoring
- 考慮事項：
- 同一の Mule ランタイムにデプロイするアプリケーションの数を制限します。Mule ランタイムで起こる再起動や管理アクティビティは、すべての常駐アプリケーションに影響します。
- 関連するアプリケーションは、同じ Mule ランタイムにまとめてデプロイします。
- CloudHub 2.0 は、1 件の Mule ランタイムにつき最大 10 個のアプリケーションをデプロイ可能。オンプレミスのランタイムにはさらに多くのアプリケーションをデプロイできますが、アプリケーションを増やすときには注意が必要です。
- ランタイムが使用するライセンスの他、コアやメモリーのサイズを調整して、ランタイムの再利用可能性の要因を判断します。
API ポリシー
API ポリシーは、API の規制、管理、セキュリティ、サービス品質を実現させます。セキュリティ、トラフィック管理、SLA (サービス品質保証) などがあります。Anypoint Platform では、API ポリシーは API Manager 内で使用されます。
ひとつのポリシーを、複数の API に展開・使用することが可能です。
- 再利用の対象： 複数の API デプロイメントで使用可能なコンフィギュレーション
- 対象者：プラットフォーム管理者
- 用途：複数の API で同一ポリシーを制御する場合 (トラフィック制御、セキュリティなど)。
- MuleSoft 製品/機能：Anypoint API Manager
- 例：レート制限ポリシー、IP ホワイトリスト、トークン実行ポリシーなど。
- 考慮事項：
- できる限り既製のポリシーを (再) 利用します。
- 既存のポリシーがビジネス要件を満たしていない場合、カスタムポリシーの作成を検討します。
- ポリシーの定義、継続管理する場合のガバナンスとオーナーシップを策定します。
- プロキシやゲートウェイをデプロイするために利用可能な Mule ライセンスやリソースに応じて、ポリシー実行用の API プロキシのデプロイメントを慎重に検討します。
共通サービス
共通サービスは、プラットフォームがそのままの形で提供するものではありません。顧客が共通で使用するアプリケーションを自ら開発し、複数のアプリケーションや API で使用することが可能です。
そのようなアプリケーションコンポーネントには、ロギングフレームワークや例外処理フレームワーク、監査フレームワーク、キャッシングフレームワーク、単位換算などがあります。
- 再利用の対象：複数の APIおよびインテグレーションアプリケーション開発プロジェクトで使用される、再利用可能なアプリケーションコンポーネント
- 対象者：開発者コミュニティ
- 用途：複数のアプリケーションで、共通のトレイトやサービスを共有する場合
- MuleSoft 製品：Anypoint Studio、Anypoint Designer、Anypoint Runtime Manager
- 例：ロギングフレームワークや例外処理フレームワーク、監査フレームワーク、キャッシングフレームワークなど
- 考慮事項：
- アーキテクトとリード開発者を早い段階で巻き込み、共通サービスの要件を理解します。
- 共通サービスをライブラリとしてデプロイします。再利用可能な API としてデプロイするとさらに良いでしょう。この場合、共通サービスは単なる API として扱うことができます。
- 共通サービスを Exchange から公開し、共通サービスを利用できることを開発者コミュニティに周知します。
- 設計やコードのレビュー段階で共通サービスが使われるようにします。
セキュリティグループ
セキュリティグループは役割が類似しているユーザーをグループ化し、これらの役割に必要な権限を付与するために使用します。一度定義すると、プロジェクト内や複数のプロジェクトで使用できるようになります。
- 再利用の種類：プロジェクトで使用される再利用可能な設定項目
- 対象者：プラットフォーム管理者
- 用途：複数のプロジェクトやアプリケーションで類似する役割や権限を共有
- MuleSoft 製品：Anypoint Access Management
- 例： 営業担当者グループ、監査人など
再利用の投資利益率（ROI）
ソリューションの再利用が可能になれば、IT 部門は、より早く、より安く開発及びデプロイが可能になります。しかし、複数ユーザーが利用できるだけの十分な普遍性と抽象性が本質的に備わるようにコンポーネントを開発するためには先行投資が必要です。また、再利用可能なコンポーネントを構築するメリットは、ユーザー基盤や適切なユースケースが存在する場合でのみ獲得することができます。
チームは再利用可能なコンポーネントの ROI や効果を測定する規律を確立する必要があります。そのような KPI を測定することで、経営陣への報告が可能になり、チームの成果も証明できます。
主要な指標と KPI
再利用の効果を把握するのに役立つ重要な KPI や指標をいくつかご紹介します。
- 再利用可能なオブジェクトの総数
- 再利用率
- 使用者の増加率
- 再利用性によって削減されたコストの概算
- 再利用性によって節約された時間の概算
ROI の計算
次の方法を使用して ROI を算出できます。
- 利益を計算するための計算式を定義。通常、計算式には以下の要素が含まれます。
- 再利用可能なコンポーネントの数 (N)
- コンポーネントの構築コスト (CDev)
- 全ユーザーによる予想再利用率 (R)
- 再利用 1 回あたりの回避コスト (Cavoid)
- 指標を収集し節約できた金額を算出
- 投資環境の変化を推定
- 主要な指標にフォーカスし報告
Anypoint Platform を使って再利用を実現する
再利用性を高めるためには、コンポーネントを特定させ抽象化し、より広範に使用できる状態にすることが特に重要です。Anypoint Platform には、再利用の要件に応じて組織をサポートするようようなツールが多数用意されています。これらのツールは連携して機能し、API やインテグレーションソリューションのライフサイクル全体を通じた管理を実現します。
是非、 Anypoint Platform の無料トライアルにお申し込みください。API やインテグレーションの再利用を始めましょう。
