SaaS の成功は、企業がコモディティ化されたビジネス プロセスを識別し、ソフトウェアにカプセル化できることに大きく起因しています。 企業内のネットワーク チームやインフラストラクチャ チームにも同じことが当てはまります。
SaaS (Software as a Service) は、今日の「クラウド」市場の中で最大の市場です。 IaaS(AWS、Azure、Google Cloud など)に対する期待にもかかわらず、採用率と継続的な成長の点では、SaaS が他のすべての形式の「クラウド」をはるかに上回っているのが現実です。
そして、それは止まる気配を見せていない。 2016 年初頭の世論調査では、SaaS の継続的な爆発的な増加が示され、回答者によると、IT 部門で正式にサポートされている SaaS アプリの数はわずか 1 年で 50% 増加し、2015 年の 8 個から 2016 年には 12 個に増加したとのことです。 報告書では、その数は再び増加し、2017年には17に達すると予測している。
「クラウド」が登場して 10 年が経過していることを考えると、従来はかなり標準的なapplicationsと考えられていたものの採用率としては、かなり印象的な数字です。 CRM、ERP、CMS、生産性関連のオフィススイートやファイル共有サイトについてお話します。
SaaS とインフラストラクチャの自動化とがどう関係するのか疑問に思われるかもしれません。 結局のところ、これはリンゴとステーキです。 ネットワークのプロビジョニングとスケーリングの自動化は、SaaS とはまったく異なります。
ただし、ある意味そうなのだが。 少しお待ちください。説明します。
すべての SaaSapplicationsに共通するテーマの 1 つは、機能のコモディティ化です。 ファイル共有のためのドラッグ アンド ドロップは、デスクトップでネットワーク上の共有フォルダーを使用する場合でも、ブラウザーベースのインターフェースを使用する場合でも、ファイルを共有するための非常によく理解されているパラダイムです。 ドキュメントやプレゼンテーション、さらにはコンテンツの公開でも同様です。 X または Y を実行する方法を定義する、かなり明確に定義されたプロセスがあり、インターフェイスが Web ブラウザーであるかスタンドアロン アプリであるかによってプロセスが実際に変わることはなく、アイコンとインターフェイスだけが変わります。
多くのビジネス機能も高度に標準化(コモディティ化)されています。 顧客サービス担当者 (CSR) がお客様の非常に重要な電話に応答する際に従うプロセス (実際、彼らは皆、重要な電話であると断言しています) は、やり取りする相手が誰であっても、ほぼ同じである可能性が高いです。 ケーブル会社や小売業者に注文について電話すると、かなり標準化された体験が得られます。 しかし、私の言葉だけを鵜呑みにしないでください。Harvard Business Review (2005 年) に掲載された素晴らしい記事では、このプロセス標準化の収束について論じられており、その後すぐに、現在「SaaS」として知られる現象につながりました。
標準プロセスにより、プロセス機能のアウトソーシングも容易になります。 プロセスを効果的にアウトソーシングするには、組織はコストに加えて 3 つの点を評価する手段が必要です。 まず、外部プロバイダーの一連のアクティビティとその流れについて説明します。 たとえば、原価計算や人事福利厚生管理が具体的に何で構成されるかについて企業は合意に達していないため、購入者とプロバイダーの間でどのようなサービスが実行されるべきなのかは依然として不明確です。 したがって、組織は、アウトソーシングされたプロセスについて話し合う際に簡単かつ効率的にコミュニケーションできるように、プロセス アクティビティに関する一連の標準を必要とします。 これらのプロセスアクティビティとフローの標準は、さまざまなビジネスや業界で登場し始めています。 いくつかは、800 社を超える企業が加盟するサプライチェーン協議会などのプロセス グループの努力の結果です。
プロセスが標準化(コモディティ化)されると、それをコード化して、販売可能なフロントエンドを追加するのが非常に簡単になります。 そして、初期の SaaS プロバイダーがスターダムにのし上がるのに貢献したのは、こうしたビジネス機能の根本的なコモディティ化だったと私は考えています。 基本的なデータ モデルとインターフェイスを使用すると、プロセスを顧客のニーズに合わせて最小限のカスタマイズを簡単に提供できました。 出来上がり。 すぐに成功しました。
次に、これをインフラストラクチャとネットワークに適用してみましょう。 プロビジョニング、管理、スケールに関連するプロセスは、applications間で非常にコモディティ化されているため、ネット オペレーターは必要なコマンドを眠っている間に入力できます。 唯一の違いは、ポート、IP アドレス、ルートなどのアプリケーション固有の変数です。 これらは、審査委員会が考える必要がないため、変更を歓迎する変更です。 「ああ、そのアプリにファイアウォール ルールを追加するんですね。承認しました。」
これらを実行するためにネット オペレーターに要求される注意と同様に、これらを承認する際にはほとんど考慮する必要がありません。これは、すでに何百回も実行されており、プロセスは常に同じであり、誰もが何が起こっているかを知っているからです。 一貫性があり、予測可能で、繰り返し可能です。
承認された。
これらは、自動化とオーケストレーションに適した、IT 内部のコモディティ化されたプロセスです。 自動化への投資によるビジネス価値をすぐに証明したい場合、これらは最適な出発点です。 そのコモディティ化されたプロセスの上にインターフェースを構築し、現在使用されている手動の方法の代わりにそれをプロセスに組み込みます (統合)。 出来上がり。 プロセスの実行コストが削減され、さらに、次の変更管理委員会の会議を待つ必要がないため、プロセスが速くなります (実際には、会議をスキップできる可能性があり、それ自体が利点のようなものです)。
はい、時間とおそらくお金(そしておそらくツールとトレーニングへの投資)が必要ですが、短期間のコストは長期的には報われるでしょう。 時間のかかるコモディティ化されたプロセスを自動化することで、エンジニアやアーキテクトが他のプロジェクトに取り組むことができるようになります。 変更管理委員会によって自動的に承認される可能性が低いプロジェクト。
SaaS が勝利するのは、ビジネスを検討し、共通のプロセスを理解し、それをより簡単かつ迅速に操作する方法を提供するときです。 それは 2006 年にも当てはまり、今日でも当てはまります。 インフラストラクチャの自動化の取り組みについても同様です。 一般的なプロセスを見つけて、それをより簡単かつ迅速に操作する方法を提供します。これは、「エンド ユーザー」にとっても他のエンジニアにとっても役立ちます。