Apigee: SAP 向け API の管理を強化するソリューション
Google Cloud Japan Team
※この投稿は米国時間 2020 年 11 月 6 日に、Google Cloud blog に投稿されたものの抄訳です。
企業が SAP 環境を Google Cloud に移行する理由はさまざまです。最もよく挙げられる理由は、SAP のワークロードを Google Cloud に移行することで得られる、アジリティ、スケーラビリティ、セキュリティの面での利点です。稼働時間とパフォーマンスの改善に注目する企業も多くあります。
また、ほとんどの企業はなんらかのタイミングで、自社のビジネスデータの中に「宝」が眠っており、それを掘り出すための鍵を握るのがクラウドであると考えるようにもなります。しかし、クラウドを利用してデータから収益を上げようとする場合にぶつかる課題は特殊なものです。また、そうした課題に対処するには専用のツールが必要になります。クラウドで SAP 環境を運用している企業の大部分は、レガシー システムおよびデータストアも利用し続けていますが、こうした企業の方がより大きな課題を抱える傾向があります。
API の可能性と注意点
こうした状況で役に立つのが、Google Cloud の高度なデータ分析機能、機械学習機能、AI 機能、そして特に API(アプリケーション プログラミング インターフェース)管理ツールです。Apigee API Management Platform は、SAP システムおよびデータストアにイノベーションとチャンスをもたらすことができるため、Google の多くの SAP のお客様にとって期待の星となっています。
API 管理は、ビジネスデータから価値を獲得するうえで直接的に重要な役割を果たします。適切なデータセットを、そのデータを収益化する意思と能力のある人々につなぐことで、間接的なメリット(売上の増加やカスタマー エクスペリエンスの向上につながる分析データの生成など)と直接的なメリット(データへのアクセス権の他社への販売など)の両方を手に入れることができます。
こうした種類のトランザクションをきめ細かく処理できるため、API は現代のデジタル ビジネス プラクティスの柱となっています。現在、あらゆるモバイル デバイス、ウェブサイト、アプリケーションに、連携サービスやデータソースにアクセスするための API が使用されています。API は、アプリ、プラットフォーム、アプリケーション エコシステム全体をつなぐ役目を果たします。また、Representational State Transfer(REST)などの事実上の標準を使用することで、API を利用して革新的なアプリケーションを短時間で構築し、デプロイできます。
レガシー システムが最新の API と調和しない 3 つの理由
SAP 環境を運用している Google Cloud のお客様は、データを有効に活用しようとお考えかもしれません。しかし、その SAP システムおよびデータ、さらに REST などの最新のアプローチを採用していない従来の API では、それはかなり難しいでしょう。その理由は次のとおりです。
アクセス性、ユーザビリティ、セキュリティのバランスをとる作業は困難で、リスクが高い。ビジネスクリティカルなシステムへのアクセスをサードパーティや社内のデベロッパーに提供する場合、大きなリスクを伴うことがあります。セキュリティを重視している SAP のチームですら、SAP のレガシー システムに信頼できるプログラムからのアクセスを提供するプロセスには、長い時間と多大な労力がかかることが珍しくありません。また、アクセスの制限と API 機能の制限という手法は共にセキュリティ リスクの緩和という意味では有用ですが、こうした戦術を採用した場合、イノベーションの速度が遅くなり、そもそもこのプロセスを開始した理由が損なわれてしまいます。
SAP のレガシー アプリケーションとその他のデータストア全体で API を管理する作業は複雑でコストがかかり、技術的に困難である。最新の API の「手法と根拠」と、レガシー システムの設計のベースとなっているプログラムからのアクセスのタイプの間には根本的な不一致があります。例えば、最新のアプリは通常、API リクエストをかなり大量に送信します。これは、クライアント側のシングルページ アプリケーションにも、弾力的にスケールされた最新のアプリサーバーで実行されている従来のサーバー側アプリにも当てはまります。また、最近のアプリでは使用することになっているデータ ペイロードとレガシー システムが提供することになっている、データ ペイロードとでは、サイズと構造にも相違があります。
これらの例は結局、同じ問題に行き着きます。SAP のレガシー システムを利用している場合も、そうしたシステムから移行しようとしている場合も、最近のユースケースや統合事例でデータにアクセスできるようにするのは非常に困難であるということです。また、サードパーティのデベロッパーに依頼して、レガシー システムを利用できるように手法とスキルセットを調整してもらうという案は、なかなか受け入れられないでしょう。
API アクセスの収益化には、別の技術的および実際的な課題がある。多くの企業にとって、データに関する重要なポイントは収益化です。つまり、有効利用が望めるデータソースにアクセスする権限を有料にしてデベロッパーに請求するということです。これは、既存の API の前に仮想的な回転式改札口を置いておけばよいというほど単純な問題ではありません。あらゆる収益化戦略の成否は、その料金に左右されます。これは、データの利用者、データアクセスのタイミング、データの用途を正確に理解しなければならないことを意味します。デベロッパーに API コールの料金を請求しなくても、貴社の API トラフィックに関連するすべてのデータフローとデータ インタラクションの全体像を把握できるなど、貴重な知見がより高度な分析により得られるようになります。概して、API を収益化するには、単に旧式の手法に従ってシステムを公開するだけではなく、デベロッパーの利用を考慮して API を最新のスタイルで構築し、設計、管理する必要があります。
レガシーであるかどうかにかかわらず、SAP 環境が SAP システムのデータに焦点を当てるものであり、SAP システム内のデータを他のアプリケーションに公開するものではないというのいうは、おそらく周知の事実でしょう。また、こうしたツールが自動的に構築されることはないため、問題は誰が構築するのかという点になります。
Apigee: API 管理でギャップを埋める
Apigee のような API 管理ソリューションを利用する IT 組織は、より効率的にこうした問題に対処できます。具体的には、以下の 3 つの主な SAP アプリケーション モダナイゼーション パターンに対処するために Apigee を活用しています。これらのパターンはすべて、API を使用して価値を創出する際に生じる課題を示しています。
1. レガシー サービスのモダナイゼーション。Apigee の重要な機能の一つに、SAP のレガシー インターフェースに API の「ラッパー」を配置するというものがあります。これによりデベロッパーは、機能豊富で即応性に優れた最新の API で作業できるようになります。また、Apigee プラットフォームは、API 呼び出しを受け取り、変換して最適化するプロセスを処理してから、基盤となる SAP 環境にリクエストを渡します。
API 管理に対するこのアプローチにより、IT 組織はいくつかの便利な機能も手に入れることができます。Apigee は SAP のレガシー インターフェースに機能を追加するための API の設計、実装、テストのプロセスを簡略化し、デベロッパーが API を使用して作業する場所、方法、タイミングの管理を支援します。これは Apigee の API モニタリングおよび指標のベースにもなります。これらの作業を IT チームが独力で構築するには多大な労力が必要になるため、この機能は重要です。
2. ソースシステムからの API の抽出。Apigee プラットフォームは、SAP のレガシー システムとデベロッパーの間に抽出レイヤーを提供することで、一貫性があり信頼性が高く、予測可能なデベロッパー エクスペリエンスも確保します。このように基盤ソースシステムから API を分離することで、Apigee はシステムの処理と可用性の変化に適応できます。その一方、デベロッパーが API を使用することで、通常どおりにビジネスを継続できます。このようにして、SAP 導入企業は API ソリューションをパッケージ化して販売でき(デベロッパー ポータルを介して API を公開するなど)、ターゲット システムごとに API の利用をモニタリングできます。
デベロッパーのエントリ ポイントからソースシステムを分離することで、連携したアプリケーションに、ECC から S/4HANA への移行といった大規模なバックエンドの変更の影響が及ばないようにすることもできます。バックエンドの変更をサービスに適用しても、アプリは中断されることなく同じ API の呼び出しを続けます。移行によって、複数の SAP および SAP 以外の実装の S/4HANA への統合、または一部の機能をクラウドネイティブのシステムに移動することによる中核的な SAP システムのクリーンアップなどに結び付くこともあります。Apigee は消費側のアプリケーションを基盤システムに対する変更から抽出し、これらの多様なシステム間に統一性を持たせるため、ECC から S/4HANA への移行などの統合プロジェクトにおけるリスクを軽減できます。
3. クラウドネイティブでスケーラブルなサービスの作成。Apigee は、SAP アプリケーションと、マイクロサービスが重要な役割を果たす最新の分散型アプリケーション アーキテクチャ間のギャップを埋めることができる点でも秀でています。ほとんどの場合、このギャップは大きなものです。また、SAP データをマイクロサービスとして再パッケージ化し、このデータを収益化する機能を提供できるだけでなく、パフォーマンス、可用性、セキュリティに関する重要な機能もいくつか備えています。アクセス制御、認証、セキュリティ モニタリング、脅威評価に対処できるだけでなく、必要に応じてトラフィックをスロットリングしてバックエンド システムを通常どおり使用し続ける一方で、あらゆるワークロードに合わせてスケールできるエンドポイントをアプリケーションに提供します。
言うまでもなく、Apigee のセキュリティ機能は API 管理ツールの用途にかかわらず非常に重要です。Apigee はパフォーマンス、分析、信頼性に関する機能も提供するため、最初から完全に成熟した API 収益化戦略を展開できますが、イノベーションのために SAP システムを公開することでミッション クリティカルなシステムを危険にさらすこともなく、IT チームも安心です。
Conrad Electronic と Apigee: API を使用してイノベーションを促進
非常に多くの企業が Apigee を使用して、これまでは可能と思えなかった手法で SAP のレガシー環境を有効に利用しています。Apigee と Google Cloud のその他のコンポーネントを連携させ、SAP ユーザーにイノベーションの新たな道筋を示した事例として、Conrad Electronic が挙げられます。
Conrad Electronic は長年の歴史を持つドイツの小売企業であり、イノベーションに向けて一歩ずつ着実に進むアプローチをとっています。同社は、既存の SAP のレガシー環境と Google BigQuery を併用することで、デジタル面での変革を実現しました。これにより、以前は分散した数十ものシステムに保存されていたデータをリポジトリに一元化できました。Conrad Electronic は、その変革の影響力と有効性を、Apigee を使用して 2 つのレベルで増大させました。
まず、Apigee を使用して配送会社および B2B 顧客の調達システムとのデータ交換を管理し、これらの会社に提供する小売エクスペリエンスを改善する一方で、従来のトランザクション環境につきものの障害とエラーの可能性を削減しています。
また同時に、Apigee を使用して自社のデベロッパーにイノベーションと試験運用のための最新のツールセットを提供しています。小規模な開発チームはこれを活かし、店内のスタッフと来店した客が、自分のタブレットなどのデバイスを使用して主要な製品、サービス、保証に関する情報にアクセスできるようにする、使いやすいツールを構築しました。
Conrad Electronics でデジタル・ディスラプション担当最高責任者を務める Aleš Drábek 氏は、次のように述べています。「API を利用すれば、何にも依存することなく自由に、短期間で効率的にアイデアを現実のものとすることができます。効率的な API 管理ソリューションである Apigee のおかげで、API の能力を活かして、お客様との関わり方、そして B2B のお客様へのデータの転送方法を変革できました。」
API 管理が秘める可能性
イノベーションを起こすための新しいビジネスモデルや手法で SAP システムを使えるようにする際に生じる課題を Apigee でいかに解決できるかについて詳しくは、こちらをご覧ください。また、SAP のお客様向けの Google Cloud ソリューションについて詳しくは、こちらをご覧ください。
-Google Cloud SAP 戦略およびアーキテクチャ担当パートナー技術リーダー Benjamin Schuler