當我們?nèi)ニ阉鳌凹軜嫛?，可以得到很多的架構圖片，比如組織架構、業(yè)務架構、數(shù)據(jù)架構、技術架構、安全架構、產(chǎn)品架構、部署架構等。

什么是架構，通常大家說架構一般指軟件架構，架構是指軟件的基礎結構，創(chuàng)造這些基礎結構的準則，以及對這些結構的描述。在這個定義基礎上，我們可以簡單理解為架構往往是對事物主體的結構性描述。

產(chǎn)品架構是對產(chǎn)品的一種結構性描述。一般可以包括前端系統(tǒng)、業(yè)務管理、運營管理、基礎支撐等子產(chǎn)品或子系統(tǒng)，并描述各個子產(chǎn)品或子系統(tǒng)之間的關聯(lián)關系。

在公司整體戰(zhàn)略之下，需要基于公司戰(zhàn)略等多種因素設計組織架構，組織架構影響業(yè)務架構，業(yè)務架構影響產(chǎn)品架構，產(chǎn)品架構影響技術架構。

從這個鏈條可以看出產(chǎn)品架構基于業(yè)務架構。做產(chǎn)品架構前，需要對業(yè)務架構有清晰的了解。

一、業(yè)務架構對產(chǎn)品設計的5個影響

業(yè)務架構是基于組織架構設計的，業(yè)務架構是把企業(yè)的業(yè)務戰(zhàn)略轉化為日常運作的渠道，業(yè)務戰(zhàn)略決定業(yè)務架構，它包括業(yè)務的運營模式、流程體系、組織體系、資源分布等內(nèi)容。

業(yè)務架構是一個比較專業(yè)的研究課題，技術人員一般對業(yè)務架構的關注度相對較低，更重視產(chǎn)品架構、技術架構。這里我們簡單示例什么是業(yè)務架構，這些架構事實上影響我們的產(chǎn)品架構設計，如下圖5-1就是其中一個業(yè)務架構設計的框架圖。

業(yè)務架構圖

業(yè)務架構對企業(yè)的收入模式、支出成本、客戶群體、客戶關系、需要的資源、關鍵活動，以及合作伙伴等進行設計說明。

業(yè)務架構對產(chǎn)品架構的影響，主要體現(xiàn)在以下幾個方面：

1. 系統(tǒng)參與角色

業(yè)務架構一般會明確用戶范圍;營銷端的參與人員，比如渠道商或代理商，大客戶銷售團隊等;運營端的參與人員，如售后、客戶成功等團隊;合作伙伴的參與，如第三方合作平臺等。每類角色按需設計對應的使用終端。

2. 系統(tǒng)運營流程

業(yè)務架構對運營流程有較明確的定義，如開戶、續(xù)費、注銷、變更、售前售后工單處理、庫存入庫出庫處理、合同流程、發(fā)票流程等。這些構成SaaS平臺的運營流程，是產(chǎn)品實現(xiàn)商業(yè)價值的重要手段，產(chǎn)品環(huán)節(jié)一般需要有相應的處理。

3. 核心價值

業(yè)務架構需要明確SaaS服務對客戶帶來的價值，這個價值往往需要通過產(chǎn)品端來呈現(xiàn)，業(yè)務架構的價值描述，很大程度上就是我們產(chǎn)品建設的側重點。

4. 周邊系統(tǒng)

業(yè)務架構中的合作伙伴、資源一定程度上體現(xiàn)出需要與產(chǎn)品交互的其他系統(tǒng)，這些“其他系統(tǒng)”可能是產(chǎn)品需要的一些基礎能力(如文字識別、計算能力等)、數(shù)據(jù)(權限數(shù)據(jù)、業(yè)務數(shù)據(jù))、流程(管理流程、運營流程)等 ，而這些能力需要合伙伙伴或者公司的現(xiàn)有資源中提供。這些周邊系統(tǒng)會以各種各樣的作用支撐著產(chǎn)品的運轉。

5. 計費模式

業(yè)務架構一般會說明收入和成本模型。收入的處理過程影響運營產(chǎn)品的設計，如公司在線下收款，可以產(chǎn)品只需要控制用戶賬號的可用狀態(tài)或有效期，如果是線上收款，就需要設計一套開通、續(xù)費的線上支付流程。有些SaaS產(chǎn)品還會涉及到收入和成本費用的攤銷，以配合財務工作的處理，也可能需要在產(chǎn)品中完成此類計算。

