ケーススタディ

どのようにしてアメリカの金融検証プラットフォームがIron Suiteにドキュメントスタックを統合したか

AVIATION
更新日:

主要な中東の商業旅客航空会社（国際線展開の準備中の国旗航空会社）が、IronPDFとIron Suite全体を組み込んで、OpenShiftベースのマイクロサービスプラットフォームで高ボリュームのドキュメント生成を確保しています。予約、発券、チェックイン、運用全体での利用を確保しています。 デプロイメントはMicrosoft Azure上のRed Hat OpenShiftでインプロセスで実行され、プラットフォームの残りと水平に拡張し、フルSuite（IronPDF、IronOCR、IronXL、IronBarcode、IronQR、IronZIP、IronWebScraper、IronSecureDoc、IronPrint）を単一の商用パッケージとして固定する3年間のUnlimited Enterprise SaaS OEM契約で支えられています。

要約

  • 産業: 航空（商業旅客航空、国際線展開準備中の中東の旗艦航空会社）。
  • Iron 製品: Iron Suite（フルバンドル）、主要な製造用途のIronPDFと他のアジャセントワークフローで使用可能。
  • ワークフロー: Microsoft Azure上のRed Hat OpenShift上 for .NETマイクロサービス内での埋め込み、高ボリュームPDFドキュメント生成。
  • 見出しの成果: 初の国際サービスに間に合った単一ベンダーのドキュメントおよびデータスタック、Iron Softwareのソリューションチームと共同で設計されたスケーリングアーキテクチャ。
  • ライセンシングモデル: Iron Suite Unlimited Enterprise SaaS OEM、3年間のサブスクリプション、2028年5月に更新。

課題

この決定は、並行して進行中の3つの問題（ビジネス、技術、商業）に駆動されましたが、すべてが航空会社の開始ウィンドウをクリアする必要がありました。

ビジネスのプレッシャー: その航空会社は商業運用の初投入ならびに国際路線の展開準備を進めており、ツールの故障を吸収するための余裕はスケジュールにはありませんでした。 プラットフォームが生成するすべてのPDF（搭乗券、チケット領収書、手荷物タグ、マニフェスト、規制機関向けレポート）は直接乗客、地上ハンドラー、規制当局に送られます。 どのような欠陥でも、搭乗口、規制当局、顧客に影響し、経営陣および民間航空当局に可視化されるタイムラインがあります。 上に重ねられたのは、企業調達、法務審査、EULA交渉、そしてサウジアラビア王国特有の契約処理がすべて購入前にクリアされる必要があり、ライセンシングモデルは開発者ごと、ポッドごと、クラスターごとの費用が予想外に発生しないように航空会社のスケールに適応する必要がありました。

技術的な壁: 早期の評価では、コミットメント前に解決しなければならないパフォーマンス問題が明らかになりました。 PDFのレンダリングは、プラットフォームの他の部分と並行して、負荷に応じてコンテナを追加することでスケールしなければなりませんでした。 キャリアのエンジニアリングスタックは、.NETをプロダクションパスとして、Node.jsとPythonと一緒に使用しています。ライブラリファミリは、これらすべてに対応する必要がありました。 Microsoft Azure上のRed Hat OpenShiftとの互換性は、キャリアのクラウド内で直接検証されなければなりませんでした。

商業的な障壁: キャリアは、ライブラリを内蔵したアプリケーションを内部で操作し、パートナー向けチャネルで配信するためのOEMグレードの再配布権を必要としていました。 開発者ごとやデプロイメントごとの計量は、航空会社の規模では問題外でした。 コスト形状は、技術的な適合性と同様に重要でした。 法務審査では、EULA、保険、責任条項、KSA特有の税金処理が、社内外の顧問との複数ラウンドで取り扱われました。 オープンソースのPDFライブラリは、航空会社グレードのテンプレートに対するレンダリングの忠実性、商業サポートと責任保護、予測可能なパフォーマンスの3点で不十分でした。 マルチベンダーによる接続（別々のPDF、OCR、Excel、バーコードベンダー）が存在する場合、キャリアが管理する必要のあるEULAのレビューとサポート関係が増加してしまいます。

Iron Softwareが支援した点

なぜこのベンダーなのか

