本地部署時代 在軟體還是“本地部署（on-premise）”的時候，SaaS的版圖被大型玩家把持著，幾乎所有的垂直領域（營銷、支持、銷售、人力）都被微軟、SAP等大公司的解決方案占據。那時候的用戶並沒有什麼“軟體棧”可供選擇。 第一代SaaS冠軍 隨著互聯網的不斷普及，SaaS模式開始發揮作用。第一 ...
本地部署時代
在軟體還是“本地部署（on-premise）”的時候，SaaS的版圖被大型玩家把持著，幾乎所有的垂直領域（營銷、支持、銷售、人力）都被微軟、SAP等大公司的解決方案占據。那時候的用戶並沒有什麼“軟體棧”可供選擇。
第一代SaaS冠軍
隨著互聯網的不斷普及，SaaS模式開始發揮作用。第一代純“SaaS”玩家獲得了很好的發展勢頭。這些玩家提供的是垂直化而非水平化方案，滿足了垂直領域的諸多需求。
而用戶開始有了更多的選擇。
SaaS的第一次爆發
隨著SaaS日益普及（即企業無論大小都已準備好購買SaaS），以及技術門檻的不斷降低，許多垂直領域涌現出了許多新的玩家。這些新生初創企業往往聚焦於某個垂直領域的特定部分，相對於更大的老玩家提供了更好的UX/UI。
此時用戶開始需要思考自己的SaaS技術棧構成，需要想清楚應該用什麼。
現狀
主要的SaaS垂直領域已經開始變得人滿為患。從大型玩家到中小型甚至微型SaaS（只是更大型SaaS的“擴展”或“插件”的SaaS）層出不窮，用戶的選擇變得數以百計甚至數以千計。
隨著大家把越來越多的SaaS追加進自己的技術棧裡面，軟體互連、數據遷移、技術棧管理、工作流集成、體驗定製等工作的痛苦也與日俱增。
於是新的混合型產品/方案開始浮現，試圖填補這些缺口：
垂直型SaaS中樞（Vertical SaaS Hub）：把用戶技術棧的差異集中化，以便更好地進行管理。此類中樞會聚焦於某一個垂直領域上面。
例子：營銷域的 Lytics以及支持域的elev.io。
解綁定API（Unbundling API）：把SaaS打包為API而不是傳統的完型產品，這樣用戶可以根據自己的需求打造自己的UX。
這是一種開發“內部”產品（而不是重新發明輪子）或對現有技術棧做出補充的有趣辦法。
例子：營銷域的Clearbits以及支持域的supportive.io。
客戶數據層：segment.io是“收集、管理以及引導客戶分析數據的單一中樞”。工作機制：你把你所有的客戶數據（通過javascript標簽）傳給segment.io，後者再路由給你使用的SaaS。這樣你的客戶數據就集中化到一個層上面，可以無縫地從一個服務遷移到另一服務，或者通過同一客戶數據連接不同垂直領域的軟體。
命令&通知層：棧裡面有很多app的時候，有個問題是你希望不需要每次都要登錄上去才知道應用情況。Slack就是通知層（你可以把SaaS插入到Slack以便可以直接接收通知）。你還可以直接從Slack界面發起動作。就像命令行一樣。比方說“/hangout”發起Google hangout就是例子。
補充
橫向層
個人認為segment.com對於SaaS生態體系來說是一個重要產品（Slack已經很大了）
會有新的層出現，但是出現什麼樣的層未知（發現層？單點登錄層？安全層？……）
對於SaaS製造商的影響
對SaaS製造商來說，通過相關橫向層提供集成開始變得重要（比方說必要時進行細分領域或Slack集成）
客戶點擊2下就能夠從你的產品遷移到競爭對手那裡，你也許不喜歡這個，但客戶是不會在乎的。如果你不提供這項功能的話一開始他可能就不會選擇你。
SaaS中樞
這些中樞可以僅僅是“界面”中樞（參見 elev.io），或者提供與現有棧的更深層面的功能集成，像 Lytics。“中樞”的概念很寬泛，你可以同時使用幾個中樞。
這些中樞也會與橫向層進行連接。Lytics和elev.io都有跟segment.com的集成。
隨著技術棧的不斷壯大，會有越來越多新的混合產品和方案的出現。預期未來幾年一切都會不斷演進和變化。
推薦閱讀：
