統合の進化とミドルウェアの台頭

ずっと昔に遡って、Windows NT Server が一般的に使われるOSだったとき、筆者が所属していた会社では、Windows XPへの全社的な変更を検討していました。残念ながら簡単には実現せず、OSは長い間 Windows 2000のままでした。なぜでしょうか？原材料調達から出荷までの生産プロセス全体が SAP と Filemaker Pro の両方に接続されていたためです。

まず、コンサルタントに両方を統合するために必要な作業を依頼しました。ところが、GUI が Internet Explorer 6 で作成されていたので、統合/GUI とコンパチでない IE7を使用している Windows XP にアップグレードすることはできませんでした。この会社は、XPだけでなく SAP、Filemaker Pro の新しいユーザーライセンスを購入した上で、2回目のデータベース統合のために新たにコンサルタント料を支払い、最終的にXPに移行しましたが、非常に高い勉強代を払うことになってしまいました。これはコンパチ問題が絡んだ本当に高コストのカスタマイズ化の例ですが、このような当時広く使用されていた2つのアプリケーションを統合するのには、より良い、より安価な方法があったはずです。

ミドルウェアの効用

最近は製品とサービスの統合を可能にするミドルウェアが台頭してきて、複数のプロセスの自動化が期待されています。

ジョージア州のアトランタに本社を置く FWaaS プラットフォーム、OmniNet Inc. の創設者兼CEOである Andrew Bagrin 氏は次のように語っています。「ミドルウェアは多くのことを可能にした上に、もっと発展し、APIを公開したり、さらには直接製品を統合したりしました。以前は、電話システムをヘルプデスクのサポートシステムやCRMに統合することは、小さな仕事ではありませんでしたが、現在ではほとんどの主要な（低コスト）電話システムは ZenDesk、Salesforce、Hubspot などに簡単に統合できます。APIは、活用するにはまだ統合と開発に工数が必要で、コンサルタントが不要になるといった状況ではありませんが、すべての分野でよりアクセスしやすくなっており達成可能なレベルに近づいています。求められる内容が少し変化しているものの、コンサルタントの必要性はなくなってはおらず、統合の必要性の高まりによってむしろ増加していると思われます。」

統合の意義

「さまざまな製品とサービスを統合することで、業務の自動化が簡単に行え、誰もが自分の仕事がやりやすくなり、顧客を含むすべての人にとってはるかに心地良い環境を醸成することができます。」と、Bagrin 氏は話しています。

筆者はまた、ミドルウェアの台頭によってコンサルタントの誠実さが試されるようになったと感じています。2000年代初頭の統合では何千ドルものコストがかかり、手間や労力もかなり要しました。プロセスを自動化する最初の試みとして2つのアプリケーションを成功裏に統合できたとしましょう。このタスクのときに調査作業が完了しているので、2回目に類似の統合を達成するのはかなり容易になります。最初のタスクの必要な部分を修正すれば、実証済みの成果が得られます。もちろん、顧客が支払うのは全工程分に対して...という以前のシナリオは描きにくくなっています。現在、APIや統合メソッドのコストは固定されています。よく使われるアプリケーションが関与している場合は特にそうです。主流製品と互換性がある製品を提供することが最大の利益につながると判断した開発者も多く、事実上、多くの統合は無料になってきています。

どの製品も他製品と統合する能力を組み込んでいるとすると、セキュリティに対する脅威はないでしょうか？

統合のセキュリティについて

セキュリティの脅威はどこにでもあり、ミドルウェアも例外ではありません。プロセスの自動化のためにアプリケーション間でデータを共有すれば、当然、データ損失のリスクは高くなります。ただ、何が共有されているかをしっかり把握して、個人を特定できる情報（Personally Identifiable Information、PII）を安全に保護できれば、その限りではありません。

Bagrin 氏は、次のように説明します。「データを共有する標準的な方法があるという事実は、コンサルタントが手作業でデータを共有して統合しようとする場合に比べると、セキュリティ面でより優れていることを意味します。セキュリティに対する全体的な認識や体制は、以前と比べて格段に良くなっていますが、データ侵害の方もすごい勢いで増えているため、セキュリティが良くなったという感じはしません。これは、いわゆる統計の嘘です。昔はセキュリティが弱かったのですが、組織化された脅威の実行者はいませんでした。ハッカーたちがより狡知になってセキュリティの弱点を利用し始めると、データのセキュリティが向上しました。これに対応して、やがてハッカーたちは組織化され、さらに手の込んだ攻撃を仕掛けてくるようになりました。非常に強力なサイバーセキュリティと、非常に洗練されたサイバー犯罪とのいたちごっこが始まりました。皮肉なのは両者にとってお互いが必要だったということです。組織化されたサイバー犯罪がなかったら、今日のセキュリティははるかに劣悪だったでしょう。」

まさにその通りだと思います。洗練されたハッカー（地下室にこもるひ弱ないたずら者ではなく、ダークウェブでツールやエクスプロイトを購入する狡猾者）の存在が、サイバーセキュリティの継続的な改善を余儀なくしているという面があります。

すべてを統合？

すべてのプロセスが統合されるとしたら、安全は保てるのでしょうか？「すべての統合」は実現可能でしょうか？

「それは達成したい夢です。すべてを統合できたら素晴らしいのですが、統合を必要とせず、スタンドアロンとしての使用の方が優れているものは存在します。あるものを統合すると、ある程度までそれを公開することになり、セキュリティを弱めます。人は、より大きなニーズを満たす優れたものでない限り、複雑な統合ソリューションよりも使いやすい即座に解決するソリューションを選びがちです。業務の場合は自動化や統合が望ましいのは通例ですが、業務でない場合は考慮が必要です。統合され、コーヒー豆や砂糖の在庫が減ってきたら自動注文するようなコーヒーマシンは高くつきます。複雑過ぎるので、誰かが手動で管理する方がずっと簡単でしょう。」と、Bagrin 氏は述べています。

最後に、今日、システムの統合は、2つ以上のアプリケーション間でデータを共有できるミドルウェアのおかげで、20年前よりも明らかに簡単になりました。業務アプリケーションだけに限定されるものでもありません。統合できるかというより、何を統合するかという選択の問題になってきています。CMS、たとえば WordPress、を使っている場合、ショッピングカートを統合することを考えるかもしれません。使いたいニュースレター・プログラム、またはメーリングリストや実際にメンバーシップ・サイトとして機能する別のプラットフォームなどとの統合が検討されるでしょう。製品やサービスの購入に際しては、いくつかの機能を自動化する必要が出てきます。自動化機能は、プライベート会員のウェブサイトやニュースレターとも統合可能です。このようなことをすべて達成できるソリューションが必要です。そういったソリューションを持っていなかったら、あきらめて、販売とフォローアップのタスクを手動で１つずつ時間をかけて処理していくようにするしかないでしょう。

アプリケーション、ウェブサイト・プラットフォーム、APIを適切に組み合わせて統合するよう決めれば自動化できるであろうタスクを、手作業で処理することでどれだけの時間を無駄に使い続けますか？