【編集部注】著者のPeter Yared氏はSaphoの創業者でCTO。以前はCBS InteractiveでCTO/CIOを務めた。
これまでアプリケーション開発はずっと危険に満ちていた：プロジェクトは肥大化し、高価につき、決してリリースされない。実装技術は ‐ サービス指向アーキテクチャ（SOA）からビジネスプロセス管理（BPM）に至るまで ‐ その肥大化と歩調を合わせる傾向にある。RedpointのTomasz Tunguzが最近指摘したようにSaaS（サービスとしてのソフトウェア）の成長は鈍化しており、次世代のアプリケーションは既存のアプリケーション同士を斬新な方法で新しいワークフローへと織り上げたものになる。
サービス、アプリケーション、およびフローの「マイクロウェーブ」
アプリケーション開発における「マイクロ」の傾向とは、複雑な問題に対して、ボトムアップにシンプルなソリューションを提供することに注力するといったものである。マイクロサービスは簡単に複数のシステムと統合することが可能であり、マイクロアプリは簡単なユーザーインターフェイスを提供することが可能で、そしてマイクロフローは利用者にシステムを横断してタスクを完了させることを可能にする。サービス、アプリケーション、およびフローのこの「マイクロウェーブ」3人組は、ソリューションを即座に提供するために、既存のシステムを斬新で有機的な手段を用いて織り上げる新しい方法を提供する。
マイクロサービス
アプリケーション間の相互運用性は、長い間アプリケーション開発における聖杯（追い求めても手に入れることができない価値あるもの）となっていた。1990年代のCORBA/IIOPといったヘビー級トップダウンアーキテクチャは、2000年代にはSOAへと進化した。SOAの実装には、企業全体への義務と協調の適用が必要とされた。SOAPなどのペイロード規格は、ヘビー級で特に認証層での非互換性に満ちていた。
GEのようなわずかな企業が、SOAを実装するための規律を持っていたが、ほとんどの企業にとって、SOAプロジェクトは、広く採用されることはなかった。たとえ成功した後でも、企業の世界の恒常的な売却や買収は、SOAをムービングターゲット（定まっていない目標）にし続けた。
ここ数年は、マイクロサービスが流行となっている。マイクロサービスとは、アトミックで、バックエンドで単一の操作（例えば顧客レコードを1件取得するといった）を実行するような自己完結型のものである。マイクロサービスへの最も一般的なインタフェースは、よく知られていて、非常に単純なJSON/REST/HTTPSパラダイムを採用している。認証も単純であり、一般的に使いやすいAPIキーを採用している。
マイクロサービスの美しさは、それらの作成、デプロイ、および共有が信じられないほど簡単なことだ。新規および既存のアプリケーションは、簡単に多数の外部ならびに内部のマイクロサービスを呼び出すことができる。否定論者たちは、マイクロサービスがまるでキノコのようにあまりにも簡単に増殖し、スケールしにくく共有や発見が難しいという点を正しく指摘している。しかし、これらは強引な技術によってではなく、各企業内のポリシーによって囲い込まれるべき問題である。
アプリ同士が有機的に通信することを簡単にすることによって、アプリ開発と展開方法の新世代が生み出され、そのことが企業とソフトウェアベンダー双方にとってアプリケーションの新世代を加速することをとても容易にしている。
マイクロアプリ
2008年にiOSとAndroidのアプリストアが発足して以来、モバイルアプリが多くの消費者のプライマリインターフェイスとして採用されてきた。利用可能なアプリケーションの過多で、消費者のデバイス上にアプリをインストールさせ、それを使い続けて貰うことはとても難しくなっている。それ故に、ベンダーが機能をアプリの中に山のように積み上げて既存の利用者を新しい機能で引きとめようとしたり、同時により多くのユーザーを惹きつけようとすることは、とてもありふれたやり方である。その結果、ネイティブアプリはますます肥大化し、ナビゲートするのが難しくなって来ている。
インテリジェントでコンテキストに敏感な「マイクロアプリ」のニューウェーブが、出現し始めている。マイクロアプリケーションをサポートするプラットフォームは、インタラクティブなSlackやFacebook Messengerのボットから、天候やフライトといったGoogleのインタラクティブな回答ボックスといったものまでを含んでいる。これらのマイクロアプリケーションは、通常は単一目的のもので、簡単なユーザーインタフェースとコンテキストを組み合わせて利用する。
Facebook Messengerのマイクロアプリはリッチなバブルとメニューで構成されている
マイクロアプリはHTMLに基づいており動的にロードされる。一般的にはアプリストアをバイパスし、SlackやFacebook Messengerといった既存のコミュニケーションツールへと直接ロードされるのだ。「ボット」が使う自然言語の側面には間違いなく抵抗がある。しかし、素早くマイクロアプリをメッセンジャーの中にロードしたり、結果を検索できたりする能力は、急速に勢いを増している。Facebook Messengerは特に、新しい機能を素早く統合しつつある、例えば動的なメニューやインタラクティブなユニットで、それを使えばシャツを買うことからビザの注文までが可能になる。
Slackの開発者リレーションのディレクターであるAmit Shevatは、マイクロアプリを一言で上手く表現してくれた：「それは1つのことを本当に上手に行わなければならない」。
マイクロフロー
ビジネスプロセスマネジメント（BPM）ツールは、組織がビジネスプロセスの自動化をトップダウンに実装するのに役立つ。それらは通常、非常に高価であり、デプロイにも長い時間がかかる。BPMツールは、人間とのインタラクションや機械間（MtoM）の転送を必要とする、長期間に渡るワークフローを管理する。
マイクロフローへ最初に進出したのは、IFTTTやZapierといった企業で、あるマシンから他のマシンへのデータ転送を扱う ‐ 例えばSalesforce上で締結された契約をZendeskへ送るといったようなものだ。これらのサービスには人気があるが、それらは牽引力と収入の上限に達している。例えばWorkatoといった新しい企業が、SaaS型システム間のMtoMワークフローを拡張しているが、それらは複雑さという点においてBPMソリューションと似通っていて、プログラマ向けのドメイン専用言語（DSL）を必要とする。
Slack内でのマイクロフロー
マイクロフローのための新たな可能性は、人間-機械インタラクションの場である。今やSlackやSkypeのようなメッセンジャープラットフォームが、リッチでインタラクティブなHTMLを通してユーザーがバックエンドと対話することを可能にしている。ユーザーがどのようにエンタープライズソフトウェアと対話するかについて再考するチャンスが存在しているのだ。
マイクロフローを使用すれば、複雑で扱いにくいレガシーシステムをバイパスして、ユーザーは承認などの単純なアクションを実行することができる。現代の労働者、特に若い労働者の最大の不満の一つは、長年に渡ってアップグレードされていないレガシーITシステムと対話することの困難さである。X世代（1960年代初頭-1970年代半ば生まれ）の労働者の多くが、どうしてそこら中にタイプライターがあるのだろうと訝しんだように、ミレニアル世代（1980年代半ばから2005年位までの生まれ）は、多くのグローバル2000で採用されている不必要に複雑で時代遅れのシステムに困惑しているのだ。
経営幹部や管理者でも、マイクロフローから便益を受けることが可能だ。例えばたまにしか使わないシステムにログインすることを要求する多数の承認を行う際などに。多くの企業が、経費管理などの機能のために複数のシステムを持っている。IT部門は恐らくシステムを統合する長期計画を有しているかもしれないが、マイクロフローは幹部たちに、単一のインターフェイスを通して複数のシステムと容易にインタラクトすることを可能にする。
マイクロフローは、典型的にはユーザと幾つかのタイプの対話を必要とするため、それらはモバイルデバイスやメッセンジャーの通知機能を最大限に利用することができる。このような単純で、簡単に使用できるマイクロフローは、より多くのマクロワークフローへ関係者たちを完全に巻き込むことを容易にする。
「マイクロウェーブ」の未来へ向かって
マイクロサービス、マイクロアプリ、そしてマイクロフローを相互に組み合わせることによって、次世代のアプリケーションを提供するための新しいパラダイムが提供される。私たちが過去の教訓から学び、マイクロ革命を「肥大化」させないことを願っている。
[ 原文へ ]
（翻訳：Sako）
一方、Fleetmaticsのサービスの既存顧客は、企業の広範な業務の一環に車両を常時運転する従業員を雇用している企業だ（Fleetmaticsの既存顧客にはTime Warner Cable 、DirecTVがいる）。