現在、キャリアのドキュメントパイプラインは、Azure上のRed Hat OpenShiftのマイクロサービスに直接組み込まれたIronPDFで運用されています。 レンダリングのワークロードは、プラットフォームの他の部分と並行して、追加のワーカーポッドを追加することでスケールします。 フルIron Suiteはライセンスされ、隣接するワークフローがオンラインになるごとに利用可能で、3年間のUnlimited Enterprise SaaS OEM契約が商業的な基準として設けられています。

単一のベンダーに統合するという決定は、一つの機能によって決まったものではありませんでした。 その代替案に駆り立てられたものでした。それは、別々のPDF、OCR、Excel、そしてバーコードベンダーを結合することが、EULAレビュー、再配布のリスク、そしてそれぞれが運用コストを伴うまさにそのスケールでのサポート関係を増加させるというものでした。Iron Suiteは、キャリアのプラットフォームモデルに一致する単一の商業契約のもとで、ドキュメントとデータのツールキット（PDF生成、OCR、スプレッドシート、バーコードとQRコード、ZIPパッケージ化、ウェブスクレイピング、安全なドキュメント、印刷）をすべてカバーします。

生の機能カバレッジを超える3つの基準が評価において重みを持ちました。

  • ランタイムの移植性。 .NETはキャリアの主な生産言語ですが、Node.jsとPythonは隣接するサービス向けに活発に評価されています。 Iron Suiteはすべてをカバーし、キャリアは、Node.jsとPythonのバインディングが通常は.NETの後約1か月後に新機能を受けることが事前に知らされています。
  • OpenShift-on-Azureの互換性。 キャリアが運用する特定のコンテナプラットフォーム内での動作が実証済みです。 Iron Softwareのソリューションチームがトライアル中にこれを確認しました。
  • エンゲージメントの質。 顧客のエンジニアと一緒に座って、動作するスケーリングデザインを生み出すベンダーは、公共のドキュメントを指し示すベンダーとは異なるパートナーシップを示唆します。

Ironが提供したもの

2025年1月中旬の3日間にわたり、Iron Softwareのソリューションチームは、キャリアのエンジニアと連携して、キャリアのOpenShift環境におけるIronPDFのリファレンスデザインを作成しました。 作業は、1月16日のアーキテクチャレビュー、1月17日から19日にかけての技術的連携と概念実証作業、そして1月20日に提供された完全なスケーリングアーキテクチャと技術ブロック図をカバーしました。 評価の際に指摘されたパフォーマンス問題は、構成調整とエンゲージメントが推奨したアーキテクチャ変更の組み合わせによって解決されました。 顧客は商業的完了前に解決を確認しました。

アーキテクチャが整った後の統合は簡単でした。 IronPDFは、キャリアの既存 for .NETサービス内にライブラリとしてインストールされました。 他のサービスはドキュメントをレンダリングする必要があるときに直接呼び出し、OpenShift上の追加ポッドに負荷が分散されます。 IronPDFがサービス内で動作するため、ドキュメントの内容がプラットフォームを離れることはありません。 セキュリティは、キャリア自身のAzureアカウント内に留まり、情報セキュリティレビューが簡略化され、調達プロセスから準拠質問のカテゴリ全体が削除されました。

エンゲージメントとタイムライン

エンゲージメント自体は高いタッチがありました。 専任の営業リーダーと、技術、商業、法的トピックを含む10以上のミーティング、Ironサポートとソリューションエンジニアリングによる迅速なエスカレーションが評価をスケジュール通りに進めました。 エンタープライズグレードのサポート（プライオリティキュー、迅速な応答時間、優先的なバグ修正）が、トライアル全体を通じて利用可能であり、現在も続いています。 キャリアは、将来的な状態として24/7サポートを望んでいました。 現在、カバレッジは24/5で、24/7の問題はIron Softwareによって活発に評価中です。

初めての接触から契約締結までの期間は約7か月（2024年10月から2025年5月22日）で、法務と調達の確認に時間がかかりました。 技術的な意思決定は締結前にほぼ完了していました。 システムは、2025年の後半のキャリアの国際ルート開始を支えるために間に合い、現在は商業運用を支えるために稼働中です。

ライセンスと調達適合

