IBM Z

APIで基幹業務をデジタルサービス化する

記事をシェアする:

IBMグローバル経営層スタディによると、企業のITは顧客接点と基幹業務の異なる2つの観点の強化が必要となっている。前者は新しい顧客体験を提供するサービスを迅速に構築、継続して改善し、後者は堅牢かつ確実に遂行しつつビジネスの変化に対応することが求められる。基幹業務にはこれまで培われたアプリケーションやデータの大量の既存資産が蓄積されており、軽量なRESTプロトコルのインターフェースであるAPIを提供することで迅速、かつ少ないコストで新しい顧客体験のサービスから基幹業務の利用が可能である。加えて堅牢で信頼性の高い基幹系システム上でサービスが実行されることにより、処理量や性能を含め高いサービス・レベルで実現できる。2018年8月22日に弊社より発表した業界別「デジタル時代の次世代アーキテクチャー」においても、顧客接点と基幹業務を融合した今後の企業全体アーキテクチャーが紹介されており、APIによるデジタル・サービス基盤の提供が重要とされている。

デジタル時代の次世代アーキテクチャー

 

IDCホワイトペーバーでは「コネクテッド・メインフレーム」が提唱され、長年にわたり基幹業務を支え続けてきたメインフレーム資産のモダナイゼーションと社内外の資産とのインテグレーションの取り組みにより、ビジネス革新が生まれ収益の伸びと運用効率の改善が報告されている。IDCの調査によると「コネクテッド・メインフレーム」の採用企業は、ビジネス/ ITスタッフの生産性を向上したり運用コストを削減すると同時に、年間平均で約2億ドルの追加収益を実現している。「コネクテッド・メインフレーム」を実現するための代表的な技術としてAPIは位置づけられる。
具体的にメインフレームにおける基幹業務のAPI化を実現するには、(1)API基盤アーキテクチャー、(2)API標準インターフェース定義、(3)APIライフサイクル管理の3つの観点を検討する必要がある。

(1)API基盤アーキテクチャー
基幹業務が稼働するメインフレームにAPIでアクセスするためには顧客接点とのAPI接続機能の配置を検討する必要がある。①顧客接点側のクライアント層、②顧客接点とメインフレームの中間層、③メインフレーム層の3つの選択肢があるが、APIによるエコシステム形成を考慮すると各クライアント層に個別配置することは現実的ではなく、②または③を選択することになる。②はIBM Integration Bus (IIB)を代表例とする従来の汎用ハブ製品を中間層に配置し、API接続のための管理機能と変換機能を実現する。ハブとして多様なプロトコル連携をサポートする等の柔軟性・接続性あるいはESB(Enterprise Service Bus)基盤として充実した機能、加えて豊富な導入実績が利点である。一方、③はメインフレーム上でAPI連携機能を提供するz/OS Connect Enterprise Edition (z/OS Connect EE) を利用し、メインフレーム独自のインターフェースをREST/JSON APIに変換する。変換ツールの提供により短期間・低コストで導入が可能であり、継続してメインフレームの信頼性や可用性を享受できる。②の中間層への配置と比較してインターフェース変更時の保守作業や資産管理の責任範囲がメインフレーム側に明確にできることが利点である。

API基盤アーキテクチャー〜API接続機能の配置〜

(2)API標準インターフェース
デジタル・サービスで使用される文字コードはUTF-8が主流であり、メインフレームで使用されるEBCDICとの文字コード変換が必要である。特に外字やシフト・コードを利用している場合には独自の追加文字コード変換が必要となるため、保守性の面でもできるだけ標準化対応したい。またREST/JSONインターフェースはペイロードの軽量化やユーザビリティーの高いAPIを目指して、必要最小限の項目を公開するように設計する。メインフレーム側で正常応答とエラー応答で異なるマルチ・レイアウトのインターフェースが定義されている場合には、共通フォーマット定義を含めて対応要否の確認が必要となる。

(3)APIライフサイクル管理
公開するAPIの登録、利用、削除のライフサイクル管理の仕組み、体制、運用プロセスの定義が必要となる。APIの登録や検索機能に始まり、公開範囲に基づく認証・アクセス制御、API改廃時の連絡方法、課金や監査のためのロギング等の必要な管理機能を実装する。API管理機能はメインフレームへのAPI接続以外に多様なAPIを対象とした管理基盤として、別途API Connect製品が配置されている場合が多く、メインフレーム層のAPI連携機能と機能分担することも可能である。さらにAPI Connect製品は、API ゲートウェイとして複数APIを利用した処理の同期点管理(APIサービスのトランザクション管理)や負荷分散機能を提供できる。
メインフレームにおける基幹業務のAPI化にはいくつかの考慮点があるが、APIにより資産価値の高い基幹業務をデジタル・サービスとして提供する試みは、デジタル・エコシステム形成のための第一歩であり、メインフレームにおけるイノベーションが実際に実現可能であるという認識が高まっていくと思われる。

当ブログは、2018-09-21公開版の再掲載です。


More IBM Z stories

IBM Z 移行の勘所 – お役立ちブログ情報編

IBM Z をご愛顧いただいているお客様、また IBM Z の導入、展開、移行に際しお世話になっておりますビジネスパートナー向けに、このたび、IBM Systems Japan Blog に IBM Z 移行に関するお役 […]

さらに読む

2024年に60周年を迎えるもの

毎年、様々な周年が話題になります。調べてみると、2024年に周年を迎えるものは、列挙はしませんが多種多様です。その中で、日本にとって象徴的と言えるのは、たぶん、開業60周年を迎える東海道新幹線ではないかと思います。 東名 […]

さらに読む