从发展模式看SaaS服务的昨天、今天和明天
本文从SaaS的发展上分析了各种模式，并从一个全新的角度观察了Slack火爆的原因。
预先配置(on-premise) 时代
在预先配置时代，市场上只有 Microsoft，SAP 等几家通过提供了市场、销售、客户支持等一整套软件垄断了各个细分领域。对用户来说还没有 “我自己的软件栈” 这种说法。
SaaS 先驱
随着互联网深入人心，很多企业看到了 SaaS 模式的意义。第一批 SaaS 厂商获得了广泛认同，他们并没有提供全套的解决方案，而是提供了细分领域的解决方案，专注在该细分领域中满足用户的各种需求。
用户开始有了更多的选择。
第一次 SaaS 大爆发
随着 SaaS 的广泛应用，不同规模的企业都可以选择 SaaS，而SaaS 的技术门槛也逐渐降低，许多初创企业开始进入一些细分领域 SaaS 市场。和大型 SaaS 厂商相比，这些初创企业往往更专注于细分领域中的一小块，而且用户体验和界面也更加友好。
这个时候，用户才真正不得不思考他们的 SaaS 软件栈，以及他们应该怎么选择。
现在?
在几个主要的细分领域，都挤满了各种 SaaS 厂商。从大型厂商到中小型的，甚至微型 SaaS(即大型 SaaS 的一个插件或者扩展)，人们有成百上千种解决方案可以选择。
SaaS 软件栈中的软件越来越多，随之带来的问题也多了起来，软件的相互连接，数据迁移，栈的管理，工作流集成，自定义用户体验等问题逐渐困扰着用户。
为了解决这些问题，一些新的混合产品和方法自然而然诞生了。
细分领域的 SaaS 中心(SaaS Hubs)：它们专注于单个细分领域，把该细分领域的 SaaS 软件栈中的不同软件进行集中管理。
例子：市场营销领域的 Lytics，客户支持领域的 elev.io
分拆的 API：他们将 API 分层进行打包，而不是将整个产品进行打包，这样用户可以根据需求自定义自己的用户体验。
这对于构建内部产品，或者补充现有 SaaS 软件栈来说，是一个有趣的方法。我曾写过一篇关于这类产品的更详细的文章。
例子：市场营销领域的 Clearbits 和 客户支持领域的 supportive.io
客户数据层(Customer Data layer)：segment.io 是一个收集、管理、发送用户分析数据的单一中心(hub)。它是这样运作的，你将所有客户数据通过 javascript 标签 发送给 segment.io，segment.io 将数据发送回你在用的某个 SaaS 软件。通过将你的客户数据集中到单一的层，你可以无缝地迁移数据，连接不同细分领域的两个软件。
命令和提醒层(Command & notification layer)：当在你的 SaaS 软件栈中有许多应用时，你需要一个层来保证不用每次登陆就能接收到不同应用的提醒。 Slack 就是这样一个提醒层，你可以将你的 SaaS 软件接入 Slack 来直接获得提醒。Slack 还允许你直接在界面中执行命令，比如执行“/hangout” 命令会启动 Google hangout 程序。
附加说明
整合层(Transversal layer)
是的，我相信 segment.com 是对 SaaS 生态系统来说一个重要的产品(Slack 已经很大了)
是的，我相信更多附加的层还会出现，哪些层呢?很难预测，我也不知道( 探索，单点登录，安全?)
给 SaaS 厂商的结论
对 SaaS 厂商来说提供对相关的整合层之间的集成很重要(比如 segment 或者 Slack 集成)
你可能不喜欢客户可以点两下就从你的产品迁移到你的竞争对手产品中，但是客户并不这么想。如果你不允许客户这样做，客户可能一开始就不会选择你。
SaaS 中心 (SaaS Hubs)
这些中心可以仅仅是界面中心(elev.io 就是这样子) 或者提供了深度集成功能，就像 Lytics。中心的概念非常宽泛，人们可能同时用到很多个中心。
这些中心同样连接到整合层。Lytics 和 elev.io 同样有 segment.com 集成。
随着 SaaS 软件栈继续增长，还会有很多问题浮现出来，也会有越来越多的混合产品来解决这些问题，所以我估计未来几年一切都会发生变化。
本文作者：佚名
来源：51CTO