この契約は、Iron Suite Unlimited Enterprise SaaS OEMライセンスで、3年間のサブスクリプション、サポートとアップデートを含みます。 ここで"無制限"という言葉は多くの役割を果たします：開発者の人数、コンテナの数、トランザクション量すべてが再価格設定なしに拡張可能です。 OEM権は、ライブラリを内部アプリケーションやパートナー向けチャンネルに組み込むことをカバーします。

最初に答える必要があった特定の商業的質問は、OEMグレードの再配布と無制限使用のスケーリングでした。 キャリアは、複数のパートナー関係を通じて文書出力を出荷するホストされたプラットフォームを運営しています。 その使用は、外部SaaSの再配布ではなく、OEMとしてきれいに分類される必要があり、ライセンスモデルは、ポッドやクラスターごとのメータリングなしでマイクロサービスプラットフォームに対応する必要がありました。 両方が契約構造で対処されました：再配布権は明確に記述され、無制限使用モデルが開発者ごとまたは展開ごとのコスト形状を置き換えました。

法的手続きは、カレンダーが存在するところでした。 EULA、保険、契約上の補償、サウジアラビア特有の税務処理はすべて、Iron Softwareの法務チームとキャリアの社内及び外部顧問との間で複数のレビュープロセスが必要でした。 評価から商業終了までの7か月のタイムラインはその作業を反映しており、署名前に商業条件に両辺が一致して終了しました。

商業的には、この契約は、代替ベンダからのサーバーごと、開発者ごと、ポッドあたりのコストモデルを置き換えるためにキャリアが必要としていた固定された複数年の枠を提供しました。 高速で拡大する航空会社プラットフォームの生涯を通じてTCOを計画する企業の財務チームにとって、その構造は単一の製品価格ポイントよりも価値があります。

結果

特定の生産指標（p95の遅延、スループット、ポッド数、インシデントレート）は機密保持され、公開されたバージョンでは顧客が提供したものです。 エンゲージメントが生み出した方向性のある成果は具体的です。

ベンダーの統合。 文書生成、OCR、スプレッドシート処理、バーコードとQRコード、ZIPパッケージング、安全な文書処理、印刷すべてが、1つの商業契約の下で1つのベンダーのSDKを通じて現在実行されています。 かつては複数の別々のライブラリ購入（それぞれが独自のEULA、再配布モデル、サポート関係、更新サイクルを持つ）だったものが1つにまとめられました。

起動時から存在するスケーリングアーキテクチャ。 Iron Softwareのソリューションチームが2025年1月に作成したスケーリング設計は、購入前にパフォーマンスの問題を解決しました。 キャリアのプラットフォームには、現在その特定の環境に基づいてOpenShift設定でレンダリング負荷を処理するための文書化されたテスト済みのパターンがあります。

商業的な予測可能性。 固定された3年間の枠。 開発者、ポッド、およびトランザクションのための無制限使用権。 ライセンス計算はプラットフォームの成長から切り離されており、これにより高速スケーリングキャリアの核投資を保証する財務チームにとっての予測の不確実性がいくつか除去されます。

予定通りに納品された文書インフラ。 システムは2025年末のキャリアの初の国際サービス期間中に生産され、今日では商業ワークフロー全体で運用されています。 隣接するワークフローはライセンスされており、キャリアがオンラインで導入するに伴い活性化されるように設定されています：チェックインでのID文書処理のためのIronOCR、搭乗および手荷物のためのIronBarcodeとIronQR、安全な文書配信のためのIronSecureDoc。

キャリアのIron Suiteエンゲージメントは、一連の一致した決定に帰結します：ドキュメントとデータ表面全体をカバーする単一のベンダー、実際に高速スケーリング航空プラットフォームがどのように動作するかに合ったライセンスモデル、商業終了前に作動するスケーリング設計を作成したエンジニアリングエンゲージメント、およびプランを立てられる3年間の固定商業フロア。これを支える生産指標は機密保持されています。

もし同様の統合（大量文書生成、マルチランタイムスタック、コンテナ展開、厳格な企業調達）を評価している場合、Iron Softwareのソリューションエンジニアリングチームはまさにこの種の決定をカバーするアーキテクチャレビュコールを実施しており、トライアルライセンスは何も署名する前に検証可能なプロダクション対応です。