SaaS賽道是一個超大賽道，足夠容納上萬家服務商，不太可能有哪個服務商能滿足所有場景，大部分SaaS服務商在某個垂直領域，提供差異化的產品和服務，SaaS產品大部分都是面向B端客戶，少部分面向C端客戶，本文主要講的B端SaaS產品，
B端SaaS產品的挑戰
B端SaaS產品為企業提供協同辦公的工具，幫助企業解決某類經營管理問題，核心價值在于增加收入、降本提效、管控風險，一般會按業務垂直或行業垂直來細分，業務垂直型的SaaS產品有CRM、人力資源、ERP、推廣營銷、財稅、OA等細分市場；行業垂直型的產品有零售、餐飲、旅游、教育、醫療、物流等細分市場，
B端SaaS產品有以下特點：
-
客戶是一個群體：B端SaaS產品為某個企業組織服務，一項業務目標通常需要由多名角色完成，例如，訂單履約流程，需要消費者、運營人員、倉儲人員、配送人員共同完成，產品幫助他們高效完成分工協作，
-
功能繁雜：由于B端SaaS產品涉及企業經營的方方面面，關聯的用戶角色多、業務流程長，反應到產品上，選單、界面、配置項特別多，復雜度遠高于C端產品，為了實作一項功能需求，往往會影響其他許多功能，需要進行全面的梳理，考慮各種極端情況，才能保證整體功能正常，
-
定制化功能：B端SaaS產品必然會有很多定制化需求，如果一味抗拒，很容易丟掉一些優質客戶，但如果大包大攬地接受，系統復雜度會指數級上升，高昂的研發維護成本將很難承受，所以如何處理好定制化需求，是一項非常艱巨的任務，
-
見效慢、難量化：由于B端SaaS產品的客戶是一個群體，產品上線新功能，通常是管理層先評估，能否在企業中適用，如果合適，才會組織一線人員，進行操作培訓，這樣一來一回，可能要2個月后才有客戶正式使用新功能，其次，業務見效的影響因素非常多，很多時候并非因為產品設計問題，
這些特點都會導致SaaS產品的軟體架構錯綜復雜，很容易嚴重腐化，演變成難以維護的“大泥球”，最終導致產品喪失競爭力，被市場淘汰，
SaaS產品的生產系統簡易模型
通過一個SaaS產品的生產系統的簡易模型，來描述SaaS產品的各個發展階段的狀態，
生產系統剛開始的狀態
業務越來越復雜，架構腐化嚴重，生產系統的狀態
期望的生產系統狀態
企業架構是什么？
企業架構既包括對企業的愿景、戰略、業務、組織的分析，又包括基于業務架構進行的應用系統分析與設計，是非常全面的架構設計框架，但很少有程式員了解過企業架構，更別提在軟體研發程序中應用企業架構，然而，當下消費互聯網的流量見頂，產業互聯網必將成為未來趨勢，企業架構也會越來越普及，誰先上船，誰就有了先發優勢，
企業架構的歷史
1996年，克林格.科恩法案頒布，美國聯邦政府立法，強制要求政府機構使用企業架構理論構建自己的IT系統，最重要的機構是國防部、財政部，這一舉措，直接讓政府機構的數字化水平，像坐上火箭般高速發展，
同一時間，大名鼎鼎的TOGAF也在猥瑣發育，它大量參考了政府機構的企業架構理論，沉淀出一套更加通用的企業架構方法論，
目前80%的福布斯排行榜前50名的企業，以及60％的美國500強企業，都在使用TOGAF理論改善自身的IT架構，
但是，目前中國各行各業對企業架構理論的理解和應用還處于非常初期的階段，
企業架構期望解決的痛點問題
資訊孤島：業務與IT技術存在資訊鴻溝，各業務域間存在資訊鴻溝，協作效率低下，
標準不一：業務概念非標準化，系統邊界劃分復雜混亂，技術標準不兼容，
靈活性差：新業務無法基于已有的解決方案和能力快速組裝上線，業務無法快速迭代創新，
企業架構的價值
認知框架的價值
有些人可能會問，認知框架能有什么價值？常見的價值不是新簽客戶數、客單價、銷售收入這些嗎？說的沒錯，這些都是最直觀的業務價值，但架構想創造的是更深層次的價值，并不是很直觀，
要說清楚認知框架的價值，首先要了解什么是認知負荷，認知負荷是專業的心理學理論，簡單來說就是，人腦的短時記憶和處理的資訊數是極其有限，一般人就2-3條資訊，牛掰點的4-5條，但是，長時記憶的容量幾乎是無限的，長時記憶就是我們積累的知識，知識以框架的形式存盤于長時記憶中，框架就是根據資訊元素的使用方式來組織資訊，它提供知識組織和存盤的機制，可以減少短時記憶負荷，
說人話就是，人腦的短時記憶和長時記憶，可類比為記憶體和硬碟，人腦的記憶體容量就芝麻點大，只能存盤2-3條資訊，但硬碟空間是無限的，為了提高人腦處理效率，就必須將資訊進行抽象，原來有30條資訊，抽象后就變3條了，這樣就能處理過來了，而抽象的框架就是我們要說的架構，
其實整個研發周期，真正在生產（敲代碼）的時間非常少，可能連20%都不到，產研團隊大部分時間都花在澄清資訊和認知資訊上，有了認知框架，能夠顯著降低整個團隊的認知負荷，進而極大地提升生產效率，
質量提升的價值
這個比較好理解，通過架構規劃和治理活動，可以有效提升整個軟體系統的質量屬性，
產品層面的質量屬性：
功能性：指軟體產品能夠提供正確的、符合預期的結果，能夠安全地保存資訊和資料，用戶權限與訪問權限匹配等，
易用性：指產品對用戶來說易理解、易學習、易操作，
技術層面的質量屬性：
穩定性：不容易出故障，出了故障也能快速恢復，
性能：軟體的回應時間符合預期，在極端場景下（例如高并發、大批量資料處理等），也能維持一定的性能水平，
可維護性：軟體容易修改，不會牽一發而動全身；容易除錯和修復bug；容易落地自動化測驗，
還有其他質量屬性，不一一列舉，
自我約束的價值
系統不做什么和能做什么同樣重要，就像成功的經驗需要固化下來，并規模化復制，成熟的認知框架也需要固化下來，并約束團隊，讓團隊在正確的路上行進，錯誤的路就別再嘗試了，例如，團隊A做了商品管理，其他團隊拿去用就行了，別再重復造輪子，最終導致一座座資料孤島，
可能有人會說，這會約束團隊創新吧？但創新和荒誕常常就一步之遙，這一步可能就是遵守最基本的約束規則，
企業架構的概念模型
本文主要參考TOGAF企業架構理論，但TOGAF的內容非常非常多，也常常被批評太“笨重”，不太可能應用到所有知識，這里介紹的已經是裁剪后的企業架構概念模型，保留最精華的內容，方便大家理解和實踐，
-
目標：指的是企業的宏觀業務目標或戰略，一般會依賴多個業務能力來實作，
-
業務專案：指的是長期的、持續性的業務專案，一般需要制定明確的經營計劃和財務預算，
-
業務能力：業務能力描述了企業目前能做什么或需要做什么，業務能力建模的關鍵點在于它定義了企業做什么，而不是如何做（由業務流程描述），業務能力獨立于組織架構、業務流程、資源，準確地說，這些業務要素是支撐企業的業務能力而存在的，以“招聘人才”為例，“招聘人才”包括人力部門（人力資源團隊）、業務流程（例如吸引、篩選、面試、雇用）和IT系統（例如招聘系統、人事系統），準確定義的業務能力是非常穩定的，在過去的幾十年中，招聘的流程、技術、模式發生了翻天覆地的變化，但“招聘人才”這項業務能力始終恒定存在，業務能力遵循高內聚、低耦合的特性，正是因為業務能力的這些特性，業務能力對構建IT架構提供了至關重要的幫助，圍繞業務能力構建的IT系統會具備更加穩定的結構，并易于擴展，
-
組織架構：想要深入理解企業的組織架構，是非常困難的一件事，因為大部分人都沒有實際經營過一家企業，更沒有參與設計過企業的組織架構，但組織架構屬于 B 端 SaaS 產品非常底層的架構，非常考驗架構能力，幾乎所有的業務場景都需要應用組織資料，背后反應的是企業決策層的經營戰略和財務戰略，因此需要掌握一定的企業管理知識和財務知識，如果能夠掌握組織架構的概念和要點，對設計好 B 端 SaaS 產品幫助巨大，
-
業務流程：是指為達成特定業務目標，由不同的角色分工完成的一系列活動，活動之間不僅有嚴格的先后順序限定，并且活動的內容、方式、責任等也都必須有明確的安排和界定，讓不同活動在不同崗位角色之間進行流轉與交接，業務流程對于B端產品的意義不僅在于對B端客戶業務的一種描述，更在于SaaS產研團隊對B端業務運營的理解和剖析，這種理解是對企頁澩的優化、對企業組織機構的優化以及對管理制度的一系列深入探究，只有真正理解業務流程，才能幫助B端客戶達成期望的目標：降低企業運營成本，提高市場需求的回應速度，爭取企業利潤的最大化，
-
應用系統：即應用系統的架構設計，它起到統一規劃、承上啟下的作用，向上承接了企業戰略目標和業務發展，向下規劃和指導各個IT組件的定位和功能定義，通常包括系統、容器、組件、代碼等元素的劃分規范，以及它們的定義、邊界和互動協議，
-
服務：應用系統間的互動協議，具備一定的服務功能，并且提供給外部使用，
-
IT組件：具體的IT技術組件，例如，mysql、kafka、虛擬機、es等，
-
提供方：提供和維護IT組件的人，一般是運維團隊，
-
技術類別：通過抽象IT組件的共性特征，對組件進行分類的方法，用于管理IT組件，
企業架構在SaaS中的應用場景
賦能企業數字化轉型是SaaS產品非常重要的發展方向，而數字化轉型最重要的一步，就是將企業的業務模式和商業模式從真實世界搬到數字世界，這需要對業務進行全量全要素的建模和采集，
企業架構在國外已經發展了二三十年，為什么又被重新提及，因為企業架構是一套非常優秀且在國外有大量成功案例的架構方法論，能夠顯著提高數字化的效率和質量，這樣說可能比較虛，我們以零售行業為例，列舉一些數字化水平低的經營痛點，
會員數字化水平低
-
門店與會員互動的渠道主要是個人微信號，個微限制較多導致大量會員流失，
-
門店會員缺乏觸達渠道，進店率低，由于疫情原因，會員招募逐年下滑，
-
會員被掌握在導購個人手上，隨著人才流失而流失，
-
會員資料沒有合理采集和使用，只能基于銷售資料或財務資料決策，單客價值挖掘效率低下，
渠道數字化水平低
-
線上線下交易履約流程沒有標準化，線上運營主要依賴外部人員，業務資料散落在各處，
-
渠道全鏈路資料無法收集，沒有數字化手段洞察消費者需求，不同渠道的商品布局規劃只能依賴經驗做決策，
-
渠道商對數字化認知低，前端用戶資料收集難，系統打通難，
煙囪式的系統架構
-
企業內部系統煙囪式發展，系統之間資料沒有打通，數字資產無法共享，無法相互連接，形成一座座資料孤島，完全沒有發揮出資料的價值，
-
建設IT系統非常燒錢，企業花了大把的投入，但缺乏企業自上而下的全域設計，對業務收益甚微，
總結
既然企業數字化轉型已是必然趨勢，掌握數字化這項武器是大部分企業的必經之路，企業數字化轉型不僅推動和加速SaaS發展，也是SaaS的巨大紅利，
當然企業數字化轉型肯定不是一件簡單的事情，道阻且長，既要循序漸進，也要掌握好的方法論，企業架構可能是需要重點關注的解題方法，
本文來自博客園，作者：湯師爺說，轉載請注明原文鏈接：https://www.cnblogs.com/tangshiye/p/16230200.html
轉載請註明出處，本文鏈接：https://www.uj5u.com/ruanti/469860.html
標籤：其他
上一篇：設計模式七大原則—里氏替換原則