假如所在公司沒有清晰的業(yè)務架構，或者部分環(huán)節(jié)缺失怎么辦?如果可以引導，我們盡量引導業(yè)務部門完善相關的環(huán)節(jié)，但有些客觀情況是我們無法改變的，我們可以嘗試按照現(xiàn)有架構，收集梳理信息，做好整體的結構設計，確保具備可擴充能力，能夠滿足后續(xù)需求，再根據(jù)業(yè)務各環(huán)節(jié)成熟度設計產(chǎn)品架構，分階段去實現(xiàn)。

二、產(chǎn)品架構

SaaS產(chǎn)品架構的設計，可以考慮模塊化、漸進式設計。

2.1 模塊化設計

所謂模塊化是指降低業(yè)務間的耦合。低耦合、高內(nèi)聚是技術架構的重要設計原則，在產(chǎn)品端也非常值得借鑒。

模塊式化設計對于系統(tǒng)建模、技術實現(xiàn)、升級迭代、業(yè)務推廣都有很多幫助。模塊化設計也是對最小化場景(MVP)的一種有效支撐。

SaaS產(chǎn)品隨著公司的發(fā)展，業(yè)務范圍、功能都會越來越大，而客戶可能僅需要部分能力，如果功能間耦合太多，對客戶的功能選擇會增加限制;銷售政策制定起也會受到掣肘，無法靈活組合產(chǎn)品進行銷售，對業(yè)務推廣產(chǎn)生一定影響。

如何做好模塊化設計?

模塊化設計針對有獨立性、可復用的業(yè)務或功能進行抽取，包裝功能集合構成產(chǎn)品進行推廣使用，方便客戶根據(jù)需要進行產(chǎn)品組合，模塊化設計在傳統(tǒng)軟件中也非常重要。

(1)歸類與抽象

需要對相似的功能或者場景進行歸類然后抽象出來進行設計。在軟件設計領域，越是底層的東西越容易復用，越是偏向應用端的東西，越難以復用。比如構成一套軟件服務，可以有服務器硬件、應用服務中間件(比如數(shù)據(jù)庫等)、各種微服務、業(yè)務流程、外部入口等，這套軟件架構中，服務器硬件是處于架構底層，比較基礎且通用性很強;應用入口處于架構高層級，形式相對靈活，復用性較低。在產(chǎn)品端也是同理，基礎信息如人員、機構等屬于基礎信息，同一組織在不同系統(tǒng)中的結構大體一樣，復用性強，其次是各類業(yè)務流程，再其次是業(yè)務表單。

我們要做的產(chǎn)品模塊化設計，是針對不同用戶的需求，將完成某項業(yè)務的場景進行分析、歸類、抽象，抽取共性部分，做成可實現(xiàn)多種組合的產(chǎn)品形態(tài)。

(2)數(shù)據(jù)接口

系統(tǒng)一般由邏輯(算法)和信息兩部分構成，信息又分為內(nèi)容和數(shù)據(jù);邏輯是構建軟件功能的骨架，內(nèi)容和數(shù)據(jù)是血肉，其中以數(shù)據(jù)尤為重要。

假如要實現(xiàn)軟件模塊化且模塊之間相互獨立，必須要先拋棄邏輯(實現(xiàn)方法)，因為有邏輯就代表這兩個模塊誰也離不開誰，就不能稱之為獨立。

如果這兩個模塊必須要關聯(lián)在一起，但又不允許它們在邏輯上互相干涉，那么最好的辦法就是為它們內(nèi)部包含的數(shù)據(jù)進行抽象化，形成標準化接口，以數(shù)據(jù)調(diào)用的形式實現(xiàn)兩個模塊間的互相協(xié)作。

模塊化的一個特征是復用，在產(chǎn)品設計上復用意味著需要多種場景的結合，如果只有一個場景，就不是復用，在多個場景都需要使用的情況下，會有數(shù)據(jù)交互的需要，模塊化設計就是要把共性的東西抽取出來后，提供標準接口，進行數(shù)據(jù)交互，這個共性的東西，可以是字段，也可以是規(guī)則。

大家通常理解的SDK，也是模塊化設計的一種體現(xiàn)。模塊化的產(chǎn)品可以是一個界面、也可以是一個功能，還可以是一個子系統(tǒng)。

2.2 漸進式設計

