2.3.1 把架構視為交流工具

軟件架構是一張藍圖，IT系統的設計、構建、部署、維護及管理，都要依照這張藍圖來進行。很多利益相關者都想對系統架構有一個良好的理解，然而單單從某一個視角來切入系統架構，是無法滿足所有人的。由于不同的利益相關者可能有著不同的需求與期望，因此，我們需要從多個角度來觀察架構。

為了把架構的實質內容準確地告知利益相關者，我們需要從各種不同的角度來進行溝通。比如，在與業務的發起方進行溝通時，架構師一定要采用與業務有關的說法來交談，例如要清晰地闡明該架構是怎樣解決業務需求的。在與業務方面的利益相關者進行溝通時，架構師也要使他們確信：這個架構并不是那種原來已經嘗試過但卻沒能取得成功的架構。架構師所選取的表現形式，應該要能展示出這套架構為了滿足某些宏觀的業務用例，是怎樣把一個或多個ABB的能力結合起來的。這種表現形式（也就是觀察點，本章稍后將會詳述它）及展示形式，同時還要凸顯出架構藍圖的價值，并把這套藍圖視為整個系統得以設計和構建的基礎。架構藍圖的這種效用，按照業務術語來說，就叫做價值驅動力（value driver），我們最終需要依靠這種驅動力，來確保該架構能夠獲得足夠的投資，這些資金，至少要能夠使系統得以部署并穩定地進行運作。

架構的表現形式有很多種，技術團隊可以根據自身所處的技術領域選用適當的形式。比如：

應用程序架構師（application architect）需要理解系統的應用程序架構，需要專注于功能組件、組件的結構以及組件之間的依賴關系，也就是說，他們需要從功能架構的視角進行觀察。

基礎設施架構師（infrastructure architect）可能對服務器的拓撲結構、服務器之間的網絡連接狀況以及服務器中各個功能組件的排布狀況感興趣（然而他們所關注的問題并不局限于這些），也就是說，他們需要從操作架構的視角進行觀察。

業務流程的擁有者（business process owner）當然要了解架構所支持或加以自動化的各種業務流程，這些流程是通過對系統所提供的特性與功能進行編排而實現出來的，其實現方式，通常是把一個或多個業務組件所具備的各種能力加以協調。業務流程的擁有者所感興趣的這些問題，可以用靜態的業務組件視圖及動態的業務流程視圖來進行展示，也就是說，他們需要從業務架構的角度進行觀察。

針對架構問題進行有效的溝通，可以促使我們就正確的解決方案與方法展開有益的討論，并對各種方案進行分析及權衡，以做出相應的決策。這不僅可以確保利益相關者的意見受到關注，而且還能夠提升架構本身的質量。

我們要用各種方式與多位利益相關者進行溝通，使他們都能夠明白架構的價值，并且了解價值中與自己有關的那個方面，同時還要使他們積極參與架構的演化過程，這對架構是否能夠適當地延續下去，會起到很關鍵的作用。