企業級SaaS架構實戰(2):架構視圖與視角
企業級的SaaS系統涉及的利益干系人眾多,那么該如何將其做好分類,便于快速獲取相應信息?本文將介紹SaaS架構視圖與視角,便于你了解相關內容,更好展開工作。
把企業級SaaS系統架構描述清楚,是一項極其復雜的工作。
因為企業級SaaS系統涉及的利益干系人眾多,例如:客戶、產品經理、研發、銷售、運營、管理層等等。由于背景不同,認知不同,每個人看待它的角度、方法都各不相同。
為了控制復雜度,我們需要設計一整套架構描述物,并且為它們做好分類和定義,讓每種架構描述物都有自己的側重,讓每個利益干系人都能快速獲取關注的信息。
為了達成這個目標,首先需要理解視圖與視角的概念。
一、架構的視角
什么是視角?大白話就是你站在什么地方看。
我們以城市系統為例,你站在城市的某條馬路上,能看到什么?能看到幾座樓房,幾排樹木,幾條大馬路,熙熙攘攘的一些人。但是你站在飛機上看,能看到什么?能看到一片一片的樓盤,能看到群山,能看到江河湖海。所以,你能看到什么和你站在什么地方看有很大關系,同時也會影響你看事物的粒度。
如果把視角比作一個坐標點,那它需要一套坐標系,坐標系通常有4個維度:廣度、深度、視圖類型、時間。
- 廣度是指看待事物的寬度,以業務流程為例,根據出發點不同,有時需要看一個部門內的流程,有時需要看多個部門的協作流程,有時需要看端到端跨所有部門的流程。
- 深度是指看待事物時,要到達哪個細節層次,例如看業務流程,需要看到組織級、部門級、還是某個崗位的具體操作步驟??窜浖到y,需要看到系統級、模塊級、還是一行行的代碼。廣度和深度一般是相互影響的,如果看待事物的廣度越寬,那么層次就會越抽象,這和組織架構的設計也是相輔相成的,一般高層管理者看問題非常全面,但對細節不關注,一線執行人員,對問題的細節非常了解,但視角卻非常窄。
- 視圖類型是為利益干系人量身打造的一組關注點的集合,下文中會詳細介紹。
- 時間維度比較好理解,就是看待事物的時間點,過去、現在、還是未來。
二、架構視圖
什么是視圖?大白話就是你想看到什么。
視圖是為利益干系人量身打造的一組關注點的集合。
同樣以城市系統為例,想要趕早高峰的上班族,他的關注點是哪條路線最快,因此他需要一副地鐵公交路線圖;想要租房的租客,他的關注點是公司附近有哪些小區,租金多少,因此他需要一副出租房源圖;想要疏通下水道的工人,他的關注點是下水道是怎樣排布的,因此他需要一副下水道的排布圖。
同一個城市系統,不同角色的關注點是完全不一樣的,想要獲取的信息也是完全不一樣,如果把所有信息雜糅在一起,不做視圖隔離,導致的結果就是信息太龐雜,每個人都很難獲取想要的信息。
同理,不同干系人看待軟件系統的關注點也是迥然不同的,為了把不同人的關注點區分開,誕生了很多軟件視圖的分類方法,比較著名的有“4+1”視圖,TOGAF的業務架構、應用架構、數據架構、技術架構等視圖分類法。
企業級SaaS系統的視圖可分為:商家業務架構,SaaS業務架構,應用架構,數據架構,技術架構。其中業務架構是靈魂,應用架構,數據架構,技術架構都是支撐業務架構而存在的,這三者也統稱IT架構。
商家的業務架構s:為了實現企業的業務戰略,企業將自身業務結構化表達為全面的、多維度的抽象模型,包括:業務能力、端到端的價值交付、信息和組織結構,它們之間的關系,以及它們與戰略、產品、策略、項目執行、利益干系人之間的關系。
這里多了個“s”,并不是打錯,代表復數的意思,由于SaaS軟件需要服務數量龐大的B端客戶,這些客戶可能有多種業態、不同規模、不同行業,這意味著它不能只分析一家商家的業務架構,而需要分析多種業態下商家的業務架構,這也是SaaS系統設計復雜的原因之一。
SaaS的業務架構:其實SaaS企業與企業客戶的業務架構定義是一樣的,不同的是細節內容,例如:零售企業賣的產品主要是實物商品,而SaaS企業賣的產品是SaaS軟件服務。業務模式上,兩者也有非常大的區別。
- 應用架構:基于業務架構,設計出應用系統的層次結構,包括系統、應用、模塊、組件等構件的劃分規范,它們的定義、邊界、相互間的交互協議,以及它們和業務活動的關系。
- 數據架構:數據架構描述了一系列的模型、策略、規則、標準,它們決定數據如何獲取、如何存儲、如何分布、如何集成,以及數據如何在系統和組織中使用。數據架構是企業架構中非常重要的一塊架構領域,通常包括3個架構過程,概念模型設計(設計業務概念模型)、邏輯模型設計(設計模型間的邏輯關系與自身屬性)、物理模型設計(設計數據的技術實現細節)。
- 技術架構:技術架構描述了一系列的可部署的軟件包、硬件能力,以及它們之間的協作關系,通過它們可以支撐起企業對業務、數據、應用服務的需求,它們包括但不限于IT基礎設施、中間件、網絡、通信設施、運算能力、硬件標準等。
總結
通過視圖與視角,我們可以分離關注點,將復雜問題進行拆解,讓每個局部的復雜度控制在一個可以接受的范圍。
同時,團隊有了統一的認知坐標系,進一步促成了業務標準化,以業務標準化為基礎,通過分離不變點與變化點,提煉出可復用的組件,快速響應業務需求變化。
本文由 @湯師爺 原創發布于人人都是產品經理。未經許可,禁止轉載。
題圖來自Unsplash,基于CC0協議。
該文觀點僅代表作者本人,人人都是產品經理平臺僅提供信息存儲空間服務。
- 目前還沒評論,等你發揮!