SaaS產(chǎn)品是逐步迭代的，產(chǎn)品設計也不是一蹴而就的，需要有一個不斷前進的過程，漸進式設計非常契合SaaS產(chǎn)品。比如我們公司的產(chǎn)品，有企業(yè)客戶、集團客戶、代理商、平臺運營人員、售后人員等參與，在設計系統(tǒng)的過程中，并不是一上來就把所有的工作全部做完， 這樣周期太長，也不利于快速驗證產(chǎn)品和市場的匹配，所以產(chǎn)品架構自然而然也變成了一種漸進的設計過程。

漸進式設計需要盡量考慮未來產(chǎn)品的全局，以滿足后續(xù)產(chǎn)品擴展需要。

以我曾經(jīng)做過的一個產(chǎn)品舉例，產(chǎn)品的用戶可以分為三大類，關系如下圖：

產(chǎn)品關系示例

在產(chǎn)品架構的搭建過程中，我們在清楚有這些基礎結構以后，按照優(yōu)先級順序，逐步發(fā)展產(chǎn)品。如圖：

產(chǎn)品架構示例圖

首先搭建了企業(yè)版產(chǎn)品和簡單的運營管理系統(tǒng)，讓用戶能夠使用起來。后來隨著代理商力量的不斷計入，需要為代理商設計一套管理系統(tǒng)，代理商系統(tǒng)需要依賴于公司運營管理系統(tǒng)(公司運營早期就已經(jīng)有了代理商加入，運營管理平臺只有最簡單的代理商管理功能，能夠標記客戶所屬代理商，但并沒有去開發(fā)一套代理商管理系統(tǒng)，只是預留了擴展能力)。

隨著平臺的發(fā)展，用戶群體不斷擴大，集團客戶也在不斷增加，公司又基于企業(yè)版產(chǎn)品開發(fā)了集團版產(chǎn)品，滿足集團企業(yè)客戶的需要。

整個代理商管理系統(tǒng)和公司運營管理系統(tǒng)也跟隨迭代，從最初的企業(yè)注冊審核，到用戶工單管理、結算續(xù)費管理、再到增加集團版的開通管理流程及結算流程，歷時用了幾年時間。產(chǎn)品整體架構經(jīng)歷了多個版本的迭代，才逐步變成現(xiàn)在的體系，并且還在持續(xù)完善中。

產(chǎn)品架構的漸進式設計和最小化可用產(chǎn)品(MVP)并不是一回事，產(chǎn)品架構漸進式設計是為了產(chǎn)品穩(wěn)步推進并可擴展，先集中精力解決當前的重要需求和問題，所積累的產(chǎn)品成果，會成為將來產(chǎn)品發(fā)展的基礎，而不是MVP中表示的每一個過程都可能要重構。

MVP有一個非常生動的例子，用戶需求是一輛車，那么車的MVP及產(chǎn)品演進過程應該如下圖5-5的第二部分所示：

MVP的演進

產(chǎn)品架構的漸進式設計和產(chǎn)品的MVP有什么關系，其實是兩個維度的事情，產(chǎn)品架構漸進式設計是對現(xiàn)在業(yè)務的快速響應，以及對未來業(yè)務擴張的支撐。

MVP是在產(chǎn)品迭代過程中，在不同的階段，可能需要進行重構，上圖的例子，在一些產(chǎn)品論壇上都有闡述，這對MVP的解釋是很準確的，最小化可行產(chǎn)品需要做到每次迭代都是完整可用的，可用場景閉環(huán)是MVP的核心指標，這是產(chǎn)品從0到1的一種有效驗證方式，但我認為這種重構并不一定是必須的.

很多軟件產(chǎn)品在迭代的過程中，都是在原有基礎上的擴展，實際上產(chǎn)品架構具備彈性和擴展性，這是一名優(yōu)秀產(chǎn)品經(jīng)理需要具備的能力，畢竟任何歷史投入都是有成本的，優(yōu)秀的設計應該是在原有基礎上的擴展，而不是推倒重來。

B端產(chǎn)品在發(fā)展過程中，也比較注重產(chǎn)品和服務的結合，這個服務并不是指產(chǎn)品即服務，而是在早期產(chǎn)品不夠完善的情況下，部分環(huán)節(jié)通過線下服務來補充，這也是SaaS產(chǎn)品發(fā)展的一種形式。

產(chǎn)品架構大體能夠說清楚了系統(tǒng)間的關系，但對于具體的產(chǎn)品流程，產(chǎn)品架構圖是無法表達清楚的，還需要輔助系統(tǒng)流程圖進行說明。